Current Internet-Drafts This summary sheet provides a short synopsis of each Internet-Draft available within the "internet-drafts" directory at the shadow sites directory. These drafts are listed alphabetically by working group acronym and start date. IPv6 over Low power WPAN (6lowpan) ---------------------------------- "Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN)", Zach Shelby, Samita Chakrabarti, Erik Nordmark, 24-Oct-11, The IETF 6LoWPAN working group defines IPv6 over Low-power Wireless Personal Area Networks such as IEEE 802.15.4. This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly follow traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non-transitive wireless links. The traditional IPv6 link concept and heavy use of multicast make the protocol inefficient and sometimes impractical in a low power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, addressing mechanisms and duplicate address detection for 6LoWPAN and similar networks. The document, thus updates RFC 4944 to specify the use of the optimizations defined here. "Problem Statement and Requirements for 6LoWPAN Routing", Eunsook Kim, Dominik Kaspar, Carles Gomez, Carsten Bormann, 20-Nov-11, 6LoWPANs are formed by devices that are compatible with the IEEE 802.15.4 standard. However, neither the IEEE 802.15.4 standard nor the 6LoWPAN format specification define how mesh topologies could be obtained and maintained. Thus, it should be considered how 6LoWPAN formation and multi-hop routing could be supported. This document provides the problem statement and design space for 6LoWPAN routing. It defines the routing requirements for 6LoWPAN networks, considering the low-power and other particular characteristics of the devices and links. The purpose of this document is not to recommend specific solutions, but to provide general, layer-agnostic guidelines about the design of 6LoWPAN routing, which can lead to further analysis and protocol design. This document is intended as input to groups working on routing protocols relevant to 6LoWPAN, such as the IETF ROLL WG. "Transmission of IPv6 Packets over Bluetooth Low Energy", Johanna Nieminen, Basavaraj Patil, Teemu Savolainen, Markus Isomaki, Zach Shelby, Carles Gomez, 14-May-12, Bluetooth Low Energy is a low power air interface technology defined by the Bluetooth Special Interest Group (BT SIG). The standard Bluetooth radio has been widely implemented and available in mobile phones, notebook computers, audio headsets and many other devices. The low power version of Bluetooth is a new specification and enables the use of this air interface with devices such as sensors, smart meters, appliances, etc. The low power variant of Bluetooth is commonly specified in revision 4.0 of the Bluetooth specifications and commonly refered to as Bluetooth 4.0. This document describes how IPv6 is transported over Bluetooth Low Energy using 6LoWPAN techniques. IPv6 Maintenance (6man) ----------------------- "IPv6 UDP Checksum Considerations", Gorry Fairhurst, Magnus Westerlund, 23-Dec-11, This document examines the role of the UDP transport checksum when used with IPv6, as defined in RFC2460. It presents a summary of the trade-offs for evaluating the safety of updating RFC 2460 to permit an IPv6 UDP endpoint to use a zero value in the checksum field as an indication that no checksum is present. This method is compared with some other possibilities. The document also describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations. It concludes that UDP with a zero checksum in IPv6 can safely be used for this purpose, provided that this usage is governed by a set of constraints. "Distributing Address Selection Policy using DHCPv6", Arifumi Matsumoto, Tomohiro Fujisaki, Jun-ya Kato, Tim Chown, 21-Feb-12, RFC 3484 defines default address selection mechanisms for IPv6 that allow nodes to select appropriate address when faced with multiple source and/or destination addresses to choose between. The RFC 3484 allowed for the future definition of methods to administratively configure the address selection policy information. This document defines a new DHCPv6 option for such configuration, allowing a site administrator to distribute address selection policy overriding the default address selection policy table, and thus control the address selection behavior of nodes in their site. "The Line Identification Destination Option", Suresh Krishnan, Alan Kavanagh, Balazs Varga, Sven Ooghe, Erik Nordmark, 9-Mar-12, In Ethernet based aggregation networks, several subscriber premises may be logically connected to the same interface of an edge router. This document proposes a method for the edge router to identify the subscriber premises using the contents of the received Router Solicitation messages. The applicability is limited to broadband network deployment scenarios where multiple user ports are mapped to the same virtual interface on the Edge Router. "Duplicate Address Detection Proxy", Fabio Costa, Xavier Pougnard, Li Hongyu, Jean-Michel Combes, 8-Mar-12, The document describes a mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-multipoint architecture with "split-horizon" forwarding scheme. Based on the DAD signalling, the first hop router stores in a Binding Table all known IPv6 addresses used on a point-to-multipoint domain (e.g. VLAN). When a node performs DAD for an address already used by another node, the first hop router replies instead of this last one. "UDP Checksums for Tunneled Packets", Marshall Eubanks, Phil Chimento, 12-Mar-12, This document provides an update of RFC 2460[RFC2460] in order to improve the performance of IPv6 in an increasingly important use case, the use of tunneling to carry new transport protocols. The performance improvement is obtained by relaxing the IPv6 UDP checksum requirement for suitable tunneling protocol where header information is protected on the "inner" packet being carried. This relaxation removes the overhead associated with the computation of UDP checksums on tunneled IPv6 packets and thereby improves the efficiency of the traversal of firewalls and other network middleware by such new protocols. We describe how the IPv6 UDP checksum requirement can be relaxed in the situation where the encapsulated packet itself contains a checksum, the limitations and risks of this approach, and provides restrictions on the use of this relaxation to mitigate these risks. "Neighbor Unreachability Detection is too impatient", Erik Nordmark, Igor Gashinsky, 12-Mar-12, IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. That function is very useful when a host has an alternative, for instance multiple default routers, since it allows the host to switch to the alternative in short time. This time is 3 seconds after the node starts probing by default. However, if there are no alternatives, this is far too impatient. This document specifies relaxed rules for Neighbor Discovery retransmissions that allows an implementation to choose different timeout behavior based on whether or not there are alternatives. "Processing of IPv6 "atomic" fragments", Fernando Gont, 1-Feb-12, The IPv6 specification allows packets to contain a Fragment Header without the packet being actually fragmented into multiple pieces. Such packets typically result from hosts that have received an ICMPv6 "Packet Too Big" error message that advertises a "Next-Hop MTU" smaller than 1280 bytes, and are currently processed by some implementations as "fragmented traffic". Thus, by forging ICMPv6 "Packet Too Big" error messages an attacker can cause hosts to employ "atomic fragments", and then launch any fragmentation-based attacks against such traffic. This document discusses the generation of the aforementioned "atomic fragments", the corresponding security implications, and formally updates RFC 2460 and RFC 5722 such that fragmentation-based attack vectors against traffic employing "atomic fragments" are completely eliminated. "Representing IPv6 Zone Identifiers in Uniform Resource Identifiers", Brian Carpenter, Robert Hinden, 17-Feb-12, This document describes how the Zone Identifier of an IPv6 scoped address can be represented in a Uniform Resource Identifier that includes a literal IPv6 address. It updates RFC 3986 and RFC 4007. "Default Address Selection for Internet Protocol version 6 (IPv6)", Dave Thaler, Richard Draves, Arifumi Matsumoto, Tim Chown, 15-May-12, This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification. This document obsoletes RFC 3484. "Transmission of IPv6 over MS/TP Networks", Kerry Lynn, Jerry Martocci, Carl Neilson, Stuart Donaldson, 12-Mar-12, MS/TP (Master-Slave/Token-Passing) is a contention-free access method for the RS-485 physical layer that is used extensively in building automation networks. This document describes the frame format for transmission of IPv6 packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks. "Enhanced Duplicate Address Detection", Rajiv Asati, Hemant Singh, Wes Beebee, Eli Dart, Wesley George, Carlos Pignataro, 10-Apr-12, Appendix A of the IPv6 Duplicate Address Detection (DAD) document in RFC 4862 discusses Loopback Suppression and DAD. However, RFC 4862 does not settle on one specific automated means to detect loopback of Neighbor Discovery (ND of RFC 4861) messages used by DAD. Several service provider communities have expressed a need for automated detection of looped backed ND messages used by DAD. This document includes mitigation techniques and then outlines the Enhanced DAD algorithm to automate detection of looped back IPv6 ND messages used by DAD. For network loopback tests, the Enhanced DAD algorithm allows IPv6 to self-heal after a loopback is placed and removed. Further, for certain access networks the document automates resolving a specific duplicate address conflict. "A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)", Fernando Gont, 18-May-12, This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that addresses configured using this method are stable within each subnet, but the Interface Identifier changes when hosts move from one network to another. The aforementioned method is meant to be an alternative to generating Interface Identifiers based on IEEE identifiers, such that the benefits of stable addresses can be achieved without sacrificing the privacy of users. IPv6 Site Renumbering (6renum) ------------------------------ "IPv6 Enterprise Network Renumbering Scenarios and Guidelines", Bing Liu, Sheng Jiang, Brian Carpenter, 6-Feb-12, This document analyzes enterprise renumbering events and describes the best current practice among the existing renumbering mechanisms. According to the different stages of renumbering events, considerations and best current practices are described in three categories: during network design, for preparation of renumbering, and during a renumbering operation. A gap inventory is listed at the end of this document. "IPv6 Site Renumbering Gap Analysis", Bing Liu, Sheng Jiang, Brian Carpenter, Stig Venaas, 12-Mar-12, This document briefly introduces the existing mechanisms could be utilized by IPv6 site renumbering and envisions the effort could be done. This document tries to cover the most explicit issues and requirements of IPv6 renumbering. Through the gap analysis, the document provides a basis for future work to identify and develop solutions or to stimulate such development as appropriate. The gap analysis is presented following a renumbering event procedure clue. Application Bridging for Federated Access Beyond web (abfab) ------------------------------------------------------------ "A GSS-API Mechanism for the Extensible Authentication Protocol", Sam Hartman, Josh Howlett, 9-Apr-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 EAP mechanism. Through the GS2 family of mechanisms, these protocols also define how Simple Authentication and Security Layer (SASL, RFC 4422) applications use the Extensible Authentication Protocol. "Name Attributes for the GSS-API EAP mechanism", Sam Hartman, Josh Howlett, 12-Mar-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 and Profiles for SAML", Josh Howlett, Sam Hartman, 12-Mar-12, This document specifies a RADIUS attribute, a binding and two profiles for the Security Assertion Mark-up Language (SAML). The attribute provides RADIUS encapsulation of SAML protocol messages, while the binding describes the transport of this attribute, and the SAML protocol messages within, using RADIUS. The profiles describe the application of this binding for Abfab authentication and assertion query/request. The SAML RADIUS attribute and binding are defined generically to permit application in other scenarios, such as network access. "Application Bridging for Federated Access Beyond web (ABFAB) Use Cases", Rhys Smith, 21-Feb-12, Federated authentication has so far been typically associated with Web-based services, but there is growing interest in the application of federated authentication for non-Web services. The goal of this document is to document a selection of the wide variety of contexts whose user experience could be improved through the use of technologies based on the ABFAB architecture and specifications. "Application Bridging for Federated Access Beyond Web (ABFAB) Architecture", Josh Howlett, Sam Hartman, Hannes Tschofenig, Eliot Lear, 10-Mar-12, 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 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. ADSL MIB (adslmib) ------------------ "xDSL multi-pair bonding (G.Bond) MIB", Edward Beili, Moti Morgenstern, 12-Mar-12, This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets. This document proposes an extension to the Interfaces Group MIB with a set of common objects for managing multi-pair bonded Digital Subscriber Line (xDSL) interfaces, defined in ITU-T recommendations G.998.1, G.998.2 and G.998.3. The MIB modules specific to each bonding technology are defined in G9981-MIB, G9982-MIB and G9983-MIB respectively. "xDSL multi-pair bonding using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB", Edward Beili, 12-Mar-12, This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP based internets. This document proposes an extension to the GBOND-MIB module with a set of objects for managing multi-pair bonded xDSL interfaces using Time-Division Inverse Multiplexing (TDIM), defined in ITU-T recommendation G.998.3. "ATM-Based xDSL Bonded Interfaces MIB", Edward Beili, 12-Mar-12, This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP based networks. This document proposes an extension to the GBOND-MIB module with a set of objects for managing ATM-based multi-pair bonded xDSL interfaces, defined in ITU-T recommendation G.998.1. "Ethernet-based xDSL multi-pair bonding (G.Bond/Ethernet) MIB", Edward Beili, Moti Morgenstern, 12-Mar-12, This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP based internets. This document proposes an extension to the GBOND-MIB module with a set of objects for managing Ethernet-based multi-pair bonded xDSL interfaces, defined in ITU-T recommendation G.998.2. Application-Layer Traffic Optimization (alto) --------------------------------------------- "Application-Layer Traffic Optimization (ALTO) Requirements", Sebastian Kiesel, Stefano Previdi, Martin Stiemerling, Richard Woundy, Yang Yang, 19-Apr-12, Many Internet applications are used to access resources, such as pieces of information or server processes, which are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications, which have to select one or several hosts from a set of candidates capable of providing a desired resource. This guidance shall be based on parameters that affect performance and efficiency of the data transmission between the hosts, e.g., the topological distance. The ultimate goal is to improve performance (or Quality of Experience) in the application while reducing resource consumption in the underlying network infrastructure. This document enumerates requirements for specifying, assessing, or comparing protocols and implementations. "ALTO Protocol", Richard Alimi, Reinaldo Penno, Yang Yang, 11-Mar-12, Networking applications today already have access to a great amount of Inter-Provider network topology information. For example, views of the Internet routing table are easily available at looking glass servers and entirely practical to be downloaded by clients. What is missing is knowledge of the underlying network topology from the ISP or Content Provider (henceforth referred as Provider) point of view. In other words, what a Provider prefers in terms of traffic optimization -- and a way to distribute it. The ALTO Service provides network information (e.g., basic network location structure, preferences of network paths) with the goal of modifying network resource consumption patterns while maintaining or improving application performance. The basic information of ALTO is based on abstract maps of a network. These maps provide simplified, yet enough information of a network for applications to effectively utilize. Additional services are built on top the maps. This document describes a protocol implementing the ALTO Service. Although the ALTO service would primarily be provided by the network (i.e., the ISP), content providers and third parties could also operate this service. Applications that could use this service are those that have a choice in connection endpoints. Examples of such applications are peer-to-peer (P2P) and content delivery networks. "ALTO Deployment Considerations", Martin Stiemerling, Sebastian Kiesel, Stefano Previdi, 2-Mar-12, Many Internet applications are used to access resources, such as pieces of information or server processes, which are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to 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, 8-Mar-12, The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications, which have to select one or several hosts from a set of candidates that are able to provide a desired resource. Entities seeking guidance need to discover and possibly select an ALTO server to ask. This is called ALTO server discovery. This memo describes an ALTO server discovery mechanism based on several alternative mechanisms that are applicable in a diverse set of ALTO deployment scenarios. Access Node Control Protocol (ancp) ----------------------------------- "Access Node Control Protocol (ANCP) MIB module for Access Nodes", Stefaan De Cnodder, Moti Morgenstern, 2-May-12, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing access nodes that are using the Access Node Control Protocol (ANCP). "Multicast Control Extensions for ANCP", Francois Le Faucheur, Roberta Maglione, Tom Taylor, 30-Apr-12, This document specifies the extensions to the Access Node Control Protocol required for support of the multicast use cases defined in the Access Node Control Protocol framework document and one additional use case described in this document. These use cases are organized into the following ANCP capabilities: o NAS-initiated multicast replication; o conditional access with white and black lists; o conditional access with grey lists; o bandwidth delegation; o committed bandwidth reporting. These capabilities may be combined according to the rules given in this specification. "Applicability of Access Node Control Mechanism to PON based Broadband Networks", Nabil Bitar, Sanjay Wadhwa, 17-Jan-12, The purpose of this document is to provide applicability of the Access Node Control Mechanism, as described in [RFC5851], to PON based broadband access. The need for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node Complex (a combination of Optical Line Termination (OLT) and Optical Network Termination (ONT) elements) is described in a multi-service reference architecture in order to perform QoS- related, service-related and Subscriber-related operations. The Access Node Control Mechanism is also extended for interaction between components of the Access Node Complex (OLT and ONT). The Access Node Control mechanism will ensure that the transmission of information between the NAS and Access Node Complex (ANX) and between the OLT and ONT within an ANX does not need to go through distinct element managers but rather uses a direct device-to- device communication and stays on net. This allows for performing access link related operations within those network elements to meet performance objectives. Applications Area Working Group (appsawg) ----------------------------------------- "Simple Web Discovery (SWD)", Michael Jones, Yaron Goland, 14-Dec-11, Simple Web Discovery (SWD) defines an HTTPS GET based mechanism to discover the location of a given type of service for a given principal starting only with a domain name. "Advice for Safe Handling of Malformed Messages", Murray Kucherawy, 19-May-12, The email ecosystem has long had a very permissive set of common processing rules in place, despite increasingly rigid standards governing its components, ostensibly to improve the user experience. The handling of these come at some cost, and various components are 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. 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. 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 simply reject or discard them. Accordingly, this document presents recommendations 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, 28-Feb-12, 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. "Deprecating the X- Prefix and Similar Constructs in Application Protocols", Peter Saint-Andre, Dave Crocker, Mark Nottingham, 9-Apr-12, Historically, designers and implementers of application protocols have often distinguished between standardized and unstandardized parameters by prefixing the names of unstandardized parameters with the string "X-" or similar constructs. In practice, that convention causes more problems than it solves. Therefore, this document deprecates the convention for newly-defined parameters with textual (as opposed to numerical) names in application protocols. "The "about" URI Scheme", Lachlan Hunt, Mykyta Yevstifeyev, 26-Mar-12, This document specifies the "about" URI scheme, which is widely used by web browsers and some other applications to designate access to their internal resources, such as settings, application information, hidden built-in functionality, and so on. "WebFinger", Paul Jones, Gonzalo Salgueiro, Joseph Smarr, 21-May-12, This specification defines the WebFinger protocol. WebFinger may be used to discover information about people on the Internet, such as a person's personal profile address, identity service, telephone number, or preferred avatar. WebFinger may also be used to learn information about objects on the network, such as the amount of toner in a printer or the physical location of a server. "Email Greylisting: An Applicability Statement for SMTP", Murray Kucherawy, Dave Crocker, 26-Apr-12, This document describes the art of email greylisting, the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism. Greylisting is an established mechanism deemed essential to the repertoire of current anti-abuse email filtering systems. "JSON Patch", Paul Bryan, 9-Mar-12, JSON Patch defines the media type "application/json-patch", a JSON document structure for expressing a sequence of operations to apply to a JSON document. "JSON Pointer", Paul Bryan, Kris Zyp, 9-Mar-12, JSON Pointer defines a string syntax for identifying a specific value within a JSON document. "Forwarded HTTP Extension", Andreas Petersson, Martin Nilsson, 20-Apr-12, This document standardizes an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, e.g., the originating IP address of a request or IP number of the proxy on the user-agent facing interface. Given a trusted path of proxying components, this makes it possible to arrange so that each subsequent component will have access to e.g., 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. "Update to MIME regarding Charset Parameter Handling in Textual Media Types", Alexey Melnikov, Julian Reschke, 9-May-12, This document changes RFC 2046 rules regarding default charset parameter values for text/* media types to better align with common usage by existing clients and servers. Editorial Note (To be removed by RFC Editor) Discussion of this draft should take place on the Apps Area Working Group mailing list (apps-discuss@ietf.org), which is archived at . "Media Type Specifications and Registration Procedures", Ned Freed, John Klensin, Tony Hansen, 18-May-12, This document defines procedures for the specification and registration of media types for use in HTTP, MIME and other Internet protocols. "Additional Media Type Structured Syntax Suffixes", Tony Hansen, 22-May-12, A content media type name sometimes includes partitioned meta- information distinguish by a Structured Syntax, to permit noting an attribute of the media as a suffix to the name. This document defines several Structured Syntax Suffixes for use with media type registrations. In particular, it defines and registers the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" Structured Syntax Suffixes, and updates the "+xml" Message Type Structured Syntax Suffix registration. "Indicating Email Handling States in Trace Fields", Dave Crocker, Murray Kucherawy, 18-May-12, This memo registers a trace field clause for use in indicating transitions between handling queues or processing states, including enacting inter- and intra-host message transitions. This might include message quarantining, mailing list moderation, timed delivery, queueing for further analysis, content conversion, or other similar causes, as well as optionally identifying normal handling queues. Address Resolution for Massive numbers of hosts in the Data center (armd) ------------------------------------------------------------------------- "Problem Statement for ARMD", Thomas Narten, Manish Karir, Ian Foo, 12-Mar-12, This document examines address resolution issues related to the massive scaling of data centers. Our initial scope is relatively narrow. Specifically, it focuses on address resolution (ARP and ND) within the data center. Authority-to-Citizen Alert (atoca) ---------------------------------- "Requirements, Terminology and Framework for Exigent Communications", Henning Schulzrinne, Steve Norreys, Brian Rosen, Hannes Tschofenig, 12-Mar-12, Before, during and after emergency situations various agencies need to provide information to a group of persons or to the public within a geographical area. While many aspects of such systems are specific to national or local jurisdictions, emergencies span such boundaries and notifications need to reach visitors from other jurisdictions. This document provides terminology, requirements and an architectural description for protocols exchanging alerts between IP-based end points. Audio/Video Transport Core Maintenance (avtcore) ------------------------------------------------ "Why RTP Does Not Mandate a Single Security Mechanism", Colin Perkins, Magnus Westerlund, 31-Oct-11, This memo discusses the problem of securing real-time multimedia sessions, and explains why the Real-time Transport Protocol (RTP), and the associated RTP control protocol (RTCP), do not mandate a single media security mechanism. It also discusses how applications using RTP can meet the goals of BCP 61 to have strong and mandatory to implement security. "Explicit Congestion Notification (ECN) for RTP over UDP", Magnus Westerlund, Ingemar Johansson, Colin Perkins, Piers O'Hanlon, Ken Carlberg, 14-May-12, This memo specifies how Explicit Congestion Notification (ECN) can be used with the Real-time Transport Protocol (RTP) running over UDP, using RTP Control Protocol (RTCP) as a feedback mechanism. It defines a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT (STUN) extension used in the optional initialization method using Interactive Connectivity Establishment (ICE). Signalling and procedures for negotiation of capabilities and initialization methods are also defined. "RTCP Extension for Third-party Loss Report", Wenson Wu, Frank Xia, Roni Even, 13-Apr-12, In a large RTP session using the RTP Control Protocol (RTCP) feedback mechanism defined in RFC 4585, a feedback target may experience transient overload if some event causes a large number of receivers to send feedback at once. This overload is usually avoided by ensuring that feedback reports are forwarded to all receivers, allowing them to avoid sending duplicate feedback reports. However, there are cases where it is not recommended to forward feedback reports, and this may allow feedback implosion. This memo discusses these cases and defines a new RTCP third-party loss report that can be used to inform receivers that the feedback target is aware of some loss event, allowing them to suppress feedback. Associated SDP signaling is also defined. "Monitoring Architecture for RTP", Wenson Wu, Geoff Hunt, Philip Arden, 1-May-12, This memo proposes an architecture for extending RTP Control Protocol (RTCP) with a new RTCP Extended Reports (XR) (RFC3611) block type to report new metrics regarding media transmission or reception quality, following RTCP guideline established in RFC5968. This memo suggests that a new block should contain a single metric or a small number of metrics relevant to a single parameter of interest or concern, rather than containing a number of metrics which attempt to provide full coverage of all those parameters of concern to a specific application. Applications may then "mix and match" to create a set of blocks which covers their set of concerns. Where possible, a specific block should be designed to be re-usable across more than one application, for example, for all of voice, streaming audio and video. "RTCP for inter-destination media synchronization", Ray van Brandenburg, Hans Stokking, Fernando Boronat, Mario Montagud, Kevin Gross, 22-May-12, This document gives information on an RTCP Packet Type and RTCP XR Block Type including associated SDP parameters for Inter-Destination Media Synchronization (IDMS). The RTCP XR Block Type, registered with IANA based on an ETSI specification, is used to collect media playout information from participants in a group playing-out (watching, listening, etc.) a specific RTP media stream. The RTCP packet type specified by this document is used to distribute a 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. "RTP Congestion Control: Circuit Breakers for Unicast Sessions", Colin Perkins, Varun Singh, 5-Mar-12, The Real-time Transport Protocol (RTP) is widely used for telephony, video conferencing, and telepresence applications. These applications are often used over best-effort UDP/IP networks. If congestion control is not implemented then network congestion will deteriorate the user's multimedia experience. This document does not propose a congestion control algorithm. Instead, it specifies a minimal set of "circuit-breakers". Circuit-breakers are conditions under which an RTP flow should cease to transmit media to protect the network from excessive congestion. It is expected that all RTP applications running on best-effort networks will be able to run without triggering these circuit breakers in normal operation. "AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP)", David McGrew, Kevin Igoe, 3-May-12, This document defines how AES-GCM, AES-CCM, and other Authenticated Encryption with Associated Data (AEAD) algorithms, can be used to provide confidentiality and data authentication mechanisms in the SRTP protocol. "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, 15-May-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. Audio/Video Transport Extensions (avtext) ----------------------------------------- "Support for Multiple Clock Rates in an RTP Session", Marc Petit-Huguenin, Glen Zorn, 10-May-12, This document clarifies the RTP specification when different clock rates are used in an RTP session. It also provides guidance on how to interoperate with legacy RTP implementations that use multiple clock rates. "Considerations for Deploying the Rapid Acquisition of Multicast RTP Sessions (RAMS) Method", Ali Begen, 10-May-12, The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a method based on RTP and RTP Control Protocol (RTCP) that enables an RTP receiver to rapidly acquire and start consuming the RTP multicast data. Upon a request from the RTP receiver, an auxiliary unicast RTP retransmission session is set up between a retransmission server and the RTP receiver, over which the reference information about the new multicast stream the RTP receiver is about to join is transmitted at an accelerated rate. This often precedes, but may also accompany, the multicast stream itself. When there is only one multicast stream to be acquired, the RAMS solution works in a straightforward manner. However, when there are two or more multicast streams to be acquired from the same or different multicast RTP sessions, care should be taken to configure each RAMS session appropriately. This document provides example scenarios and discusses how the RAMS solution could be used in such scenarios. "Content Splicing for RTP Sessions", Jinwei Xia, 19-Feb-12, This memo outlines RTP splicing. Splicing is a process that replaces the content of the main multimedia stream with other multimedia content, and delivers the substitutive multimedia content to receiver for a period of time. This memo provides some RTP splicing use cases, then we enumerate a set of requirements and analyze whether an existing RTP level middlebox can meet these requirements, at last we provide concrete guidelines for how the chosen middlebox works to handle RTP splicing. Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- "Stream Control Transmission Protocol (SCTP) Network Address Translation", Randall Stewart, Michael Tuexen, Irene Ruengeler, 11-Mar-12, 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. "Common requirements for Carrier Grade NATs (CGNs)", Simon Perreault, Ikuhei Yamagata, Shin Miyakawa, Akira Nakagawa, Hiroyuki Ashida, 3-May-12, This document defines common requirements for Carrier-Grade NAT (CGN). It updates RFC 4787. "Analysis of Stateful 64 Translation", Reinaldo Penno, Tarun Saxena, Mohamed Boucadair, Senthil Sivakumar, 2-Mar-12, Due to specific problems, NAT-PT was deprecated by the IETF as a mechanism to perform IPv6-IPv4 translation. Since then, new efforts have been undertaken within IETF to standardize alternative mechanisms to perform IPv6-IPv4 translation. This document analyzes to what extent the new stateful translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT. "Discovery of IPv6 Prefix Used for IPv6 Address Synthesis", Teemu Savolainen, Jouni Korhonen, Dan Wing, 14-May-12, This document describes a method for detecting presence of DNS64 and for learning IPv6 prefix used for protocol translation on an access network. The method depends on existence of a well-known IPv4-only domain name "ipv4only.arpa". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid traversal through NAT64 on dual-stack accesses 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 Definitions of Managed Objects for Network Address Translators (NAT)", Simon Perreault, Tina Tsou, Senthil Sivakumar, 17-Apr-12, 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. Binary Floor Control Protocol Bis (bfcpbis) -------------------------------------------- "The Binary Floor Control Protocol (BFCP)", Tom Kristensen, 12-Mar-12, 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", Tom Kristensen, Gonzalo Camarillo, 5-Mar-12, 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 15. Bidirectional Forwarding Detection (bfd) ---------------------------------------- "BFD Generic Cryptographic Authentication", Manav Bhatia, Vishwas Manral, Dacheng Zhang, 4-Apr-12, This document proposes an extension to Bidirectional Forwarding Detection (BFD) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes described in the base specification. This document adds the basic infrastructure thats required for supporting algorithm and key agility for BFD. "Authenticating BFD using HMAC-SHA-2 procedures", Dacheng Zhang, Manav Bhatia, Vishwas Manral, 11-Jan-12, This document describes how Hashed Message Authentication Mode (HMAC) in conjunction with the SHA-256, SHA-384, and SHA-512 algorithms can be used for authenticating Bidirectional Forwarding Detection (BFD). It uses the Generic Cryptographic Authentication and Generic Meticulous Cryptographic Authentication sections to carry the authentication data. This updates, but does not supercede, the cryptographic authentication mechanism specified in RFC 5880. Basic Level of Interoperability for SIP Services (bliss) -------------------------------------------------------- "Call Completion for Session Initiation Protocol (SIP)", Martin Huelsemann, Roland Jesske, Dale Worley, Denis Alexeitsev, 29-Nov-11, The call completion feature defined in this specification allows the caller of a failed call to be notified when the callee becomes available to receive a call. For the realization of a basic solution without queuing, this document references the usage of the dialog event package (RFC 4235) that is described as 'automatic redial' in the SIP Service Examples (RFC 5359). For the realization of a more comprehensive solution with queuing , this document introduces an architecture for implementing these features in the Session Initiation Protocol where "Call completion" implementations associated with the caller's and callee's endpoints cooperate to place the caller's request for call completion into a queue at the callee's endpoint, and when a caller's request is ready to be serviced, re-attempt of the original, failed call is made. The architecture is designed to interoperate well with existing call- completion solutions in other networks. "Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)", Alan Johnston, Mohsen Soroushnejad, Venkatesh Venkataramanan, 4-May-12, This document describes the requirements and implementation of a group telephony feature commonly known as Bridged Line Appearance (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line Appearance (SCA). When implemented using the Session Initiation Protocol (SIP), it is referred to as shared appearances of an Address of Record (AOR) since SIP does not have the concept of lines. This feature is commonly offered in IP Centrex services and IP-PBX offerings and is likely to be implemented on SIP IP telephones and SIP feature servers used in a business environment. This feature allows several user agents (UAs) to share a common AOR, learn about calls placed and received by other UAs in the group, and pick up or join calls within the group. This document discusses use cases, lists requirements and defines extensions to implement this feature. Benchmarking Methodology (bmwg) ------------------------------- "Methodology for benchmarking MPLS protection mechanisms", Jean-Louis Le Roux, Samir Vapiwala, Scott Poretsky, Jay Karthik, Rajiv Papneja, Shankar Rao, 28-Oct-11, This draft describes the methodology for benchmarking MPLS Protection mechanisms for link and node protection as defined in [MPLS-FRR-EXT]. This document provides test methodologies and testbed setup for measuring failover times while considering all dependencies that might impact faster recovery of real-time applications bound to MPLS based traffic engineered tunnels. The benchmarking terms used in this document are defined in [TERM-ID]. "Methodology for Benchmarking SIP Networking Devices", Carol Davids, Vijay Gurbani, Scott Poretsky, 12-Mar-12, 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, 12-Mar-12, This document provides a terminology for benchmarking SIP performance in networking devices. Terms are included for test components, test setup parameters, and performance benchmark metrics for black-box benchmarking of SIP networking devices. The performance benchmark metrics are obtained for the SIP control plane and media plane. The terms are intended for use in a companion methodology document for complete performance characterization of a device in a variety of conditions making it possible to compare performance of different devices. It is critical to provide test setup parameters and a methodology document for SIP performance benchmarking because SIP allows a wide range of configuration and operational conditions that can influence performance benchmark measurements. It is necessary to have terminology and methodology standards to ensure that reported benchmarks have consistent definition and were obtained following the same procedures. Benchmarks can be applied to compare performance of a variety of SIP networking devices. "IP Flow Information Accounting and Export Benchmarking Methodology", Jan Novak, 23-Apr-12, This document provides a methodology and framework for quantifying the performance impact of monitoring of IP flows on a network device and export of this information to a collector. It identifies the rate at which the IP flows are created, expired, and successfully exported as a new performance metric in combination with traditional throughput. The metric is only applicable to the devices compliant with the Architecture for IP Flow Information Export [RFC5470]. The methodology quantifies the impact of the IP flow monitoring process on the network equipment. "RFC 2544 Applicability Statement: Use on Production Networks Considered Harmful", Scott Bradner, Kevin Dubray, Jim McQuaid, Al Morton, 26-Apr-12, Benchmarking Methodology Working Group (BMWG) has been developing key performance metrics and laboratory test methods since 1990, and continues this work at present. Recent application of the methods beyond their intended scope is cause for concern. This memo clarifies the scope of RFC 2544 and other benchmarking work for the IETF community. "Benchmarking Methodology for Content-Aware Network Devices", Mike Hamilton, Sarah Banks, 12-Mar-12, 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, 8-Jan-12, Benchmarking Methodologies have always relied on test conditions with constant packet sizes, with the goal of understanding what network device capability has been tested. Tests with constant packet size reveal device capabilities but differ significantly from the conditions encountered in operational deployment, and so additional tests are sometimes conducted with a mixture of packet sizes, or "IMIX". The mixture of sizes a networking device will encounter is highly variable and depends on many factors. An IMIX suited for one networking device and deployment will not be appropriate for another. However, the mix of sizes may be known and the tester may be asked to augment the fixed size tests. To address this need, and the perpetual goal of specifying repeatable test conditions, this draft defines a way to specify the exact repeating sequence of packet sizes from the usual set of fixed sizes, and other forms of mixed size specification. Common Control and Measurement Plane (ccamp) -------------------------------------------- "Traffic Engineering Database Management Information Base in support of MPLS-TE/GMPLS", Masanori Miyazawa, Tomohiro Otani, Kenji Kumaki, Thomas Nadeau, 8-May-12, This memo defines the Management Information Base (MIB) objects in order to manage traffic engineering database (TED) information with extension in support of Multi-Protocol Label Switching (MPLS) with traffic engineering (TE) as well as Generalized MPLS (GMPLS) for use with network management protocols. "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks", Young Lee, Greg Bernstein, Dan Li, Wataru Imajuku, 7-Mar-12, 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, 24-Apr-12, A wavelength switched optical network (WSON) requires that certain key information elements are made available to facilitate path computation and the establishment of label switching paths (LSPs). The information model described in "Routing and Wavelength Assignment Information for Wavelength Switched Optical Networks" shows what information is required at specific points in the WSON. Part of the WSON information model contains aspects that may be of general applicability to other technologies, while other parts are fairly specific to WSONs. This document provides efficient, protocol-agnostic encodings for the WSON specific information elements. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses. Such encodings can be used to extend GMPLS signaling and routing protocols. In addition these encodings could be used by other mechanisms to convey this same information to a path computation element (PCE). "GMPLS RSVP-TE extensions for OAM Configuration", Attila Takacs, Don Fedyk, He Jia, 11-Jan-12, OAM is an integral part of transport connections, hence it is required that OAM functions are activated/deactivated in sync with connection commissioning/decommissioning; avoiding spurious alarms and ensuring consistent operation. In certain technologies OAM entities are inherently established once the connection is set up, while other technologies require extra configuration to establish and configure OAM entities. This document specifies extensions to RSVP-TE to support the establishment and configuration of OAM entities along with LSP signaling. "GMPLS RSVP-TE Extensions for Ethernet OAM Configuration", Attila Takacs, Balazs Gero, Hao Long, 11-Jan-12, The GMPLS controlled Ethernet Label Switching (GELS) work extended GMPLS RSVP-TE to support the establishment of Ethernet LSPs. IEEE Ethernet Connectivity Fault Management (CFM) specifies an adjunct OAM flow to check connectivity in Ethernet networks. CFM can be also used with Ethernet LSPs for fault detection and triggering recovery mechanisms. The ITU-T Y.1731 specification builds on CFM and specifies additional OAM mechanisms, including Performance Monitoring, for Ethernet networks. This document specifies extensions of GMPLS RSVP-TE to support the setup of the associated Ethernet OAM (CFM and Y.1731) entities defining Ethernet technology specific TLV based on [OAM-CONF-FWK]. "GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks", Young Lee, Greg Bernstein, 24-Apr-12, 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-Mar-12, 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, 13-Apr-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. "GMPLS RSVP-TE Extensions for SONET/SDH and OTN OAM Configuration", Andras Kern, Attila Takacs, 2-Mar-12, GMPLS has been extended to support connection establishment in both SONET/SDH [RFC4606] and OTN [RFC4328] networks. However support for the configuration of the supervision functions is not specified. Both SONET/SDH and OTN implement supervision functions to qualify the transported signals. This document defines extensions to RSVP-TE for SONET/SDH and OTN OAM configuration based on the OAM Configuration Framework defined in [GMPLS-OAM-FWK]. "Framework for GMPLS and PCE Control of G.709 Optical Transport Networks", Fatai Zhang, Dan Li, Han Li, Sergio Belotti, Daniele Ceccarelli, 8-Mar-12, This document provides a framework to allow the development of protocol extensions to support Generalized Multi-Protocol Label Switching (GMPLS) and Path Computation Element (PCE) control of Optical Transport Networks (OTN) as specified in ITU-T Recommendation G.709 as consented in October 2009. "Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS/ MPLS-TE Networks", Weiqiang Sun, Guoying Zhang, 31-Jan-12, When setting up a label switched path (LSP) in Generalized MPLS and MPLS/TE networks, the completion of the signaling process does not necessarily mean that the cross connection along the LSP have been programmed accordingly and in a timely manner. Meanwhile, the completion of signaling process may be used by applications as indication that data path has become usable. The existence of this delay and the possible failure of cross connection programming, if not properly treated, will result in data loss or even application failure. Characterization of this performance can thus help designers to improve the application model and to build more robust applications. This document defines a series of performance metrics to evaluate the availability of data path in the signaling process. "RSVP-TE Extensions for Collecting SRLG Information", Fatai Zhang, Dan Li, Oscar de Dios, Cyril Margaria, 12-Mar-12, 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. "Signaling Extensions for Wavelength Switched Optical Networks", Greg Bernstein, Sugang Xu, Young Lee, Giovanni Martinelli, Hiroaki Harai, 7-Mar-12, This memo provides extensions to Generalized Multi-Protocol Label Switching (GMPLS) signaling for control of wavelength switched optical networks (WSON). Such extensions are necessary in WSONs under a number of conditions including: (a) when optional processing, such as regeneration, must be configured to occur at specific nodes along a path, (b) where equipment must be configured to accept an optical signal with specific attributes, or (c) where equipment must be configured to output an optical signal with specific attributes. In addition this memo provides mechanisms to support distributed wavelength assignment with bidirectional LSPs, and choice in distributed wavelength assignment algorithms. These extensions build on previous work for the control of lambda and G.709 based networks. "Link Management Protocol Behavior Negotiation and Configuration Modifications", Daniele Ceccarelli, Lou Berger, Dan Li, 16-Jan-12, The Link Management Protocol (LMP) is used to coordinate the properties, use, and faults of data links in Generalized Multiprotocol Label Switching (GMPLS) networks. This document defines an extension to LMP to negotiate capabilities and indicate support for LMP extensions. The defined extension is compatible with non-supporting implementations. "Usage of The RSVP Association Object", Lou Berger, 25-Oct-11, The RSVP ASSOCIATION object was defined in the context of GMPLS (Generalized Multi-Protocol Label Switching) controlled label switched paths (LSPs). In this context, the object is used to associate recovery LSPs with the LSP they are protecting. This document reviews how association is to be provided in the context of GMPLS recovery. No new procedures or mechanisms are defined by this document and it is strictly informative in nature. "RSVP-TE Extensions for Associated Bidirectional LSPs", Fei Zhang, Ruiquan Jing, 7-Mar-12, 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. "Information model for G.709 Optical Transport Networks (OTN)", Sergio Belotti, Pietro Grandi, Daniele Ceccarelli, Diego Caviglia, Fatai Zhang, Dan Li, 18-Jan-12, The recent revision of ITU-T recommendation G.709 [G.709-v3] has introduced new fixed and flexible ODU containers in Optical Transport Networks (OTNs), enabling optimized support for an increasingly abundant service mix. This document provides a model of information needed by the routing and signaling process in OTNs to support Generalized Multiprotocol Label Switching (GMPLS) control of all currently defined ODU containers. "Updates to ASON Routing for OSPFv2 Protocols (RFC 5787bis)", Andrew Malis, Acee Lindem, 8-Aug-11, The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON). The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies including optical networks such as time division multiplexing (TDM) networks including SONET/SDH and Optical Transport Networks (OTNs), and lambda switching optical networks. The requirements for GMPLS routing to satisfy the requirements of ASON routing, and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON. Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations current when those documents were written. Future extensions of revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. "RSVP Association Object Extensions", Lou Berger, Francois Le Faucheur, Ashok Narayanan, 9-Mar-12, The RSVP ASSOCIATION object was defined in the context of GMPLS (Generalized Multi-Protocol Label Switching) controlled label switched paths (LSPs). In this context, the object is used to associate recovery LSPs with the LSP they are protecting. This object also has broader applicability as a mechanism to associate RSVP state, and this document defines how the ASSOCIATION object can be more generally applied. This document also defines extended ASSOCIATION objects which, in particular, can be used in the context of Transport Profile of Multiprotocol Label Switching (MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC 3473. It also modifies the definition of the Association ID field defined in RFC 4872. "RSVP-TE Extensions to Exchange MPLS-TP LSP Identifiers", Fei Zhang, 7-Mar-12, The MPLS Transport Profile (MPLS-TP) identifiers document [RFC6370] specifies an initial set of identifiers, such as local assigned tunnel number and Global_ID, which can be used to form Maintenance Entity Point Identifier (MEP_ID). As to some Operation, Administration and Maintenance (OAM) functions, such as Connectivity Verification (CV) [RFC6428], source MEP_ID must be inserted in the OAM packets, so that the peer endpoint can compare the received and expected MEP_IDs to judge whether there is a mismatch [RFC6371], which means that the two MEP nodes need to pre-store each other's MEP_IDs. This document defines the signaling extensions to exchange the Label Switched Path (LSP) identifiers. "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, 13-Apr-12, The recent revision of ITU-T Recommendation G.709 [G709-V3] has introduced new fixed and flexible ODU containers, enabling optimized support for an increasingly abundant service mix. This document describes OSPF routing protocol extensions to support Generalized MPLS (GMPLS) control of all currently defined ODU containers, in support of both sub-lambda and lambda level routing granularity. "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control", Fatai Zhang, Guoying Zhang, Sergio Belotti, Daniele Ceccarelli, Khuzema Pithewan, 8-Mar-12, Recent progress in ITU-T Recommendation G.709 standardization has introduced new ODU containers (ODU0, ODU4, ODU2e and ODUflex) and enhanced Optical Transport Networking (OTN) flexibility. Several recent documents have proposed ways to modify GMPLS signaling protocols to support these new OTN features. It is important that a single solution is developed for use in GMPLS signaling and routing protocols. This solution must support ODUk multiplexing capabilities, address all of the new features, be acceptable to all equipment vendors, and be extensible considering continued OTN evolution. This document describes the extensions to the Generalized Multi- Protocol Label Switching (GMPLS) signaling to control the evolving Optical Transport Networks (OTN) addressing ODUk multiplexing and new features including ODU0, ODU4, ODU2e and ODUflex. Content Delivery Networks Interconnection (cdni) ------------------------------------------------ "Content Distribution Network Interconnection (CDNI) Problem Statement", Ben Niven-Jenkins, Francois Le Faucheur, Nabil Bitar, 20-May-12, Content Delivery Networks (CDNs) provide numerous benefits: reduced delivery cost for cacheable content, improved quality of experience for End Users and increased robustness of delivery. For these reasons they are frequently used for large-scale content delivery. As a result, existing CDN Providers are scaling up their infrastructure and many Network Service Providers (NSPs) are deploying their own CDNs. It is generally desirable that a given content item can be delivered to an End User regardless of that End User's location or attachment network. This is the motivation for interconnecting standalone CDNs so they can interoperate as an open content delivery infrastructure for the end-to-end delivery of content from Content Service Providers (CSPs) to End Users. However, no standards or open specifications currently exist to facilitate such CDN interconnection. The goal of this document is to outline the problem area of CDN interconnection for the IETF CDNI (CDN Interconnection) working group. "Content Distribution Network Interconnection (CDNI) Requirements", Kent Leung, Yiu Lee, 7-Dec-11, Content Delivery Networks (CDNs) are frequently used for large-scale content delivery. As a result, existing CDN providers are scaling up their infrastructure and many Network Service Providers (NSPs) are deploying their own CDNs. There is a requirement for interconnecting standalone CDNs so that their collective CDN footprint can be leveraged for the end-to-end delivery of content from Content Service Providers (CSPs) to end users. The Content Distribution Network Interconnection (CDNI) working group has been chartered to develop an interoperable and scalable solution for such CDN interconnection. The goal of the present document is to outline the requirements for the solution and interfaces to be specified by the CDNI working group. This draft is a work in progress and requirements may be added, modified, or removed by the working group. Requirements Language The key words "High Priority", "Medium Priority" and "Low Priority" in this document are to be interpreted in the following way: o "High Priority" indicates requirements that are to be supported by the CDNI interfaces. A requirement is stated as "High Priority" when it is established by the working group that it can be met without compromising the targeted schedule for WG deliverables, or when it is established that specifying a solution without meeting this requirement would not make sense and would justify re- adjusting the WG schedule, or both. This is tagged as "[HIGH]". o "Medium Priority" indicates requirements that are to be supported by the CDNI interfaces unless the WG realizes at a later stage that attempting to meet this requirement would compromise the overall WG schedule (for example it would involve complexities that would result in significantly delaying the deliverables). This is tagged as "[MED]". o "Low Priority" indicates requirements that are to be supported by the CDNI interfaces provided that dedicating WG resources to this work does not prevent addressing "High Priority" and "Medium Priority" requirements and that attempting to meet this requirement would not compromise the overall WG schedule. This is tagged as "[LOW]". "Use Cases for Content Delivery Network Interconnection", Gilles Bertrand, Stephan Emile, Trevor Burbridge, Philip Eardley, Kevin Ma, Grant Watson, 23-May-12, Content Delivery Networks (CDNs) are commonly used for improving the End User experience of a content delivery service, at a reasonable cost. This document focuses on use cases that correspond to identified industry needs and that are expected to be realized once open interfaces and protocols supporting interconnection of CDNs are specified and implemented. The document can be used to guide the definition of the requirements to be supported by CDN Interconnection (CDNI) interfaces. "Framework for CDN Interconnection", Larry Peterson, Bruce Davie, 27-Apr-12, This document presents a framework for Content Distribution Network Interconnection (CDNI). The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnect CDNs. CDN Interconnection requires the specification of several interfaces and mechanisms to address issues such as request routing, metadata exchange, and the acquisition of content by one CDN from another. The intent of this document is to outline what each interface needs to accomplish, and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. ControLling mUltiple streams for tElepresence (clue) ---------------------------------------------------- "Use Cases for Telepresence Multi-streams", Allyn Romanow, Stephen Botzko, Mark Duckworth, Roni Even, Iformata Communications, 9-Jan-12, Telepresence conferencing systems seek to create the sense of really being present for the participants. A number of techniques for handling audio and video streams are used to create this experience. When these techniques are not similar, interoperability between different systems is difficult at best, and often not possible. Conveying information about the relationships between multiple streams of media would allow senders and receivers to make choices to allow telepresence systems to interwork. This memo describes the most typical and important use cases for sending multiple streams in a telepresence conference. "Framework for Telepresence Multi-Streams", Allyn Romanow, Mark Duckworth, Andrew Pepperell, Brian Baldino, 12-Mar-12, This memo offers a framework for a protocol that enables devices in a telepresence conference to interoperate by specifying the relationships between multiple media streams. Internet Wideband Audio Codec (codec) ------------------------------------- "Definition of the Opus Audio Codec", Jean-Marc Valin, Koen Vos, Tim Terriberry, 17-May-12, This document defines the Opus interactive speech and audio codec. Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances. It scales from low bitrate narrowband speech at 6 kb/s to very high quality stereo music at 510 kb/s. Opus uses both linear prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. "Summary of Opus listening test results", Christian Hoene, Jean-Marc Valin, Koen Vos, Jan Skoglund, 1-May-12, This document describes and examines listening test results obtained for the Opus codec and how they relate to the requirements. Congestion Exposure (conex) --------------------------- "ConEx Concepts and Use Cases", Bob Briscoe, Richard Woundy, Alissa Cooper, 2-Mar-12, This document provides the entry point to the set of documentation about the Congestion Exposure (ConEx) protocol. It explains the motivation for including a ConEx marking at the IP layer: to expose information about congestion to network nodes. Although such information may have a number of uses, this document focuses on how the information communicated by the ConEx marking can serve as the basis for significantly more efficient and effective traffic management than what exists on the Internet today. "Congestion Exposure (ConEx) Concepts and Abstract Mechanism", Matt Mathis, Bob Briscoe, 12-Mar-12, This document describes an abstract mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. Today, network elements at any layer may signal congestion to the receiver by dropping packets or by ECN markings, and the receiver passes this information back to the sender in transport-layer feedback. The mechanism described here enables the sender to also relay this congestion information back into the network in-band at the IP layer, such that the total amount of congestion from all elements on the path is revealed to all IP elements along the path, where it could, for example, be used to provide input to traffic management. This mechanism is called congestion exposure or ConEx. The companion document "ConEx Concepts and Use Cases" provides the entry-point to the set of ConEx documentation. "IPv6 Destination Option for Conex", Suresh Krishnan, Mirja Kuehlewind, Carlos Ucendo, 12-Mar-12, Conex is a mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. This document specifies an IPv6 destination option that is capable of carrying conex markings in IPv6 datagrams. "TCP modifications for Congestion Exposure", Mirja Kuehlewind, Richard Scheffenegger, 10-May-12, Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by previous packets on the same flow. This document describes the necessary modifications to use ConEx with the Transmission Control Protocol (TCP). Constrained RESTful Environments (core) --------------------------------------- "Constrained Application Protocol (CoAP)", Zach Shelby, Klaus Hartke, Carsten Bormann, Brian Frank, 12-Mar-12, This document specifies the Constrained Application Protocol (CoAP), a specialized web transfer protocol for use with constrained networks and nodes for machine-to-machine applications such as smart energy and building automation. These constrained nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while networks such as 6LoWPAN often have high packet error rates and a typical throughput of 10s of kbit/s. CoAP provides a method/response interaction model between application end-points, supports built-in resource discovery, and includes key web concepts such as URIs and content-types. CoAP easily translates to HTTP for integration with the web while meeting specialized requirements such as multicast support, very low overhead and simplicity for constrained environments. "Blockwise transfers in CoAP", Carsten Bormann, Zach Shelby, 15-Feb-12, CoAP is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for the small payloads we expect from temperature sensors, light switches, and similar building-automation devices. Occasionally, however, applications will need to transfer larger payloads -- for instance, for firmware updates. With HTTP, TCP does the grunt work of slicing large payloads up into multiple packets and ensuring that they all arrive and are handled in the right order. CoAP is based on datagram transports such as UDP or DTLS, which limits the maximum size of resource representations that can be transferred without too much fragmentation. Although UDP supports larger payloads through IP fragmentation, it is limited to 64 KiB and, more importantly, doesn't really work well for constrained applications and networks. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options, for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. In summary, the Block options provide a minimal way to transfer larger representations in a block-wise fashion. "CoRE Link Format", Zach Shelby, 23-May-12, This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes and other relationships between links. Based on the HTTP Link Header field defined in RFC5988, the CoRE Link Format is carried as a payload and is assigned an Internet media type. A well-known URI is defined as a default entry-point for requesting the links hosted by a server. "Observing Resources in CoAP", Klaus Hartke, 12-Mar-12, CoAP is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that gives clients the ability to observe such changes. "Group Communication for CoAP", Akbar Rahman, Esko Dijk, 9-Mar-12, This is a working document intended to develop draft text for the CoAP protocol specification in the area of group communication. A solution based on IP multicast is proposed and detailed. Also, guidance is provided for deployment in various constrained network topologies. Cga & Send maIntenance (csi) ---------------------------- "Analysis of Possible DHCPv6 and CGA Interactions", Sheng Jiang, Sean Shen, 12-Mar-12, This document analyzes the possible interactions between DHCPv6 and Cryptographically Generated Addresses (CGAs), and gives recommendations on whether or not these interactions should be developed as solutions. Call Control UUI Service for SIP (cuss) --------------------------------------- "A Mechanism for Transporting User to User Call Control Information in SIP", Alan Johnston, James Rafferty, 4-May-12, 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. "Interworking ISDN Call Control User Information with SIP", Keith Drage, Alan Johnston, 4-May-12, The motivation and use cases for interworking and transporting ITU-T DSS1 User-user information element data in SIP are described in the "Problem Statement and Requirements for Transporting User to User Call Control Information in SIP" document. As networks move to SIP it is important that applications requiring this data can continue to function in SIP networks as well as the ability to interwork with this ISDN service for end-to- end transparency. This document defines a usage (a new package) of the User-to-User header field to enable interworking with this ISDN service. This document covers the interworking with both public ISDN and private ISDN capabilities, so the potential interworking with QSIG will also be addressed. The package is identified by a new value "isdn-uui" of the "purpose" header field parameter. DNS-based Authentication of Named Entities (dane) ------------------------------------------------- "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", Paul Hoffman, Jakob Schlyter, 17-May-12, Encrypted communication on the Internet often uses Transport Level Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. Datagram Congestion Control Protocol (dccp) ------------------------------------------- "Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-UDP)", Thomas Phelan, Gorry Fairhurst, Colin Perkins, 26-Mar-12, This document specifies an alternative encapsulation of the Datagram Congestion Control Protocol (DCCP), referred to as DCCP-UDP. This encapsulation allows DCCP to be carried through the current generation of Network Address Translation (NAT) middleboxes without modification of those middleboxes. This document also updates the SDP information for DCCP defined in RFC 5762. Decoupled Application Data Enroute (decade) ------------------------------------------- "DECoupled Application Data Enroute (DECADE) Problem Statement", Haibin Song, Ning Zong, Yang Yang, Richard Alimi, 7-May-12, Peer-to-peer (P2P) applications have become widely used on the Internet today and make up a large portion of the traffic in many networks. In P2P applications, one technique for reducing the transit and uplink P2P traffic is to introduce storage capabilities within the network. Traditional caches (e.g., P2P and Web caches) provide such storage, but they are complex (due to explicitly supporting individual P2P application protocols and cache refresh mechanisms) and they do not allow users to manage access to content in the cache. For example, content providers wishing to use in- network storage cannot easily control cache access and resource usage policies to satisfy their own requirements. This document discusses the introduction of in-network storage for P2P applications, and shows the need for a standard protocol for accessing this storage. "DECADE Requirements", Gu Yingjie, David Bryan, Yang Yang, Richard Alimi, 12-Mar-12, The target of the DECoupled Application Data Enroute (DECADE) system is to provide an open and standard in-network storage system for applications, primarily P2P (peer-to-peer) applications, to store, retrieve and manage their data. This draft enumerates and explains requirements, not only for storage and retrieval, but also for data management, access control and resource control, that should be considered during the design and implementation of a DECADE- compatible system. These are requirements on the entire system; some of the requirements may eventually be implemented by an existing protocol with/without some extensions (e.g., a protocol used to read and write data from the storage system). The requirements in this document are intended to ensure that a DECADE-compatible system architecture includes all of the desired functionality for intended applications. "DECADE Architecture", Richard Alimi, Akbar Rahman, Dirk Kutscher, Yang Yang, 12-Mar-12, Content Distribution Applications (e.g., P2P applications) are widely used on the Internet and make up a large portion of the traffic in many networks. One technique to improve the network efficiency of these applications is to introduce storage capabilities within the networks; this is the capability to be provided by a DECADE (DECoupled Application Data Enroute) compliant system. This document presents an architecture for DECADE, discusses the underlying principles, and identifies key functionalities required for introducing in-network storage for these applications. In addition, some examples are given to illustrate these concepts in an informative manner. "Integration Examples of DECADE System", Ning Zong, Xiaohui Chen, Zhigang Huang, Lijiang Chen, Hongqiang Liu, 11-Mar-12, Decoupled Application Data Enroute (DECADE) system is an in-network storage infrastructure which is still under discussion and standardization process in IETF DECADE WG. 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). Dynamic Host Configuration (dhc) -------------------------------- "Description of Cisco Systems' Subnet Allocation Option for DHCPv4", Richard Johnson, Kim Kinnear, Mark Stapp, Jay Kumarasamy, 5-Apr-12, This memo documents a currently existing and previously privately defined DHCPv4 option, documenting the operation and usage of the Cisco Systems Subnet Allocation Option for DHCPv4. The option is passed between the DHCPv4 Client and the DHCPv4 Server to request dynamic allocation of a subnet, give specifications of subnet(s) allocated, and report usage statistics. This memo documents the current usage of the option in agreement with [RFC3942], which declares that any pre-existing usages of option numbers in the range 128 - 223 should be documented and the working group will try to officially assign those numbers to those options. "Client Identifier Option in DHCP Server Replies", Narasimha Swamy, Gaurav Halwasia, SEZ Unit, 12-Mar-12, This document updates RFC2131 [RFC2131]. The changes to [RFC2131] defined in this draft clarifies the use of 'client identifier' option by the DHCP servers. The clarification addresses the issues arising out of the point specified by [RFC2131] that the server 'MUST NOT' return client identifier' option to the client. Requirements "Rebind Capability in DHCPv6 Reconfigure Messages", D. Evans, Ralph Droms, Sheng Jiang, 18-Apr-12, This document updates RFC 3315 (DHCPv6) to allow the Rebind message type to appear in the Reconfigure Message option of a Reconfigure message. It extends the Reconfigure message to allow a DHCPv6 server to cause a DHCPv6 client to send a Rebind message. The document also clarifies how a DHCPv6 client responds to a received Reconfigure message. "Layer 2 Relay Agent Information", Bharat Joshi, Pavan Kurapati, 25-Jan-12, In some networks, DHCP servers rely on Relay Agent Information option appended by Relay Agents for IP address and other parameter assignment policies. This works fine when end hosts are directly connected to Relay Agents. In some network configurations, one or more Layer 2 devices may reside between DHCP clients and Relay agent. In these network scenarios, it is difficult to use the Relay Agent Information option for IP address and other parameter assignment policies effectively. So there is a need for the device that is closest to the end hosts to append a Relay Agent Information option in DHCP messages. These devices are typically known as Layer 2 Relay Agents. This document aims to describe the network scenarios where a Layer 2 Relay Agent is in use and also how it handles DHCP messages. "The DHCPv4 Relay Agent Identifier Suboption", Bharat Joshi, D.T.V. Rao, Mark Stapp, 10-Jan-12, This draft defines a new Relay Agent Identifier suboption for the Dynamic Host Configuration Protocol's (DHCP) Relay Agent Information option. The suboption carries a value that uniquely identifies the relay agent device within the administrative domain. The value is normally administratively-configured in the relay agent. The suboption allows a DHCP relay agent to include the identifier in the DHCP messages it sends. "Bulk DHCPv4 Lease Query", Kim Kinnear, Mark Stapp, Bharat Joshi, Neil Russell, 12-Mar-12, The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery extension allows a requestor to request information about DHCPv4 bindings. This mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. This document extends the DHCPv4 Leasequery protocol to allow for bulk transfer of DHCPv4 address binding data via TCP. "Forcerenew Nonce Authentication", David Miles, Wojciech Dec, James Bristow, Roberta Maglione, 11-Mar-12, Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows for the reconfiguration of a single host by forcing the DHCP client into a Renew state on a trigger from the DHCP server. In Forcerenew Nonce Authentication the server sends a nonce to the client in the initial DHCP ACK that is used for subsequent validation of a FORCERENEW message. This document updates RFC 3203. "Secure DHCPv6 Using CGAs", Sheng Jiang, Sean Shen, 12-Mar-12, The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCPv6 servers to pass configuration parameters. It offers configuration flexibility. If not secured, DHCPv6 is vulnerable to various attacks, particularly spoofing attack. This document analyzes the security issues of DHCPv6 and specifies a Secure DHCPv6 mechanism based on using CGAs. "DHCPv6 Redundancy Deployment Considerations", Jean-Francois Tremblay, John Brzozowski, Jack Chen, Tomasz Mrugalski, 31-Oct-11, This document documents some deployment considerations for those who wishing to use DHCPv6 to support their deployment of IPv6. Specifically, providing semi-redundant DHCPv6 services is discussed in this document. "Configuring Cryptographically Generated Addresses (CGA) using DHCPv6", Sheng Jiang, 10-Apr-12, A Cryptographically Generated Address is an IPv6 addresses binding with a public/private key pair. However, the current CGA specifications are lack of procedures to enable proper management of the usage of CGAs. This document defines the process using DHCPv6 to manage CGAs in detail. A new DHCPv6 option is defined accordingly. This document also analyses the configuration of the parameters, which are used to generate CGAs, using DHCPv6. Although the document does not define new DHCPv6 option to carry these parameters for various reasons, the configuration procedure is described. "Prefix Assignment in DHCPv6", Sheng Jiang, Frank Xia, Behcet Sarikaya, 22-May-12, This document introduce a procedure for configuring hosts' IPv6 address which the prefix is assigned from a DHCPv6 server through DHCPv6 protocol while the interface identifiers are independently generated by the hosts. The method is applicable to Cryptographically Generated Addresses (CGA), and other IPv6 addresses with host-generated interface identifiers. "DHCPv6 through Tunnels", Ole Troan, Marc Blanchet, Xiaohu Xu, Dayong Guo, 28-Apr-12, The host configuration protocol DHCPv6 [RFC3315] relies on link-local addresses as source addresses and multicast addresses for destination addresses. However, some tunnel links (e.g., 6rd [RFC5969] ) do not have IPv6 link-local addresses and do not support IPv6 multicast addresses. Taking 6rd as an example, this document specifies how DHCPv6 is used across such tunnel links. "DHCPv4 over IPv6 Transport", Yong Cui, Peng Wu, Jianping Wu, Ted Lemon, 18-May-12, 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 Agents on Broadband Access Server", Leaf Yeh, Mohamed Boucadair, Ted Lemon, 6-May-12, The DHCPv6 RADIUS option provides a communication mechanism between relay agent and the server. This mechanism can help the centralized DHCPv6 server to select the right configuration for the client based on the authorization information received from a separate RADIUS server which is not located at the same place of DHCPv6 server in the cases where the NAS acts as DHCPv6 relay agent and RADIUS client simultaneously. "Issues with multiple stateful DHCPv6 options", Ole Troan, Bernie Volz, 6-May-12, 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 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, 7-May-12, In the IPv6 address allocation scenarios, host self-generated addresses are notionally conflicted with the network managed address architecture. These addresses need to be registered in the networking management plate for the purposes of central address administration. This document introduces a generic address registration solution using DHCPv6, and defines one new ND option and one new DHCPv6 option in order to propagate the solicitations of registering self-generated addresses. The registration procedure reuses the existing IA_NA in the DHCPv6 protocol. Diameter Maintenance and Extensions (dime) ------------------------------------------ "Diameter Base Protocol", Victor Fajardo, Jari Arkko, John Loughney, Glen Zorn, 7-May-12, The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services used by all Diameter applications. The Diameter base protocol as defined in this document obsoletes RFC 3588 and RFC 5719 and must be supported by all new Diameter implementations. "Diameter Applications Design Guidelines", Lionel Morand, Victor Fajardo, Hannes Tschofenig, 1-Apr-12, The Diameter Base protocol provides facilities for protocol extensibility enabling to define new Diameter applications or modify existing applications. This document is a companion document to the Diameter Base protocol that further explains and clarifies the rules to extend the Diameter Base protocol. It is meant as a guidelines document and therefore it does not add, remove or change existing rules. "Diameter Support for the EAP Re-authentication Protocol (ERP)", Sebastien Decugis, Lionel Morand, Wenson Wu, Julien Bournelle, Glen Zorn, 9-Feb-12, The EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re- authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator. This document specifies Diameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between an ER authenticator and the ER server, and a set of new AVPs that can be used to transport the cryptographic material needed by the re-authentication server. "The Diameter Capabilities Update Application", Glen Zorn, Jiao Kang, 24-Oct-10, This document defines a new Diameter application and associated command codes. The Capabilities Update application is intended to allow the dynamic update of certain Diameter peer capabilities while the peer-to-peer connection is in the open state. "Realm-Based Redirection In Diameter", Tina Tsou, Tom Taylor, 10-Jan-12, RFC 3588 allows a Diameter redirect agent to specify one or more individual hosts to which a Diameter message may be redirected by an upstream Diameter node. However, in some circumstances an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies a mechanism by which this can be achieved. New applications may incorporate this capability by reference to the present document. "Diameter Network Address and Port Translation Control Application", Frank Brockners, Cisco Systems, Vaneeta Singh, Victor Fajardo, 22-Apr-12, This document describes the framework, messages, and procedures for the Diameter Network address and port translation Control Application. This Diameter application allows per endpoint control of Network Address Translators and Network Address and Port Translators, which are added to networks to cope with IPv4-address space depletion. This Diameter application allows external devices to configure and manage a Network Address Translator device - expanding the existing Diameter-based AAA and policy control capabilities with a Network Address Translators and Network Address and Port Translators control component. These external devices can be network elements in the data plane such as a Network Access Server, or can be more centralized control plane devices such as AAA- servers. This Diameter application establishes a context to commonly identify and manage endpoints on a gateway or server, and a Network Address Translator and Network Address and Port Translator device. This includes, for example, the control of the total number of Network Address Translator bindings allowed or the allocation of a specific Network Address Translator binding for a particular endpoint. In addition, it allows Network Address Translator devices to provide information relevant to accounting purposes. "Diameter IKEv2 SK: Shared Key-based Support for IKEv2 Server to Diameter Server Interaction", Violeta Cakulev, Avi Lior, Semyon Mizikovsky, 13-Nov-11, The Internet Key Exchange protocol version 2 (IKEv2) is a component of the IPsec architecture and is used to perform mutual authentication as well as to establish and to maintain IPsec security associations (SAs) between the respective parties. IKEv2 supports several different authentication mechanisms, such as the Extensible Authentication Protocol (EAP), certificates, and shared key. Diameter interworking for Mobile IPv6 between the Home Agent, as a Diameter client, and the Diameter server has been specified. However, that specification focused on the usage of EAP and did not include support for shared key based authentication available with IKEv2. This document specifies the IKEv2 Server to the Diameter server communication when the IKEv2 Peer authenticates using the Internet Key Exchange v2 with Shared Key. "Diameter Attribute-Value Pairs for Cryptographic Key Transport", Glen Zorn, Wenson Wu, Violeta Cakulev, 18-Aug-11, Some Authentication, Authorization, and Accounting (AAA) applications require the transport of cryptographic keying material. This document specifies a set of Attribute-Value Pairs (AVPs) providing native Diameter support of cryptographic key delivery. "Diameter Support for Proxy Mobile IPv6 Localized Routing", Glen Zorn, Wenson Wu, Marco Liebsch, Jouni Korhonen, 15-May-12, In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the Mobile Access Gateway (MAG) to which it is attached are typically tunneled to a Local Mobility Anchor (LMA) for routing. The term "localized routing" refers to a method by which packets are routed directly between an MN's MAG and the MAG of its Correspondent Node (CN) without involving any LMA. In order to establish a localized routing session between two Mobile Access Gateways in a Proxy Mobile IPv6 domain, the usage of localized routing may be authorized for both MAGs. This document specifies how to accomplish this using the Diameter protocol. "Diameter Priority Attribute Value Pairs", Ken Carlberg, 31-Oct-11, This document defines Attribute-Value Pair (AVP) containers for various priority parameters for use with Diameter and the AAA framework. The parameters themselves are defined in several different protocols that operate at either the network or application layer. "Diameter Network Access Server Application", Glen Zorn, 18-May-12, This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting (AAA) services in the Network Access Server (NAS) environment; it obsoletes RFC 4005. When combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements. DNS Extensions (dnsext) ----------------------- "Clarifications and Implementation Notes for DNSSECbis", Samuel Weiler, David Blacka, 30-Apr-12, This document is a collection of technical clarifications to the DNSSECbis document set. It is meant to serve as a resource to implementors as well as a repository of DNSSECbis errata. This document updates the core DNSSECbis documents (RFC4033, RFC4034, and RFC4035) as well as the NSEC3 specification (RFC5155). It also defines NSEC3 and SHA-2 as core parts of the DNSSECbis specification. "DNAME Redirection in the DNS", Scott Rose, Wouter Wijngaards, 19-Apr-12, The DNAME record provides redirection for a sub-tree of the domain name tree in the DNS system. That is, all names that end with a particular suffix are redirected to another part of the DNS. This is a revision to the original specification in RFC 2672 (which this document obsoletes) as well as updating RFC 3363 and RFC 4294 to align with this revision. "Extension Mechanisms for DNS (EDNS0)", Joao Damas, Michael Graff, Paul Vixie, 7-Feb-12, The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward compatible mechanisms for allowing the protocol to grow. This document updates the EDNS0 specification (RFC 2671) based on feedback from deployment experience in several implementations. It also closes the IANA registry for extended labels created as part of RFC 2671 and obsoletes RFC 2673 ("Binary Labels in the Domain Name System") which depends on the existence of extended labels. "Signaling Cryptographic Algorithm Understanding in DNSSEC", Steve Crocker, Scott Rose, 1-May-12, The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. This draft sets out to specify a way for validating end-system resolvers to signal to a server which cryptographic algorithms and hash algorithms they support. "Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status", Scott Rose, 19-Apr-12, The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. There is currently an IANA registry for these algorithms that is incomplete in that it lacks the recommended implementation status of each algorithm. This document provides an applicability statement on algorithm implementation status for DNSSEC component software. This document lists each algorithm's status based on the current reference. In the case that an algorithm is specified without an implementation status, this document assigns one. "DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates", Scott Rose, 19-Apr-12, The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. The algorithms specified for use with DNSSEC are reflected in an IANA maintained registry. This document presents a set of changes for some entries of the registry. "DNS Incremental Zone Transfer Protocol (IXFR)", Alfred Hoenes, Ondrej Sury, Shane Kerr, 24-Apr-12, The standard means within the Domain Name System protocol for maintaining coherence among a zone's authoritative name servers consists of three mechanisms. Incremental Zone Transfer (IXFR) is one of the mechanisms and originally was defined in RFC 1995. This document aims to provide a more detailed and up-to-date specification of the IXFR mechanism and to align it with the current specification of the primary zone transfer mechanism, AXFR, given in RFC 5936. Further, based on operational experience, this document juxtaposes to the original IXFR query a new query type, IXFR-ONLY, that will likely be preferred over IXFR in specific deployments. This document obsoletes and replaces RFC 1995. "Domain Name System (DNS) IANA Considerations", Donald Eastlake, 2-May-12, This document specifies Internet Assigned Number Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. It obsoletes RFC 6195. Domain Name System Operations (dnsop) ------------------------------------- "DNS Referral Response Size Issues", Paul Vixie, Akira Kato, 9-May-12, With a mandated default minimum maximum UDP message size of 512 octets, the DNS protocol presents some special problems for zones wishing to expose a moderate or high number of authority servers (NS RRs). This document explains the operational issues caused by, or related to this response size limit, and suggests ways to optimize the use of this limited space. Guidance is offered to DNS server implementors and to DNS zone operators. "DNSSEC Operational Practices, Version 2", Olaf Kolkman, Matthijs Mekking, 13-Apr-12, This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. This document obsoletes RFC 4641 as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations. "DNSSEC Policy & Practice Statement Framework", Fredrik Ljunggren, Anne-Marie Eklund-Lowinder, Tomofumi Okubo, 8-Mar-12, This document presents a framework to assist writers of DNSSEC Policy and Practice Statements such as Domain Managers and Zone Operators on both the top-level and secondary level, who is managing and operating a DNS zone with Security Extensions (DNSSEC) implemented. In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement. Data for Reachability of Inter/tra-NetworK SIP (drinks) ------------------------------------------------------- "Session Peering Provisioning Framework (SPPF)", Kenneth Cartwright, Syed Ali, Alexander Mayrhofer, Vikas Bhatia, 12-Mar-12, This document specifies the data model and the overall structure for a framework to provision session establishment data into Session Data Registries and SIP Service Provider data stores. The framework is called the Session Peering Provisioning Framework (SPPF). The provisioned data is typically used by network elements for session peering. "Session Peering Provisioning (SPP) Protocol over SOAP", Kenneth Cartwright, Vikas Bhatia, 12-Mar-12, The Session Peering Provisioning Framework (SPPF) is an XML framework that exists to enable the provisioning of session establishment data into Session Data Registries or SIP Service Provider data stores. Sending XML data structures over Simple Object Access Protocol (SOAP) and HTTP(s) is a widely used, de-facto standard for messaging between elements of provisioning systems. Therefore the combination of SOAP and HTTP(s) as a transport protocol for SPPF is a natural fit. The obvious benefits include leveraging existing industry expertise, leveraging existing standards, and a higher probability that existing provisioning systems can be more easily integrated with this protocol. This document describes the specification for transporting SPPF XML structures over SOAP and HTTP(s). Email Address Internationalization (eai) ---------------------------------------- "POP3 Support for UTF-8", Randall Gellens, Chris Newman, Jiankang Yao, Kazunori Fujiwara, 10-Apr-12, This specification extends the Post Office Protocol version 3 (POP3) to support un-encoded international characters in user names, passwords, mail addresses, message headers, and protocol-level textual strings. "Post-delivery Message Downgrading for Internationalized Email Messages", Kazunori Fujiwara, 13-Apr-12, The Email Address Internationalization (SMTPUTF8) extension allows UTF-8 characters in mail header fields. Upgraded POP and IMAP servers support internationalized Email messages. If a POP/IMAP client does not support Email Address Internationalization, POP/IMAP servers cannot send Internationalized Email Headers to the client and cannot remove the message. To avoid the situation, this document describes a conversion mechanism for internationalized Email messages to be in traditional message format. In the process, message elements requiring internationalized treatment are recoded or removed and receivers are able to know that they received messages containing such elements even if they cannot treat the internationalized elements. "IMAP Support for UTF-8", Pete Resnick, Chris Newman, Sean Shen, 26-Dec-11, This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support UTF-8 encoded international characters in user names, mail addresses and message headers. This specification replaces RFC 5738. "Mailing Lists and UTF-8 Addresses", John Levine, Randall Gellens, 15-Dec-11, This document describes considerations for mailing lists with the introduction of internationalized email addresses. It outlines some possible scenarios for handling lists with mixtures of internationalized and traditional addresses, but does not offer implementation or deployment advice. "EAI: Simplified POP/IMAP downgrading", Arnt Gulbrandsen, 2-May-12, This document specifies a method for IMAP and POP servers to serve internationalized messages to conventional clients. The specification is simple, easy to implement and provides only rudimentary results. Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- "Best Current Practice for Communications Services in support of Emergency Calling", Brian Rosen, James Polk, 6-Sep-11, The IETF and other standards organization have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks and services using IETF protocols should use such standards to make emergency calls. "Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements", Henning Schulzrinne, Hannes Tschofenig, 11-Mar-12, The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. The main data structure, the element, used for encapsulating information about service boundaries is defined in the LoST protocol specification and circumscribes the region within which all locations map to the same service Uniform Resource Identifier (URI) or set of URIs for a given service. This document defines an XML protocol to exchange these mappings between two nodes. This mechanism is designed for the exchange of authoritative elements between two entities. Exchanging cached elements, i.e. non-authoritative elements, is possible but not envisioned. In any case, this document can also be used without the LoST protocol even though the format of the element is re-used from the LoST specification. "Additional Data related to an Emergency Call", Brian Rosen, Hannes Tschofenig, Roger Marshall, 12-Mar-12, When an emergency call is sent to a Public Safety Answering Point (PSAP), the device that sends it, as well as any service provider in the path of the call, or access network may have information about the call which the PSAP may be able to use. This document describes an XML data structure that contains this kind of information in a standardized form. A Uniform Resource Identifier (URI) that points to the structure can be included in the SIP signaling with the call, or the data may be included in the body of a SIP message. "Data-Only Emergency Calls", Brian Rosen, Henning Schulzrinne, Hannes Tschofenig, 12-Mar-12, 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 and in some rare cases they may require a session to be established. These type of interactions are called 'data-only emergency calls'. "Public Safety Answering Point (PSAP) Callback", Henning Schulzrinne, Hannes Tschofenig, Christer Holmberg, Milan Patel, 11-Mar-12, 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. Note that this version of the document does not yet specify a solution due to the lack of the working group participants agreeing on the requirements. "Trustworthy Location Information", Hannes Tschofenig, Henning Schulzrinne, Bernard Aboba, 4-Apr-12, For some location-based applications, such as emergency calling or roadside assistance, it is important to be able to determine whether location information is trustworthy. This document outlines potential threats to trustworthy location and analyzes the operational issues with potential solutions. "Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices", Henning Schulzrinne, Stephen McCann, Gabor Bajko, Hannes Tschofenig, Dirk Kroeselberg, 12-Mar-12, The IETF emergency services architecture assumes that the calling device has acquired rights to use the access network or that no authentication is required for the access network, such as for public wireless access points. Subsequent protocol interactions, such as obtaining location information, learning the address of the Public Safety Answering Point (PSAP) and the emergency call itself are largely decoupled from the underlying network access procedures. In some cases, however, the device does not have these credentials for network access, does not have a VoIP service provider, or the credentials have become invalid, e.g., because the user has exhausted their prepaid balance or the account has expired. This document provides a problem statement, introduces terminology and describes an extension for the base IETF emergency services architecture to address these scenarios. Energy Management (eman) ------------------------ "Requirements for Energy Management", Juergen Quittek, Rolf Winter, Thomas Dietz, Benoit Claise, Mouli Chandramouli, 13-Mar-12, This document defines requirements for standards specifications for energy management. The requirements defined in this document concern monitoring functions as well as control functions. In detail, the focus of the requirements is on the following features: identification of powered entities, monitoring of their power state, power inlets, power outlets, actual power, power properties, consumed energy, and contained batteries. Further requirements are included to enable control of powered entities' power supply and power state. This document does not specify the features that must be implemented by compliant implementations but rather features that must be supported by standards for energy management. "Energy Management Framework", Benoit Claise, John Parello, Little Silver, Juergen Quittek, Bruce Nordman, 12-Mar-12, This document defines a framework for providing Energy Management for devices within or connected to communication networks, and components thereof. The framework defines an Energy Management Domain as a set of Energy Objects, for which each Energy Object is identified, classified and given context. Energy Objects can be monitored and/or controlled with respect to Power, Power State, Energy, Demand, Power Quality, and battery. Additionally the framework models relationships and capabilities between Energy Objects. "Energy Object Context MIB", John Parello, Benoit Claise, Mouli Chandramouli, 13-Mar-12, This document defines a subset of a Management Information Base (MIB) for energy management of devices. The module addresses device identification, context information, and the relationships between reporting devices, remote devices, and monitoring devices. "Definition of Managed Objects for Battery Monitoring", Juergen Quittek, Rolf Winter, Thomas Dietz, 7-Mar-12, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines managed objects that provide information on the status of batteries in managed devices. "Power and Energy Monitoring MIB", Mouli Chandramouli, Little Silver, Juergen Quittek, Thomas Dietz, Benoit Claise, 9-Mar-12, This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices. "Energy Management (EMAN) Applicability Statement", Mouli Chandramouli, Bruce Nordman, 20-Dec-11, The objective of Energy Management (EMAN) is to provide an energy management framework for networked devices. This document presents the applicability of the EMAN framework for a variety of scenarios. This document lists use cases and target devices that can potentially implement the EMAN framework and associated SNMP MIB modules. These use cases are useful for identifying requirements for the framework. Further, we describe the relationship of the EMAN framework to relevant other energy monitoring standards and architectures. EAP Method Update (emu) ----------------------- "Requirements for a Tunnel Based EAP Method", Hao Zhou, Joseph Salowey, Katrin Hoeper, Stephen Hanna, 19-Dec-10, This memo defines the requirements for a tunnel-based Extensible Authentication Protocol (EAP) Method. This tunnel method will use Transport Layer Security (TLS) to establish a secure tunnel. The tunnel will provide support for password authentication, EAP authentication and the transport of additional data for other purposes. "Channel Binding Support for EAP Methods", Sam Hartman, T. Clancy, Katrin Hoeper, 14-May-12, This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods to address the lying Network Access Service (NAS) as well as the lying provider problem. "Tunnel EAP Method (TEAP) Version 1", Hao Zhou, Nancy Cam-Winget, Joseph Salowey, Stephen Hanna, 11-Mar-12, 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. FEC Framework (fecframe) ------------------------ "Methods to convey FEC Framework Configuration Information", Rajiv Asati, 21-Feb-12, FEC Framework document [RFC6363] defines the FEC Framework Configuration Information necessary for the FEC framework operation. This document describes using existing signaling protocols such as Session Announcement Protocol (SAP), Session Initiation Protocol (SIP), Real Time Stream Protocol (RTSP) etc. to determine and dynamically communicate the Configuration information between sender(s) and receiver(s). "Guidelines for Implementing DVB-IPTV Application-Layer Hybrid FEC Protection", Ali Begen, Thomas Stockhammer, 15-Dec-09, The Annex E of the Digital Video Broadcasting (DVB)-IPTV technical specification defines an optional Application-layer Forward Error Correction (AL-FEC) protocol to protect the streaming media carried over RTP transport. The DVB-IPTV AL-FEC protocol uses two layers for FEC protection. The first (base) layer is based on the 1-D interleaved parity code. The second (enhancement) layer is based on the Raptor code. By offering a layered approach, the DVB-IPTV AL-FEC protocol offers a good protection against both bursty and random packet losses at a cost of decent complexity. This document describes how one can implement the DVB-IPTV AL-FEC protocol by using the 1-D interleaved parity code and Raptor code that have already been specified in separate documents. "Raptor FEC Schemes for FECFRAME", Mark Watson, Thomas Stockhammer, Michael Luby, 10-May-12, This document describes Fully-Specified Forward Error Correction (FEC) Schemes for the Raptor and RaptorQ codes and their application to reliable delivery of media streams in the context of FEC Framework. The Raptor and RaptorQ codes are systematic codes, where a number of repair symbols are generated from a set of source symbols and sent in one or more repair flows in addition to the source symbols that are sent to the receiver(s) within a source flow. The Raptor and RaptorQ codes offer close to optimal protection against arbitrary packet losses at a low computational complexity. Six FEC Schemes are defined, two for protection of arbitrary packet flows, two that are optimised for small source blocks and another two for protection of a single flow that already contains a sequence number. Repair data may be sent over arbitrary datagram transport (e.g. UDP) or using RTP. "Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in FEC Framework", Ulas Kozat, Ali Begen, 17-May-12, This document provides a pseudo Content Delivery Protocol (CDP) to protect multiple source flows with one or more repair flows based on the FEC Framework and the Session Description Protocol (SDP) elements defined for the framework. The purpose of the document is not to provide a full-pledged protocol, but to show how the defined framework and SDP elements can be combined together to design a CDP. "RTP Payload Format for Raptor FEC", Mark Watson, Thomas Stockhammer, 24-Feb-12, This document specifies an RTP Payload Format for Forward Error Correction repair data produced by the Raptor FEC Schemes. Raptor FEC Schemes are specified for use with the IETF FEC Framework which supports transport of repair data over both UDP and RTP. This document specifies the Payload Format which is required for the use of RTP to carry Raptor repair flows. "Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME", Vincent Roca, Mathieu Cunche, Jerome Lacan, Amine Bouabdallah, Kazuhisa Matsuzono, 8-Mar-12, This document describes a fully-specified simple FEC scheme for Reed- Solomon codes over GF(2^^m), with 2 <= m <= 16, that can be used to protect arbitrary media streams along the lines defined by the FECFRAME framework. Reed-Solomon codes belong to the class of Maximum Distance Separable (MDS) codes which means they offer optimal protection against packet erasures. They are also systematic codes, which means that the source symbols are part of the encoding symbols. The price to pay is a limit on the maximum source block size, on the maximum number of encoding symbols, and a computational complexity higher than that of LDPC codes for instance. "Simple LDPC-Staircase Forward Error Correction (FEC) Scheme for FECFRAME", Vincent Roca, Mathieu Cunche, Jerome Lacan, 8-Mar-12, This document describes a fully-specified simple FEC scheme for LDPC- Staircase codes that can be used to protect media streams along the lines defined by the FECFRAME framework. These codes have many interesting properties: they are systematic codes, they perform close to ideal codes in many use-cases and they also feature very high encoding and decoding throughputs. LDPC-Staircase codes are therefore a good solution to protect a single high bitrate source flow, or to protect globally several mid-rate flows within a single FECFRAME instance. They are also a good solution whenever the processing load of a software encoder or decoder must be kept to a minimum. Forwarding and Control Element Separation (forces) -------------------------------------------------- "ForCES Logical Function Block (LFB) Library", Weiming Wang, Evangelos Haleplidis, Kentaro Ogawa, Chuanhuang Li, Joel Halpern, 22-May-12, This document defines basic classes of Logical Function Blocks (LFBs) used in the Forwarding and Control Element Separation (ForCES). The basic LFB classes are defined according to ForCES FE model and ForCES protocol specifications, and are scoped to meet requirements of typical router functions and considered as the basic LFB library for ForCES. The library includes the descriptions of the LFBs and the XML definitions. "ForCES Intra-NE High Availability", Kentaro Ogawa, Weiming Wang, Evangelos Haleplidis, Jamal Hadi Salim, 20-Feb-12, This document discusses CE High Availability within a ForCES NE. "Interoperability Report for Forwarding and Control Element Separation (ForCES)", Evangelos Haleplidis, Jamal Hadi Salim, Kentaro Ogawa, Ming Gao, Weiming Wang, 9-Jan-12, This document captures test results from the second Forwarding and control Element Separation (ForCES) interoperability test which took place on February 24-25, 2011 in the Internet Technology Lab (ITL) of Zhejiang Gongshang University, China. Geographic Location/Privacy (geopriv) ------------------------------------- "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", Jorge Cuellar, Hannes Tschofenig, Henning Schulzrinne, James Polk, John Morris, Martin Thomson, 14-Oct-11, This document defines an authorization policy language for controlling access to location information. It extends the Common Policy authorization framework to provide location-specific access control. More specifically, this document defines condition elements specific to location information in order to restrict access based on the current location of the Target. Furthermore, this document defines two algorithms for reducing the granularity of returned location information. The first algorithm is defined for usage with civic location information while the other one applies to geodetic location information. Both algorithms come with limitations, i.e. they provide location obfuscation under certain conditions and may therefore not be appropriate for all application domains. "Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)", James Polk, 12-Mar-12, This document creates a Dynamic Host Configuration Protocol (DHCP) Option for transmitting a client's geolocation Uniform Resource Identifier (URI). This Location URI can then be dereferenced in a separate transaction by the client or sent to another entity and dereferenced to learn physically where the client is located. "A Location Dereferencing Protocol Using HELD", James Winterbottom, Hannes Tschofenig, Henning Schulzrinne, Martin Thomson, 7-May-12, This document describes how to use the Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS) as a dereferencing protocol to resolve a reference to a Presence Information Data Format Location Object (PIDF-LO). The document assumes that a Location Recipient possesses a URI that can be used in conjunction with the HTTP-Enabled Location Delivery (HELD) protocol to request the location of the Target. "Location Configuration Extensions for Policy Management", Martin Thomson, James Winterbottom, Richard Barnes, Hannes Tschofenig, 28-Nov-11, Current location configuration protocols are capable of provisioning an Internet host with a location URI that refers to the host's location. These protocols lack a mechanism for the target host to inspect or set the privacy rules that are applied to the URIs they distribute. This document extends the current location configuration protocols to provide hosts with a reference to the rules that are applied to a URI, so that the host can view or set these rules. "Location Information Server (LIS) Discovery using IP address and Reverse DNS", Martin Thomson, Ray Bellis, 29-Mar-12, The residential gateway is a device that has become an integral part of home networking equipment. Discovering a Location Information Server (LIS) is a necessary part of acquiring location information for location-based services. However, discovering a LIS when a residential gateway is present poses a configuration challenge, requiring a method that is able to work around the obstacle presented by the gateway. This document describes a solution to this problem. The solution provides alternative domain names as input to the LIS discovery process based on the network addresses assigned to a Device. "Specifying Civic Address Extensions in PIDF-LO", James Winterbottom, Martin Thomson, Richard Barnes, Brian Rosen, Robins George, 28-Feb-12, New fields are occasionally added to civic addresses. A backwardly- compatible mechanism for adding civic address elements to the Geopriv civic address format is described. A formal mechanism for handling unsupported extensions when translating between XML and DHCP civic address forms is defined for entities that need to perform this translation. Intial extensions for some new elements are also defined. The LoST protocol mechanism that returns civic address element names used for validation of location information is clarified to require a namespace on each element. Global Routing Operations (grow) -------------------------------- "BGP Monitoring Protocol", John Scudder, Rex Fernando, Stephen Stuart, 1-Dec-11, This document proposes a simple protocol, BMP, which can be used to monitor BGP sessions. BMP is intended to provide a more convenient interface for obtaining route views for research purpose than the screen-scraping approach in common use today. The design goals are to keep BMP simple, useful, easily implemented, and minimally service-affecting. BMP is not suitable for use as a routing protocol. "FIB Suppression with Virtual Aggregation", Paul Francis, Xiaohu Xu, Hitesh Ballani, Dan Jen, Robert Raszuk, Lixia Zhang, 30-Dec-11, The continued growth in the Default Free Routing Table (DFRT) stresses the global routing system in a number of ways. One of the most costly stresses is FIB size: ISPs often must upgrade router hardware simply because the FIB has run out of space, and router vendors must design routers that have adequate FIB. FIB suppression is an approach to relieving stress on the FIB by not loading selected RIB entries into the FIB. Virtual Aggregation (VA) allows ISPs to shrink the FIBs of any and all routers, easily by an order of magnitude with negligible increase in path length and load. FIB suppression can be deployed autonomously by an ISP without requiring cooperation between adjacent ISPs, and can co-exist with legacy routers in the ISP. "Graceful BGP session shutdown", Pierre Francois, Bruno Decraene, Cristel Pelsser, Keyur Patel, Clarence Filsfils, 8-Dec-11, This draft describes operational procedures aimed at reducing the amount of traffic lost during planned maintenances of routers or links, involving the shutdown of BGP peering sessions. "Auto-Configuration in Virtual Aggregation", Paul Francis, Xiaohu Xu, Hitesh Ballani, Dan Jen, Robert Raszuk, Lixia Zhang, 30-Dec-11, Virtual Aggregation as specified in [I-D.ietf-grow-va] requires configuration of a static "VP-List" on all routers. The VP-List allows routers to know which prefixes may or may not be FIB- installed. This draft specified an optional method of determining this that requires far less configuration. Specifically, it requires the configuration of a "VP-Range" in ASBRs connected to transit and peer ISPs. A Non-transitive Extended Communities Attribute is used to convey to other routers that a given route can be FIB-suppressed. "Simple Virtual Aggregation (S-VA)", Robert Raszuk, Alton Lo, Lixia Zhang, Xiaohu Xu, 3-May-12, The continued growth in the Default Free Routing Table (DFRT) stresses the global routing system in a number of ways. One of the most costly stresses is FIB size: ISPs often must upgrade router hardware simply because the FIB has run out of space, and router vendors must design routers that have adequate FIB. FIB suppression is an approach to relieving stress on the FIB by NOT loading selected RIB entries into the FIB. Simple Virtual Aggregation (S-VA) is a simple form of Virtual Aggregation (VA) that allows any and all edge routers to shrink their RIB and FIB requirements substantially and therefore increase their useful lifetime. S-VA does not increase FIB requirements for core routers. S-VA is extremely easy to configure considerably more so than the various tricks done today to extend the life of edge routers. S-VA can be deployed autonomously by an ISP (cooperation between ISPs is not required), and can co-exist with legacy routers in the ISP. "Distribution of diverse BGP paths.", Robert Raszuk, Rex Fernando, Keyur Patel, Danny McPherson, Kenji Kumaki, 3-May-12, The BGP4 protocol specifies the selection and propagation of a single best path for each prefix. As defined and widely deployed today BGP has no mechanisms to distribute alternate paths which are not considered best path between its speakers. This behaviour results in number of disadvantages for new applications and services. This document presents an alternative mechanism for solving the problem based on the concept of parallel route reflector planes. Such planes can be built in parallel or they can co-exist on the current route reflection platforms. Document also compares existing solutions and proposed ideas that enable distribution of more paths than just the best path. This proposal does not specify any changes to the BGP protocol definition. It does not require upgrades to provider edge or core routers nor does it need network wide upgrades. "Operational Requirements for Enhanced Error Handling Behaviour in BGP-4", Rob Shakir, 27-Mar-12, BGP-4 is utilised as a key intra- and inter-Autonomous System routing protocol in modern IP networks. The failure modes as defined by the original protocol standards are based on a number of assumptions around the impact of session failure. Numerous incidents both in the global Internet routing table and within Service Provider networks have been caused by strict handling of a single invalid UPDATE message causing large-scale failures in one or more Autonomous Systems. This memo describes the current use of BGP-4 within Service Provider networks, and outlines a set of requirements for further work to enhance the mechanisms available to a BGP-4 implementation when erroneous data is detected. Whilst this document does not provide specification of any standard, it is intended as an overview of a set of enhancements to BGP-4 to improve the protocol's robustness to suit its current deployment. "Issues with Private IP Addressing in the Internet", Anthony Kirkham, 12-May-12, The purpose of this document is to provide a discussion of the potential problems of using private, RFC1918, or non-globally- routable addressing within the core of an SP network. The discussion focuses on link addresses and to a small extent loopback addresses. While many of the issues are well recognised within the ISP community, there appears to be no document that collectively describes the issues. Host Identity Protocol (hip) ---------------------------- "Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)", Ari Keranen, Gonzalo Camarillo, Jouni Maenpaa, 23-Apr-12, This document is the Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) instance specification for the REsource LOcation And Discovery (RELOAD) protocol. The document provides the details needed to build a RELOAD-based overlay that uses HIP. "Host Identity Protocol Version 2 (HIPv2)", Robert Moskowitz, Tobias Heer, Petri Jokela, Tom Henderson, 12-Mar-12, 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. "Native NAT Traversal Mode for the Host Identity Protocol", Ari Keranen, Jan Melen, 22-Dec-11, This document specifies a new Network Address Translator (NAT) traversal mode for the Host Identity Protocol (HIP). The new mode is based on the Interactive Connectivity Establishment (ICE) methodology and UDP encapsulation of data and signaling traffic. The main difference from the previously specified modes is the use of HIP messages for all NAT traversal procedures. Handover Keying (hokey) ----------------------- "EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK)", Zehn Cao, Hui Deng, Wenson Wu, Glen Zorn, 1-May-12, The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. The EAP Re-authentication Protocol (ERP) specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator. Authenticated Anticipatory Keying (AAK) is a method by which cryptographic keying material may be established upon one or more candidate attachment points (CAPs) prior to handover. AAK uses the AAA infrastructure for key transport. This document specifies the extensions necessary to enable AAK support in ERP. "Handover Keying (HOKEY) Architecture Design", Glen Zorn, Qin Wu, Tom Taylor, Yoav Nir, Katrin Hoeper, Sebastien Decugis, 13-Jan-12, The Handover Keying (HOKEY) Working Group seeks to minimize handover delay due to authentication when a peer moves from one point of attachment to another. Work has progressed on two different approaches to reduce handover delay: early authentication (so that authentication does not need to be performed during handover), and reuse of cryptographic material generated during an initial authentication to save time during re-authentication. A basic assumption is that the mobile host or "peer" is initially authenticated using the Extensible Authentication Protocol (EAP), executed between the peer and an EAP server as defined in RFC 3748. This document defines the HOKEY architecture. Specifically, it describes design objectives, the functional environment within which handover keying operates, the functions to be performed by the HOKEY architecture itself, and the assignment of those functions to architectural components. It goes on to illustrate the operation of the architecture within various deployment scenarios that are described more fully in other documents produced by the HOKEY Working Group. "EAP Extensions for EAP Re-authentication Protocol (ERP)", Zhen Cao, Baohong He, Yang Shi, Wenson Wu, Glen Zorn, 17-May-12, The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to avoid repeating the entire EAP exchange with another authenticator. This document specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re- authentication between the peer and an EAP re-authentication server through any authenticator. The re-authentication server may be in the home network or in the local network to which the peer is connecting. This memo obsoletes RFC 5296. Home Networking (homenet) ------------------------- "Home Networking Architecture for IPv6", Tim Chown, Jari Arkko, Anders Brandt, Ole Troan, Jason Weil, 12-Mar-12, This text describes evolving networking technology within small residential home networks. The goal of this memo is to define the architecture for IPv6-based home networking and the associated principles, considerations and requirements. The text briefly highlights the implications of the introduction of IPv6 for home networking, discusses topology scenarios, 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 Bis (httpbis) ----------------------------------------- "HTTP/1.1, part 1: URIs, Connections, and Message Parsing", Roy Fielding, Yves Lafon, Julian Reschke, 12-Mar-12, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 1 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616 and moves it to historic status, along with its predecessor RFC 2068. Part 1 provides an overview of HTTP and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations. This part also obsoletes RFCs 2145 (on HTTP version numbers) and 2817 (on using CONNECT for TLS upgrades) and moves them to historic status. "HTTP/1.1, part 2: Message Semantics", Roy Fielding, Yves Lafon, Julian Reschke, 12-Mar-12, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields. "HTTP/1.1, part 3: Message Payload and Content Negotiation", Roy Fielding, Yves Lafon, Julian Reschke, 12-Mar-12, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation. "HTTP/1.1, part 4: Conditional Requests", Roy Fielding, Yves Lafon, Julian Reschke, 12-Mar-12, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests. "HTTP/1.1, part 5: Range Requests and Partial Responses", Roy Fielding, Yves Lafon, Julian Reschke, 12-Mar-12, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests. "HTTP/1.1, part 6: Caching", Roy Fielding, Yves Lafon, Mark Nottingham, Julian Reschke, 12-Mar-12, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 6 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. "HTTP/1.1, part 7: Authentication", Roy Fielding, Yves Lafon, Julian Reschke, 12-Mar-12, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines the HTTP Authentication framework. "Initial Hypertext Transfer Protocol (HTTP) Method Registrations", Julian Reschke, 3-Jan-12, This document registers those Hypertext Transfer Protocol (HTTP) methods which have been defined in standards-track RFCs before the IANA HTTP Method Registry was established. "Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations", Julian Reschke, 20-Feb-12, This document registers Hypertext Transfer Protocol (HTTP) authentication schemes which have been defined in standards-track RFCs before the IANA HTTP Authentication Scheme Registry was established. BiDirectional or Server-Initiated HTTP (hybi) --------------------------------------------- "WebSocket Per-frame Compression", Takeshi Yoshino, 22-May-12, This specification defines a WebSocket extension that adds per-frame compression functionality to the WebSocket Protocol. It compresses the "Application data" portion of WebSocket data frames using specified compression algorithm. One reserved bit RSV1 in the WebSocket frame header is allocated to control application of compression for each frame. This specification provides one compression method available for the extension using DEFLATE. Please send feedback to the hybi@ietf.org mailing list. "A Multiplexing Extension for WebSockets", John Tamplin, Takeshi Yoshino, 19-Apr-12, The WebSocket Protocol [RFC6455] requires a new transport connection for every WebSocket connection. This presents a scalability problem when many clients connect to the same server, and is made worse by having multiple clients running in different tabs of the same user agent. This extension provides a way for separate logical WebSocket connections to share an underlying transport connection. Please send feedback to the hybi@ietf.org mailing list. Inter-Domain Routing (idr) -------------------------- "Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4), Second Version", Jeffrey Haas, 12-Mar-12, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing the Border Gateway Protocol, Version 4. "Dynamic Capability for BGP-4", Srihari Ramachandra, Enke Chen, 5-Dec-11, This document defines a new BGP capability termed "Dynamic Capability", which would allow the dynamic update of capabilities over an established BGP session. This capability would facilitate non-disruptive capability changes by BGP speakers. "Issues in Revising BGP-4 (RFC1771 to RFC4271)", Andrew Lange, 27-Mar-12, This document records the issues discussed and the consensus reached in the Interdomain Routing (IDR) Working Group during its efforts to revise and bring up to date the base specification for the BGP-4 protocol as documented in RFC1771. The document focuses on the changes tracked from August 2002 when the last major push for revision began. The results of these efforts are encoded in RFC4271, which should be taken as normative for any of the issues that were discussed. The discussion here is intended to record how and why some of the changes to BGP were made. "Generic Subtype for BGP Four-octet AS specific extended community", Dhananjaya Rao, Pradosh Mohapatra, Jeffrey Haas, 11-Mar-12, Maintaining the current best practices with communities, ISPs and enterprises that are assigned a 4-octet AS number may want the BGP UPDATE messages they receive from their customers or peers to include a 4-octet AS specific BGP extended community. This document defines a new sub-type within the four-octet AS specific extended community to facilitate this practice. "BGP Support for Four-octet AS Number Space", Quaizar Vohra, Enke Chen, 24-Apr-12, The Autonomous System (AS) number is encoded as a two-octet entity in the base BGP specification. This document describes extensions to BGP to carry the Autonomous System numbers as four-octet entities. This document obsoletes RFC 4893. "BGP Link Bandwidth Extended Community", Pradosh Mohapatra, Rex Fernando, 9-Apr-12, This document describes an application of BGP extended communities that allows a router to perform unequal cost load balancing. "The Accumulated IGP Metric Attribute for BGP", Pradosh Mohapatra, Rex Fernando, Eric Rosen, James Uttaro, 12-Dec-11, Routing protocols that have been designed to run within a single administrative domain ("IGPs") generally do so by assigning a metric to each link, and then choosing as the installed path between two nodes the path for which the total distance (sum of the metric of each link along the path) is minimized. BGP, designed to provide routing over a large number of independent administrative domains ("autonomous systems"), does not make its path selection decisions through the use of a metric. It is generally recognized that any attempt to do so would incur significant scalability problems, as well as inter-administration coordination problems. However, there are deployments in which a single administration runs several contiguous BGP networks. In such cases, it can be desirable, within that single administrative domain, for BGP to select paths based on a metric, just as an IGP would do. The purpose of this document is to provide a specification for doing so. "Advertisement of the best external route in BGP", Pedro Marques, Rex Fernando, Enke Chen, Pradosh Mohapatra, Hannes Gredler, 3-Jan-12, The current BGP-4 protocol specification [RFC4271] states that the selection process chooses the best path for a given route which is added to the Loc-Rib and advertised to all peers. Previous versions [RFC1771] of the specification defined a different rule for Internal BGP Updates. Given that Internal paths are not re- advertised to Internal peers, it was specified that the best of the external paths, as determined by the path selection tie breaking algorithm, would be advertised to Internal peers. This document extends that procedure to operate in environments where Route Reflection [RFC4456] or Confederations [RFC5065] are used and explains why advertising the additional routing information can improve convergence time without causing routing loops. Additional benefits include reduction of inter-domain churn and avoidance of permanent route oscillation. "Best Practices for Advertisement of Multiple Paths in IBGP", James Uttaro, Place Barbe, Pierre Francois, Roberto Fragassi, Adam Simpson, Pradosh Mohapatra, 25-Nov-11, Add-Paths is a BGP enhancement that allows a BGP router to advertise multiple distinct paths for the same prefix/NLRI. This provides a number of potential benefits, including reduced routing churn, faster convergence and better loadsharing. This document provides recommendations to implementers of Add-Paths so that network operators have the tools needed to address their specific applications and to manage the scalability impact of Add- Paths. A router implementing Add-Paths may learn many paths for a prefix and must decide which of these to advertise to peers. This document analyses different algorithms for making this selection and provides recommendations based on the target application. "Assigned BGP extended communities", Bruno Decraene, Pierre Francois, 21-May-12, 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, 16-Dec-11, In this document we enhance the existing BGP route refresh mechanisms to provide for the demarcation of the beginning and the ending of a route refresh. The enhancement can be used to facilitate on-line, non-disruptive consistency validations of BGP routing updates. "Dissemination of Flow Specification Rules for IPv6", Robert Raszuk, Burjiz Pithawala, Danny McPherson, 29-Apr-12, Dissemination of Flow Specification Rules [RFC5575] provides a protocol extension for propagation of traffic flow information for the purpose of rate limiting or filtering. The [RFC5575] specifies those extensions for IPv4 protocol data packets. This specification extends the current [RFC5575] and defines changes to the original document in order to make it also usable and applicable to IPv6 data packets. "BGP Optimal Route Reflection (BGP-ORR)", Robert Raszuk, Christian Cassar, Erik Aman, Bruno Decraene, 3-May-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, Randy Bush, 10-Jan-12, The BGP specification mandates a maximum BGP message size of 4096 octets. As BGP is extended to support newer AFI/SAFIs, there is a need to extend the maximum message size beyond 4096 octets. This draft provides an extension to BGP to extend its current message size from 4096 octets to 65535 octets. "Revised Error Handling for BGP UPDATE Messages", John Scudder, Enke Chen, Pradosh Mohapatra, Keyur Patel, 15-Dec-11, According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable as a session reset would impact not only routes with the offending attribute, but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages, and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for several existing attributes. "BGP Custom Decision Process", Alvaro Retana, Russ White, 18-May-12, 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, 22-May-12, This document updates RFC 4271 and proscribes the use of AS 0 in BGP OPEN and AS_PATH / AS4_PATH BGP attribute. "Accelerated Routing Convergence for BGP Graceful Restart", Keyur Patel, Enke Chen, Rex Fernando, John Scudder, 5-Dec-11, In this document we specify extensions to BGP graceful restart in order to avoid unnecessary transmission of the routing information preserved across a session restart, thus accelerating the routing convergence. "Notification Message support for BGP Graceful Restart", Keyur Patel, Rex Fernando, John Scudder, 6-Dec-11, The current BGP Graceful Restart mechanism limits the usage of BGP Graceful Restart to BGP protocol messages other than a BGP NOTIFICATION message. This document defines an extension to the BGP Graceful Restart that permits the Graceful Restart procedures to be performed when the BGP speaker receives a BGP NOTIFICATION Message. This document also defines a new BGP NOTIFICATION Cease Error subcode to prevent BGP speakers supporting the extension defined in this document from performing a Graceful Restart. "Automatic Route Target Filtering for legacy PEs", Pradosh Mohapatra, Arjun Sreekantiah, Keyur Patel, Burjiz Pithawala, Alton Lo, 18-Jan-12, This document describes a simple procedure that allows "legacy" BGP speakers to exchange route target membership information in BGP without using mechanisms specified in RFC 4684. The intention of the proposed technique is to help in partial deployment scenarios and is not meant to replace RFC 4684. "Carrying next-hop cost information in BGP", Ilya Varlashkin, Robert Raszuk, 27-Mar-12, This document describes new BGP SAFI to exchange cost information to next-hops for the purpose of calculating best path from a peer perspective rather than local BGP speaker own perspective. "BGP OPERATIONAL Message", David Freedman, Robert Raszuk, Rob Shakir, 13-Mar-12, The BGP Version 4 routing protocol (RFC4271) is now used in many ways, crossing boundaries of administrative and technical responsibility. The protocol lacks an operational messaging plane which could be utilised to diagnose, troubleshoot and inform upon various conditions across these boundaries, securely, during protocol operation, without disruption. This document proposes a new BGP message type, the OPERATIONAL message, which can be used to effect such a messaging plane for use both between and within Autonomous Systems. "Internet Exchange Route Server", Elisa Jasinska, Nick Hilliard, Robert Raszuk, Niels Bakker, 26-Mar-12, 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. Internet Area Working Group (intarea) ------------------------------------- "Updated Specification of the IPv4 ID Field", Joseph Touch, 16-Sep-11, The IPv4 Identification (ID) field enables fragmentation and reassembly, and as currently specified is required to be unique within the maximum lifetime for all datagrams with a given source/destination/protocol tuple. If enforced, this uniqueness requirement would limit all connections to 6.4 Mbps. Because individual connections commonly exceed this speed, it is clear that existing systems violate the current specification. This document updates the specification of the IPv4 ID field in RFC791, RFC1122, and RFC2003 to more closely reflect current practice and to more closely match IPv6 so that the field's value is defined only when a datagram is actually fragmented. It also discusses the impact of these changes on how datagrams are used. "Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID) in Shared Address Deployments", Mohamed Boucadair, Joseph Touch, Pierre Levis, Reinaldo Penno, 17-Apr-12, This document analyzes a set of solution candidates to mitigate some of the issues encountered when address sharing is used. In particular, this document focuses on means to reveal a host identifier (HOST_ID) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. This host identifier must be unique to each host under the same shared IP address. IP Flow Information Export (ipfix) ---------------------------------- "Configuration Data Model for IPFIX and PSAMP", Gerhard Muenz, Benoit Claise, Paul Aitken, 11-Jul-11, This document specifies a data model for configuring and monitoring Selection Processes, Caches, Exporting Processes, and Collecting Processes of IPFIX and PSAMP compliant Monitoring Devices using the NETCONF protocol. The data model is defined using UML (Unified Modeling Language) class diagrams and formally specified using YANG. The configuration data is encoded in Extensible Markup Language (XML). "Flow Selection Techniques", Salvatore D'Antonio, Tanja Zseby, Christian Henke, Lorenzo Peluso, 23-Apr-12, Flow selection is the process of selecting a subset of flows from all observed flows. The Flow Selection Process may be located at an observation point, or on an IPFIX Mediator. Flow selection reduces the effort of post-processing flow data and transferring Flow Records. This document describes motivations for flow selection and presents flow selection techniques. It provides an information model for configuring flow selection techniques and discusses what information about a flow selection process should be exported. "Definitions of Managed Objects for Packet Sampling", Thomas Dietz, Benoit Claise, Juergen Quittek, 31-Oct-11, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes extensions to the IPFIX SELECTOR MIB module [I-D.dkcm-ipfix-rfc5815bis]. For IPFIX implementations that use packet Sampling (PSAMP) techniques as described in [RFC5475], this memo defines the PSAMP MIB module containing managed objects for providing information on applied packet selection functions and their parameters. "Definitions of Managed Objects for IP Flow Information Export", Thomas Dietz, Atsushi Kobayashi, Benoit Claise, Gerhard Muenz, 26-Mar-12, This document defines managed objects for IP Flow Information eXport (IPFIX). These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors including the basic configuration information. "Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol", Brian Trammell, Arno Wagner, Benoit Claise, 27-Feb-12, This document describes the export of aggregated Flow information using IPFIX. An Aggregated Flow is essentially an IPFIX Flow representing packets from multiple Original Flows sharing some set of common properties. The document describes Aggregated Flow export within the framework of IPFIX Mediators and defines an interoperable, implementation-independent method for Aggregated Flow export. "Guidelines for Authors and Reviewers of IPFIX Information Elements", Brian Trammell, Benoit Claise, 7-Mar-12, This document provides guidelines for the definition of IPFIX Information Elements for addition to the IANA IPFIX Information Element registry, in order to extend the applicability of the IPFIX protocol to new operations and management areas. "Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information", Benoit Claise, Brian Trammell, 7-Mar-12, 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 an information Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101. "Specification of the Protocol for IPFIX Mediation", Benoit Claise, Atsushi Kobayashi, Brian Trammell, 6-Dec-11, This document specifies the IP Flow Information Export (IPFIX) protocol specific to Mediation. "Information Model for IP Flow Information eXport (IPFIX)", Benoit Claise, Brian Trammell, 8-Mar-12, This memo defines an overview of the information model for the IP Flow Information eXport (IPFIX) protocol. It is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although developed for the IPFIX protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications. This document obsoletes RFC 5102. IP Performance Metrics (ippm) ----------------------------- "Reporting IP Network Performance Metrics: Different Points of View", Al Morton, Gomathi Ramachandran, Ganga Maguluri, 10-May-12, Consumers of IP network performance metrics have many different uses in mind. The memo provides "long-term" reporting considerations (e.g., hours, days, weeks or months, as opposed to 10 seconds), based on analysis of the two key audience points-of-view. It describes how the audience categories affect the selection of metric parameters and options when seeking info that serves their needs. "Round-trip Packet Loss Metrics", Al Morton, 8-May-12, Many user applications (and the transport protocols that make them possible) require two-way communications. To assess this capability, and to achieve test system simplicity, round-trip loss measurements are frequently conducted in practice. The Two-Way Active Measurement Protocol specified in RFC 5357 establishes a round-trip loss measurement capability for the Internet. However, there is currently no metric specified according to the RFC 2330 framework. This memo adds round-trip loss to the set of IP Performance Metrics (IPPM). "Test Plan and Results for Advancing RFC 2679 on the Standards Track", Len Ciavattone, Ruediger Geib, Al Morton, Matthias Wieser, 11-Mar-12, This memo proposes to advance a performance metric RFC along the standards track, specifically RFC 2679 on One-way Delay Metrics. Observing that the metric definitions themselves should be the primary focus rather than the implementations of metrics, this memo describes the test procedures to evaluate specific metric requirement clauses to determine if the requirement has been interpreted and implemented as intended. Two completely independent implementations have been tested against the key specifications of RFC 2679. "Ericsson TWAMP Value-Added Octets", Steve Baillargeon, Christofer Flinta, Andreas Johnsson, Svante Ekelin, 26-Apr-12, This memo describes an extension to the TWAMP test protocol for identifying and managing packet trains, which enables measuring capacity metrics like the available path capacity, tight section capacity and UDP delivery rate in the forward and reverse path directions. This memo contains the description of a working prototype. It does not represent a consensus of the IETF community. The IETF community is currently working on the problem statement and has not reached consensus on the preferred method for measuring capacity metrics. IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ "Point to Point VPNs Problem Statement", Stephen Hanna, 6-Mar-12, This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. Manual configuration of all possible tunnels is too cumbersome in such cases, so an automated method is needed. Internationalized Resource Identifiers (iri) -------------------------------------------- "Internationalized Resource Identifiers (IRIs)", Martin Duerst, Michel Suignard, Larry Masinter, 11-Mar-12, This document defines the Internationalized Resource Identifier (IRI) protocol element, as an extension of the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). Grammar and processing rules are given for IRIs and related syntactic forms. Defining IRI as a new protocol element (rather than updating or extending the definition of URI) allows independent orderly transitions: protocols and languages that use URIs must explicitly choose to allow IRIs. Guidelines are provided for the use and deployment of IRIs and related protocol elements when revising protocols, formats, and software components that currently deal only with URIs. This document is part of a set of documents intended to replace RFC 3987. "Guidelines and Registration Procedures for New URI/IRI Schemes", Tony Hansen, Ted Hardie, Larry Masinter, 13-Dec-11, This document updates the guidelines and recommendations for the definition of Uniform Resource Identifier (URI) schemes, and extends the registry and guidelines to apply when the schemes are used with Internationalized Resource Identifiers (IRIs). It also updates the process and IANA registry for URI/IRI schemes. It obsoletes RFC 4395. "Guidelines for Internationalized Resource Identifiers with Bi- directional Characters (Bidi IRIs)", Martin Duerst, Larry Masinter, Adil Allawi, 9-Mar-12, This specification gives guidelines for selection, use, and presentation of International Resource Identifiers (IRIs) which include characters with inherent right-to-left (rtl) writing direction. "Equivalence and Canonicalization of Internationalized Resource Identifiers (IRIs)", Larry Masinter, Martin Duerst, 1-Mar-12, Internationalized Resource Identifiers (IRIs) are unicode strings used to identify resources on the Internet. Applications that use IRIs often define a means of comparing two IRIs to determine when two IRIs are equivalent for the purpose of that application. Some applications also define a method for 'canonicalizing' or 'normalizing' an IRI -- translating one IRI into another which is equivalent under the comparison method used. This document gives guidelines and best practices for defining and using IRI comparison, equivalence, normalization and canonicalization methods. IS-IS for IP Internets (isis) ----------------------------- "Advertising Generic Information in IS-IS", Les Ginsberg, Stefano Previdi, Mike Shand, 10-Nov-10, This draft describes the manner in which generic application information (i.e. information not directly related to the operation of the IS-IS protocol) should be advertised in IS-IS LSPs and defines guidelines which should be used when flooding such information. "IS-IS Multi-Instance", Abhay Roy, David Ward, Les Ginsberg, Mike Shand, Stefano Previdi, 14-Feb-12, This draft describes a mechanism that allows a single router to share one or more circuits among multiple Intermediate System To Intermediate System (IS-IS) routing protocol instances. Multiple instances allow the isolation of resources associated with each instance. Routers will form instance specific adjacencies. Each instance can support multiple topologies. Each topology has a unique Link State Database (LSDB). Each Protocol Data Unit (PDU) will contain a new Type Length Value (TLV) identifying the instance and the topology(ies) to which the PDU belongs. Javascript Object Signing and Encryption (jose) ----------------------------------------------- "JSON Web Algorithms (JWA)", Michael Jones, 12-May-12, The JSON Web Algorithms (JWA) specification enumerates cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS) and JSON Web Encryption (JWE) specifications. "JSON Web Encryption (JWE)", Michael Jones, Eric Rescorla, Joe Hildebrand, 12-May-12, JSON Web Encryption (JWE) is a means of representing encrypted content using JSON data structures. Cryptographic algorithms and identifiers used with this specification are enumerated in the separate JSON Web Algorithms (JWA) specification. Related digital signature and MAC capabilities are described in the separate JSON Web Signature (JWS) specification. "JSON Web Key (JWK)", Michael Jones, 12-May-12, A JSON Web Key (JWK) is a JSON data structure that represents a public 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 used with this specification are enumerated in the separate JSON Web Algorithms (JWA) specification. "JSON Web Signature (JWS)", Michael Jones, John Bradley, Nat Sakimura, 12-May-12, JSON Web Signature (JWS) is a means of representing content secured with digital signatures or Message Authentication Codes (MACs) using JSON data structures. Cryptographic algorithms and identifiers used with this specification are enumerated in the separate JSON Web Algorithms (JWA) specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. Keying and Authentication for Routing Protocols (karp) ------------------------------------------------------ "Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements", Gregory Lebovitz, Manav Bhatia, 10-May-12, Different routing protocols exist and each employs its own mechanism for securing the protocol packets on the wire. While most already have some method for accomplishing cryptographic message authentication, in many cases the existing methods are dated, vulnerable to attack, and employ cryptographic algorithms that have been deprecated. The "Keying and Authentication for Routing Protocols" (KARP) effort aims to overhaul and improve these mechanisms. This document does not contain protocol specifications. Instead, it defines the areas where protocol specification work is needed and a set of requirements for KARP design teams to follow. RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" is a companion to this document; KARP design teams will use them together to review and overhaul routing protocols. These two documents reflect the input of both the IETF's Security Area and Routing Area in order to form a mutually agreeable work plan. This document has three main parts. The first part provides an overview of the KARP effort. The second part lists the threats from RFC 4593, Generic Threats To Routing Protocols, that are in scope for attacks against routing protocols' transport systems, including any mechanisms built into the routing protocols themselves, which accomplish packet authentication. The third part enumerates the requirements that routing protocol specifications must meet when addressing those threats for RFC 6518's "Work Phase 1", the update to a routing protocol's existing transport security. "Analysis of OSPF Security According to KARP Design Guide", Sam Hartman, Dacheng Zhang, 12-Mar-12, This document analyzes OSPFv2 and OSPFv3 according to the guidelines set forth in section 4.2 of draft-ietf-karp-design-guide. "Operations Model for Router Keying", Sam Hartman, Dacheng Zhang, 25-Apr-12, 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 Security According to KARP Design Guide", Mahesh Jethanandani, Keyur Patel, Lianshu Zheng, 26-Mar-12, This document analyzes BGP, LDP, PCEP and MSDP according to guidelines set forth in section 4.2 of Keying and Authentication for Routing Protocols Design Guidelines [RFC6518]. Common Authentication Technology Next Generation (kitten) --------------------------------------------------------- "GSS-API Naming Extensions", Nico Williams, Leif Johansson, Sam Hartman, Simon Josefsson, 27-Mar-12, The Generic Security Services API (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers. "A SASL & GSS-API Mechanism for OpenID", Eliot Lear, Hannes Tschofenig, Henry Mauldin, Simon Josefsson, 24-Feb-12, OpenID has found its usage on the Internet for Web Single Sign-On. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL and GSS-API mechanism for OpenID that allows the integration of existing OpenID Identity Providers with applications using SASL and GSS-API. "SAML Enhanced Client SASL and GSS-API Mechanisms", Scott Cantor, Simon Josefsson, 28-Feb-12, 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. Kerberos (krb-wg) ----------------- "Kerberos Principal Name Canonicalization and KDC-Generated Cross-Realm Referrals", Sam Hartman, Kenneth Raeburn, Larry Zhu, 12-Mar-12, The memo documents a method for a Kerberos Key Distribution Center (KDC) to respond to client requests for Kerberos tickets when the client does not have detailed configuration information on the realms of users or services. The KDC will handle requests for principals in other realms by returning either a referral error or a cross-realm TGT to another realm on the referral path. The clients will use this referral information to reach the realm of the target principal and then receive the ticket. This memo also provides a mechanism for verifying that a request has not been tampered with in transit. This memo updates RFC 4120. "PKINIT Algorithm Agility", Love Astrand, Larry Zhu, Margaret Wasserman, 8-Mar-12, This document updates PKINIT, as defined in RFC 4556, to remove protocol structures tied to specific cryptographic algorithms. The PKINIT key derivation function is made negotiable, the digest algorithms for signing the pre-authentication data and the client's X.509 certificates are made discoverable. These changes provide preemptive protection against vulnerabilities discovered in the future against any specific cryptographic algorithm, and allow incremental deployment of newer algorithms. "An information model for Kerberos version 5", Leif Johansson, 11-Mar-12, This document describes an information model for Kerberos version 5 from the point of view of an administrative service. There is no standard for administrating a kerberos 5 KDC. This document describes the services exposed by an administrative interface to a KDC. "Kerberos Options for DHCPv6", Shoichi Sakane, Masahiro Ishiyama, 8-Mar-12, This document defines new four options for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) to carry configuration information related to the Kerberos protocol [RFC4120]. "Camellia Encryption for Kerberos 5", Greg Hudson, 8-Mar-12, This document specifies two encryption types and two corresponding checksum types for the Kerberos cryptosystem framework defined in RFC 3961. The new types use the Camellia block cipher in CBC-mode with ciphertext stealing and the CMAC algorithm for integrity protection. "Deprecate DES, RC4-HMAC-EXP, and other weak cryptographic algorithms in Kerberos", Love Astrand, Tom Yu, 27-Feb-12, The Kerberos 5 network authentication protocol, originally specified in RFC1510, can use the Data Encryption Standard (DES) for encryption. Almost 30 years after first publishing DES, the National Institute of Standards and Technology (NIST) finally withdrew the standard in 2005, reflecting a long-established consensus that DES is insufficiently secure. By 2008, commercial hardware costing less than USD 15,000 could break DES keys in less than a day on average. DES is long past its sell-by date. Accordingly, this document updates RFC1964, RFC4120, RFC4121, and RFC4757 to deprecate the use of DES, RC4-HMAC-EXP, and other weak cryptographic algorithms in Kerberos. Because RFC1510 (obsoleted by RFC4120) supports only DES, this document reclassifies RFC1510 as Historic. "Container Authenticated by Multiple MACs", Simo Sorce, Tom Yu, Thomas Hardjono, 23-May-12, Abstract: This document proposes a Kerberos Authorization Data container that supersedes AD-KDC-ISSUED. It allows for multiple MACs or signatures on the contained Authorization Data elements. "POSIX Authorization Data", Simo Sorce, Tom Yu, Thomas Hardjono, 9-Feb-12, This document proposes a Kerberos Authorization Data element containing user and group directory information similar to that provided by RFC 2307, typically used by POSIX and POSIX-like systems in the course of login type activities. Layer 2 Virtual Private Networks (l2vpn) ---------------------------------------- "ARP Mediation for IP Interworking of Layer 2 VPN", Himanshu Shah, Giles Heron, Vach Kompella, Eric Rosen, 12-Jan-12, The Virtual Private Wire Service (VPWS) [RFC4664] provides point-to-point connections between pairs of Customer Edge (CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge, PE, device) to a pseudowire (connecting the two PEs). In general, the Attachment Circuits must be of the same technology (e.g., both Ethernet, both ATM), and the pseudowire must carry the frames of that technology. However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the pseudowire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as "ARP Mediation". ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit. The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP. "OAM Procedures for VPWS Interworking", Mustapha Aissaoui, Peter Busschbach, Monique Morrow, Thomas Nadeau, 6-Jan-12, This draft proposes OAM procedures for the Ethernet interworking, IP interworking and FR-ATM interworking Virtual Private Wire Service (VPWS). "Multicast in VPLS", Rahul Aggarwal, Yakov Rekhter, Yuji Kamite, Luyuan Fang, 2-Feb-12, This document describes a solution for overcoming a subset of the limitations of existing VPLS multicast solutions. It describes procedures for VPLS multicast that utilize multicast trees in the sevice provider (SP) network. One such multicast tree can be shared between multiple VPLS instances. Procedures by which a single multicast tree in the SP network can be used to carry traffic belonging only to a specified set of one or more IP multicast streams from one or more VPLSes are also described. "LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS", Pranjal Dutta, Florin Balus, Olen Stokes, Geraldine Calvignac, 20-May-12, [RFC4762] describes a mechanism to remove or unlearn MAC addresses that have been dynamically learned in a VPLS Instance for faster convergence on topology change. The procedure also removes MAC addresses in the VPLS that do not require relearning due to such topology change. This document defines an enhancement to the MAC Address Withdrawal procedure with empty MAC List [RFC4762], which enables a Provider Edge(PE) device to remove only the MAC addresses that need to be relearned. Additional extensions to [RFC4762] MAC Withdrawal procedures are specified to provide optimized MAC flushing for the PBB-VPLS specified in [PBB-VPLS Model]. "Extension to LDP-VPLS for Ethernet Broadcast and Multicast", Raymond Key, Yuji Kamite, Zhihua Liu, Manuel Paul, Ruediger Kunze, Lizhong Jin, 5-Dec-11, This document proposes a simple extension to LDP-VPLS to improve bandwidth efficiency for Ethernet broadcast/multicast traffic within a carrier's network. It makes use of unidirectional point-to-multipoint PseudoWires to minimise payload frame duplication on physical links. "Requirements for MEF E-Tree Support in VPLS", Raymond Key, Simon DeLord, Frederic JOUNAY, Lu Huang, Zhihua Liu, Manuel Paul, Ruediger Kunze, Nick Regno, Joshua Rogers, 13-Apr-12, This document provides functional requirements for Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) support in Virtual Private LAN Service (VPLS). It is intended that potential solutions will use these requirements as guidelines. "A Framework for E-Tree Service over MPLS Network", Lucy Yong, Yuji Kamite, Wim Henderickx, 30-Jan-12, This document proposes a solution framework for supporting Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) services over a Multiprotocol Label Switching (MPLS) network. The objective is to provide a simple and effective approach to emulate E-Tree services in addition to Ethernet LAN (E-LAN) services on an existing MPLS network. "BGP MPLS Based Ethernet VPN", Rahul Aggarwal, Ali Sajassi, Wim Henderickx, Nabil Bitar, Ravi Shekhar, John Drake, 27-Feb-12, This document describes procedures for BGP MPLS based Ethernet VPNs (E-VPN). "PBB E-VPN", Ali Sajassi, Samer Salam, Sami Boutros, Nabil Bitar, Aldrin Isaac, Lizhong Jin, 30-Mar-12, 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, Samer Salam, Clarence Filsfils, 30-Mar-12, 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. Layer 3 Virtual Private Networks (l3vpn) ---------------------------------------- "OSPFv3 as a PE-CE routing protocol", Padma Pillay-Esnault, Peter Moyer, Jeff Doyle, Emre Ertekin, Michael Lundberg, 10-Jan-12, Many Service Providers (SPs) offer Virtual Private Network (VPN) services to their customers using a technique in which Customer Edge (CE) routers are routing peers of Provider Edge (PE) routers. The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. Support currently exists for both IPv4 and IPv6 VPNs, however only Open Shortest Path First protocol version 2 (OSPFv2) as PE-CE protocol is specified. This document extends those specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing protocol. The OSPFv3 PE-CE functionality is identical to that of OSPFv2 except for the differences described in this document. "MVPN: Using Bidirectional P-Tunnels", Yiqun Cai, Eric Rosen, IJsbrand Wijnands, Arjen Boers, 6-Feb-12, The documents specifying multicast support for BGP/MPLS IP VPNs allow customer multicast data to be transported through a service provider's network through a set multicast tunnels. Such tunnels are advertised by BGP in a BGP attribute known as the "Provider Multicast Service Interface (PMSI) Tunnel Attribute". The base specifications allow the PMSI Tunnel Attribute to advertise bidirectional multicast distribution trees as "PMSI Tunnels"; however, those documents do not provide all the necessary details for using those tunnels. These details are provided in this document. This document also specifies the procedures for assigning customer multicast flows to specific bidirectional PMSI tunnels. "Virtual Hub-and-Spoke in BGP/MPLS VPNs", Huajin Jeng, James Uttaro, Luay Jalil, Bruno Decraene, Yakov Rekhter, Rahul Aggarwal, 19-Apr-12, With BGP/MPLS VPNs any-to-any connectivity among sites of a given Virtual Private Network would require each Provider Edge router that has one or more of these sites connected to it to hold all the routes of that Virtual Private Network. The approach described in this document allows to reduce the number of Provider Edge routers that have to maintain all these routes by requiring only a subset of these routers to maintain all these routes. Furthermore, when Provider Edge routers use ingress replication to carry multicast traffic of VPN customers, the approach described in this document could 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", Andy Green, Sameer Gulrajani, Pradeep Jain, Jeffrey Zhang, Saud Asif, 10-May-12, 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. Low Extra Delay Background Transport (ledbat) --------------------------------------------- "Low Extra Delay Background Transport (LEDBAT)", Greg Hazel, Janardhan Iyengar, Mirja Kuehlewind, Stanislav Shalunov, 31-Oct-11, LEDBAT is an experimental delay-based congestion control algorithm that attempts to utilize the available bandwidth on an end-to-end path while limiting the consequent increase in queueing delay on the path. LEDBAT uses changes in one-way delay measurements to limit congestion that the flow itself induces in the network. LEDBAT is designed for use by background bulk-transfer applications; it is designed to be no more aggressive than TCP congestion control and to yield in the presence of any competing flows when latency builds, thus limiting interference with the network performance of the competing flows. Locator/ID Separation Protocol (lisp) ------------------------------------- "Locator/ID Separation Protocol (LISP)", Dino Farinacci, Vince Fuller, Dave Meyer, Darrel Lewis, 5-May-12, This draft describes a network layer based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. LISP can be incrementally deployed, without a "flag day", and offers traffic engineering, multi-homing, and mobility benefits to early adopters, even when there are relatively few LISP-capable sites. Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and Addressing Workshop. "LISP Alternative Topology (LISP+ALT)", Vince Fuller, Dino Farinacci, Dave Meyer, Darrel Lewis, 6-Dec-11, This document describes a simple distributed index system to be used by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router (ITR) or Map Resolver (MR) to find the Egress Tunnel Router (ETR) which holds the mapping information for a particular Endpoint Identifier (EID). The MR can then query that ETR to obtain the actual mapping information, which consists of a list of Routing Locators (RLOCs) for the EID. Termed the Alternative Logical Topology (ALT), the index is built as an overlay network on the public Internet using the Border Gateway Protocol (BGP) and the Generic Routing Encapsulation (GRE). "Interworking LISP with IPv4 and IPv6", Darrel Lewis, Dave Meyer, Dino Farinacci, Vince Fuller, 4-Mar-12, This document describes techniques for allowing sites running the Locator/ID Separation Protocol (LISP) to interoperate with Internet sites (which may be using either IPv4, IPv6, or both) but which are not running LISP. A fundamental property of LISP speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive. While EIDs are syntactically identical to IPv4 or IPv6 addresses, normally routes to them are not carried in the global routing system so an interoperability mechanism is needed for non- LISP-speaking sites to exchange traffic with LISP-speaking sites. This document introduces three such mechanisms. The first uses a new network element, the LISP Proxy Ingress Tunnel Routers (Proxy-ITRs) (Section 5) to act as a intermediate LISP Ingress Tunnel Router (ITR) for non-LISP-speaking hosts. Second the document adds Network Address Translation (NAT) functionality to LISP Ingress and LISP Egress Tunnel Routers (xTRs) to substitute routable IP addresses for non-routable EIDs. Finally, this document introduces the Proxy Egress Tunnel Router (Proxy ETR) to handle cases where a LISP ITR cannot send packets to non-LISP sites without encapsulation. "LISP Map Server Interface", Vince Fuller, Dino Farinacci, 5-Mar-12, This draft describes the Maping Service for the Locator Identifier Separation Protocol (LISP), implemented by two new types of LISP- speaking devices, the LISP Map Resolver and LISP Map Server, that provides a simplified "front end" to for one or more Endpoint ID to Routing Locator mapping databases. By using this service interface and communicating with Map Resolvers and Map Servers, LISP Ingress Tunnel Routers and Egress Tunnel Routers, are not dependent on the details of mapping database systems, which facilitates experimentation with different database designs. Since these devices implement the "edge" of the LISP infrastructure, connect directly to LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP. "LISP for Multicast Environments", Dino Farinacci, Dave Meyer, John Zwiebel, Stig Venaas, 8-Feb-12, This draft describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the LISP architecture. "LISP Internet Groper (LIG)", Dave Meyer, Dino Farinacci, 9-Sep-11, A simple tool called the LISP Internet Groper or 'lig' can be used to query the LISP mapping database. This draft describes how it works. "LISP Map-Versioning", Luigi Iannone, Damien Saucez, Olivier Bonaventure, 1-Mar-12, This document describes the LISP (Locator/ID Separation Protocol) Map-Versioning mechanism, which provides in-packet information about Endpoint-ID to Routing Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and transport such a version number in the LISP specific header of LISP- encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is transparent to implementations not supporting this feature, since in the LISP-specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support the mechanism. "LISP MIB", Gregg Schudel, Amit Jain, Victor Moreno, 29-Nov-11, This document defines managed objects for the Locator/ID Separation Protocol (LISP). These objects provide information useful for monitoring LISP devices, including basic configuration information, LISP status, and operational statistics. "LISP Network Element Deployment Considerations", Lorand Jakab, Albert Cabellos-Aparicio, Florin Coras, Jordi Domingo-Pascual, Darrel Lewis, 12-Mar-12, 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, Dave Meyer, Vince Fuller, 24-Apr-12, 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-Security (LISP-SEC)", Fabio Maino, Vina Ermagan, Albert Cabellos-Aparicio, Damien Saucez, Olivier Bonaventure, 12-Mar-12, This memo specifies LISP-SEC, a set of security mechanisms that provide origin authentication, integrity and anti-replay protection to LISP's EID-to-RLOC mapping data conveyed via mapping lookup process. LISP-SEC also enables verification of authorization on EID- prefix claims in Map-Reply messages. "LISP Threats Analysis", Damien Saucez, Luigi Iannone, Olivier Bonaventure, 1-Mar-12, This document analyzes the threats against the security of the Locator/Identifier Separation Protocol and proposes a set of recommendations to mitigate some of the identified security risks. Mobile Ad-hoc Networks (manet) ------------------------------ "Dynamic MANET On-demand (AODVv2) Routing", Charles Perkins, Ian Chakeres, 12-Mar-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. "The Optimized Link State Routing Protocol version 2", Thomas Clausen, Christopher Dearlove, Philippe Jacquet, Ulrich Herberg, 15-May-12, 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 Neighborhood Discovery Protocol", Ulrich Herberg, Robert Cole, Ian Chakeres, 6-May-12, This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB module defined in this memo, denoted NHDP-MIB, also reports state, performance information and notifications. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. "Definition of Managed Objects for the Optimized Link State Routing Protocol version 2", Ulrich Herberg, Robert Cole, Thomas Clausen, 11-May-12, 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 metrics, 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. "Definition of Managed Objects for Performance Reporting", Robert Cole, Joseph Macker, Andy Bierman, 31-Jan-12, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring autonomous report generation on any device that supports MIBs containing counter and gauge objects for performance monitoring. This allows a management station to instruct a device to build off-line reports to be collected asynchronously by the management station. Further, this REPORT-SAMPLED-MIB can be configured in a proxy configuration where the report generation is performed on a device in close network proximity to the device containing the referenced counter objects. Hence, this capability allows network operators to reduce the SNMP polling traffic burden on Mobile Ad-Hoc and Disruption Tolerant Networks which is typical of SNMP performance management applications. "Dynamic Link Exchange Protocol (DLEP)", Stan Ratliff, Cisco Cisco, Greg Harrison, Darryl Satterwhite, Shawn Jury, 6-Feb-12, When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make forwarding decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. A bidirectional, event- driven communication channel between the router and the modem is necessary. "Using Integrity Check Values and Timestamps in NHDP", Ulrich Herberg, Thomas Clausen, 12-Mar-12, This document specifies a security extension to the MANET Neighbor Discovery Protocol (NHDP). The extension introduces the use of Integrity Check Values (ICVs) and Timestamps in HELLO messages in order to counter a selection of security threats to NHDP. "Security Threats for NHDP", Ulrich Herberg, Jiazi Yi, Thomas Clausen, 9-Apr-12, This document analyses common security threats of the Neighborhood Discovery Protocol (NHDP), and describes their potential impacts on MANET routing protocols using NHDP. Messaging Abuse Reporting Format (marf) --------------------------------------- "Extensions to DKIM for Failure Reporting", Murray Kucherawy, 20-Mar-12, This document presents extensions to the DomainKeys Identified Mail (DKIM) specification to allow for detailed reporting of message authentication failures in an on-demand fashion. "SPF Authentication Failure Reporting using the Abuse Report Format", Scott Kitterman, 15-Mar-12, This memo presents extensions to the Abuse Reporting Format (ARF), and Sender Policy Framework (SPF) specifications to allow for detailed reporting of message authentication failures in an on-demand fashion. This memo updates RFC4408 by providing an IANA registry for SPF modifiers. "Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)", Return Path, Murray Kucherawy, 25-Apr-12, RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This Applicability Statement describes common methods for utilizing this format for reporting both abuse and authentication failure events. Mailbox Providers of any size, mail sending entities, and end users can use these methods as a basis to create procedures that best suit them. Some related optional mechanisms are also discussed. MBONE Deployment (mboned) ------------------------- "Automatic Multicast Tunneling", Gregory Bumgardner, 23-Apr-12, This document describes Automatic Multicast Tunneling (AMT), a protocol for delivering multicast traffic from sources in a multicast-enabled network to receivers that lack multicast connectivity to the source network. The protocol uses UDP encapsulation and unicast replication to provide this functionality. The AMT protocol is specifically designed to support rapid deployment by requiring minimal changes to existing network infrastructure. "Multicast Addresses for Documentation", Stig Venaas, Rishabh Parekh, Gunter Van de Velde, Tim Chown, Marshall Eubanks, 17-May-12, This document discusses which multicast addresses should be used for documentation purposes and reserves multicast addresses for such use. Some multicast addresses are derived from AS numbers or unicast addresses. This document also explains how these can be used for documentation purposes. "IPv6 Multicast Address Format With Embedded IPv4 Multicast Address", Mohamed Boucadair, Jacni Qin, Yiu Lee, Stig Venaas, Xing Li, Mingwei Xu, 23-May-12, This document specifies an extension to the IPv6 multicast addressing architecture to be used in the context of IPv4-IPv6 interconnection. In particular, this document defines an address format for IPv4- embedded IPv6 multicast addresses. This address format can be used for IPv4-IPv6 translation or encapsulation schemes. This document updates RFC4291. "IPv4-IPv6 Multicast: Problem Statement and Use Cases", Christian Jacquenet, Mohamed Boucadair, Yiu Lee, Jacni Qin, Tina Tsou, Qiong Sun, 11-May-12, 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. Media Server Control (mediactrl) -------------------------------- "Media Control Channel Framework (CFW) Call Flow Examples", Alessandro Amirante, Lorenzo Miniero, Simon Romano, Tobia Castaldi, 9-Jan-12, This document provides a list of typical Media Control Channel Framework [RFC6230] call flows. It aims at being a simple guide to the use of the interface between Application Servers and MEDIACTRL- based Media Servers, as well as a base reference documentation for both implementors and protocol researchers. "Media Resource Brokering", Chris Boulton, Gary Munson, Lorenzo Miniero, 9-Jan-12, The MediaCtrl work group in the IETF has proposed an architecture for controlling media services. The Session Initiation Protocol (SIP) is used as the signalling protocol which provides many inherent capabilities for message routing. In addition to such signalling properties, a need exists for intelligent, application level media service selection based on non-static signalling properties. This is especially true when considered in conjunction with deployment architectures that include 1:M and M:N combinations of Application Servers and Media Servers. This document introduces a Media Resource Broker (MRB) entity which manages the availability of Media Servers and the media resource demands of Application Servers. The document includes potential deployment options for an MRB and appropriate interfaces to Application Servers and Media Servers. Mobility EXTensions for IPv6 (mext) ----------------------------------- "Transport Layer Security-based Mobile IPv6 Security Framework for Mobile Node to Home Agent Communication", Jouni Korhonen, Basavaraj Patil, Hannes Tschofenig, Dirk Kroeselberg, 28-Mar-12, Mobile IPv6 signaling between a mobile node and its home agent is secured using IPsec. The security association between a mobile node and the home agent is established using IKEv1 or IKEv2. The security model specified for Mobile IPv6, which relies on IKE/IPsec, requires interaction between the Mobile IPv6 protocol component and the IKE/ IPsec module of the IP stack. This document proposes an alternate security framework for Mobile IPv6 and Dual-Stack Mobile IPv6, which relies on Transport Layer Security for establishing keying material and other bootstrapping parameters required to protect Mobile IPv6 signaling and data traffic between the mobile node and home agent. Multiple Interfaces (mif) ------------------------- "DHCPv6 Route Options", Wojciech Dec, Tomasz Mrugalski, Tao Sun, Behcet Sarikaya, 24-Feb-12, This document describes DHCPv6 Route Options for provisioning IPv6 routes on DHCPv6 client nodes. This is expected to improve the ability of an operator to configure and influence a nodes' ability to pick an appropriate route to a destination when this node is multi- homed and where other means of route configuration may be impractical. "Improved DNS Server Selection for Multi-Interfaced Nodes", Teemu Savolainen, Jun-ya Kato, Ted Lemon, 26-Mar-12, A multi-interfaced node is connected to multiple networks, some of which may be utilizing private DNS namespaces. A node commonly receives DNS server configuration information from all connected networks. Some of the DNS servers may have information about namespaces other servers do not have. When a multi-interfaced node needs to utilize DNS, the node has to choose which of the servers to contact to. This document describes DHCPv4 and DHCPv6 options that can be used to configure nodes with information required to perform informed DNS server selection decisions. "MIF API consideration", Dapeng Liu, Ted Lemon, Yuri Ismailov, Zhen Cao, 5-Mar-12, This document describes an abstract API that provides the minimal functionality required for a program to communicate effectively with peers and services on the network while running on a host that has more than one active network interface. This API is abstract: we describe the functionality that must be provided, not the bindings that should be used to provide that functionality. The functionality described here provides the building blocks from which higher-level APIs might be built, and is not intended to be used directly by typical applications. Managed Incident Lightweight Exchange (mile) -------------------------------------------- "Guidelines for Defining Extensions to IODEF", Brian Trammell, 9-May-12, This document provides guidelines for extensions to IODEF [RFC5070] for exchange of incident management data, and contains a template for Internet-Drafts describing those extensions, in order to ease the work and improve the quality of extension descriptions. "IODEF-extension to support structured cybersecurity information", Takeshi Takahashi, Kent Landfield, Thomas Millar, Youki Kadobayashi, 10-May-12, This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 [RFC5070] to facilitate enriched cybersecurity information exchange among cybersecurity entities. It provides the capability of embedding structured information, such as identifier- and XML-based information. "GRC Report Exchange", Kathleen Moriarty, Said Tabet, David Waltermire, 13-Apr-12, Governance, risk, and compliance (GRC) programs provide oversight (governance) of risks and compliance initiatives within an organization. GRC reports are increasingly provided in an XML format. This specification defines a common method to securely transport GRC and other XML reports. The defined messaging capability provides policy options and markings in an XML schema, options for confidentiality at the document/report level, and security for the end-to-end communication. XML reports may be shared between service providers and clients, enterprises, or within enterprises. Reports may also be exchanged for official purposes such as business report filings, compliance report filings, and the handling of legal incidents (eWarrant, eDiscovery, etc.) This work is a generalized format derived from the secure exchange of incident information defined by RFC6545, Real-time Inter-network Defense (RID). "Expert Review for IODEF Extensions in IANA XML Registry", Brian Trammell, 9-May-12, This document specifies restrictions on additions to the subset of the IANA XML Namespace and Schema registries, to require Expert Review for extensions to IODEF. Mobility for IPv4 (mip4) ------------------------ "Dynamic Prefix Allocation for NEMOv4", George Tsirtsis, Vincent Park, Kent Leung, 22-Feb-12, The base NEMOv4 specification defines extensions to Mobile IPv4 for mobile networks. This specification defines a dynamic prefix allocation mechanism. "Flow Binding Support for Mobile IPv4", Alexandru Petrescu, George Tsirtsis, Hesham Soliman, Kent Leung, Sri Gundavelli, 12-Feb-12, This specification defines extensions to Mobile IPv4 protocol for allowing a mobile node with multiple interfaces to register a care-of address for each of its network interfaces and to simultaneously establish multiple Mobile IP tunnels with its home agent. This essentially allows the mobile node to utilize all the available network interfaces and build an higher aggregated data pipe with the home agent for its home address traffic. Furthermore, these extensions also allow the mobile node and the home agent to negotiate flow policies for binding individual traffic flows with the registered care-of addresses. Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- "Real Time Streaming Protocol 2.0 (RTSP)", Henning Schulzrinne, Anup Rao, Rob Lanphier, Magnus Westerlund, Martin Stiemerling, 12-Mar-12, 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, 7-May-12, This document defines a solution for Network Address Translation (NAT) traversal for datagram based media streams setup and controlled with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signalling channel, defining the necessary extra RTSP extensions and procedures. "An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback", Hadriel Kaplan, Kaynam Hedayat, Nagarjuna Venna, Paul Jones, Arjun Roychowdhury, C Sivachelvan, Nathan Stratton, 25-Mar-12, The wide deployment of Voice over IP (VoIP), Text and Video over IP services has introduced new challenges in managing and maintaining real-time voice/text/video quality, reliability, and overall performance. In particular, media delivery is an area that needs attention. One method of meeting these challenges is monitoring the media delivery performance by looping media back to the transmitter. This is typically referred to as "active monitoring" of services. Media loopback is especially popular in ensuring the quality of transport to the edge of a given VoIP, Real-time Text or Video over IP service. Today in networks that deliver real-time media, short of running 'ping' and 'traceroute' to the edge, administrators are left without the necessary tools to actively monitor, manage, and diagnose quality issues with their service. The extension defined herein adds new SDP media attributes, which enable establishment of media sessions where the media is looped back to the transmitter. Such media sessions will serve as monitoring and troubleshooting tools by providing the means for measurement of more advanced VoIP, Real-time Text and Video over IP performance metrics. "SDP Media Capabilities Negotiation", Robert Gilman, Roni Even, Flemming Andreasen, 12-Mar-12, Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP. The base framework defines only capabilities for negotiating transport protocols and attributes. In this document, we extend the framework by defining media capabilities that can be used to negotiate media types and their associated parameters. "The Evaluation of Different Network Addres Translator (NAT) Traversal Techniques for Media Controlled by Real-time Streaming Protocol (RTSP)", Magnus Westerlund, Thomas Zeng, 7-May-12, This document describes several Network Address Translator (NAT) traversal techniques that was considered to be used by Real-time Streaming Protocol (RTSP). Each technique includes a description on how it would be used, the security implications of using it and any other deployment considerations it has. There are also disussions on how NAT traversal techniques relates to firewalls and how each technique can be applied in different use cases. These findings where used when selecting the NAT traversal for RTSP 2.0 standardized in the MMUSIC WG. "SDP: Session Description Protocol", Mark Handley, Van Jacobson, Colin Perkins, Ali Begen, 27-Feb-12, 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, 29-Jan-12, Middleboxes are defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. Two such functions are network address translation and firewalling. When Application Layer Gateways, such as SIP entities, interact with NATs and firewalls, as described in the MIDCOM architecture, then problems may occur in the transport of media traffic when signaling protocol interaction takes place along the media path, as it is the case for recent key exchange proposals (such as DTLS-SRTP). This document highlights problems that may arise. Unfortunately, it is difficult for the end points to detect or predict problematic behavior and to determine whether the media path is reliably available for packet exchange. This document aims to summarize the various sources and effects of NAT and firewall control, the reasons that they exist, and possible means of improving their behavior to allow protocols that rely upon signaling along the media path to operate effectively. "Session Description Protocol (SDP) Extension For Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)", Miguel Garcia, Simo Veikkolainen, 14-May-12, 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, 12-Mar-12, 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, 12-Mar-12, 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, 23-Feb-12, This specification defines a new SDP Grouping Framework SDP grouping framework extension, "BUNDLE", that can be used with the Session Description Protocol (SDP) Offer/Answer mechanism to negotiate the usage of bundled media, which refers to the usage of a single 5-tuple for media associated with multiple SDP media descriptions ("m=" lines). "Miscellanoues Capabilities Negotiation in the Session Description Protocol (SDP)", Miguel Garcia, Simo Veikkolainen, Robert Gilman, 25-Mar-12, 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). 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, 17-Jan-12, MPLS-TP is based on a profile of the MPLS and PW procedures as specified in the MPLS-TE and (MS-)PW architectures developed by the IETF. The ITU-T has specified a Transport Network architecture. This document provides a thesaurus for the interpretation of MPLS-TP terminology within the context of the ITU-T Transport Network recommendations. It is important to note that MPLS-TP is applicable in a wider set of contexts than just Transport Networks. The definitions presented in this document do not provide exclusive nor complete interpretations of MPLS-TP concepts. This document simply allows the MPLS-TP terms to be applied within the Transport Network context. "An Overview of the OAM Tool Set for MPLS based Transport Networks", Nurit Sprecher, Luyuan Fang, 17-Apr-12, This document provides an overview of the OAM toolset for MPLS based Transport Networks (MPLS-TP). The toolset consists of a comprehensive set of fault management and performance monitoring capabilities (operating in the data-plane) which are appropriate for transport networks as required in RFC 5860 and support the network and services at different nested levels. This overview includes a brief recap of MPLS-TP OAM requirements and functions, and of generic mechanisms created in the MPLS data plane to allow the OAM packets run in-band and share their fate with data packets. The protocol definitions for each of the MPLS-TP OAM tools are defined in separate documents (RFCs or Working Group drafts) which are referenced by this document. "Multipoint LDP in-band signaling for Point-to-Multipoint and Multipoint- to-Multipoint Label Switched Paths", IJsbrand Wijnands, Toerless Eckert, Nicolai Leymann, Maria Napierala, 1-Dec-11, Consider an IP multicast tree, constructed by Protocol Independent Multicast (PIM), needs to pass through an MPLS domain in which Multipoint LDP (mLDP) Point-to-Multipoint and/or Multipoint-to- Multipoint Labels Switched Paths (LSPs) can be created. The part of the IP multicast tree that traverses the MPLS domain can be instantiated as a multipoint LSP. When a PIM Join message is received at the border of the MPLS domain, information from that message is encoded into mLDP messages. When the mLDP messages reach the border of the next IP domain, the encoded information is used to generate PIM messages that can be sent through the IP domain. The result is an IP multicast tree consisting of a set of IP multicast sub-trees that are spliced together with a multipoint LSP. "Updates to LDP for IPv6", Carlos Pignataro, Rajiv Asati, Rajiv Papneja, Vishwas Manral, 23-Jan-12, The Label Distribution Protocol (LDP) specification defines procedures to exchange label bindings over either IPv4, IPv6 or both networks. This document corrects and clarifies the LDP behavior when IPv6 network is used (with or without IPv4). This document updates RFC 5036. "Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-based Management Overview", Daniel King, Venkatesan Mahalingam, 13-Apr-12, A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe. The MPLS Transport Profile (MPLS-TP) is a profile of MPLS functionality specific to the construction of packet-switched transport networks. This document describes the MIB-based architecture for MPLS-TP, and indicates the interrelationships between different existing MIB modules that can be leveraged for MPLS-TP network management and identifies areas where additional MIB modules are required. "Configuration of Pro-Active Operations, Administration, and Maintenance (OAM) Functions for MPLS-based Transport Networks using LSP Ping", Elisa Bellagamba, Loa Andersson, Pontus Skoldstrom, David Ward, John Drake, 13-Apr-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 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. "MPLS-TP Security Framework", Luyuan Fang, Ben Niven-Jenkins, Scott Mansfield, Richard Graveman, 26-Mar-12, This document provides a security framework for Multiprotocol Label Switching Transport Profile (MPLS-TP). MPLS-TP extends MPLS technologies and introduces new OAM capabilities, a transport- oriented path protection mechanism, and strong emphasis on static provisioning supported by network management systems. This document addresses the security aspects relevant in the context of MPLS-TP specifically. It describes potential security threats, security requirements for MPLS-TP, and mitigation procedures for MPLS-TP networks and MPLS-TP interconnection to other MPLS and GMPLS networks. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call. [RFC Editor, please remove this note before publication as an RFC and insert the correct Streams Boilerplate to indicate that the published RFC has IETF Consensus.] "The Use of Entropy Labels in MPLS Forwarding", Kireeti Kompella, John Drake, Shane Amante, Wim Henderickx, Lucy Yong, 9-May-12, Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing across MPLS networks using the concept of "entropy labels". It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications. "The Generalized TTL Security Mechanism (GTSM) for Label Distribution Protocol (LDP)", Carlos Pignataro, Rajiv Asati, 14-May-12, The Generalized TTL Security Mechanism (GTSM) describes a generalized use of a packets Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify that the packet was sourced by a node on a connected link, thereby protecting the router's IP control-plane from CPU utilization based attacks. This technique improves security and is used by many protocols. This document defines the GTSM use for the Label Distribution Protocol (LDP). This specification uses a bit reserved in RFC 5036 and therefore updates RFC 5036. "Seamless MPLS Architecture", Nicolai Leymann, Bruno Decraene, Clarence Filsfils, Maciek Konstantynowicz, Dirk Steinberg, 12-Mar-12, 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", Rahul Aggarwal, Yakov Rekhter, 7-Dec-11, This document describes procedures for building inter-area point-to- multipoint (P2MP) segmented service LSPs by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and label distribution protocol. Within each IGP area the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress replication is used within an IGP area, then MP2P LDP LSPs or P2P RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may be BGP MVPN, VPLS multicast or IP multicast over MPLS. "LDP IP and PW Capability", Kamran Raza, Sami Boutros, 15-Feb-12, Currently, no LDP capability is exchanged for LDP applications like IP label switching and L2VPN/PW signaling. When an LDP session comes up, an LDP speaker may unnecessarily advertise its local state for such LDP applications even when the peer session may be established for some other applications like ICCP. This document proposes a solution by which an LDP speaker announces its disinterest or non- support for IP label switching or L2VPN/PW application, hence disabling corresponding application state exchange over the established LDP session. "MPLS-TP Traffic Engineering (TE) Management Information Base (MIB)", Venkatesan Mahalingam, Kannan Sampath, Sam Aldrin, Thomas Nadeau, 13-Apr-12, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects of Tunnels, Identifiers, Label Switch Router and Textual conventions for Multiprotocol Label Switching (MPLS) based Transport Profile (TP). "Definition of Time-to-Live TLV for LSP-Ping Mechanisms", Siva Sivabalan, Sami Boutros, George Swallow, Shaleen Saxena, Vishwas Manral, Sam Aldrin, 6-Mar-12, LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. However, in the present form, this mechanism is inadequate to verify connectivity of a segment of a Multi-Segment PseudoWire (MS-PW) from any node on the path of the MS-PW. This document defines a TLV to address this shortcoming. "MPLS-TP Identifiers Following ITU-T Conventions", Rolf Winter, Eric Gray, Huub van Helvoort, Malcolm Betts, 6-Mar-12, This document specifies an extension to the identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). Identifiers that follow IP/MPLS conventions have already been defined. This memo augments that set of identifiers for MPLS-TP management and OAM functions to include identifier information in a format typically used by the ITU-T. "LDP Extensions for Multi Topology Routing", Quintin Zhao, Luyuan Fang, Chao Zhou, Lianyuan Li, Ning So, 11-Mar-12, 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 describes the LDP protocol extensions required to support MT routing in an MPLS environment. "Applicability of MPLS-TP Linear Protection for Ring Topologies", Yaacov Weingarten, Stewart Bryant, Nurit Sprecher, Daniele Ceccarelli, Diego Caviglia, Francesco Fondelli, Marco Corsi, Wu Bo, Xuehui Dai, 29-Apr-12, This document presents an applicability statement to address the requirements for protection of ring topologies for Multi-Protocol Label Switching Transport Profile (MPLS-TP) Label Switched Paths (LSP) on multiple layers. The MPLS-TP Requirements document specifies specific criteria for justification of dedicated protection mechanism for particular topologies, including optimizing the number of OAM entities needed, minimizing the number of labels for protection paths, minimizing the number of recovery elements in the network, and minimizing the number of control and management transactions necessary. The document proposes a methodology for ring protection based on existing MPLS-TP survivability mechanisms, specifically those defined in MPLS-TP Linear Protection, without the need for specification of new constructs or protocols. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. "Handling MPLS-TP OAM Packets Targeted at Internal MIPs", Adrian Farrel, Hideki Endo, Rolf Winter, Yoshinori Koike, Manuel Paul, 12-Mar-12, The Framework for Operations, Administration and Maintenance (OAM) within the MPLS Transport Profile (MPLS-TP) describes how Maintenance Entity Group Intermediate Points (MIPs) may be situated within network nodes at the incoming and outgoing interfaces. This document describes a way of forming OAM messages so that they can be targeted at MIPs on incoming or MIPs on outgoing interfaces, forwarded correctly through the "switch fabric", and handled efficiently in node implementations where there is no distinction between the incoming and outgoing MIP. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. "MPLS-TP Applicability; Use Cases and Design", Luyuan Fang, Nabil Bitar, Raymond Zhang, 20-Dec-11, This document provides applicability, use case studies and network design considerations for Multiprotocol Label Switching Transport profile (MPLS-TP). In the recent years, MPLS-TP has emerged as the technology of choice for the new generation of packet transport. Many service providers (SPs) are working to replace the legacy transport technologies, e.g. SONET/SDH, TDM, and ATM technologies, with MPLS-TP for packet transport, in order to achieve higher efficiency, lower operational cost, while maintaining transport characteristics. The use cases for MPLS-TP include Metro Ethernet access and aggregation, Mobile backhaul, and packet optical transport. The design considerations discussed in this documents ranging from operational experience; standards compliance; technology maturity; end-to-end forwarding and OAM consistency; compatibility with IP/MPLS networks; multi-vendor interoperability; and optimization vs. simplicity design trade off discussion. The general design principle is to provide reliable, manageable, and scalable transport solutions. "LDP Downstream-on-Demand in Seamless MPLS", Thomas Beckhaus, Bruno Decraene, Kishore Tiruveedhula, Maciek Konstantynowicz, Luca Martini, 12-Mar-12, Seamless MPLS design enables a single IP/MPLS network to scale over core, metro and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access, including high number of devices, their position in network topology and their compute and memory constraints that limit the amount of state access devices can hold.This can be achieved with LDP Downstream-on-Demand (LDP DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design. In addition, a new optional TLV type in the LDP label request message is defined for fast-up convergence. "MPLS Generic Associated Channel (G-ACh) Advertisement Protocol", Dan Frost, Stewart Bryant, Matthew Bocci, 23-May-12, The MPLS Generic Associated Channel (G-ACh) provides an auxiliary logical data channel associated with a Label Switched Path (LSP), a pseudowire, or a section (link) over which a variety of protocols may flow. These protocols are commonly used to provide Operations, Administration, and Maintenance (OAM) mechanisms associated with the primary data channel. This document specifies simple procedures by which an endpoint of an LSP, pseudowire, or section may inform the other endpoints of its capabilities and configuration parameters, or other application-specific information. This information may then be used by the receiver to validate or adjust its local configuration, and by the network operator for diagnostic purposes. "MPLS-TP Next-Hop Ethernet Addressing", Dan Frost, Stewart Bryant, Matthew Bocci, 23-May-12, The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet-switched transport networks. This document presents considerations for link-layer addressing of Ethernet frames carrying MPLS-TP packets. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. "Temporal and hitless path segment monitoring", Yoshinori Koike, Satoshi Ueno, Manuel Paul, Alessandro D'Alessandro, 27-Mar-12, 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. Multipath TCP (mptcp) --------------------- "TCP Extensions for Multipath Operation with Multiple Addresses", Alan Ford, Costin Raiciu, Mark Handley, Olivier Bonaventure, 26-Mar-12, TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network, and thus improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e. reliable bytestream), and provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. "MPTCP Application Interface Considerations", Michael Scharf, Alan Ford, 17-Apr-12, Multipath TCP (MPTCP) adds the capability of using multiple paths to a regular TCP session. Even though it is designed to be totally backward compatible to applications, the data transport differs compared to regular TCP, and there are several additional degrees of freedom that applications may wish to exploit. This document summarizes the impact that MPTCP may have on applications, such as changes in performance. Furthermore, it discusses compatibility issues of MPTCP in combination with non-MPTCP-aware applications. Finally, the document describes a basic application interface which is a simple extension of TCP's interface for MPTCP-aware applications. Multicast Mobility (multimob) ----------------------------- "Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains", Thomas Schmidt, Shuai Gao, Hong-Ke Zhang, Matthias Waehlisch, 9-Jan-12, Multicast communication can be enabled in Proxy Mobile IPv6 domains via the Local Mobility Anchors by deploying MLD Proxy functions at Mobile Access Gateways, via a direct traffic distribution within an ISP's access network, or by selective route optimization schemes. This document describes the support of mobile multicast senders in Proxy Mobile IPv6 domains for all three scenarios. Mobile sources always remain agnostic of multicast mobility operations. "Multicast Mobility Routing Optimizations for Proxy Mobile IPv6", Juan Zuniga, Luis Contreras, Carlos Bernardos, Seil Jeon, Younghan Kim, 5-Mar-12, 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 deployments scenarios. "PMIPv6 multicast handover optimization by the Subscription Information Acquisition through the LMA (SIAL)", Luis Contreras, Carlos Bernardos, Ignacio Soto, 22-May-12, 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' active multicast subscriptions information 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 also can be applied to other solutions envisioned as possible architectural evolutions of it. 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). Network Endpoint Assessment (nea) --------------------------------- "PT-TLS: A TCP-based Posture Transport (PT) Protocol", Paul Sangster, Nancy Cam-Winget, Joseph Salowey, 9-May-12, This document specifies PT-TLS, a TCP-based Posture Transport (PT) protocol. The PT-TLS protocol carries the Network Endpoint Assessment (NEA) message exchange under the protection of a Transport Layer Security (TLS) secured tunnel. "PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods", Nancy Cam-Winget, Paul Sangster, 15-May-12, This document specifies PT-EAP, an EAP based Posture Transport (PT) protocol designed to be used only inside a TLS protected tunnel method. The document also describes the intended applicability of PT-EAP. "NEA Asokan Attack Analysis", Joseph Salowey, Stephen Hanna, 26-Apr-12, The Network Endpoint Assessment protocols are subject to a subtle forwarding attack that has become known as the NEA Asokan Attack. This document describes the attack and countermeasures that may be mounted. Network-Based Mobility Extensions (netext) ------------------------------------------ "RADIUS Support for Proxy Mobile IPv6", Frank Xia, Behcet Sarikaya, Jouni Korhonen, Sri Gundavelli, Damjan Damic, 30-Jan-12, This document defines new attributes to facilitate Proxy Mobile IPv6 operations using the RADIUS infrastructure. The protocol defined in this document uses Radius based interfaces of the mobile access gateway and the local mobility anchor with the AAA server for authentication, authorization and policy functions. The RADIUS interactions between the mobile access gateway and the RADIUS-based AAA server take place when the Mobile Node attaches, authenticates and authorizes to a Proxy Mobile IPv6 domain. Furthermore, this document defines the RADIUS-based interface between the local mobility anchor and the AAA RADIUS server for authorizing received Proxy Binding Update messages for the mobile node's mobility session. In addition to the mobility session setup related interactions, this document defines the baseline for the mobile access gateway and the local mobility anchor generated accounting. "Logical Interface Support for multi-mode IP Hosts", Telemaco Melia, Sri Gundavelli, 29-Apr-12, A Logical Interface is a software semantic internal to the host operating system. This semantic is available in all popular operating systems and is used in various protocol implementations. The Logical Interface support is required on the mobile node operating in a Proxy Mobile IPv6 domain, for leveraging various network-based mobility management features such as inter-technology handoffs, multihoming and flow mobility support. This document explains the operational details of Logical Interface construct and the specifics on how the link-layer implementations hide the physical interfaces from the IP stack and from the network nodes on the attached access networks. Furthermore, this document identifies the applicability of this approach to various link-layer technologies and analyzes the issues around it when used in context with various mobility management features. "Localized Routing for Proxy Mobile IPv6", Suresh Krishnan, Rajeev Koodli, Paulo Loureiro, Wenson Wu, Ashutosh Dutta, 7-May-12, Proxy Mobile IPv6 (PMIPv6) is a network based mobility management protocol that enables IP mobility for a host without requiring its participation in any mobility-related signaling. PMIPv6 requires all communications to go through the local mobility anchor. As this can be suboptimal, localized routing (LR) allows mobile nodes attached to the same or different mobile access gateways to route traffic by using localized forwarding or a direct tunnel between the gateways. This document proposes initiation, utilization and termination mechanisms for localized routing between mobile access gateways within a proxy mobile IPv6 domain. It defines two new signaling messages, Localized Routing Initiation (LRI) and Local Routing Acknowledgment (LRA), that are used to realize this mechanism. "Access Network Identifier (ANI) Option for Proxy Mobile IPv6", Sri Gundavelli, Jouni Korhonen, Mark Grayson, Kent Leung, Rajesh Pazhyannur, 25-Apr-12, The local mobility anchor in a Proxy Mobile IPv6 domain is able to provide access network and access operator specific handling or policing of the mobile node traffic using information about the access network to which the mobile node is attached. This specification defines a mechanism and a related mobility option for carrying the access network identifier and the access operator identification information from the mobile access gateway to the local mobility anchor over Proxy Mobile IPv6. "Prefix Delegation for Proxy Mobile IPv6", Xingyue Zhou, Jouni Korhonen, Carl Williams, Sri Gundavelli, Carlos Bernardos, 12-Mar-12, Proxy Mobile IPv6 enables IP mobility for a host without requiring its participation in any mobility signaling, being the network responsible for managing IP mobility on behalf of the host. However, Proxy Mobile IPv6 does not support assigning a prefix to a router and managing its IP mobility. This document specifies an extension to Proxy Mobile IPv6 protocol for supporting network mobility using DHCPv6-based Prefix Delegation. "IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6", Sri Gundavelli, Xingyue Zhou, Jouni Korhonen, Rajeev Koodli, 9-Feb-12, This specification defines a mechanism and a related mobility option for carrying IPv4 Offload traffic selectors between a mobile access gateway and a local mobility anchor in a Proxy Mobile IPv6 domain. Based on the received offload flow selectors from the local mobility anchor, a mobile access gateway can enable offload traffic rule on the selected IPv4 flows. "Proxy Mobile IPv6 Extensions to Support Flow Mobility", Carlos Bernardos, 12-Mar-12, 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. This document assumes that the mobile node implements the logical interface model, therefore allowing the support of traffic flows on different physical interfaces regardless of the assigned prefixes on these physical interfaces. "Service Selection for Mobile IPv6", Jouni Korhonen, Ulf Nilsson, Vijay Devarapalli, 23-Apr-12, In some Mobile IPv6 deployments, identifying the mobile node or the mobility service subscriber is not enough to distinguish between multiple services possibly provisioned to the said mobile node and its mobility service subscription. A capability to specify different services in addition to the mobile node identity can be leveraged to provide flexibility for mobility service providers on provisioning multiple services to one mobility service subscription. This document describes a Service Selection Mobility Option for both conventional Mobile IPv6 and Proxy Mobile IPv6 that is intended to assist home agents and local mobility agents to make a specific service selection for the mobility service subscription during the binding registration procedure. This specification updates RFC5213 and obsoletes RFC5149. "EAP Attributes for WiFi - EPC Integration", Ravi Valmikam, Rajeev Koodli, 23-Apr-12, 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. NETCONF Data Modeling Language (netmod) --------------------------------------- "IANA Interface Type and Address Family YANG Modules", Martin Bjorklund, 29-Apr-12, This document defines the initial versions of the iana-if-type and iana-afn-safi YANG modules. "A YANG Data Model for Interface Configuration", Martin Bjorklund, 29-Apr-12, This document defines a YANG data model for the configuration of network interfaces. It is expected that interface type specific configuration data models augment the generic interfaces data model defined in this document. "Translation of SMIv2 MIB Modules to YANG Modules", Juergen Schoenwaelder, 20-Apr-12, YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF protocol, NETCONF remote procedure calls, and NETCONF notifications. The Structure of Management Information (SMIv2) defines fundamental data types, an object model, and the rules for writing and revising MIB modules for use with the SNMP protocol. This document defines a translation of SMIv2 MIB modules into YANG modules, enabling read-only (config false) access to data objects defined in SMIv2 MIB modules via NETCONF. "A YANG Data Model for Routing Configuration", Ladislav Lhotka, 20-Feb-12, This document contains a specification of four YANG modules. Together they form the core routing data model which serves as a basis for configuring a routing subsystem. It is therefore expected that this module will be augmented by additional YANG modules defining data models for individual routing protocols and other related functions. The core routing data model provides common building blocks for such configurations - router instances, routes, routing tables, routing protocols and route filters. "A YANG Data Model for IP Configuration", Martin Bjorklund, 29-Apr-12, This document defines a YANG data model for configuration of IP implementations. "YANG Data Model for System Management", Andy Bierman, Martin Bjorklund, 31-Jan-12, This document defines a YANG data model for the configuration and identification of the management system of a device. Network File System Version 4 (nfsv4) ------------------------------------- "Administration Protocol for Federated Filesystems", Craig Everhart, Daniel Ellard, James Lentini, Manoj Naik, Renu Tewari, 6-Jun-11, This document describes the administration protocol for a federated file system that enables file access and namespace traversal across collections of independently administered fileservers. The protocol specifies a set of interfaces by which fileservers with different administrators can form a fileserver federation that provides a namespace composed of the filesystems physically hosted on and exported by the constituent fileservers. "Using DNS SRV to Specify a Global File Name Space with NFS version 4", Craig Everhart, Andy Adamson, Jiaying Zhang, 8-Mar-12, The NFS version 4 protocol provides a mechanism for a collection of NFS file servers to collaborate in providing an organization-wide file name space. The DNS SRV RR allows a simple way for an organization to publish the root of its filesystem name space, even to clients that might not be intimately associated with such an organization. The DNS SRV RR can be used to join these organization- wide file name spaces together to allow construction of a global, uniform NFS file name space. "NSDB Protocol for Federated Filesystems", James Lentini, Craig Everhart, Daniel Ellard, Renu Tewari, Manoj Naik, 11-Mar-11, This document describes a filesystem federation protocol that enables file access and namespace traversal across collections of independently administered fileservers. The protocol specifies a set of interfaces by which fileservers with different administrators can form a fileserver federation that provides a namespace composed of the filesystems physically hosted on and exported by the constituent fileservers. "Network File System (NFS) Version 4 Protocol", Thomas Haynes, David Noveck, 8-May-12, The Network File System (NFS) version 4 is a distributed filesystem protocol which owes heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. This document, together with the companion XDR description document, RFCNFSv4XDR, replaces RFC 3530 as the definition of the NFS version 4 protocol. "Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description", Thomas Haynes, David Noveck, 12-Mar-12, The Network File System (NFS) version 4 is a distributed filesystem protocol which owes heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. This document, together with RFC3530bis replaces RFC 3530 as the definition of the NFS version 4 protocol. "NFS Version 4 Minor Version 2", Thomas Haynes, 23-May-12, This Internet-Draft describes NFS version 4 minor version two, focusing mainly on the protocol extensions made from NFS version 4 minor version 0 and NFS version 4 minor version 1. Major extensions introduced in NFS version 4 minor version two include: Server-side Copy, 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", Thomas Haynes, 23-May-12, This Internet-Draft provides the XDR description for NFSv4 minor version two. "Remote Procedure Call (RPC) Security Version 3", Thomas Haynes, Nico Williams, 23-Apr-12, This document specifies version 3 of the Remote Procedure Call (RPC) security protocol (RPCSEC_GSS). This protocol provides for: compound authentication of client hosts and users to server (constructed by generic composition), channel binding, security label assertions for multi-level and type enforcement, privilege assertions, and identity assertions. "Object-Based Parallel NFS (pNFS) Operations", Benny Halevy, Boaz Harrosh, Brent Welch, 28-Mar-12, Parallel NFS (pNFS) extends Network File System version 4 (NFSv4) to allow clients to directly access file data on the storage used by the NFSv4 server. This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used, a.k.a. the Layout Type. The main pNFS operations and data types in NFSv4 Minor version 1 specify a layout- type-independent layer; layout-type-specific information is conveyed using opaque data structures whose internal structure is further defined by the particular layout type specification. This document specifies the NFSv4.1 Object-Based pNFS Layout Type as a companion to the main NFSv4 Minor version 1 specification. "pNFS block disk protection", David Black, Jason Glasgow, Sorin Faibish, 22-May-12, Parallel NFS (pNFS) extends Network File System version 4 (NFSv4) to enable direct client access to file data on storage, bypassing the NFSv4 server. This can increase both performance and parallelism, but requires additional client functionality, some of which depends upon the type of storage used. The pNFS specification for block storage (RFC 5663) describes how clients can identify the volumes used for pNFS, but this mechanism requires communication with the NFSv4 server. This document updates RFC 5663 to add a mechanism that enables identification of block storage devices used by pNFS file systems without communicating with the server. This enables clients to control access to pNFS block devices when the client initially boots, as opposed to waiting until the client can communicate with the NFSv4 server. "Requirements for Labeled NFS", Thomas Haynes, 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, 11-Apr-12, The migration feature of NFSv4 provides for moving responsibility for a single filesystem from one server to another, without disruption to clients. Recent implementation experience has shown problems in the existing specification for this feature. This document discusses the issues which have arisen and explores the options available for curing the issues via clarification and correction of the NFSv4.0 and NFSv4.1 specifications. Individual Submissions (none) ----------------------------- "The ARK Identifier Scheme http://www.ietf.org/internet-drafts/draft-kunze-ark-16.txt", John Kunze, R. Rodgers, 2-Apr-12, 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. "The 'tdb' and 'duri' URI schemes, based on dated URIs", Larry Masinter, 21-Jan-12, This document defines two URI schemes. The first, 'duri' (standing for "dated URI"), identifies a resource as of a particular time. This allows explicit reference to the "time of retrieval", similar to the way in which bibliographic references containing URIs are often written. The second scheme, 'tdb' ( standing for "Thing Described By"), provides a way of minting URIs for anything that can be described, by the means of identifying a description as of a particular time. These schemes were posited as "thought experiments", and therefore this document is designated as Experimental. "An IPv4 Flowlabel Option", Thomas Dreibholz, 31-Dec-11, This draft defines an IPv4 option containing a flowlabel that is compatible to IPv6. It is required for simplified usage of IntServ and interoperability with IPv6. "BGP Persistent Route Oscillation Solutions", Daniel Walton, Enke Chen, Alvaro Retana, John Scudder, 15-Dec-11, In this document we present two sets of paths for an address prefix that can be advertised by a BGP route reflector or confederation ASBR to eliminate the MED-induced route oscillations in a network. The first set involves all the available paths, and would achieve the same routing consistency as the full IBGP mesh. The second set, which is a subset of the first one, involves the neighbor-AS based Group Best Paths, and would be sufficient to eliminate the MED- induced route oscillations (subject to certain commonly adopted topological constrains). "EAP Support in Smartcard", Pascal Urien, Guy Pujolle, 27-Jan-12, This document describes the functional interface, based on the ISO7816 standard, to EAP methods, fully and securely executed in smart cards. This class of tamper resistant device may deliver client or server services; it can compute Root Keys from an Extended Master Session Key (EMSK). "Reliable Server Pooling Applicability for IP Flow Information Exchange", Thomas Dreibholz, Lode Coene, Phillip Conrad, 31-Dec-11, This document describes the applicability of the Reliable Server Pooling architecture to the IP Flow Information Exchange using the Aggregate Server Access Protocol (ASAP) functionality of RSerPool only. Data exchange in IPFIX between the router and the data collector can be provided by a limited retransmission protocol. "Lumas - Language for Universal Message Abstraction and Specification", Peter Cordell, 2-Feb-07, A number of methods and tools are available for defining the format of messages used for application protocols. However, many of these methods and tools have been designed for purposes other than message definition, and have been adopted on the basis that they are available rather than being ideally suited to the task. This often means that the methods make it difficult to get definitions correct, or result in unnecessary complexity and verbosity both in the definition and on the wire. Lumas - Language for Universal Message Abstraction and Specification - has been custom designed for the purpose of message definition. It is thus easy to specify messages in a compact, extensible format that is readily machine manipulated to produce a compact encoding on the wire. "Stream Control Transmission Protocol (SCTP) Packet Drop Reporting", Randall Stewart, Peter Lei, Michael Tuexen, 17-Feb-12, This document describes a new chunk type for SCTP. This new chunk type can be used by both endhosts and routers to report the loss of SCTP datagrams due to errors in transmission or other drops not due to congestion. "IP Fast Reroute using tunnels", Stewart Bryant, Clarence Filsfils, Stefano Previdi, Mike Shand, 16-Nov-07, This draft describes an IP fast re-route mechanism that provides backup connectivity in the event of a link or router failure. In the absence of single points of failure and asymmetric costs, the mechanism provides complete protection against any single failure. If perfect repair is not possible, the identity of all the unprotected links and routers is known in advance. This IP Fast Reroute advanced method was invented in 2002 and draft (draft-bryant-ipfrr-tunnels-00.txt) describing it was submitted to the IETF in May 2004. It was one of the first methods of achieving full repair coverage in an IP Network, and as such the draft has been widely referenced in the academic literature. The authors DO NOT propose that this IPFRR method be implemented since better IPFRR advanced method capable of achieving full repair coverage have subsequently been invented. "Certificate Exchange Messaging for EDIINT draft-meadors-certificate-exchange-14.txt Abstract", Kyle Meadors, Dale Moberg, 22-Dec-11, The EDIINT AS1, AS2 and AS3 message formats do not currently contain any neutral provisions for transporting and exchanging trading partner profiles or digital certificates. EDIINT Certificate Exchange Messaging provides the format and means to effectively exchange certificates for use within trading partner relationships. The messaging consists of two types of messages, Request and Response, which allow trading partners to communicate certificates, their intended usage and their acceptance through XML. Certificates can be specified for use in digital signatures, data encryption or SSL/TLS over HTTP (HTTPS). "The OCB Authenticated-Encryption Algorithm", Ted Krovetz, Phillip Rogaway, 22-Jan-12, This document specifies OCB, a shared-key blockcipher-based encryption scheme that provides privacy and authenticity for plaintexts and authenticity for associated data. "Applicability of Reliable Server Pooling for Real-Time Distributed Computing", Thomas Dreibholz, 31-Dec-11, This document describes the applicability of the Reliable Server Pooling architecture to manage real-time distributed computing pools and access the resources of such pools. "Secure SCTP", Carsten Hohendorf, Esbold Unurkhaan, Thomas Dreibholz, 31-Dec-11, This document explains the reason for the integration of security functionality into SCTP, and gives a short description of S-SCTP and its services. S-SCTP is fully compatible with SCTP defined in RFC4960, it is designed to integrate cryptographic functions into SCTP. "Combined Presence Schemas Utilizing RELAX NG", Jari Urpalainen, 9-Oct-08, This memo describes a batch of Presence Information Data Format (PIDF) and its extension schemas written with the RELAX NG schema language. Unlike with the current W3C XML Schema language it is possible to write reasonable forwards and backwards compatible presence combination schemas. These RELAX NG schemas are stricter than the W3C Schemas and thus the instance documents that validate with these schemas follow the intended content model more closely. Especially, these schemas are targeted to actual implementations in order to decrease interoperability problems. "Operational Reliability for EDIINT AS2", John Duker, Dale Moberg, 16-Apr-12, The goal of this document is to define approaches to achieve a "once and only once" delivery of messages. The EDIINT AS2 protocol [AS2] is implemented by a number of software tools on a variety of platforms with varying capabilities and with varying network service quality. Although the AS2 protocol defines a unique "Message-ID", current implementations of AS2 do not provide a standard method to prevent the same message (re-transmitted by the initial sender) from reaching back-end business applications at the initial receiver. TCP underpinnings of HTTP over which AS2 operates generally provide a good quality of network connectivity, but experience indicates a need to be able to compensate for both transient server and socket exceptions, including "Connection refused" as well as "Server busy." In addition, difficulties with server availability, stability, and loads can result in reduced operational reliability. This document describes some ways to compensate for exceptions and enhance the reliability of AS2 protocol operation. Implementation of these reliability features is indicated by presence of the "AS2- Reliability" value in the EDIINT-Features header. Intended Status The intent of this document is to be placed on the RFC track as an Informational RFC. Feedback Instructions: NOTE TO RFC EDITOR: This section should be removed by the RFC editor prior to publication. If you want to provide feedback on this draft, follow these guidelines: -Send feedback via e-mail to the ietf-ediint list for discussion, with "AS2 Reliability" in the Subject field. To enter or follow the discussion, you need to subscribe to ietf-ediint@imc.org. -Be specific as to what section you are referring to, preferably quoting the portion that needs modification, after which you state your comments. -If you are recommending some text to be replaced with your suggested text, again, quote the section to be replaced, and be clear on the section in question. "Improving DNS Service Availability by Using Long TTL Values", Eric Osterweil, Vasileios Pappas, 23-Feb-12, Due to the hierarchical tree structure of the Domain Name System [RFC1034][RFC1035], losing all of the authoritative servers that serve a zone can disrupt services to not only that zone but all of its descendants. This problem is particularly severe if all the authoritative servers of the root zone, or of a top level domain's zone, fail. Although proper placement of secondary servers, as discussed in [RFC2182], can be an effective means against isolated failures, it is insufficient to protect the DNS service against a Distributed Denial of Service (DDoS) attack. This document proposes to reduce the impact of DDoS attacks against top level DNS servers by setting long TTL values for NS records and their associated A and AAAA records. Our proposed changes are purely operational and can be deployed incrementally. "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)", Keith Drage, Christer Holmberg, Roland Jesske, 2-Apr-12, This document describes a set of private Session Initiation Protocol (SIP) header fields (P-headers) used by the 3rd-Generation Partnership Project (3GPP), along with their applicability, which is limited to particular environments. The P-header fields are for a variety of purposes within the networks that the partners use, including charging and information about the networks a call traverses. "DTCP: Dynamic Tasking Control Protocol", David Cavuto, 11-Nov-09, Dynamic Tasking Control Protocol is a message-based interface by which an authorized client may connect to a server -- usually a network element (NE) or security policy enforcement point (PEP) -- and issue dynamic requests for data. These tasking requests contain, among other parameters, packet matching criteria that may apply to certain packets flowing through that network element. The primary intent of the tasking request is to instruct that network element to send copies of packets matching those criteria to a destination (usually via tunneling) for further inspection or other action. The protocol contains a security architecture to address client or server spoofing as well as replay prevention. The protocol assumes that multiple clients may simultaneously control a single server. "The "pack" URI Scheme", Andrey Shur, Jerry Dunietz, 17-Feb-09, A package is a logical entity that holds a collection of parts. Given the URI for a complete package, the "pack" URI scheme provides for the construction and use of URIs referring to individual parts within the package. It also provides for the use of part's URIs as base URIs for resolving relative references between the parts in a single package. "The Public Suffix Structure file format and its use for Cookie domain validation", Yngve Pettersen, 6-Mar-12, This document defines the term "Public Suffix domain" as meaning a domain under which multiple parties that are unaffiliated with the owner of the Public Suffix domain may register subdomains. Examples of Public Suffix domains include "org", "co.uk", "k12.wa.us" and "uk.com". It also defines a file format that can be used to distribute information about such Public Suffix domains to relying parties. As an example, this information is then used to limit which domains an Internet service can set HTTP cookies for, strengthening the rules already defined by the cookie specification. This specification updates RFC 6265 [RFC6265] by defining the term "Public Suffix domain". "DNSSEC Validator API", Suresh Krishnaswamy, Robert Story, Abhijit Hayatnagarkar, 12-Mar-12, The DNS Security Extensions (DNSSEC) provide origin authentication and integrity of DNS data. However, the current resolver Application Programming Interface (API) does not specify how a validating stub resolver should communicate results of DNSSEC processing back to the application. This document describes an API between applications and a validating stub resolver that allows applications to control the DNSSEC validation process and obtain results of DNSSEC processing. "Applicability of Reliable Server Pooling for SCTP-Based Endpoint Mobility", Thomas Dreibholz, Jobin Pulinthanath, 31-Dec-11, This document describes a novel mobility concept based on a combination of SCTP with Dynamic Address Reconfiguration extension and Reliable Server Pooling (RSerPool). "Reliable Server Pooling (RSerPool) Bakeoff Scoring", Thomas Dreibholz, Michael Tuexen, 31-Dec-11, This memo describes some of the scoring to be used in the testing of Reliable Server Pooling protocols ASAP and ENRP at upcoming bakeoffs. "Extended Community Based Outbound Route Filter for BGP-4", Enke Chen, Alton Lo, Keyur Patel, 5-Dec-11, This document defines two new Outbound Router Filter types for BGP, termed "Extended Community Outbound Route Filter Type I", and "Extended Community Outbound Route Filter Type II", that can be used to perform extended community based route filtering. "Distributed DNS Implementation in IpV6", Lican Huang, 27-Jan-12, This file is a proposal for P2P based Domain Name query strategy in IpV6. The DNS servers construct n-tuple overlay virtual hierarchical overlay network. With cached addresses of DNS servers, the overload of traffic in tree structure can be avoided and more security can be enhanced due to the random lookup paths. This strategy may use for Domain Name query and reverse Domain Name query in IpV6 for a large number of domain names. "A Framework for Distributed Conferencing", Simon Romano, Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Alfonso Buono, 19-Dec-11, This document defines the framework for Distributed Conferencing (DCON). The framework draws inspiration from the work carried out in the XCON working group, which has defined a complete architecture for centralized conferencing. DCON is based on the idea that a distributed conference can be setup by appropriately orchestrating the operation of a number of XCON focus elements, each in charge of managing a certain number of participants. Interaction between each participant and the corresponding conference focus is based on the standard XCON framework, whereas inter-focus interaction is defined in this document. "Requirements for Distributed Conferencing", Simon Romano, Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Alfonso Buono, 19-Dec-11, This document examines the requirements for Distributed Conferencing (DCON). Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols as needed. Together, these documents will provide a guideline for building interoperable conferencing applications. The current works in SIPPING and XCON working groups marginally address the matter, which is nonetheless considered as out-of-scope. The requirements listed in this document are in part based on thoughts derived from the cited working groups activities. "Requirements for the XCON-DCON Synchronization Protocol", Simon Romano, Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Alfonso Buono, 19-Dec-11, The Distributed Conferencing (DCON) framework provides the means to distribute Centralized Conference (XCON) information by appropriately orchestrating a number of centralized focus entities (clouds). The mechanism we propose to make each XCON cloud communicate with its related DCON peer is based on the use of some kind of XCON-DCON Synchronization Protocol (XDSP). This document gives the requirements for XDSP. "A context mechanism for controlling caching of HTTP responses", Yngve Pettersen, 6-Mar-12, A common problem for sensitive web services is informing the client, in a reliable fashion, when a password protected resource is no longer valid because the user is logged out of the service. This is, in particular, considered a potential security problem by some sensitive services, such as online banking, when the user navigates the client's history list, which is supposed to display the resource as it was when it was loaded, not as it is the time the user navigates to it. This document presents a method for collecting such sensitive resources into a group, called a "Cache Context", which permits the server to invalidate all the resources belonging in the group either by direct action, or according to some expiration policy. The context can be configured to invalidate not just the resources, but also specific cookies, HTTP authentication credentials and HTTP over TLS session information. "Using Saratoga with a Bundle Agent as a Convergence Layer for Delay-Tolerant Networking", Lloyd Wood, Jim McKim, Wesley Eddy, Will Ivancic, Chris Jackson, 26-Mar-12, 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-11, This document describes the Handle Resolution option for the ASAP protocol. "A Flexible Authentication Framework for the Transport Layer Security (TLS) Protocol using the Extensible Authentication Protocol (EAP)", Yoav Nir, Yaron Sheffer, Hannes Tschofenig, Peter Gutmann, 19-Dec-11, Many of today's Web security problems have their root in the widespread usage of weak authentication mechanisms bundled with the usage of password based credentials. Dealing with both of these problems is the basis of this publication. This document extends the Transport Layer Security (TLS) protocol with a flexible and widely deployed authentication framework, namely the Extensible Authentication Protocol (EAP), to improve security of Web- as well as non-Web-based applications. The EAP framework allows so-called EAP methods, i.e. authentication and key exchange protocols, to be plugged into EAP without having to re-design the underlying protocol. The benefit of such an easy integration is the ability to run authentication protocols that fit a specific deployment environment, both from a credential choice as well as from the security and performance characteristics of the actual protocol. This work follows the example of IKEv2, where EAP has been added to allow clients to seamlessly use different forms of authentication credentials, such as passwords, token cards, and shared secrets. "Definition of a Delay Measurement Infrastructure and Delay-Sensitive Least-Used Policy for Reliable Server Pooling", Thomas Dreibholz, Xing Zhou, 31-Dec-11, This document contains the definition of a delay measurement infrastructure and a delay-sensitive Least-Used policy for Reliable Server Pooling. "The Lightweight Global Navigation Satellite System (GNSS) Support Protocol (LGSP)", Carlo Kopp, Mike Tyson, 21-Dec-07, This document presents the Lightweight GNSS (Global Navigation Satellite System) Support Protocol (LGSP). The Lightweight GNSS Support Protocol (LGSP) is being developed in order to provide a comprehensive solution which solves the problems inherent in traditional radio-based Differential GPS (DGPS) protocols. LGSP will also provide additional support for GNSS user equipment, such as a GPS almanac retrieval method, allowing compatible units to perform faster almanac acquisition, thus resulting in less time until an initial position measurement can be established. Other supporting features include alternative distribution of GPS navigation messages and differential correction messages, a hierarchical mirroring architecture, redundant backup operation and load balancing functions. "Saratoga: A Scalable Data Transfer Protocol", Lloyd Wood, Wesley Eddy, Charles Smith, Will Ivancic, Chris Jackson, 26-Mar-12, This document specifies the Saratoga transfer protocol. Saratoga was originally developed to transfer remote-sensing imagery efficiently from a low-Earth-orbiting satellite constellation, but is useful for many other scenarios, including ad-hoc peer-to-peer communications, delay-tolerant networking, and grid computing. Saratoga is a simple, lightweight, content dissemination protocol that builds on UDP, and optionally uses UDP-Lite. Saratoga is intended for use when moving files or streaming data between peers which may have permanent, sporadic or intermittent connectivity, and is capable of transferring very large amounts of data reliably under adverse conditions. The Saratoga protocol is designed to cope with highly asymmetric link or path capacity between peers, and can support fully-unidirectional data transfer if required. In scenarios with dedicated links, Saratoga focuses on high link utilization to make the most of limited connectivity times, while standard congestion control mechanisms can be implemented for operation over shared links. Loss recovery is implemented via a simple negative-ack ARQ mechanism. The protocol specified in this document is considered to be appropriate for experimental use on private IP networks. "Session Initiation Protocol Service Example -- Music on Hold", Dale Worley, 13-Feb-12, The "music on hold" feature is one of the most desired features of telephone systems in the business environment. "Music on hold" is where, when one party to a call has the call "on hold", that party's telephone provides an audio stream (often music) to be heard by the other party. Architectural features of SIP make it difficult to implement music-on-hold in a way that is fully compliant with the standards. The implementation of music-on-hold described in this document is fully effective and standards-compliant, and has a number of advantages over the methods previously documented. In particular, it is less likely to produce peculiar user interface effects and more likely to work in systems which perform authentication than the method of RFC 5359. "Mutual Authentication Protocol for HTTP", Yutaka Oiwa, Hajime Watanabe, Hiromitsu Takagi, Boku Kihara, Tatsuya Hayashi, Yuichi Ioku, 18-May-12, This document specifies a mutual authentication method for the Hyper- text Transport Protocol (HTTP). This method provides a true mutual authentication between an HTTP client and an HTTP server using password-based authentication. Unlike the Basic and Digest authentication methods, the Mutual authentication method specified in this document assures the user that the server truly knows the user's encrypted password. This prevents common phishing attacks: a phishing attacker controlling a fake website cannot convince a user that he authenticated to the genuine website. Furthermore, even when a user authenticates to an illegitimate server, the server cannot gain any information about the user's password. The Mutual authentication method is designed as an extension to the HTTP protocol, and is intended to replace the existing authentication methods used in HTTP (the Basic method, Digest method, and authentication using HTML forms). "Representation of Uncertainty and Confidence in PIDF-LO", Martin Thomson, James Winterbottom, 29-Mar-12, The key concepts of uncertainty and confidence as they pertain to location information are defined. Methods for the manipulation of location estimates that include uncertainty information are outlined. "Kerberos V5 Internationalization of Error Messages", Simon Josefsson, 26-Mar-12, This document describes an internationalization extension for the Kerberos V5 protocol. The extension allows error messages to be sent in the users' language. This document updates RFC 4120 to add a new PA-DATA type and to modify the protocol logic related to KRB-ERROR when the new PA-DATA extension is negotiated. "Probabilistic Routing Protocol for Intermittently Connected Networks", Anders Lindgren, Avri Doria, Elwyn Davies, Samo Grasic, 22-May-12, This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document defines PRoPHET, a Probabilistic Routing Protocol using History of Encounters and Transitivity. PRoPHET is a variant of the epidemic routing protocol for intermittently connected networks that operates by pruning the epidemic distribution tree to minimize resource usage while still attempting to achieve the best case routing capabilities of epidemic routing. It is intended for use in sparse mesh networks where there is no guarantee that a fully connected path between source and destination exists at any time, rendering traditional routing protocols unable to deliver messages between hosts. These networks are examples of networks where there is a disparity between the latency requirements of applications and the capabilities of the underlying network (networks often referred to as Delay- and Disruption-Tolerant). The document presents an architectural overview followed by the protocol specification. "Specification of 3GPP IM CN Subsystem XML body handling", John-Luc Bakker, 27-Mar-12, This document registers new disposition-types for the Content- Disposition header field that apply to the application/3gpp-ims+xml body (part) used by 3GPP. The applicability of these content- disposition values are limited to 3GPP IMS. The application/ 3gpp-ims+xml body (part) has the following three distinct uses: (1) for redirecting the emergency session to use a different domain (e.g. using a Circuit Switched call), (2) for delivering user profile specific information from the SIP registrar to an Application Server, and (3) for causing a UAC to attempt to re-register with the IMS. "P-Charge-Info - A Private Header (P-Header) Extension to the Session Initiation Protocol (SIP)", Dan York, Tolga Asveren, 3-Apr-12, This document describes 'P-Charge-Info', a private Session Initiation Protocol (SIP) header (P-header) used to convey billing information about the party to be charged. This P-Header is currently in production usage by a number of equipment vendors and carriers and this document is submitted to request the registration of this header with IANA. This P-Header may also be used in some situations to carry the ISUP Charge Number parameter for PSTN interconnection. "The BagIt File Packaging Format (V0.97)", Andy Boyko, John Kunze, Justin Littman, Liz Madden, Brian Vargas, 2-Apr-12, 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. "Better Approach To Mobile Ad-hoc Networking (B.A.T.M.A.N.)", Axel Neumann, Corinna Aichele, Marek Lindner, Simon Wunderlich, 7-Apr-08, This document specifies a simple and robust algorithm for establishing multi-hop routes in mobile ad-hoc networks. It ensures highly adaptive and loop-free routing while causing only low processing and traffic cost. "PCEP extensions for a BGP/MPLS IP-VPN", Kenji Kumaki, Tomoki Murai, Dhruv Dhody, PENG JIANG, 26-Apr-12, IP Virtual Private Networks (IP-VPNs) allow Service Providers to offer customers connectivity between sites across an IP Backbone. These VPNs can be supported using BGP/MPLS and the connections can be created by using MPLS Traffic Engineered (TE) Label Switched Paths (LSPs). The paths of these LSPs must be computed to provide the connectivity between customer sites. Path selection may be dependent on a variety of factors including traffic engineering constraints and bandwidth requirements. It is highly desirable for VPN customers to be able to dynamically establish their MPLS TE LSPs for interconnectivity between BGP/MPLS IP-VPN sites. The Path Computation Element (PCE) can determine the optimal paths of TE LSPs within an MPLS network. This document defines the PCEP extensions for the dynamic creation of MPLS TE LSPs between BGP/MPLS IP-VPN sites. "ECC in OpenPGP", Andrey Jivsov, 11-Apr-12, This document defines an Elliptic Curve Cryptography extension to the OpenPGP public key format and specifies three Elliptic Curves that enjoy broad support by other standards, including standards published by the US National Institute of Standards and Technology. The document specifies the conventions for interoperability between compliant OpenPGP implementations that make use of this extension. "Labels for Common Location-Based Services", Andrea Forte, Henning Schulzrinne, 15-Jan-10, This document creates a registry for describing the types of services available at a specific location. The registry is expected to be referenced by other protocols that need a common set of service terms as protocol constants. In particular, we define location-based service as either a point at a specific geographic location (e.g., bus stop) or a service covering a specific region (e.g., pizza delivery). "Random Data Encryption Mechanism (RDEM)", Mukul Jaitly, 1-Jun-08, This document describe an data encryption specification which is based on random bytes selection of data and random key generation. This encryption process accepts variable input and the key size is dependent on the input data. This encryption process does not depend upon any 128 or 256 fixed block encryption. The mechanism for encryption is simpler to implement, but gives key complexity of more than 256 bit encryption. "BGP Extended Community for QoS Marking", Thomas Knoll, 6-Jan-12, This document specifies a simple signalling mechanism for inter- domain QoS marking using several instances of a new BGP Extended Community. Class based packet marking and forwarding is currently performed independently within ASes. The new QoS marking community makes the targeted Per Hop Behaviour within the IP prefix advertising AS and the currently applied marking at the interconnection point known to all access and transit ASes. This enables individual (re-)marking and possibly forwarding treatment adaptation to the original QoS class setup of the respective originating AS. The extended community provides the means to signal QoS markings on different layers, which are linked together in QoS Class Sets. It provides inter-domain and cross-layer insight into the QoS class mapping of the source AS with minimal signalling traffic. "ISP Shared Address", Ikuhei Yamagata, Shin Miyakawa, Akira Nakagawa, Jiro Yamaguchi, Hiroyuki Ashida, 5-Jan-12, This document defines IPv4 ISP Shared Address to be jointly used among Internet Service Providers (ISPs). This space is intended to be used in NAT444 model which is used during the transition period to IPv6. "MVPN: Optimized use of PIM via MS-PMSIs", Yiqun Cai, Eric Rosen, IJsbrand Wijnands, Maria Napierala, Arjen Boers, 6-Feb-12, This document specifies an optimized method that a service provider can use to provide MVPN service when using PIM as the MVPN control protocol. As in prior MVPN methods, PIM control messages are sent over multicast tunnels through the provider network. However, unlike older MVPN methods, the tunnels are only created if they are needed to carry multicast data traffic; no tunnels are used only for control traffic. "Management Information Base for Cryptographically Generated Addresses (CGA)", Alberto Garcia-Martinez, Marcelo Bagnulo, 9-Apr-12, This memo defines a portion of the Management Information Base (MIB) for managing Cryptographically Generated Addresses (CGA). "Management Information Base for the SEcure Neighbor Discovery (SEND) protocol", Alberto Garcia-Martinez, Marcelo Bagnulo, 10-Apr-12, This memo defines a portion of the Management Information Base (MIB) for managing the SEND (SEcure Neighbor Discovery) Protocol. "SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol", Michael Tuexen, Irene Ruengeler, Randall Stewart, 30-Apr-12, This document defines a method for the sender of a DATA chunk to indicate that the corresponding SACK chunk should be sent back immediately and not be delayed. "The References Header for SIP", Dale Worley, 2-Apr-12, This document defines a SIP extension header, References, to be used within SIP messages to signify that the message (and the dialog containing it) is related to one or more other dialogs. It is expected to be used largely for diagnostic purposes. "Signaling RSVP-TE P2MP LSPs in an Inter-domain Environment", Zafar Ali, Rakesh Gandhi, 10-Feb-12, Point-to-MultiPoint (P2MP) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques described in [RFC4875]. However, [RFC4875] does not address many issues that come when a P2MP-TE LSP is signaled in inter-domain networks. Specifically, one of the issues in inter- domain networks is how to allow computation of a loosely routed P2MP-TE LSP such that it is re-merge free. Another issue is reoptimization of a P2MP-TE tree vs. reoptimization of an individual destination sub-LSP, as loosely routing domain border node is not aware of the reoptimization scope. This document provides a framework and required protocol extensions needed for establishing, controlling and reoptimizing P2MP MPLS and GMPLS TE LSPs in inter-domain networks. This document borrows inter-domain TE terminology from [RFC 4726], e.g., for the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes). "BGP Class of Service Interconnection", Thomas Knoll, 11-May-12, 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, 12-Mar-12, This document describes how to use a subset of the IETF-based emergency call framework for accomplishing emergency calling support in vehicles. Simplifications are possible due to the nature of the functionality that is going to be provided in vehicles with the usage of GPS. Additionally, further profiling needs to be done regarding the encoding of location information. "Auto Issued X.509 Certificate Mechanism (AIXCM)", Thierry Moreau, 6-Aug-08, The Transport Layer Security (TLS) protocol does not support the use of client public key pairs without X.509 security certificates. This document circumvents this limitation: an end-entity has access to the public domain private key of a dummy (or "explicitly meaningless") Certification Authority (CA), and can thus freely issue an X.509 security certificate for interoperability purposes. Given these workaround requirement and solution approach, the document limits itself to the strict minimal set of standardization provisions. This supports the orderly cohabitation of auto issued certificates and normal TLS traffic relying on the full Public Key Infrastructure (PKI) model. "Images in RFCs", Robert Braden, John Klensin, 12-Mar-12, Documents in the RFC series normally use only plain-text ASCII characters and a fixed-width font. However, there is sometimes a need to supplement the ASCII text with images -- e.g., graphics, equations, or pictures. The historic solution to this requirement has allowed secondary PDF and/or Postscript files, but this approach has seldom been used because it is awkward for authors and publisher. This memo sugests a convenient scheme for logically including authoritative diagrams, illustrations, equations, or other graphics within RFCs. "Multicast Routing Optimization by PIM-SM with PMIPv6", Hitoshi Asaeda, Pierrick Seite, 26-Mar-12, This document describes IP multicast routing optimization using 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 provides seamless handover. "Healthy Food and Special Dietary Requirements for IETF meetings", Mary Barnes, 12-Mar-12, 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. "NAT444 addressing models", Jiro Yamaguchi, Yasuhiro Shirasaki, Shin Miyakawa, Akira Nakagawa, Hiroyuki Ashida, 5-Jan-12, This document describes addressing models of NAT444. There are some addressing models of NAT444. The addressing models have some issues of network behaviors, operations, and addressing. This document helps network architects to use NAT444 after IPv4 address exhaustion. "Takeover Suggestion Flag for the ENRP Handle Update Message", Thomas Dreibholz, Xing Zhou, 31-Dec-11, This document describes the Takeover Suggestion Flag for the ENRP_HANDLE_UPDATE message of the ENRP protocol. "Port Restricted IP Address Assignment", Gabor Bajko, Teemu Savolainen, Mohamed Boucadair, Pierre Levis, 2-Apr-12, This document defines an IPv4 DHCP Option and related behaviours to allocate the same IPv4 address to multiple nodes by sharing the available port space among them. The two sub-options defined in this document specify random port allocation to nodes in order to maximize the entropy of port randomization. "Multicast only Fast Re-Route", Apoorva Karan, Clarence Filsfils, Dino Farinacci, Bruno Decraene, Nicolai Leymann, Wim Henderickx, 9-Mar-12, As IPTV deployments grow in number and size, service providers are looking for solutions that minimize the service disruption due to faults in the IP network carrying the packets for these services. This draft describes a mechanism for minimizing packet loss in a network when node or link failures occur. Multicast only Fast Re- Route (MoFRR) works by making simple enhancements to multicast routing protocols such as PIM and mLDP. "MPLS-TP OAM based on Y.1731", Italo Busi, Huub van Helvoort, He Jia, 11-Jan-12, This document describes methods to leverage Y.1731 [2] Protocol Data Units (PDU) and procedures (state machines) to provide a set of Operation, Administration, and Maintenance (OAM) mechanisms that meets the MPLS Transport Profile (MPLS-TP) OAM requirements as defined in [8]. In particular, this document describes the MPLS-TP technology specific encapsulation mechanisms to carry these OAM PDUs within MPLS-TP packets to provide MPLS-TP OAM capabilities in MPLS-TP networks. "Top Level Domain Name Specification", Lars-Johan Liman, Joe Abley, 29-Nov-11, The syntax for allowed Top-Level Domain (TLD) labels in the Domain Name System (DNS) is not clearly applicable to the encoding of Internationalised Domain Names (IDNs) as TLDs. This document provides a concise specification of TLD label syntax based on existing syntax documentation, extended minimally to accommodate IDNs. This document updates RFC1123. "Targeted LDP Hello Reduction", Pranjal Dutta, Giles Heron, Thomas Nadeau, 20-May-12, Targeted LDP Hellos are used for establishing adjacencies with non- directly connected peers. After an LDP session is established to a targeted peer, the session Keepalives are sufficient to notify the intent of an LSR to maintain its adjacency with the peer. This document proposes a mechanism to turn off Targeted LDP Hellos after LDP session is established to a peer. "HTTP Live Streaming", Roger Pantos, 26-Mar-12, This document describes a protocol for transferring unbounded streams of multimedia data. It specifies the data format of the files and the actions to be taken by the server (sender) and the clients (receivers) of the streams. It describes version 4 of this protocol. "The i;codepoint collation", Bjoern Hoehrmann, 14-Sep-10, This memo describes the "i;codepoint" collation. Character strings are compared based on the Unicode scalar values of the characters. The collation supports equality, substring, and ordering operations. "DHCPv4 Options for Home Information Discovery in Dual Stack MIPv6", Frank Xia, Behcet Sarikaya, 10-Jan-12, This document defines DHCPv4 options for dynamic discovery of home network information in Dual Stack Mobile IPv6. New DHCPv4 options are defined which allow a mobile node to request the home agent IPv4/v6 address, FQDN, or home network prefix and obtain it via the DHCPv4 response. "A Session Initiation Protocol (SIP) Event Package for Communication Diversion Information in support of the Communication Diversion (CDIV) Notification (CDIVN) CDIV service", John-Luc Bakker, Ranjit Avasarala, 27-Mar-12, 3GPP and TISPAN are defining the protocol specification for the Communication Diversion (CDIV) service using IP Multimedia (IM) Core Network (CN) subsystem supplementary service. As part of CDIV, a SIP based Event package framework is used for notifying users about diversions (re-directions or forwarding) of their incoming communication sessions. This document proposes a new SIP event package for allowing users to subscribe to and receive such notifications. Users can further define filters to control the rate and content of such notifications. The proposed event package is applicable to the CDIV supplementary service in IMS and may not be applicable to the general internet. . "PCEP Extensions for WSON Impairments", Greg Bernstein, Jonas Martensson, Takehiro Tsuritani, Tomonori Takeda, Young Lee, 6-Jan-12, As an optical signal progresses along its path it may be altered by the various physical processes in the optical fibers and devices it encounters. When such alterations result in signal degradation, these processes are usually referred to as "impairments". These physical characteristics may be important constraints to consider in path computation process in wavelength switched optical networks. This document provides PCEP extensions to support Impairment Aware Routing and Wavelength Assignment (IA-RWA) in wavelength switched optical networks. "Fast Handover for Multicast in Proxy Mobile IPv6", Min Hui, Hui Deng, Dapeng Liu, 12-Mar-12, This document specifies the predictive fast handover mechanism to solve the problem of handover latency and packet loss in Proxy Mobile IPv6 Multicast. Necessary extensions are specified for Handover Initiate (HI) and Handover Acknowledgement (HAck) messages to support multicast handover procedure. "LISP Mobile Node", Dino Farinacci, Darrel Lewis, Dave Meyer, Chris White, 23-Apr-12, This document describes how a lightweight version of LISP's ITR/ETR functionality can be used to provide seamless mobility to a mobile node. The LISP Mobile Node design described in this document uses standard LISP functionality to provide scalable mobility for LISP mobile nodes. "Design Considerations for Protocol Extensions", Brian Carpenter, Bernard Aboba, Stuart Cheshire, 21-Feb-12, This document discusses issues related to the extensibility of Internet protocols, with a focus on architectural design considerations. It is intended to assist designers of both base protocols and extensions. Case studies are included. "The RADIUS-Diameter Gateway (RADIA) Application", Glen Zorn, Lionel Morand, Tom Hiller, 13-Feb-12, This document describes the Diameter RADIUS-Diameter Gateway (RADIA) Application, which is designed to facillitate the interoperability of Authentication, Authorization and Accounting (AAA) systems based upon RADIUS and Diameter. "Mechanisms for Media Source Selection in the Session Description Protocol (SDP)", Jonathan Lennox, Henning Schulzrinne, 12-Mar-12, Source-specific media attributes in the Session Description Protocol (SDP) allow endpoints to describe Real-Time Transport Protocol (RTP) sources within a media stream. This document extends that mechanism by defining how participants in a multimedia session can request specific sources from a remote party. "Virtual Network Management Information Model", Hideki Okita, Masahiro Yoshizawa, Toshiaki Suzuki, Tomoyuki Iijima, 11-Mar-12, Virtual switches on server virtualization platforms cause a problem in managing networks in data center and between data centers containing several hundred switches. Accordingly, a management information model for the networks containing virtual switches is proposed. The proposed model consists of a physical layer (which represents connections between physical switches) and a virtual layer (which represents connections between virtual switches). These layers also represent the association of the virtual switch with the corresponding physical switch. This document also provides implementation examples of proposed information model in XML and Yang. "Extranet in BGP Multicast VPN (MVPN)", Rahul Aggarwal, Yakov Rekhter, Thomas Morin, Wim Henderickx, Praveen Muley, Ray Qiu, 31-Jan-12, This document describes clarifications and extensions to the procedures in [BGP-MVPN] for supporting extranets. The procedures specified in this document assume that BGP is used for transmission of MVPN customers' multicast routing information within the service provider(s) infrastructure. "Session Recording for Conferences using SMIL", Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Simon Romano, 20-Dec-11, This document deals with session recording, specifically for what concerns recording of multimedia conferences, both centralized and distributed. Each involved media is recorded separately, and is then properly tagged. A SMIL [W3C.CR-SMIL3-20080115] metadata is used to put all the separate recordings together and handle their synchronization, as well as the possibly asynchronous opening and closure of media within the context of a conference. This SMIL metadata can subsequently be used by an interested user by means of a compliant player in order to passively receive a playout of the whole multimedia conference session. The motivation for this document comes from our experience with our conferencing framework, Meetecho, for which we implemented a recording functionality. "RTP Payload Format for DRA Audio", ChuSheng Zheng, JingPing Zhang, Mao Xu, Tian Jiang, WeiXiong Zhang, 23-Aug-09, The present document describes a RTP packaging scheme for DRA compressed audio data transmission, as well as the corresponding RTP payload format. According to the properties of DRA compressed audio frame and the Maximum Transmission Unit (MTU) of network, the scheme provides 3 packaging modes for different coding and transmission requirements. "Chinese Common Name to Uniform Resource Identifier(URI) Dynamic Delegation Discovery System(DDDS) Application(CCN)", Jiankang Yao, XiaoDong Lee, 11-Sep-09, This document discusses the use of the Domain Name System(DNS) for storage of Chinese Common Name to URI mapping. More specifically, how DNS can be used for identifying URIs or services associated with the Chinese Common Names. The method used to discover the mapping is the Dynamic Delegation Discovery System, which can be found in a series of documents specified in RFC 3401. Understanding of RFC 3401 is necessary for understanding this document. "AFS Callback Extensions (Draft 14)", Matthew Benjamin, 12-Dec-11, AFS cache-control strategy is callback (invalidate) based. The AFS callback design allows a client to know when an object it has cached is no longer consistent, but the callback notification message itself provides no specific information about the triggering event. This is a protocol inefficiency, as in several scenarios it results in unnecessary round-trips to file servers to verify file status information, file access information, or to fetch file data which has not changed. We propose an extension of the callback mechanism to provide information about the event(s) triggering a callback, in the payload of the callback notification message itself. The proposed mechanism eliminates most or all unnecessary round-trips imposed by the current callback mechanism, and simultaneously allows AFS implementations to (efficiently) provide correct semantics in several scenarios involving multiple writers (ie, where AFS currently provides incorrect semantics). "Control Word Reserved bit for use in E-Tree", Simon DeLord, Raymond Key, Frederic JOUNAY, Wim Henderickx, Lucy Yong, Lizhong Jin, 16-Apr-12, The extension described in this document allows a pair of PEs connected via an Ethernet Pseudowire (PW) to signal via the use of the Control Word (CW) whether the Ethernet frame encapsulated is coming from a Root AC or a Leaf AC. This allows a PE receiving this frame to decide whether it can be forwarded to a Leaf AC or not. Such forward or drop decision is an additional filtering action after the MAC-based forwarding decision. This applies to both P2P PW and P2MP PW. "A Generic IPv6 Addresses Registration Solution Using DHCPv6", Sheng Jiang, Gang Chen, 26-Feb-12, In the IPv6 address allocation scenarios, host self-generated addresses are notionally conflicted with the network managed address architecture. These addresses need to be registered in the networking management plate for the purposes of central address administration. This document introduces a generic address registration solution using DHCPv6, and defines one new ND option and one new DHCPv6 option in order to propagate the solicitations of registering self-generated addresses. The registration procedure reuses the existing IA_NA in the DHCPv6 protocol. "Extension to VPLS for E-Tree", Raymond Key, Simon DeLord, Frederic JOUNAY, Wim Henderickx, Lucy Yong, Lizhong Jin, 16-Apr-12, This document proposes a simple and effective approach to emulate E-Tree services over an MPLS network. Section 4 presents a minimal extension to the current VPLS architecture defined in [RFC4761] and [RFC4762] to fulfil the specific E-Tree requirement: Leaf cannot communicate with Leaf. Backward compatibility issues are addressed also. "Adding Multiple TLS Certificate Status Extension requests", Yngve Pettersen, 6-Mar-12, This document introduces a replacement of the TLS Certificate Status Extension to allow clients to specify and support multiple certificate status methods. Also being introduced is a new OCSP- based method that servers can use to provide status information not just about the server's own certificate, but also the status of intermediate certificates in the chain. "PMIPv6 and Network Mobility Problem Statement", Carlos Bernardos, Maria Calderon, Ignacio Soto, 12-Mar-12, The NETLMM WG standardized Proxy Mobile IPv6 (PMIPv6). PMIPv6 enables mobile devices to connect to a PMIPv6 domain and roam across gateways without changing the IP address. Current PMIPv6 specification does only support the movement of hosts within the localized mobility domain. A mobile network (commonly referred to as a NEMO, NEtwork that MOves) can also benefit from the network-based localized mobility support provided by PMIPv6 [I-D.ietf-netext-pd-pmip], but with some limitations. This I-D describes what can be done with current standardized protocols, and describes the problem statement of fully supporting network mobility in Proxy Mobile IPv6. "Information Elements for Data Link Layer Traffic Measurement", Shingo Kashima, Kensuke Nakata, Atsushi Kobayashi, 12-Mar-12, 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. "Session Policy Framework using EAP", Stephen McCann, Michael Montemurro, 9-Jan-12, This document specifies a framework for implementing a session policy channel using EAP. It defines a standard mechanism by which a mobile device can conduct a session policy exchange with a policy network component, using EAP as a lower layer protocol, to obtain session policies. EAP Re-authentication Protocol is suggested as a mechanism to allow asynchronous use of SIP at upper layers. "NAT444", Ikuhei Yamagata, Yasuhiro Shirasaki, Akira Nakagawa, Jiro Yamaguchi, Hiroyuki Ashida, 5-Jan-12, This document describes one of the network models that are designed for smooth transition to IPv6. It is called NAT444 model. NAT444 model is composed of IPv6, and IPv4 with Carrier Grade (CGN). NAT444 is the only scheme not to require replacing Customer Premises Equipment (CPE) even if IPv4 address exhausted. But it must be noted that NAT444 has serious restrictions i.e. it limits the number of sessions per CPE so that rich applications such as AJAX and RSS feed cannot work well. Therefore, IPv6 which is free from such a difficulty has to be introduced into the network at the same time. In other words, NAT444 is just a tool to make IPv6 transition easy to be swallowed. It is designed for the days IPv4 and IPv6 co-existence. "A Uniform Resource Name (URN) Namespace for Sources of Law (LEX)", PierLuigi Spinosa, Enrico Francesconi, Caterina Lupo, 2-Apr-12, This document describes a Uniform Resource Name (URN) Namespace Identification (NID) convention as prescribed by the World Wide Web Consortium (W3C) for identifying, naming, assigning, and managing persistent resources in the legal domain. "AS2 Restart for Very Large Messages", Terry Harding, 2-Apr-12, AS2 Restart provides a method for AS2 clients and servers to restart payload transfers from the point of failure without requiring the entire document to be resent. Keywords "Security Threats for NHDP", Ulrich Herberg, Jiazi Yi, Thomas Clausen, 12-Mar-12, This document analyses common security threats of the Neighborhood Discovery Protocol (NHDP), and describes their potential impacts on MANET routing protocols using NHDP. "Mesh Structured Hierarchical Networking and IPv6", Shyam Bandyopadhyay, 3-Jan-12, This document tries to address an approach for reorganization of entire network in a large address space. It describes how a three- tier mesh structured hierarchy can be established based on fragmenting the entire space into some regions and sub regions inside each of them. It addresses issues which could be relevant to this architecture in the context of IPv6. This document also tries to come out with an approach how IP switch based network can perform as good as ATM network for the processing of real time traffic. "rxgk: GSSAPI based security class for RX", Simon Wilkinson, 10-Jan-12, rxgk is a security class for the RX RPC protocol. It uses the GSSAPI framework to provide authentication, confidentiality and integrity protection. This document provides a general description of rxgk. A further document will provide details of integration with specific RX applications. "Integrating rxgk with AFS", Simon Wilkinson, 10-Jan-12, This document describes how the new GSSAPI based rxgk security class for RX is integrated with the AFS application protocol. It describes a number of extensions to the basic rxgk protocol, clarifies a number of implementation issues, and provides values for the application specific elements of rxgk. "Transport Layer Security (TLS) Next Protocol Negotiation Extension", Adam Langley, 21-May-12, This document describes a Transport Layer Security (TLS) extension for application layer protocol negotiation. This allows the application layer to negotiate which protocol should be performed over the secure connection. "The acr URI for anonymous users", Sune Jakobsson, Kevin Smith, 1-Mar-12, This document specifies the URI (Uniform Resource Identifier) scheme "acr". The "acr" URI describes an anonymous reference, that can be mapped to a resource or user. "Stateless Automatic IPv4 over IPv6 Encapsulation / Decapsulation Technology: Global SA46T Address Format", Naoki Matsuhira, 5-Jan-12, This document proposes Stateless Automatic IPv4 over IPv6 Encapsulation / Decapsulation Technology (SA46T) Global Address Format. SA46T can apply to organization's network individually, but if coordination between the organizations made, the total number of times of encapsulations and decapusulations can be reduced. That coordination is achieved by using same SA46T address format, that is Global address. This document proposes SA46T Global address format. SA46T is a gateway technology, not protocol. But SA46T Global Address needs IANA assignment, so this document should be categorized standard track or experimental. "Stateless Automatic IPv4 over IPv6 Encapsulation / Decapsulation Technology: Specification", Naoki Matsuhira, 5-Jan-12, This document specifies Stateless Automatic IPv4 over IPv6 Encapsulation / Decapsulation Technology (SA46T) base specification. SA46T makes backbone network to IPv6 only. And also, SA46T can stack many IPv4 networks, i.e. the networks using same IPv4 (private) addresses, without interdependence. "MVPN: Extranets, Anycast-Sources, 'Hub & Spoke', with PIM Control Plane", Yiqun Cai, Eric Rosen, Rajesh Sharma, IJsbrand Wijnands, 6-Feb-12, This document provides the specification for using the PIM control plane of to provide Multicast Virtual Private Network support for extranets, for anycast sources, and for "hub and spoke" configurations. "Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute", Mohamed Boucadair, Hadriel Kaplan, Robert Gilman, Simo Veikkolainen, 23-Apr-12, This document proposes a mechanism which allows to carry multiple IP addresses, of different address families (e.g., IPv4, IPv6), in the same SDP offer. The proposed attribute solves the backward compatibility problem which plagued ANAT, due to its syntax. "Capability Exchange for Media Plane Security", Peter Dawes, 3-Feb-12, Negotiating the security mechanisms used between a Session Initiation Protocol (SIP) user agent and its next-hop SIP entity is already described in an RFC. This document extends negotiation of a security mechanism to the media plane by defining a new Session Initiation Protocol (SIP) header field parameter to label security mechanisms that apply to the media plane. "Composite Link Framework in Multi Protocol Label Switching (MPLS)", Ning So, Dave McDysan, Eric Osborne, Lucy Yong, Curtis Villamizar, 7-Mar-12, This document specifies a framework for support of composite link in MPLS networks. A composite link consists of a group of homogenous or non-homogenous links that have the same forward adjacency and can be considered as a single TE link or an IP link in routing. A composite link relies on its component links to carry the traffic over the composite link. Applicability is described for a single pair of MPLS-capable nodes, a sequence of MPLS-capable nodes, or a set of layer networks connecting MPLS-capable nodes. "Securing HTTP State Management Information", Gonzalo Salgueiro, Paul Jones, 19-Feb-12, Virtually every application on the web today that allows a user to log in or manipulate information stored on a server maintains some form of state management information. Usually, the session context is established through the use of a Uniform Resource Locator (URL) parameter or a Hypertext Transfer Protocol (HTTP) cookie that identifies the session. Without the use of Transport Layer Security (TLS), such an information exchange introduces a security risk. For a variety of reasons, TLS may not be desired or preferred in all situations and, in those cases, users are left vulnerable. This memo provides a simple method for enabling secure exchange of state management information through HTTP in situations where TLS is not employed. "Quick Failover Algorithm in SCTP", Yoshifumi Nishida, Preethi Natarajan, Armando Caro, 12-Mar-12, One of the major advantages in SCTP is supporting multi-homing communication. If a multi-homed end-point has redundant network connections, SCTP sessions can have a good chance to survive from network failures by migrating inactive network to active one. However, if we follow the SCTP standard, there can be significant delay for the network migration. During this migration period, SCTP cannot transmit much data to the destination. This issue drastically impairs the usability of SCTP in some situations. This memo describes the issue of SCTP failover mechanism and discuss its solutions which require minimal modification to the current standard. "HIP-based Virtual Private LAN Service (HIPLS)", Tom Henderson, Steven Venema, David Mattes, 7-Mar-12, The Host Identity Protocol (HIP) and architecture adds a cryptographic name space to name Internet hosts. This draft describes a use case of the HIP architecture, which is to provide a HIP-enabled virtual private LAN service (VPLS) over an untrusted network. In this case, HIP is used to secure tunnels between the provider edge (PE) equipment. "Extensions to RSVP-TE for P2MP LSP Egress Local Protection", Huaimo Chen, Ning So, Autumn Liu, Olufemi Komolafe, Lei Liu, 12-Mar-12, This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting egress nodes of a Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Path (LSP) in a Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) network. "Extensions to RSVP-TE for P2MP LSP Ingress Local Protection", Huaimo Chen, Ning So, Autumn Liu, Olufemi Komolafe, Lei Liu, 12-Mar-12, This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the ingress node of a Traffic Engineered (TE) Point-to-MultiPoint (P2MP) Label Switched Path (LSP) in a Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) network. "MPLS-TP Shared Mesh Protection", Tae-sik Cheung, Jeong-dong Ryoo, Yaacov Weingarten, Nurit Sprecher, Daniel King, 12-Mar-12, This document describes a mechanism to address the requirement to support protection of Label Switched Paths (LSPs) in an MPLS Transport Profile (MPLS-TP) mesh topology. The shared mesh protection mechanism enables multiple protection paths within a shared mesh protection domain to share protection resources for the protection of working paths by coordinating protection switching operations according to the priority assigned to each end-to-end linear protection domain. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. "Leaf discovery mechanism for mLDP based P2MP/MP2MP LSP", Lizhong Jin, Kebo Liu, Sriganesh Kini, 5-May-12, This document describes a mechanism for a root node to discover the leaf nodes of an mLDP based P2MP/MP2MP LSP. Such kind of function could be used for multiplexing/aggregating root initiated and leaf initiated application which will use mLDP based P2MP/MP2MP LSP. Examples of root initiated applications are P2MP PW [I-D.ietf-pwe3-p2mp-pw], VPLS multicast [I-D.ietf-l2vpn-vpls-mcast], L3VPN multicast [RFC6513]. And examples of leaf initiated applications are statically configured mLDP based P2MP/MP2MP LSP, mLDP in-band signaling [I-D.ietf-mpls-mldp-in-band-signaling]. "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", Petri Jokela, Robert Moskowitz, Jan Melen, 14-Feb-12, This memo specifies an Encapsulated Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP). "The PKCS#11 URI Scheme", Jan Pechanec, Darren Moffat, 28-Feb-12, 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. "Multicast Listener Extensions for MIPv6 and PMIPv6 Fast Handovers", Thomas Schmidt, Matthias Waehlisch, Rajeev Koodli, Gorry Fairhurst, 8-May-12, Fast handover protocols for MIPv6 and PMIPv6 define mobility management procedures that support unicast communication at reduced handover latency. Fast handover base operations do not affect multicast communication, and hence do not accelerate handover management for native multicast listeners. Many multicast applications like IPTV or conferencing, though, are comprised of delay-sensitive real-time traffic and will benefit from fast handover execution. This document specifies extension of the Mobile IPv6 Fast Handovers (FMIPv6) and the Fast Handovers for Proxy Mobile IPv6 (PFMIPv6) protocols to include multicast traffic management in fast handover operations. This multicast support is provided first at the control plane by a management of rapid context transfer between access routers, second at the data plane by an optional fast traffic forwarding that MAY include buffering. "Protocol for Carrying Authentication for Network Access (PANA) with IPv4 Unspecified Address", Alper Yegin, Yoshihiro Ohba, Lionel Morand, John Kaippallimalil, 14-Feb-12, This document defines how PANA client (PaC) can perform PANA authentication prior to configuring an IP address. "An Extension of HIP Base Exchange to Support Identity Privacy", Dacheng Zhang, Miika Komu, 11-Jan-12, In this document, an extension of HIP Base Exchange (BEX) is proposed protect the identity privacy of HIP hosts. Apart from describing the protocol and packet formats, the applicability and the security strength of the proposed approach are analyzed. This work is based on BLIND [YLI04]. "Recommendations on filtering of IPv4 packets containing IPv4 options", Fernando Gont, R. Atkinson, Carlos Pignataro, 11-Mar-12, This document document provides advice on the filtering of IPv4 packets based on the IPv4 options they contain. Additionally, it discusses the operational and interoperability implications of dropping packets based on the IP options they contain. "Group Key Management using IKEv2", Sheela Rowles, Aldous Yeung, Paulina Tran, Yoav Nir, 11-Mar-12, 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", Alessandro D'Alessandro, Feng Huang, Zhang Haiyan, Han Li, Huub van Helvoort, Jeong-dong Ryoo, 9-Jan-12, This document specifies a linear protection switching mechanism for MPLS-TP. This mechanism supports 1+1 unidirectional/bidirectional protection switching and 1:1 bidirectional protection switching. It is purely supported by MPLS-TP data plane, and can work without any control plane. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. "LISP Canonical Address Format (LCAF)", Dino Farinacci, Dave Meyer, Job Snijders, 25-Mar-12, This draft defines a canonical address format encoding used in LISP control messages and in the encoding of lookup keys for the LISP Mapping Database System. "Advanced Groupware Access Protocol", Iulian Radu, 15-May-12, 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. "RSVP-TE IPv6", Vishwas Manral, 30-Mar-12, RSVP defined in [RFC2205] defines a resource reservation setup protocol, designed for an integrated service internet. RSVP-TE defined in [RFC2205] extends RSVP to establish LSP's in MPLS. For RSVP-TE hops that cannot allocate Labels cannot exist in the PATH of the LSP's. It is therefore specified that for IPv6 RSVP-TE LSP's Path, PathTear and ResvConf Messages should address the messages directly to an adjacent node control plane IPv6 address. This document also specfies some other changes required for RSVP-TE to work over IPv6 transport. "Controlling Session Initiation Protocol (SIP)-Established Content Delivery Channels Using the Real-Time Streaming Protocol (RTSP)", Jouni Maenpaa, Priya Rajagopal, Jan Lindquist, Xavier Marjou, 9-Jun-10, The Session Initiation Protocol (SIP) is widely used for establishing multimedia sessions, whereas the Real Time Streaming Protocol (RTSP) is used in streaming media systems. RTSP has a dual role: it establishes a media session for the delivery of streaming media as well as controls the streaming session once it has been set up. Since SIP is also used for session establishment, there exists an overlap between the functionality provided by SIP and RTSP. In this document, we describe a model adopted by ETSI TISPAN, 3GPP, and Open IPTV Forum (OIPF) in which SIP and the SDP offer/answer model are used to set up a streaming session with an RTSP control channel and one or more media delivery streams. Such a model is beneficial since it allows the reuse of current architecture and functionality (e.g., authentication, charging, and QoS) established around SIP for RTSP- based streaming. The model benefits applications such as Internet Protocol Television (IPTV). In addition to the model, the document specifies two new variants of RTSP. "Encapsulating LMP Test message over MPLS-TP", Vishwas Manral, 30-Mar-12, LMP Test Message is transmitted over the Data Link and is used to verify the data link connectivity. In most cases these messages are transmitted over UDP. This document clarifies the use of LMP Test messages over MPLS LSP's when the IP addressing of test messages may not be available or may not be desireable. "KX509 Kerberized Certificate Issuance Protocol", Henry Hotz, Russ Allbery, 21-Feb-12, This document describes a protocol, called kx509, for using Kerberos tickets to acquire X.509 certificates. These certificates may be used for many of the same purposes as X.509 certificates acquired by other means, but if a Kerberos infrastructure already exists then the overhead of using kx509 may be much less. While not (previously) standardized, this protocol is already in use at several large organizations, and certificates issued with this protocol are recognized by the International Grid Trust Federation. "Implications of Full-Duplex HTTP", Wenbo Zhu, Mike Jennings, 20-May-12, Full-duplex HTTP follows the basic HTTP request-response semantics but also allows the server to send response data to the client when the client is still transmitting request body to the server. Requirements for Full-duplex HTTP are under-specified in the existing HTTP specification [RFC2616], and this memo intends to clarify the requirements for implementing Full-duplex HTTP on top of the standard HTTP protocol. "Protocol for Stage Illumination", Marcus Ertl, 23-Nov-11, This memo describes a protocol that builds upon UDP/IP to transport illumination and control data for stage, architectural and other illumination requirements. It may be understood as a spiritual successor of the traditional DMX (Digital MultipleX) specification series, removing it's limitations and adding flexibility and usability enhancements like auto-discovery and metadata, among other useful features. "Overview of HIP Proxy Scenarios and Solutions", Dacheng Zhang, Xiaohu Xu, Jiankang Yao, Zehn Cao, 8-Mar-12, A Host Identity Protocol (HIP) proxy is a host that holds the keying material, and participates in HIP-based communications, on behalf of one or more hosts. HIP proxies play an important role in the transition from the current Internet architecture to the HIP architecture. A core objective of a HIP proxy is to facilitate the communication between legacy (or Non- HIP) hosts and HIP hosts while not modifying the host protocol stacks. In this document, the legacy hosts served by proxies are referred to as Legacy Hosts (LHs). Currently, various design solutions of HIP proxies have been proposed. These solutions may be applicable in different working circumstances. In this document, these solutions are investigated in detail to compare their effectiveness in different scenarios. "Host Identifier Revocation in HIP", Dacheng Zhang, Dmitriy Kuptsov, Sean Shen, 9-Mar-12, This document mainly analyzes the key revocation issue with host identifiers (HIs) in the Host Identity Protocol (HIP). Generally, key revocation is an important functionality of key management systems; it is concerned with the issues of removing cryptographic keys from operational use when they are not secure or not secure enough any more. This functionality is particularly important for the security systems expected to execute for long periods. This document also attempts to investigate several issues that a designer of HI revocation mechanisms need to carefully consider. "A Mechanism for Session Initiation Protocol (SIP) Avalanche Restart Overload Control", Charles Shen, Henning Schulzrinne, Arata Koike, 15-Dec-11, When a large number of clients register with a SIP registrar server at approximately the same time, the server may become overloaded. Near-simultaneous floods of SIP SUBSCRIBE and PUBLISH requests may have similar effects. Such request avalanches can occur, for example, after a power failure and recovery in a metropolitan area. This document describes how to avoid such overload situations. Under this mechanism, a server estimates an avalanche restart backoff interval during its normal operation and conveys this interval to its clients through a new Restart-Timer header in normal response messages. Once an avalanche restart actually occurs, the clients perform backoff based on the previously received Restart-Timer header value before sending out the first request attempt. Thus, the mechanism spreads all the initial client requests and prevents them from overloading the server. "The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol(SRTP)", Woo-Hwan Kim, Jungkeun Lee, Dong-Chan Kim, Je-Hong Park, Daesung Kwon, 21-Dec-11, This document describes the use of the ARIA block cipher algorithm within the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for the Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). It details three modes of operation (CTR, CCM, GCM) and a SRTP Key Derivation Function for ARIA. "Considerations on the AS-Level Application-Layer Traffic Optimization", Hirochika Asai, Hiroshi Esaki, Tsuyoshi Momose, 17-Dec-11, Application-layer or overlay routing has been applied to various distributed systems such as content delivery networks and live media streaming systems. The problems with these systems for the layer 3 network providers, such as Internet service providers, are that these systems utilize higher-cost network resources (e.g., transit links) from the viewpoint of the layer 3 network providers but the operators have difficulties in controlling and optimizing the traffic of these systems because these systems construct their own networks over the layer 3 network. The ALTO Working Group has worked on application- layer traffic optimization to fill the gaps in routing policies between the layer 3 network and applications by providing the underlay network topology and cost information to these systems. However, there are considerations on applying application-layer traffic optimization techniques to cross-domain traffic because the cost is assumed to be configured by each AS although ASes are autonomously operated. This document summarizes general problems with overlay networks and considerations on the AS-level application- layer traffic optimization from the viewpoint of inter-AS economics. The main concerns on the AS-level application-layer traffic optimization are unfair policy configuration between distinct administrative domains and asymmetric economic policies on transit links. The underlying problem inducing these concerns is that the economic policies between interconnected ASes are non-disclosure due to commercial contracts. This document also discusses the conceivable approaches to solve the problems and considerations. "Additional Methods for Generating Key Identifiers", Sean Turner, Stephen Kent, 23-Apr-12, This document specifies additional methods for generating key identifiers from a public key. This document also specifies an extension to identify the algorithms used to generate the key identifiers. "Reputation Reporting Protocol", David Skoll, 16-Dec-11, This draft specifies a protocol for reporting various events associated with IP addresses. These events can be collected and aggregated to form a database containing information about the reputation of IP addresses. "Request by JSON ver.1.0 for OAuth 2.0", Nat Sakimura, John Bradley, 14-Apr-12, The authorization request in OAuth 2.0 utilizes query parameter serizalization. This specification defines the authorization request using JWT serialization. The request is sent thorugh 'request' parameter or by reference through 'request_uri' that points to the JWT serialized authorization request. "Miscellaneous additions to CoAP", Carsten Bormann, Klaus Hartke, 14-May-12, This short I-D makes a number of partially interrelated proposals how to solve certain problems in the CoRE WG's main protocol, the Constrained Application Protocol (CoAP). The current version has been resubmitted to keep information about these proposals available; the proposals are not all fleshed out at this point in time. "Session Initiation Protocol (SIP) History-Info Header Call Flow Examples", Mary Barnes, Francois Audet, Shida Schubert, Hans van Elburg, Christer Holmberg, 27-Mar-12, This document describes use cases and documents call flows which require the History-Info header field to capture the Request-URIs as a Session Initiation Protocol (SIP) Request is retargeted. The use cases are described along with the corresponding call flow diagrams and messaging details. "HIP support for RFIDs", Pascal Urien, Gyu Lee, Guy Pujolle, 23-Apr-12, This document describes an architecture based on the Host Identity Protocol (HIP), for active RFIDs, i.e. Radio Frequency Identifiers including tamper resistant computing resources, as specified for example in the ISO 14443 or 15693 standards. HIP-RFIDs never expose their identity in clear text, but hide this value (typically an EPC- Code) by a particular equation that can be only solved by a dedicated entity, referred as the portal. HIP exchanges occur between HIP-RFIDs and portals; they are transported by IP packets, through the Internet cloud. "A RELOAD Usage for Distributed Conference Control (DisCo)", Alexander Knauf, Gabriel Hege, Thomas Schmidt, Matthias Waehlisch, 8-May-12, This document defines a RELOAD Usage for Distributed Conference Control (DisCo) with SIP. DisCo preserves conference addressing through a single SIP URI by splitting its semantic of identifier and locator using a new Kind data structure. Conference members are enabled to select conference controllers based on proximity awareness and to recover from failures of individual resource instances. DisCo proposes call delegation to balance the load at focus peers. "Uniform Resource Identifier (URI) Scheme for Digital Video Broadcasting (DVB) Programme Resources", Mo McRoberts, Alexander Adolf, 26-Mar-12, 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. "PMIPv6 multicast handover optimization by the Request of Active Multicast Subscription (RAMS)", Luis Contreras, Carlos Bernardos, Ignacio Soto, 12-Mar-12, 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' active multicast subscriptions information 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 also can be applied to other solutions envisioned as possible architectural evolutions of it. 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). "Use of Multipath with MPLS-TP and MPLS", Curtis Villamizar, 27-Feb-12, 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 discouraged the use of multipath techniques. Some degradation of MPLS-TP OAM performance cannot be avoided when operating over current high bandwidth multipath implementations. The tradeoffs involved in using multipath techniques with MPLS and MPLS-TP are described. Requirements are discussed which enable full MPLS-TP compliant LSP including full OAM capability to be carried over MPLS LSP which are traversing multipath links. Other means of supporting MPLS-TP coexisting with MPLS and multipath are discussed. "Extensions of Host Identity Protocol (HIP) with Hierarchical Information", Xiaohu Xu, Sheng Jiang, Dacheng Zhang, Dmitry Korzun, Zehn Cao, 12-Mar-12, This document explores the benefits brought by extending the Host Identity Protocol (HIP) with hierarchical information. In addition, three types of candidate solutions are introduced. "Media Types for Sensor Markup Language (SENML)", Cullen Jennings, Zach Shelby, Jari Arkko, 20-Jan-12, This specification defines media types for representing simple sensor measurements and device parameters in the Sensor Markup Language (SenML). Representations are defined in JavaScript Object Notation (JSON), eXtensible Markup Language (XML) and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use this media type in protocols such as HTTP or CoAP to transport the measurements of the sensor or to be configured. "Load Sharing for the Stream Control Transmission Protocol (SCTP)", Paul Amer, Martin Becke, Thomas Dreibholz, Nasif Ekiz, Janardhan Iyengar, Preethi Natarajan, Randall Stewart, Michael Tuexen, 10-Mar-12, The Stream Control Transmission Protocol (SCTP) supports multi-homing for providing network fault tolerance. However, mainly one path is used for data transmission. Only timer-based retransmissions are carried over other paths as well. This document describes how multiple paths can be used simultaneously for transmitting user messages. "ISIS Protocol Extensions for Boundary Node Discovery (BND)", Dhruv Dhody, Udayasree Palle, 29-Feb-12, There are various circumstances where it is highly desirable to be able to dynamically and automatically discover a set of Boundary Nodes (BN) along with their domain information. For that purpose, this document defines extensions to the Intermediate System to Intermediate System(IS-IS) routing protocol for the advertisement of Boundary Node (BN)Discovery information within an IS-IS area or within the entire IS-IS routing domain. "OSPF Protocol Extensions for Boundary Node Discovery (BND)", Dhruv Dhody, Udayasree Palle, 29-Feb-12, There are various circumstances where it is highly desirable to be able to dynamically and automatically discover a set of Boundary Nodes (BN) along with their domain information. For that purpose, this document defines extensions to the Open Shortest Path First (OSPF) routing protocol for the advertisement of Boundary Node (BN) Discovery information within an OSPF area or within the entire OSPF routing domain. "Virtual Subnet: A Host Route based Subnet Extension Solution", KuiKe Building, Susan Hares, 12-Mar-12, This document describes a host route based subnet extension solution referred to as Virtual Subnet, which mainly reuses existing BGP/MPLS IP VPN [RFC4364] and ARP proxy [RFC925][RFC1027] technologies. Virtual Subnet provides a scalable approach for interconnecting geographically dispersed cloud data centers. "HIP-based Failure Detection and Recovery for Multihoming", Tao Yuan, Bo Hu, Qinqin Chu, Zhangfeng Hu, Wenjun Li, 2-Jan-12, Fault tolerance is one of greatest feature of multihomed host. This document proposes a failure detection and communication recovery mechanism for Host Identity Protocol. It can be applied to HIP by using new defined HIP parameters. A HIP-enabled multihomed host can switch to alternative locator if current link breaks down by adopting this mechanism. "Applicability of Stateless automatic IPv4 over IPv6 Encapsulation / Decapsulation Technology (SA46T)", Naoki Matsuhira, 5-Jan-12, This document provide IPv6 transition scenario using Stateless Automatic IPv4 over IPv6 Encapsulation / Decapsulation Technology (SA46T) and applicability of SA46T. SA46T is just one of automatic Encapsulation / Decapsulation technology, so there are several usage with SA46T. This document shows such possible applicability. "CGN Deployment with MPLS/VPNs", Victor Kuarsingh, John Cianfarani, 20-Feb-12, This document specifies a framework to integrate a Network Address Translation layer into an operator's network to function as a Carrier Grade NAT (also known as CGN or Large Scale NAT). CGN is a concept also described in [I-D.ietf-behave-lsn-requirements] and describes the model as a dual layer translation model. Although operators may wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near term needs may not be satisfied with an IPv6 deployment alone. This document provides a practical integration model which allows CGN to be integrated into the network meeting the connectivity needs of the customer while being mindful of not disrupting existing services and meeting the technical challenges that CGN brings. The model includes the use of MPLS/VPNs defined in [RFC4364] as a tool to achieve this goal. This document does not intend to defend the merits of CGN. "Registry Data Escrow Specification", Francisco Arias, Shoji Noguchi, 8-Mar-12, This document specifies the format and contents of Data Escrow deposits targeted primarly 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 other than Domain Name Registries. "Peer-to-Peer Epi-Transport Protocol", Riccardo Bernardini, Roberto Fabbro, Roberto Rinaldo, 9-Jan-12, This document describes PPETP (Peer-to-Peer Epi-Transport Protocol) a peer-to-peer distribution protocol suited for streaming applications over networks made of heterogeneous nodes. "Timezone Service Protocol", Mike Douglass, Cyrus Daboo, 13-Apr-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. "Privacy Preferences for E-Mail Messages", Ulrich Koenig, Jan Schallaboeck, 5-Dec-11, This document proposes a syntax and semantics as an extension of the Internet Message Format (e-mail message) allowing a Sending User of an e-mail message to express his or her preference for how the message content is to be handled by the Receiving Users. For this purpose, semantics of sets of different character combinations ("Privicons") are described. These can syntactically be integrated either in the first-line of the body, in the subject line and/or in a dedicated header of any e-mail message. The Privicons icon set consists of six different icons. They will be machine-readable. The Privicons concept is partly borrowing its approach from the concept of emoticons. For example, to express that the content may be forwarded and even be published. The Sending User could use the Privicon "[>]", which may be followed by an additional explanations, such as "please share". "ALTO and DECADE service trial within China Telecom", Kai Li, GuangYao Jian, 10-Mar-12, This document reports the experience of China Telecom in a recent experiment with the ALTO service and P2P caches deployment. It is found that the deployment of the ALTO service significantly improves the capability of a Service Provider to affect the distribution of P2P traffic. It is also found that a traffic localized ALTO policy may decrease the download speed of a P2P user. However, the deployment of some P2P caches can compensate such influence. "Router Advertisements for Routing between Moving Networks", Alexandru Petrescu, Christophe Janneteau, Nicolas Demailly, Sofiane Imadali, 10-Feb-12, This draft specifies extensions to the ICMPv6 Router Advertisement messages and processing. Traditionally, prefixes contained in RAs are used for on-link determination, on-link address auto- configuration, but not for path setup towards multi-hop destinations. The extensions proposed here still rely on RAs being communicated on a single link (not across several IP hops), but upon RA reception the prefixes are installed in the routing table; they are thus used for forwarding packets further than a single link (multi IP hop). "Resource Reservation Protocol (RSVP) Application-ID Profiles for Voice and Video Streams", James Polk, Subha Dhesikan, 12-Mar-12, RFC 2872 defines an Resource Reservation Protocol (RSVP) object for application identifiers. This document uses that App-ID and gives implementers specific guidelines for differing voice and video stream identifications to nodes along a reservation path, creating specific profiles for voice and video session identification. "Management Information Base for the PCE Communications Protocol (PCEP) When Requesting Point-to-Multipoint Services", Quintin Zhao, Dhruv Dhody, Udayasree Palle, Daniel King, 22-Feb-12, This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of the Path Computation Element communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs when point-to- multipoint services are requested. "LDP extensions for Pseudowire Binding to LSP Tunnels", Mach Chen, Wei Cao, Attila Takacs, Ping Pan, 11-Mar-12, Many transport services require that user traffic, in the forms of Pseudowires (PW), to be delivered on a single co-routed bidirectional LSP or two LSPs that share the same routes. In addition, the user traffic may traverse through multiple transport networks. This document specifies an optional extension in LDP that enable the binding between PWs and the underlying LSPs. "Clarification of Proper Use of "@" (at sign) in URI-style Components", Robert Simpson, 30-Jul-10, Defacto standards have evolved that conflict with existing standards, specifically RFC 3986. This document clarifies the use of the "@" (at sign) in URIs and partial URI-like addresses. "Trusted Browser Security Architecture (TBSA)", Sam Caldwell, 10-Aug-10, This document proposes a trusted browser security model intended to secure the mutual automated consent between the end-user and the content provider before allowing a web browser to engage the services of an arbitrary third-party add-on, extension or service. Properly implemented, this proposed security model would create a standardized API across all browsers to further the security of e-commerce and other on-line transactions. "An Encoding Parameter for HTTP Basic Authentication", Julian Reschke, 11-Mar-12, The "Basic" authentication scheme defined in RFC 2617 does not properly define how to treat non-ASCII characters. This has lead to a situation where user agent implementations disagree, and servers make different assumptions based on the locales they are running in. There is little interoperability for 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. "Security Assessment of the IPv6 Flow Label", Fernando Gont, 12-Mar-12, This document discusses the security implications of the IPv6 "Flow Label" header field, and analyzes possible schemes for selecting the Flow Label value of IPv6 packets. "RBridges: Support of IEEE 802.1Qbb, 802.1Qaz, and 802.1Qau", Donald Eastlake, Manoj Wadekar, Anoop Ghanwani, Puneet Agarwal, Tal Mizrahi, 2-Mar-12, IEEE 802.1 has developed standards as part of its Data Center Bridging (DCB) activity to (1) efficiently minimize data loss due to queue overflow for selected classes of traffic within Local Area Networks (LANs) meeting certain conditions and (2) provide means to allocate the available bandwidth on links to different classes of traffic. These standards were adopted as the IEEE 802.1Qbb, 802.1Qaz, and 802.1Qau amendmenst to the 802.1Q standard. This document briefly explains the standards and discusses the support of these IEEE 802 standards in RBridges (devices that implement the IETF TRILL standard). "Revealing hosts sharing an IP address using TCP option", Andrew Yourtchenko, Dan Wing, 8-Dec-11, When an IP address is shared among several subscribers -- with a NAT or with an application-level proxy -- it is impossible for the server to differentiate between different clients. Such differentiation is valuable in several scenarios. This memo describes a technique to differentiate TCP clients sharing an IP address. The proposed method uses a TCP option, which avoids altering the application-level payload and works well with SSL-protected connections. "Hosts with Any Network Connectivity Using "Bump-in-the-API"(BIA)", Ala Hamarsheh, 19-Jan-11, This document specifies a mechanism for hosts with any network connectivity (IPv4 only, IPv6 only, or dual IPv4/IPv6 connectivity) to run applications of any capability (IPv4 only, IPv6 only, or dual IPv4/IPv6) without any modification to those applications. It is a generalisation of a previous experimental protocol called "Bump-in-the-API" (BIA) [RFC3338]. New mechanism of BIA allows a changeover between the application layer and the IP communication layers from IPv4 to IPv6 and vice versa or IPv6 to IPv4 and vice versa, without requiring those applications to be converted in addressing capabilities, effectively shielding the application layer from IPv4 or IPv6 connectivity. This is considered by the authors to be one of the essential conditions for the transition to IPv6 in the Internet to be successful. "Token Revocation", Torsten Lodderstedt, Stefanie Dronia, Marius Scurtescu, 31-Mar-12, This draft proposes an additional endpoint for OAuth authorization servers for revoking tokens. "Hypertext Transfer Protocol (HTTP) Digest Authentication Using GSM 2G Authentication and Key Agreement (AKA)", Lionel Morand, 13-Feb-12, This memo specifies a one-time password generation mechanism for Hypertext Transfer Protocol (HTTP) Digest access authentication based on Global System for Mobile Communications (GSM) authentication and key generation functions A3 and A8, also known as GSM AKA or 2G AKA. The HTTP Authentication Framework includes two authentication schemes: Basic and Digest. Both schemes employ a shared secret based mechanism for access authentication. The GSM AKA mechanism performs user authentication and session key distribution in GSM and Universal Mobile Telecommunications System (UMTS) networks. GSM AKA is a challenge-response based mechanism that uses symmetric cryptography. "6to4 Provider Managed Tunnels", Victor Kuarsingh, Yiu Lee, Olivier Vautrin, 15-May-12, 6to4 Provider Managed Tunnels (6to4-PMT) provide a framework which can help manage 6to4 [RFC3056] tunnels operating in an anycast [RFC3068] configuration. The 6to4-PMT framework is intended to serve as an option to operators to help improve the experience of 6to4 operation when conditions of the network may provide sub-optimal performance or break normal 6to4 operation. 6to4-PMT provides a stable provider prefix and forwarding environment by utilizing existing 6to4 relays with an added function of IPv6 Prefix Translation. This operation may be particularly important in NAT444 infrastructures where a customer endpoint may be assigned a non- RFC1918 address thus breaking the return path for anycast [RFC3068] based 6to4 operation. The 6to4-PMT model has successfully been used in a production network and has been implemented as open source code and by a major routing vendor. "Traceroute and Ping Message Extension", Naiming Shen, Carlos Pignataro, Rajiv Asati, Enke Chen, Alia Atlas, 27-Feb-12, This document specifies extensions to traceroute and ping techniques to convey additional application information to be carried in UDP, TCP and ICMP traceroute probe messages and ICMP echo request and reply messages. The extensions are backward compatible. "Default Port for IRC via TLS/SSL", Richard Hartmann, 23-Apr-11, This document describes the commonly accepted practice of listening on TCP port 6697 for incoming IRC connections encrypted via TLS/SSL. "DNSSEC Trust Anchor Publication for the Root Zone", Joe Abley, Jakob Schlyter, Guy Bailey, 12-Mar-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. "OAuth Use Cases", George Fletcher, Torsten Lodderstedt, Zachary Zeltsan, 13-Apr-12, This document lists the OAuth use cases. The provided list is based on the Internet-Drafts of the OAUTH working group and discussions on the group's mailing list. "Management Information Base (MIB) for the PCE Communications Protocol (PCEP) for Path-Key based Confidentiality in Inter-Domain Path Computation.", Dhruv Dhody, Udayasree Palle, Quintin Zhao, Daniel King, 21-Feb-12, This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of the Path Computation Element communication Protocol (PCEP)for communications between a Path Computation Client (PCC)and a Path Computation Element (PCE), or between two PCEs when path-key- based confidentiality in inter-domain path computation is requested. "Support for RSVP-TE in L3VPNs", Kenji Kumaki, Tomoki Murai, Dean Cheng, Satoru Matsushima, PENG JIANG, 26-Apr-12, IP Virtual Private Networks (VPNs) provide connectivity between sites across an IP/MPLS backbone. These VPNs can be operated using BGP/MPLS and a single provider edge (PE) node may provide access to multiple customer sites belonging to different VPNs. The VPNs may support a number of customer services including RSVP and RSVP-TE traffic. This document describes how to support RSVP-TE between customer sites when a single PE supports multiple VPNs. "LDP Hello Cryptographic Authentication", Lianshu Zheng, Mach Chen, Manav Bhatia, 9-May-12, 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. "IPP over HTTPS Transport Binding and 'ipps' URI Scheme", Ira McDonald, Michael Sweet, 14-May-12, 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, 11-Mar-12, This specification defines how the Uniform Resource Name namespace reserved for GSMA (Global Sstandard for Mobiles Association) identities and its sub namespace for the IMEI (International Mobile station Equipment Identity) can be used as an instance-id as specified in RFC 5626 [1] and also as used by RFC 5627 [2]. 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." "LDP Extensions for Pseudo Wire (PW) Transfer in an MPLS-TP Network", Qilei Wang, Muliu Tao, Xihua Fu, Lizhong Jin, Ruiquan Jing, 12-Mar-12, As defined in [RFC5654] MPLS-TP transport path includes LSP and PW. And the possibility of transferring the ownership and control of an existing and in-use path between the management plane and the control plane, without actually affecting data plane traffic being carried over it, is a valuable option for carrier. [RFC5493] and [RFC5852] describe the LSP transfer. This memo gives the requirement and LDP extensions for PW transfer in an MPLS-TP network. "Prefix Pool Option for DHCPv6 Relay Agents on Provider Edge Routers", Leaf Yeh, Tina Tsou, Juergen Schoenwaelder, Jie Hu, 20-Jan-12, The DHCPv6 Prefix Pool option provides a mechanism for DHCPv6 Prefix Delegation (DHCPv6-PD), allowing the DHCPv6 server to notify a DHCPv6 relay agent implemented on a Provider Edge (PE) router about active prefix pools allocated by the DHCPv6 server to the PE router. The information of active prefix pools can be used to enforce IPv6 route aggregation on the PE router by adding or removing aggregated routes according to the status of the prefix pools. The advertising of the aggregated routes in the routing protocol enabled on the network- facing interface of PE routers will dramatically decreases the number of the routing table entries in the network. "Multiprotocol Label Switching Transport Profile p2mp Shared Protection", Xu Xueqiong, Yuefeng Ji, Yu jinghai, Zongpeng Du, 1-Mar-12, This document will describle two protection solutions to support protection of failures in p2mp path in MPLS-TP. According to the protection Requirements in RFC 5654, there are requirements for MPLS-TP to support sharing of protection resources such that protection paths that are known not to be required concurrently can share the same protection resources. In addition, there is a requirement for MPLS-TP to support unidirectional 1:n protection for p2mp paths. These requirements are further addressed in draft-ietf-mpls-tp-survive-fwk . so this draft will present proposed solutions . This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. "An SNMP Usage for RELOAD", YongLin Peng, Wei Wang, ZhenWu Hao, Yu Meng, 6-Mar-12, This document defines a SNMP Usage for REsource LOcation And Discovery(RELOAD), The SNMP Usage provides the functionality of managing the RELOAD network. The SNMP Usage provides lookup service for the network manager's address stored in the overlay. The SNMP Usage also defines the method that allow the registrations to map a network manager'name to a specific node reachable through the overlay. The AppAttach method is used to establish a direct connection between nodes through which SNMP messages are exchanged. "Multi-Cost ALTO", Sabine Randriamasy, Nico Schwan, 12-Mar-12, IETF is designing a new service called ALTO (Application Layer traffic Optimization) that includes a "Network Map Service", an "Endpoint Cost Service" and an "Endpoint (EP) Ranking Service" and thus incentives for application clients to connect to ISP preferred Endpoints. These services provide a view of the Network Provider (NP) topology to overlay clients. The present draft proposes a light way to extend the information provided by the current ALTO protocol in two ways. First, including information on multiple cost types in a single ALTO transaction provides a better mapping of the Selected Endpoints to needs of the growing diversity of Content and Resources Networking Applications and to the network conditions. Second, one ALTO query and response exchange on N Cost Types is faster and lighter than N single cost transactions. All this also helps producing a faster and more robust choice when multiple Endpoints need to be selected. ""Gateway-Initiated" 6rd", Tina Tsou, Cathy Zhou, Tom Taylor, Qi Chen, 4-Mar-12, This document proposes an alternative 6rd deployment model to that of RFC 5969. The basic 6rd model allows IPv6 hosts to gain access to IPv6 networks across an IPv4 access network using 6-in-4 tunnels. 6rd requires support by a device (the 6rd-CE) on the customer site, which must also be assigned an IPv4 address. The alternative model described in this document initiates the 6-in-4 tunnels from an operator-owned gateway collocated with the operator's IPv4 network edge, rather than from customer equipment. The advantages of this approach are that it requires no modification to customer equipment and avoids assignment of IPv4 addresses to customer equipment. The latter point means less pressure on IPv4 addresses in a high-growth environment. "Secure Extension of BGP by Decoupling Path Propagation and Adoption", Beichuan Zhang, Bin Liu, Dacheng Zhang, Mingui Zhang, Beichuan Zhang, 8-Jan-12, This draft proposes a novel mitigation scheme to protect the inter- domain data delivery during false routing announcements. A new path attribute is defined to Decouple propagation of a path and adoption of a path for data forwarding in BGP (DBGP). DBGP does not use suspicious paths for data forwarding, but still propagates them in the routing system to facilitate attack detection. It can extensively protect data delivery from routing announcements of false sub- prefixes, false origins, false nodes and false links, and works well with ongoing attack detection and prevention systems. "Receiver Driven Multicast RSVP TE Requirements", Christian Jacquenet, Quintin Zhao, 11-Mar-12, This document presents a set of requirements for the establishment and maintenance of Receiver-Driven Point-to-Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) Traffic-Engineered (TE) Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). "Stateless Automatic IPv4 over IPv6 Tunneling with IPv4 Address Sharing", Naoki Matsuhira, 20-Apr-12, 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. "A YANG Data Model for SNMP Configuration", Martin Bjorklund, Juergen Schoenwaelder, 12-Mar-12, This document defines a collection of YANG definitions for configuring SNMP engines. "6LoWPAN Generic Compression of Headers and Header-like Payloads", Carsten Bormann, 26-Mar-12, 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. "A Cryptographic Suite for Embedded Systems (SuiteE)", Matthew Campagna, Greg Zaverucha, 9-Apr-12, This document describes a cryptographic suite of algorithms ideal for constrained embedded systems. It uses the existing IEEE 802.15.4 standard as a starting point, builds upon existing embedded cryptographic primitives and suggests additional elliptic curve cryptography (ECC) algorithms and curves. The goal is to define a complete suite of algorithms ideal for embedded systems. "Extensions to the Path Computation Element Communication Protocol (PCEP) for Backup Egress of a Traffic Engineering Label Switched Path", Huaimo Chen, 30-Apr-12, This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to send a request for computing a backup egress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP to a PCE and for a PCE to compute the backup egress and reply to the PCC with a computation result for the backup egress. "Extensions to Path Computation Element Communication Protocol (PCEP) for Backup Ingress of a Traffic Engineering Label Switched Path", Huaimo Chen, 30-Apr-12, 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. "Lightweight 4over6: An Extension to the DS-Lite Architecture", Yong Cui, Qiong Sun, Mohamed Boucadair, Tina Tsou, Yiu Lee, Ian Farrer, 19-May-12, This document specifies an extension to DS-Lite called Lightweight 4over6. This mechanism moves the translation function from the tunnel concentrator (AFTR) to initiators (B4s), and hence reduces the mapping scale on the concentrator to a per-subscriber level. To delegate the NAPT function to the initiators, port-restricted IPv4 addresses are allocated to the initiators. "Assessing the Impact of Carrier-Grade NAT on Network Applications", Chris Donley, Lee Howard, Victor Kuarsingh, John Berg, University Colorado, 16-May-12, 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. "PCEP Extensions for Temporary Reservation of Computed Path Resources and Support for Limited Context State in PCE", Oscar de Dios, Ramon Casellas, Cyril Margaria, Young Lee, Fatai Zhang, 9-Mar-12, The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. A limited form of statefulness is useful to improve PCE functionality in situations in which the local TED might not be up to date, or in the case of concurrent requests where most of the LSPs are computed before the end of the set-up of the LSPs, when the TED is updated. The PCC is responsible to setup or not the TE-Path computed by the PCE. By providing an indication that it intends to use the resources on the TE-Path a PCC can help the PCE to get a more accurate dynamic TED view and thus the PCE can avoid suggesting the use of the same resources for subsequent TE LSPs. This document proposes an extension to the PCEP protocol to allow the PCC to indicate to the PCE to block or reserve the resources computed in a path request of a TE LSP for subsequent requests for a certain time and can help to reduce the number of crankbacks. "Multicast Router Key Management Protocol (MaRK)", Sam Hartman, Dacheng Zhang, Gregory Lebovitz, 12-Mar-12, Several routing protocols engage in one-to-many communication. In order to authenticate these communications using symmetric cryptography, a group key needs to be established. This specification defines a group protocol for establishing and managing such keys. "Multicast LDP extension for hub & spoke multipoint LSP", Lizhong Jin, Frederic JOUNAY, IJsbrand Wijnands, Nicolai Leymann, 5-May-12, 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. A packet traveling upstream should be thought of as being unicast to the root, except that it follows the path of the tree rather than ordinary unicast path. "Performance Measurement Metrics of Label Switched Path (LSP) Establishment in Multi-Layer and Multi-Domain Networks", Yuefeng Ji, Weiwei Bian, Hongxiang Wang, Shanguo Huang, Guoying Zhang, 19-Apr-12, As the increment of network scale, optical networks need to be partitioned into multi-layer and multi-domain networks for the purpose of better management. Meanwhile, as the variety of user requests, different LSPs need to be established. In order to meet different requirements of users, the LSP establishment performance is necessary to be measured in multi-layer and multi-domain networks. For this reason, typical performance measurement metrics need to be proposed. In this document, the LSP establishment delay and bit error ratio (BER), which are both as the performance measurement metrics, are illustrated, and the definition and methodologies are proposed. "Exporting MIB Variables using the IPFIX Protocol", Benoit Claise, Paul Aitken, Juergen Schoenwaelder, 12-Mar-12, This document specifies a way to complement IPFIX Flow Records with Management Base (MIB) objects, avoiding the need to define new IPFIX Information Elements for existing Management Information Base objects that are already fully specified. This method requires an extension to the current IPFIX protocol. New Template Set and Options Template Sets are specified to allow the export of Simple Network Management Protocol (SNMP) MIB Objects along with IPFIX Information Elements. "Multi-access Indicator for Mobility", Rajeev Koodli, Jouni Korhonen, 2-Mar-12, When a Mobile Node attaches to the mobile network using multiple access networks, it is important for the Mobile Network Gateway to know whether the Mobile Node is capable of simultaneous multi-access, so that the former can distribute the traffic flows using the most appropriate interface. This document defines a new EAP attribute which can be used for such an indication to the Mobile Network Gateway. The document also reserves a new MIP6-Feature-Vector flag. "PMIPv6 inter-working with WiFi access authentication", Sri Gundavelli, Marco Liebsch, Pierrick Seite, 23-Apr-12, Proxy Mobile IPv6, the IETF's protocol for network-based mobility management, requires a completed and successful authentication of the mobile node before it is registered at the mobility anchor. This document describes inter-working between access authentication mechanisms, such as IEEE 802.1X, and the Proxy Mobile IPv6 protocol to enable trusted WiFi access to a network-based mobility management domain. Furthermore, the use of authentication method specific identifiers for unique identification of mobile nodes during setup and maintenance of their mobility session is described, following recommendations of related standards organizations, such as 3GPP and the WiMAX Forum. "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for Network Management Protocols", Juergen Schoenwaelder, Tina Tsou, Cathy Zhou, 12-Mar-12, This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options providing lists of IP addresses that can be used to locate network management services. "DNS SRV Resource Records for Network Management Protocols", Juergen Schoenwaelder, Tina Tsou, Cathy Zhou, 12-Mar-12, This document specifies how to use Domain Name Service (DNS) SRV Resource Records (RRs) to locate network management services. "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, 12-Mar-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 the IPv6 Routing Protocol for Low Power and Lossy Networks (RPL). "Protocol Extension Requirement for Cooperation between PCE and Distributed Routing Controller in GMPLS Networks", Yongli Zhao, Jie Zhang, Ruiquan Jing, Dajiang Wang, Xihua Fu, 24-Apr-12, Path Computation Element (PCE) is proposed for path computation in multi-layer and multi-domain networks where PCE can be implemented in either centralized method or distributed method. In the former case, PCE can serve tens or hundreds of nodes simultaneously, while in the later case, each node is equipped with a PCE, which can be regarded as a distributed routing controller (DRC) in GMPLS networks and each one of those provides similar path computation capability. PCE and DRC have different advantages in path computation respectively. PCE is suitable for cross-layer and cross-domain path computation, especially in multi-constraints environment. But distributed routing controller is good at path computation in parallel ways and distributed network control in local domain. A cooperative path computation architecture named Dual Routing Engine (DRE) is necessary to be used in the future networks, for it based on the ideas of the cooperation of these two types of path computation engines and can take the advantages of both centralized and distributed method by which the PCE is implemented. The corresponding PCE communication protocol extension and other protocol requirements for cooperation between PCE and distributed routing controller are listed in this document to recommend the standard interfaces between different components in DRE architecture. "A Lightweight Approach to Node-to-Node Security in Diameter", Glen Zorn, Wenson Wu, 25-Jan-12, This document describes a lightweight method for cryptographically protecting a portion of the contents of a Diameter message in transit between an arbitrary pair of Diameter nodes. The scheme assumes that the destination node possesses an X.509 certificate containing an RSA public key and that that certificate is retrievable through a DNS query by the node originating the message. In addition to describing the operation of the protocol, this note specifies an Attribute-Value Pair (AVP) for the encapsulation of encrypted AVPs. "The Internet of Things - Concept and Problem Statement", Gyu Lee, Park Jung-Soo, Ning Kong, Noel Crespi, 12-Mar-12, This document explains the concept of the Internet of Things (IoT) and several features of the IoT. In addition, this document specifies problems considering technical issues for the IoT. Based on this, this document discusses architectural implications in order to solve problems. "Basic BGP Convergence Benchmarking Methodology for Data Plane Convergence", Rajiv Papneja, Bhavani Parise, Susan Hares, Ilya Varlashkin, 26-Mar-12, BGP is widely deployed and used by several service providers as the default Inter AS routing protocol. It is of utmost importance to ensure that when a BGP peer or a downstream link of a BGP peer fails, the alternate paths are rapidly used and routes via these alternate paths are installed. This document provides the basic BGP Benchmarking Methodology using existing BGP Convergence Terminology, RFC 4098. "Bundle Protocol Query Extension Block", Stephen Farrell, Aidan Lynch, Dirk Kutscher, Anders Lindgren, 8-Mar-12, The Bundle Protocol (BP) provides store-and-forward networking for Delay- and Disruption-Tolerant Networks. This document defines the BP query extension block (BPQ) which allows applications to query the stores of nodes on the path along which a bundle containing a bundle query extension block is routed. "SCTP Socket API Extensions for Concurrent Multipath Transfer", Thomas Dreibholz, Martin Becke, Hakim Adhari, 9-Mar-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, 9-Mar-12, This document describes an extension to the SCTP sockets API for querying information about the sender queue. "Alternate Encoding for OAuth 2 Token Responses", Justin Richer, 23-Apr-12, This document describes a method of representing the JSON structured responses from the OAuth 2 Token Endpoint into XML and form encoded responses. "Security Bootstrapping Solution for Resource-Constrained Devices", Behcet Sarikaya, Yoshihiro Ohba, Robert Moskowitz, Zhen Cao, Robert Cragie, 24-Apr-12, This document describes how to initially configure the network of resource constrained nodes securely, a.k.a., security bootstrapping. Bootstrapping architecture, communication channel and bootstrap security methods are described. System level objectives for security bootstrapping are stated followed by the protocols that can be used. Bootstrapping solution is based on EAP-TLS authentication with the use of raw public keys used as certificates. "HTTP framework for time-based access to resource states -- Memento", Herbert Van de Sompel, Michael Nelson, Robert Sanderson, 20-Dec-11, The HTTP-based Memento framework bridges the present and past Web by interlinking current resources with resources that encapsulate their past. It facilitates obtaining representations of prior states of a resource, available from archival resources in Web archives or version resources in content management systems, by leveraging the resource's URI and a preferred datetime. To this end, the framework introduces datetime negotiation (a variation on content negotiation), and new Relation Types for the HTTP "Link" header aimed at interlinking resources with their archival/version resources. It also introduces various discovery mechanisms that further support bridging the present and past Web. "Applicability of Proxy Mobile IPv6 Protocol for WLAN Access Networks", Sri Gundavelli, 23-Apr-12, 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. "File Transfer Protocol HOST Command for Virtual Hosts", Paul Hethmon, Robert McMurray, 7-Dec-11, The File Transfer Protocol, as defined in RFC 959 [RFC0959], does not provide a way for FTP clients and servers to differentiate between multiple DNS names that are registered for a single IP address. This document defines a new FTP command that provides a mechanism for FTP clients and servers to identify individual virtual hosts on an FTP server. "FTP TYPE Extension for Internationalized Text", John Klensin, 12-Mar-12, The traditional FTP protocol includes a TYPE command to specify the data representation. That command has values for ASCII and EBCDIC text, plus binary ("IMAGE") transmission. As the Internet becomes more international, there is a growing requirement to be able to transmit textual data, encoded in Unicode, in a way that is independent of the coding and line representation forms of particular operating systems. This memo specifies a new FTP representation TYPE value for Unicode data. "FTP consideration for IPv4/IPv6 transition", Dapeng Liu, Iljitsch van Beijnum, Zhen Cao, 11-Jan-12, The File transfer protocol(FTP) has a long histroy,, but still being widely used. The first concept of FTP was described RFC 114, and then was specified in RFC 354. FTP can work in IPv4 environment and then was extended to IPv6. RFC 2428 defines IPv6 extensions of FTP. In the IPv6-IPv4 translation scenario, considerations should be applied to FTP client, server and translation box to ensure FTP protocol work properly. This document discusses the details for FTP to work in IPv4-IPv6 transitiion scenario. This document gives recommendation regarding how IPv6 FTP client should behave in 6to4 scenario. "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. "File Transfer Protocol RANG Command for Byte Ranges", Anthony Bryan, Tatsuhiro Tsujikawa, Daniel Stenberg, 6-Apr-12, 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 a start and end point to permit restarts and repairs of interrupted data transfers in STREAM mode. "Definition of Managed Objects for SAVI Protocol", Changqing An, Jiahai Yang, Jianping Wu, Jun Bi, 19-Dec-11, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing SAVI (Source Address Validation Improvements) protocol instance. "Automating the Initial Window in TCP", Joseph Touch, 17-Jan-12, The Initial Window (IW) provides the starting point for TCP's feedback-based congestion control algorithm. Its value has increased over time to increase performance and to reflect increased capability of Internet devices. This document describes a mechanism to adjust the IW over long timescales, to make future changes more safely deployed and to potentially avoid reexamination of this value in the future. "JSON Web Token (JWT)", Michael Jones, Dirk Balfanz, John Bradley, Yaron Goland, John Panzer, Nat Sakimura, Paul Tarjan, 12-May-12, JSON Web Token (JWT) is a means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is digitally signed or MACed using JSON Web Signature (JWS) and/or encrypted using JSON Web Encryption (JWE). The suggested pronunciation of JWT is the same as the English word "jot". "Cloud/DataCenter SDO Activities Survey and Analysis", Bhumip Khasnabish, Chu JunSheng, 28-Dec-11, The objective of this draft is to present a snapshot of industry standards activities related to Cloud/DataCenter computing, networking and services including relevant features and functions. This document is a survey of current activities of cloud standards development organizations (SDOs). At the end of this survey a section on gap analysis is also presented. "Cloud Industry Workitem Survey Results", Bhumip Khasnabish, Chu JunSheng, Yu Meng, 1-Jan-12, This document presents a survey of the industry work items related to cloud computing, networking and services. At the end of this survey a section on gaps related to work items is presented. "Cloud Reference Framework", Bhumip Khasnabish, Chu JunSheng, SuAn Ma, Yu Meng, Ning So, Paul Unbehagen, Monique Morrow, Masum Hasan, 27-Dec-11, This document presents a cloud reference framework. In general, a cloud based system utilizes virtualized resources and applications. The reference framework is based on the survey of the SDOs and WGs that are focusing on cloud-based systems and services (draft- Khasnabish-cloud-sdo-survey). Both intra-cloud and inter-cloud reference frameworks are presented and the requirements of each layer are discussed. "Encoding the graphemes of the SignWriting Script with the x-ISWA-2010", Stephen Slevinski, Valerie Sutton, 3-Jan-11, For concreteness, because the universal character set is not yet universal, because an undocumented and unlabeled coded character set hampers information interchange, a 12-bit coded character set has been created that encodes the graphemes of the SignWriting script as described in the open standard of the International SignWriting Alphabet 2010. The x-ISWA-2010 coded character set is defined with hexadecimal characters and described with Unicode characters, either proposed characters on plane 1 or interchange characters on plane 15. This memo defines a standard coded character set for the Internet community. It is published for reference, examination, implementation, and evaluation. Distribution of this memo is unlimited. "IPv6 Multicast Using Native IPv4 Capabilities in a 6rd Deployment", Tina Tsou, Tom Taylor, Cathy Zhou, Hui Ji, 12-Mar-12, This document describes how IPv6 multicast can be extended across an IPv4 network to an IPv6 host, using the native multicast capabilities of the IPv4 network. "RADIUS Extensions for Port Control Protocol", Dean Cheng, Roberta Maglione, 22-Dec-11, This memo proposes a new Remote Authentication Dial In User Service (RADIUS) attribute to carry the Fully Qualified Domain Name (FQDN) of a Port Control Protocol (PCP) server, such that while the PCP server information is configured on a RADIUS server, the information can be conveyed to Network Access Server (NAS) via RADIUS protocol, and the co-located Dynamic Host Configuration Protocol (DHCP/DHCPv6) server can then populate the information to PCP client. "ECN for Stream Control Transmission Protocol (SCTP)", Randall Stewart, Michael Tuexen, Xuesong Dong, 17-Feb-12, This document describes the addition of the ECN to the Stream Control Transmission Protocol (SCTP). "Multicast Support for NAT64", Behcet Sarikaya, Teemu Kiviniemi, 10-Jan-12, This memo specifies modifications required to NAT64 so that IPv6 only hosts can receive multicast data from IPv4 only servers. The protocol is based on translating IPv4 multicast data before delivering it to the host in IPv6. The protocol also allows IPv6 only host to join IPv4 any source/ source specific multicast group in IPv6 using Multicast Listener Discovery protocol. "A Session Initiation Protocol (SIP) INFO package for Private Wire", Richard Beauchamp, Finlay Fraser, Chris Boulton, 17-Apr-12, Application level data exchanged using the SIP INFO method are supported and documented in specifications known as 'INFO Packages'. This document defines functionality associated with Session Initiation Protocol (SIP) Private Wire functionality and creates an 'INFO Package' for carrying such application level data. "Virtual Private LAN Service (VPLS) Using IS-IS", KuiKe Building, Himanshu Shah, 11-Mar-12, This document describes a light-weight Virtual Private LAN Service (VPLS), referred to as IS-IS VPLS, which uses IS-IS for auto- discovery and signaling. IS-IS VPLS is intended to be used as a scalable cloud data center network solution. "Using LDP Multipoint Extensions on Targeted LDP Sessions", Maria Napierala, Eric Rosen, 20-Apr-12, Label Distribution Protocol (LDP) can be used to set up Point-to-Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) Label Switched Paths. The existing specification for this functionality assumes that a pair of LDP neighbors are directly connected. However, the LDP base specification allows for the case where a pair of LDP neighbors are not directly connected; the LDP session between such a pair of neighbors is known as a "Targeted LDP" session. This document specifies the use of the LDP P2MP/MP2MP extensions over a Targeted LDP session. "A Simple Method for Segmenting Multicast Tunnels for Multicast VPNs", Maria Napierala, Eric Rosen, 20-Apr-12, 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. "Conference Focus Indicating CCMP Support", Rifaat Shekh-Yusef, Mary Barnes, 12-Mar-12, The Centralized Conferencing Manipulation Protocol document defines away 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 and take advantage of CCMP operations on the conference. This draft describes few options to address the above limitation with the pros and cons for each approach. "Client subnet in DNS requests", Carlo Contavalli, Wilmer van der Gaast, Sean Leach, Edward Lewis, 25-Apr-12, This draft defines an EDNS0 extension to carry information about the network that originated a DNS query, and the network for which the subsequent reply can be cached. "Reserving N and N+1 Ports with PCP", Mohamed Boucadair, Senthil Sivakumar, 19-Apr-12, This document defines a new PCP Option to reserve a pair of ports (N and N+1) by a PCP-controlled device while preserving the parity and contiguity. This PCP Option eases the NAT traversal for applications having requirements on the port parity and contiguity (e.g., RTP/ RTCP). "Media level ice-options SDP attribute", Marc Petit-Huguenin, 12-Mar-12, This document normatively updates RFC 5245 by redefining the ice- options SDP attribute as a session-level and media-level attribute. "ICE Updated Offer Problematic", John Elwell, Andrew Hutton, Thomas Stach, 12-Dec-11, Interactive Connectivity Establishment (ICE) requires an updated offer-answer cycle under some circumstances, to satisfy the needs of some devices on the signalling path. When used with SIP, this additional offer-answer cycle interacts with other things, such as fax and third party call control (3PCC). This document describes the problems and discusses possible remedies. This work is being discussed on the mmusic@ietf.org mailing list. "RTCP XR Blocks for QoE metric reporting", Geoff Hunt, Alan Clark, Wenson Wu, Roland Schott, Glen Zorn, 30-Dec-11, This document defines an RTCP XR Report Block and associated SDP parameters that allow the reporting of QoE metrics for use in a range of RTP applications. "RTCP XR Report Block for TS Decodability Statistics Metric reporting", Rachel Huang, Qin Wu, Hitoshi Asaeda, Glen Zorn, 11-Mar-12, Transport Stream is a standard container format used in the transmission and storage of multimedia data. This document defines an RTCP XR Report Block that allows the reporting of decodability statistics metrics related to transmissions in Transport Stream format. This XR Report Block includes 8 metrics from ETSI TR 101 290, which are most important and most universal metrics from priorities 1 and 2. The metrics from priority 3 are defined as application dependent monitoring, and the unadopted metrics are never or seldom happending during the content transmission. So this kind of metrics are omitted by this draft. "Content Distribution Network Interconnection (CDNI) Experiments", Francois Le Faucheur, Larry Peterson, 15-Feb-12, This document reports studies and related experiments on CDN interconnection performed by France Telecom-Orange Labs. The document summarizes implications of CDN interconnection to CDN service providers and lessons learned through CDNI experiments. The main purpose of the experiments was to test the interconnection of CDN solutions from two vendors (namely, Cisco and Verivue) and to identify the gaps and needs for standardization work for CDN interconnection. "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Hub and Spoke Multipoint Label Switched Paths (LSPs)", Lizhong Jin, Frederic JOUNAY, Manav Bhatia, 7-May-12, In Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) environment, the RSVP-TE based Point-to-Multipoint (P2MP) LSP allows traffic to transmit from root to leaf node, but there is no co-routed reverse path for traffic from leaf to root node. This draft introduces a Hub and Spoke Multipoint (HSMP) LSP, which allows traffic from both the root to the leaves through a P2MP LSP and also the leaves to the root along a co-routed reverse path. "PCEP Extension for WSON Routing and Wavelength Assignment", Young Lee, Ramon Casellas, 30-Apr-12, 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, 10-Mar-12, RPL is a flexible routing protocol applicable to a wide range of Low Power and Lossy Networks. To enable this wide applicability, RPL provides many configuration options and gives implementers choices on how to implement various components of RPL. Drawing on our experiences, we distill the design choices and configuration parameters that lead to efficient RPL implementations and operations. "SCS: Secure Cookie Sessions for HTTP", Stefano Barbato, Steven Dorigotti, Thomas Fossati, 20-Dec-11, This document provides an overview of SCS, a small cryptographic protocol layered on top of the HTTP cookie facility, that allows its users to produce and consume authenticated and encrypted cookies, as opposed to usual cookies, which are un-authenticated and sent in clear text. An interesting property, rising naturally from the given confidentiality and authentication properties, is that by using SCS cookies, it is possible to avoid storing the session state material on the server side altogether. In fact, an SCS cookie presented by the user agent to the origin server can always be validated (i.e. possibly recognized as self-produced, untampered material) and, as such, be used to safely restore application state. Hence, typical use cases may include devices with little or no storage offering some functionality via an HTTP interface, as well as web applications with high availability or load balancing requirements which would prefer to handle application state without the need to synchronize the pool through shared storage or peering. Nevertheless, its security properties allow SCS to be used whenever the privacy and integrity of cookies is a concern, by paying an affordable price in terms of increased cookie size, additional CPU clock cycles needed by the symmetric key encryption and HMAC algorithms, and related key management, which can be made a nearly transparent task. "MPLS-TP Ring Protection Switching (MRPS)", Huub van Helvoort, Jeong-dong Ryoo, 7-Apr-12, 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, 27-Feb-12, 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. "Scalable, Loop-Free BGP FRR using Repair Label", Ahmed Bashandy, Burjiz Pithawala, Jakob Heitz, 1-May-12, Consider a BGP free core scenario. Suppose the provider edge BGP speakers PE1, PE2,..., PEn know about a prefix P/m via the external routers CE1, CE2,..., CEm. If the PE router PEi loses connectivity to the primary path, it is desirable to immediately restore traffic by rerouting packets arriving from the core to PEi and destined to the prefix P/m to one of the other PE routers that advertised P/m, say PEj, until BGP re-converges. However if the loss of connectivity of PEi to the primary path also resulted in the loss of connectivity between PEj and CEj, rerouting a packet before the control plane converges may result in a loop. In this document, we propose using a repair label for traffic restoration while avoiding loops. We propose advertising the "repair" label through BGP. "Extending the Virtual Router Redundancy Protocol for TRILL campus", ZTE Corporation, fangwei hu, 29-Dec-11, TRILL can be implemented in data center networks, which requires high reliability and stability. Whenever the egress RBridges or links break down, the TRILL rerouting time depends on the IS-IS topology convergence time, which may do not meet data center service requirements in terms of resiliency. VRRP provides a redundancy mechanism to avoid single point of failure and fast switching over. This draft proposes to extend VRRP protocol to TRILL in data center networks. "Lightweight Secure Neighbor Discovery for Low-power and Lossy Networks", Behcet Sarikaya, Frank Xia, Greg Zaverucha, 30-Apr-12, This document defines lightweight secure neighbor discovery for low- power and lossy networks. The nodes generate a Cryptographically Generated Address, register the Cryptographically Generated Address with a default router and periodically refresh the registration. Modifications to 6lowpan Neighbor Discovery protocol are described for secure neighbor discovery for low-power and lossy networks. Cryptographically generated address and digital signatures are calculated using elliptic curve cryptography, so that the cryptographic operations are suitable for low power devices. "Using Secure DNS to Associate Certificates with Domain Names For S/MIME", Paul Hoffman, Jakob Schlyter, 9-Mar-12, S/MIME uses certificates for authenticating and encrypting messages. Users want their mail user agents to securely associate a certificate with the sender of an encrypted and/or signed message. DNSSEC provides a mechanism for a zone operator to sign DNS information directly. This way, bindings of certificates to users within a domain are asserted not by external entities, but by the entities that operate the DNS. This document describes how to use secure DNS to associate an S/MIME user's certificate with the intended domain name. IMPORTANT NOTE: This draft is intentionally sketchy. It is meant as a possible starting point for the DANE WG if it wants to consider making a protocol similar to TLSA, as described in draft-ietf-dane-protocol, but that applies to S/MIME. The WG may or may not want to adopt such work, or if it does, may want to use a very different scheme from the one described here. "Standard Representation Of Domain Sequence", Dhruv Dhody, Udayasree Palle, Ramon Casellas, 9-Feb-12, The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement for P2P and P2MP scenarios. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems. This document specifies a standard representation and encoding of a domain sequence, which is defined as an ordered sequence of domains traversed to reach the destination domain. This document also defines new sub-objects to be used to encode domain identifiers. "NETCONF over WebSocket", Tomoyuki Iijima, Hiroyasu Kimura, Yoshifumi Atarashi, Hidemitsu Higuchi, 4-Mar-12, This memo proposes a way of transporting NETCONF over WebSocket protocol. Web-based applications are increasing with the advancement of Web technologies and emergence of cloud computing. Management systems that support browser-based interface are getting common. It's natural to expect network devices to have browser-based managemaent interface. Currently, however, few network management protocols support the transportation over HTTP. Although NETCONF[RFC6241] was defined to be sent over SOAP/HTTPS[RFC4743], it can not realize notification mechanism[RFC5277] over SOAP/HTTPS since HTTP lacks bi-directional capabilty. But now, WebSocket protocol, the update of HTTP with bi-directional capability, is available[RFC6455]. This memo describes the way NETCONF is sent over WebSocket protocol. "Duplication Grouping Semantics in the Session Description Protocol", Ali Begen, Yiqun Cai, Heidi Ou, 11-Mar-12, 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. "Delayed Duplication Attribute in the Session Description Protocol", Ali Begen, Yiqun Cai, Heidi Ou, 10-Mar-12, 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. "IANA Registration of Enumservices for Internet Calendaring", Bernie Hoeneisen, 11-Mar-12, This document registers and obsoletes Enumservices for Internet calendaring. Specifically, this document focuses on Enumservices for iMIP (iCalendar Message-Based Interoperability Protocol), CalDAV (Calendaring Extensions to WebDAV), and iSchedule (Internet Calendar Scheduling Protocol). "Hypertext Transfer Protocol (HTTP) Keep-Alive Header", Martin Thomson, Salvatore Loreto, Greg Wilkins, 12-Mar-12, A Keep-Alive header is defined for HTTP. This hop-by-hop header informs hosts about connection management policies. Parameters are defined for idle connection timeout and maximum request count. "IPFIX Information Elements for Flow Performance Measurement", Aamer Akhter, 27-Mar-12, There is a need to be able to quantify and report the performance of network applications and the network service in handling user data. This performance data provides information essential in validating service level agreements, fault isolation as well as early warnings of greater problems. This document describes IPFIX Information Elements related to performance measurement of network based applications. In addition, to the performance information several non-metric information elements are also included to provide greater context to the reports. The measurements use audio/video applications as a base but are not restricted to these class of applications. "Methodology for Network Flow Performance Measurement", Aamer Akhter, 27-Mar-12, There is a need to be able to quantify and report the performance of network applications and the network service in handling user data. This performance data provides information essential in validating service level agreements, fault isolation as well as early warnings of network greater problems. This document describes a generic methodology for calculating metrics related to network based applications. In addition, to the performance metrics, several additional information elements are included to help provide greater context to the reports. The measurements use audio/video applications as base examples but are not restricted to these class of applications. "6LoWPAN Roadmap and Implementation Guide", Carsten Bormann, 26-Mar-12, 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 acceptance curve of the specifications. This document does not describe a new protocol or attempts 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. The current version -01 of this document is an early draft that is intended to spark the further collection of relevant information. "CoRE Simple Server Discovery", Carsten Bormann, 27-Mar-12, CoRE defines a mechanism for resource discovery based on Web linking. Many applications also need a simple form of discovery for the servers carrying these resources. This specification shows a simple way to extend the link-based resource discovery into a basic form of server discovery. The current version -01 of this document continues an initial draft that is intended to spark discussion. "Reusing the IPv4 Identification Field in Atomic Packets", Bob Briscoe, 12-Mar-12, This specification takes a new approach to extensibility that is both principled and a hack. It builds on recent moves to formalise the increasingly common practice where fragmentation in IPv4 more closely matches that of IPv6. The large majority of IPv4 packets are now 'atomic', meaning indivisible. In such packets, the 16 bits of the IPv4 Identification (IPv4 ID) field are redundant and could be freed up for the Internet community to put to other uses, at least within the constraints imposed by their original use for reassembly. This specification defines the process for redefining the semantics of these bits. It uses the previously reserved control flag in the IPv4 header to indicate that these 16 bits have new semantics. Great care is taken throughout to ease incremental deployment, even in the presence of middleboxes that incorrectly discard or normalise packets that have the reserved control flag set. "An EAP Authentication Method Based on Identity-Based Authenticated Key Exchange", Violeta Cakulev, Ioannis Broustis, 28-Feb-12, The Extensible Authentication Protocol (EAP) is an authentication framework which supports multiple authentication methods. This document defines an authentication method for EAP called EAP-IBAKE, which is based on the Identity-Based Authenticated Key Exchange (IBAKE) protocol. The IBAKE method provides mutual authentication through the use of identity-based encryption. In addition to mutual authentication this method also provides perfect forward and backwards secrecy. "Happy Eyeballs Extension for Multiple Interfaces", Gang Chen, Carl Williams, Dan Wing, Andrew Yourtchenko, 12-Mar-12, The memo has been proposed to extend happy eyeballs algorithm to fit into multiple interfaces environment. Based on this extended heuristic algorithm, a client with multiple interface could determine the optimal flow path in which specific interface has been chosen. Furthermore, an appropriate IP address family for each interface can be also identified to guarantee user experiences during IPv6 transition period. "A Forward-Search P2P TE LSP Inter-Domain Path Computation", Huaimo Chen, Dhruv Dhody, 11-Mar-12, 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. "Softwire Mesh Management Information Base(MIB)", Yong Cui, Jiang Dong, Peng Wu, Mingwei Xu, 12-Mar-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 softwire mesh [RFC5565]. "One-time Extended Community Based Outbound Route Filter for BGP-4", Jie Dong, Qing Zeng, Jakob Heitz, Keyur Patel, Rob Shakir, 8-Mar-12, This document defines a new Outbound Router Filter (ORF) type for BGP, termed "One-time Extended Community Outbound Route Filter", which would allow a BGP speaker to send to its BGP peer a route refresh request with a set of extended-community-based filters to make the peer re-advertise only the specific routes matching the filters to the speaker. This ORF-type enables a BGP speaker to refresh some specific routes without requiring its peer to re- advertise the whole Adj-RIB-Out, which makes the route refresh operation more efficient and reduces the impact on network stability. This filter does not change the outbound route filters on BGP peers and should only be used for one-time filtering. "The 'mailto' URI/IRI Scheme", Martin Duerst, Larry Masinter, Jamie Zawinski, 25-Mar-12, This document defines the format of Uniform Resource Identifiers (URIs) and Internationalized Resource Identfiers (IRIs) to identify resources that are reached using Internet mail. It adds the possibility to use Email Address Internationalization (EAI) email addresses (RFC6530) to the previous syntax of 'mailto' URIs (RFC 6068). "The FNV Non-Cryptographic Hash Algorithm", Glenn Fowler, Landon Noll, Kiem-Phong Vo, Donald Eastlake, 26-Mar-12, 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. "Updating TCP to support Variable-Rate Traffic", Gorry Fairhurst, Israfil Biswas, 23-Dec-11, This document addresses issues that arise when TCP is used to support variable-rate traffic that exhibts periods where the transmission rate is limited by the application rather than the congestion window. It updates TCP to allow a TCP sender to restart quickly following either an idle or applications-limited interval. The method is expected to benefit variable-rate TCP applications, while also providing an appropriate response if congestion is experienced. The document also evaluates TCP Congestion Window Validation (CWV), an IETF experimental specification defined in RFC 2861, and concludes that CWV sought to address important issues, but failed to deliver a widely used solution. This document recommends that the IETF should consider moving RFC 2861 from Experimental to Historic status, and that this is replaced by the current specification. "Security Considerations in the IP-based Internet of Things", Oscar Garcia-Morchon, Sye Keoh, Sandeep Kumar, Rene Hummen, Rene Struik, 26-Mar-12, 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. "RFC Editor Model (Version 2)", Olaf Kolkman, Joel Halpern, 26-Mar-12, The RFC Editor model described in this document divides the responsibilities for the RFC Series into three functions: The RFC Series Editor, the RFC Production Center, and the RFC Publisher. Internet Architecture Board (IAB) oversight via the RFC Series Oversight Committee (RSOC) is described, as is the relationship between the IETF Administrative Oversight Committee (IAOC) and the RSOC. This document reflects the experience gained with RFC Editor Model version 1, documented in [RFC5620] and obsoletes that document. "A Common API for Transparent Hybrid Multicast", Matthias Waehlisch, Stig Venaas, Thomas Schmidt, 27-Jan-12, Group communication services exist in a large variety of flavors, and technical implementations at different protocol layers. Multicast data distribution is most efficiently performed on the lowest available layer, but a heterogeneous deployment status of multicast technologies throughout the Internet requires an adaptive service binding at runtime. Today, it is difficult to write an application that runs everywhere and at the same time makes use of the most efficient multicast service available in the network. Facing robustness requirements, developers are frequently forced to use a stable, upper layer protocol provided by the application itself. This document describes a common multicast API that is suitable for transparent communication in underlay and overlay, and grants access to the different multicast flavors. It proposes an abstract naming by multicast URIs and discusses mapping mechanisms between different namespaces and distribution technologies. Additionally, it describes the application of this API for building gateways that interconnect current multicast domains throughout the Internet. "The Diameter 'Application Bridging for Federated Access Beyond Web (ABFAB)' Application", Mark Jones, Hannes Tschofenig, 12-Mar-12, The Application Bridging for Federated Access Beyond Web (ABFAB) architecture provides cross-domain authentication, authorization and accounting functionality by utilizing well-established technologies, such as Diameter, the Extensible Authentication Protocol (EAP), and the Generic Security Services API (GSS-API). This document defines a Diameter application for usage with the ABFAB architecture to convey authentication information, and authorization decisions from the Diameter server (acting as the identity provider) to the Diameter client (acting as a relying party) encoded in a Security Assertion Markup Language (SAML) encoding. "Extensible XDR Discriminated Union Primitive Type", Thomas Keiser, 3-Feb-12, AFS-3 relies upon XDR to carry Rx RPC call payloads. XDR discriminated unions are ill-suited to cases where the protocol needs to evolve without inventing new RPCs, i.e., unknown discriminant values cause the entire XDR payload to fail the decoding step. While this can be circumvented through the use of opaque payloads (and recursive XDR invocations), such solutions are inelegant and difficult to implement. This memo defines a new XDR primitive type, "ext-union", which is derived from the XDR discriminated union primitive type, but with two key variations: 1) each leg contains a length field, and 2) no default leg is supported. "A Usage for Shared Resources in RELOAD (ShaRe)", Alexander Knauf, Gabriel Hege, Thomas Schmidt, Matthias Waehlisch, 25-Apr-12, This document defines a RELOAD Usage for managing shared write access to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic primitive for enabling various coordination and notification schemes among distributed peers. Access in ShaRe is controlled by a hierarchical trust delegation scheme maintained within an access list. A new USER-CHAIN-ACL access policy allows authorized peers to write a Shared Resource without owning its corresponding certificate. This specification also adds mechanisms to store Resources with a variable name which is useful whenever peer-independent rendezvous processes are required. "Changing DNS Operators for DNSSEC signed Zones", Peter Koch, Marcos Sanz, 11-Mar-12, Changing the DNS delegation for a DNS zone is quite involved if done by the books, but most often handled pragmatically in today's operational practice at the top level with registries and registrars. This document describes a delegation change procedure that maintains consistency and validation under DNSSEC. "Controlling Traffic Offloading Using Neighbor Discovery Protocol", Jouni Korhonen, Teemu Savolainen, Yi Ding, 12-Mar-12, This specification defines an extension to IPv6 Neighbor Discovery Protocol, which allows management of IPv4 traffic offloading for multi-interface dual-stack capable hosts and moving IPv4 traffic away from a specific interface. "Mobile Communication Congestion Exposure Scenario", Dirk Kutscher, Faisal Mir, Rolf Winter, Suresh Krishnan, Carlos Bernardos, 12-Mar-12, This memo describes a mobile communications use case for congestion exposure (CONEX) with a particular focus on mobile communication networks such as 3GPP EPS. The draft describes the architecture of these networks (access and core networks), current QoS mechanisms and then discusses how congestion exposure concepts could be applied. Based on this, this memo suggests a set of requirements for CONEX mechanisms that particularly apply to mobile networks. "Management Information Base for MPLS LDP Multi Topology", Chen Li, Lianyuan Li, Lu Huang, Emily Chen, Quintin Zhao, 12-Mar-12, This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a MIB module for Multi-Topology Networks over Multi-protocol Label Switching(MPLS) Label Switching Routers(LSRs). "Lightweight Key Establishment and Management Protocol in Dynamic Sensor Networks (KEMP)", Ying Qiu, Jianying Zhou, F Bao, 12-Mar-12, When a sensor node roams within a very large and distributed wireless sensor network, which consists of numerous sensor nodes, its routing path and neighborhood keep changing. In order to provide a high level of security in this environment, the moving sensor node needs to be authenticated to new neighboring nodes as well as to establish a key for secure communication. The document proposes an efficient and scalable protocol to establish and update the secure key in a dynamic wireless sensor network environment. The protocol guarantees that two sensor nodes share at least one key with probability 1 (100%) with less memory and energy cost, while not causing considerable communication overhead. "Data Center Mobility based on BGP/MPLS, IP Routing and NHRP", Rahul Aggarwal, Ravi Shekhar, Wim Henderickx, Yakov Rekhter, 2-Feb-12, This document describes a set of network-based solutions for seamless Virtual Machine mobility in the data center. These solutions provide a toolkit which is based on IP routing, BGP/MPLS E-VPNs, BGP/MPLS IP VPNs, and NHRP. "Using PCP To Coordinate Between the CGN and Home Gateway Via Port Allocation", Qiong Sun, Mohammed Boucadair, Xiaohong Deng, Cathy Zhou, Tina Tsou, 12-Mar-12, This document defines an extension to the base PCP. New OpCode and Options are defined to enhance PCP with the ability to reserve port sets for internal hosts. "Secure Object Delivery Protocol (SODP)", Sean Turner, 10-Jan-12, This document describes the Secure Object Delivery Protocol (SODP). SODP enables clients to obtain secured packages from a Secure Object Management System (SOMS). Packages supported by a SOMS server include but are not limited to: firmware packages [RFC4108], trust anchor (TA) packages [RFC5934], symmetric key packages [RFC6031], asymmetric key packages [RFC5958], encrypted key packages [RFC6031], public key certificate enrollment packages [RFC5272], public key certificates [RFC5280], and Certificate Revocation Lists (CRLs) [RFC5280]. Client access is ideally direct and web-based, but access via agents acting on behalf of clients is supported. "Multipath TCP Support for Single-homed End-systems", Rolf Winter, Andreas Ripke, 20-Apr-12, 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. residential broadband customers). This memo describes mechanisms to make multiple paths available to multipath TCP via autoconfiguration that are not available at the end-systems but somewhere within the network. "Making Route Flap Damping Usable", Cristel Pelsser, Keyur Patel, Olaf Maennel, Pradosh Mohapatra, Randy Bush, 22-Dec-11, Route Flap Damping (RFD) was first proposed to reduce BGP churn in routers. Unfortunately, RFD was found to severely penalize sites for being well-connected because topological richness amplifies the number of update messages exchanged. Many operators have turned RFD off. Based on experimental measurement, this document recommends adjusting a few RFD algorithmic constants and limits, to reduce the high risks with RFD, with the result being damping a non-trivial amount of long term churn without penalizing well-behaved prefixes' normal convergence process. "Adaptive VLAN Assignment for Data Center RBridges", Mingui Zhang, Dacheng Zhang, 6-Mar-12, 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", Ulrich Herberg, Alvaro Cardenas, Tadashige Iwao, Michael Dow, Sandra Cespedes, 26-Mar-12, This document describes the Depth-First Forwarding (DFF) protocol for IPv6 networks based on the LoWPAN adaptation layer as specified in RFC4944. The protocol is a mesh-under data forwarding mechanism that increases reliability of data delivery. DFF forwards data frames using a network-wide "depth-first search" for the Final Destination of the frame. DFF may be used in conjunction with a routing protocol, which provides "hints" for DFF in which order to try to send the frame to the neighbors discovered by the neighborhood discovery mechanism. In that case, DFF can be used as local repair mechanism. "A Forward-Search P2MP TE LSP Inter-Domain Path Computation", Huaimo Chen, Dhruv Dhody, 11-Mar-12, 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, 28-Feb-12, Today the Dual-Stack approach is the most straightforward and the most common way for introducing IPv6 into existing systems and networks. However a typical drawback of implementing Dual-Stack is that each node will still require at least one IPv4 address. Hence, solely deploying Dual-Stack does not provide a sufficient solution to the IPv4 address exhaustion problem. Assuming a situation where most of the IP communication (e.g. always-on, VoIP etc.) can be provided via IPv6, the usage of public IPv4 addresses can significantly be reduced and the unused public IPv4 addresses can under certain circumstances be returned to the public IPv4 address pool of the service provider. New Dual-Stack enabled services can be introduced without increasing the public IPv4 address demand, when IPv6 will be the preferred network layer protocol. This document describes such a solution in a Dual-Stack PPP session network scenario and explains the protocol mechanisms which are used. "Policy Signaling for Multi-access Mobility", Rajeev Koodli, Kuntal Chowdhury, 2-Mar-12, The mobile nodes are increasingly capable of simultaneous multi-radio connectivity. This allows them to be attached to the Internet through multiple access technologies at the same time. With such multi-access, the mobile node (MN) can make use of the best-available access technology for a particular application at any given time. And, the network may be able to balance the flow of traffic across the available access technologies. The Mobile IPv6 flow binding work provides a mechanism for the MN to signal the Home Agent to balance the flows based on the MN'e needs. This document specifies a simple protocol for a mobile IP gateway (such as a Mobile IP Home Agent or a Proxy Mobile IP Local Mobility Anchor) to signal the MN of gateway's policy for traffic treatment across access technologies. Based on the response and the prevailing network conditions, the gateway then balances the traffic. "Requesting Suboptions in DHCPv6", Tomasz Mrugalski, 28-Mar-12, DHCPv6 clients may use Option Request Option (ORO) defined in RFC3315 [RFC3315] to specify, which options they would like to have configured by DHCPv6 servers. Clients may also be interested in specific options that do not appear in DHCPv6 message directly (top- level options), but rather as nested options or sub-options (i.e. options conveyed within other options). This document clarifies how to use already defined ORO to request sub-options. It also defines new Option Exclude Option (OXO) for cases, when client does not want requested options to appear within specific options. This document updates RFC3315 (if approved). "Supporting Shared Mesh Protection in MPLS-TP Networks", Ping Pan, Rajan Rao, Biao Lu, Luyuan Fang, Andrew Malis, Fei Zhang, Sam Aldrin, Fatai Zhang, Mohana Singamsetty, 13-Mar-12, Shared mesh protection is a common protection and recovery mechanism in transport networks, where multiple paths can share the same set of network resources for protection purposes. In the context of MPLS-TP, it has been explicitly requested as a part of the overall solution (Req. 67, 68 and 69 in RFC5654 [RFC5654]). It's important to note that each MPLS-TP LSP may be associated with transport network resources. In event of network failure, it may require explicit activation on the protecting paths before switching user traffic over. In this memo, we define a lightweight signaling mechanism for protecting path activation in shared mesh protection-enabled MPLS-TP networks. "Route Flap Damping Deployment Status Survey", Shishio Tsuchiya, Seiichi Kawamura, Randy Bush, Cristel Pelsser, 12-Mar-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 amoung service provider on their use of BGP Route Flap Damping. "Trends in Web Applications and the Implications on Standardization", Hannes Tschofenig, Bernard Aboba, Jon Peterson, Danny McPherson, 9-May-12, Advancements in the design of web browsers have introduced fundamental changes to the architecture of application protocols. The widespread availability and growing sophistication of JavaScript interpreters in browsers enables web servers to push to browsers all of the application logic required to implement a client-server protocol. Consequently, many client-server applications that once required an installed client on a host computer now can rely simply on a modern browser to act as a client for the purposes of a particular application. For example, where once email clients required a custom application to access an inbox, increasingly a web browser can serve this purpose as well as the purpose-built applications of the past. Similarly, HTTP with the assistance of JavaScript can subsume the functions performed by the protocols like POP3 and IMAP. The need for Internet standards beyond HTTP to implement an email inbox application consequently diminishes - why author standards and worry about interoperability of clients and servers when the server can simply push to the client all the code it needs to be interoperable? Many client-server applications on the Internet could potential migrate to this code distribution methodology. [Note: A separate mailing list has been created for discussions related to this document and it can be found here: https://www.ietf.org/mailman/listinfo/webapps ] "Transport of Fast Notification Messages", Wenhu Lu, Sriganesh Kini, Andras Csaszar, Gabor Envedi, Jeff Tantsura, 12-Mar-12, 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. "Bundle Protocol MIB", Zack Sims, Hans Kruse, 20-Apr-12, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing information about a Bundle Node - or simply a 'Node' within the scope of this document. More specifically, the managed objects for such a Node include: Node-specific information, registered Endpoint-Specific information, and generic CLA-Specific (Convergence Layer Adapter) information. "JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0", Michael Jones, Brian Campbell, Chuck Mortimore, 26-Apr-12, This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. "IPv4 and IPv6 Options to support Information Centric Networking", Andrea Detti, Stefano Salsano, Nicola Blefari-Melazzi, 25-Nov-11, The Information Centric Networking (ICN) paradigm, shifts the focus of networking from providing connections between hosts to efficiently providing content to the users. The work on ICN has traditionally been performed looking at "clean-slate" solutions which aims to replace IP with a new paradigm. On the other hand, in this memo we propose an "integration" approach to Information Centric Networking, i.e. we extend the IP protocol using a new IP Option (both for IPv4 and IPv6). The new IP option is used by routers to support networking based on content rather than (or better in addition to) end-point addresses. "A Description of KCipher-2 Encryption Algorithm", Shinsaku Kiyomoto, Wook Shin, 19-Dec-11, This document describes the KCipher-2 encryption algorithm. KCipher-2 is a stream cipher with a 128-bit key and a 128-bit initialization vector. Since the algorithm for KCipher-2 was published in 2007, security and efficiency have been rigorously evaluated through academic and industrial studies. No security vulnerability has been found as of the time this document was written. KCipher-2 offers fast encryption and decryption by means of simple operations that enable efficient implementation. KCipher-2 has been used for industrial applications, especially for mobile health monitoring and diagnostic services in Japan. "Verification Involving PSTN Reachability: Requirements and Architecture Overview", Mary Barnes, Cullen Jennings, Jonathan Rosenberg, Marc Petit-Huguenin, 12-Mar-12, 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. "Verification Involving PSTN Reachability: The ViPR Access Protocol (VAP)", Cullen Jennings, Jonathan Rosenberg, Marc Petit-Huguenin, 5-Mar-12, Verification Involving PSTN Reachability (ViPR) is a technique for inter-domain SIP federation. ViPR hybridizes the PSTN, P2P networks, and SIP, and in doing so, addresses the phone number routing and VoIP spam problems that have been a barrier to federation. The ViPR architecture uses a server, the ViPR server, which performs P2P and validation services on behalf of call agents, which acts as clients to the server. Such an architecture requires a client/server protocol between call agents and the ViPR server. That protocol, defined here, is called the ViPR Access Protocol (VAP). "The Public Switched Telephone Network (PSTN) Validation Protocol (PVP)", Marc Petit-Huguenin, Jonathan Rosenberg, Cullen Jennings, 12-Mar-12, One of the main challenges in inter-domain federation of Session Initiation Protocol (SIP) calls is that many domains continue to utilize phone numbers, and not email-style SIP URI. Consequently, a mechanism is needed that enables secure mappings from phone numbers to domains. The main technical challenge in doing this securely is to verify that the domain in question truly is the "owner" of the phone number. This specification defines the PSTN Validation Protocol (PVP), which can be used by a domain to verify this ownership by means of a forward routability check in the PSTN. "A Usage of Resource Location and Discovery (RELOAD) for Public Switched Telephone Network (PSTN) Verification", Marc Petit-Huguenin, Jonathan Rosenberg, Cullen Jennings, 12-Mar-12, Verification Involving PSTN Reachability (VIPR) is a technique for inter-domain SIP federation. VIPR makes use of the RELOAD protocol to store unverified mappings from phone numbers to RELOAD nodes, with whom a validation process can be run. This document defines the usage of RELOAD for this purpose. "Session Initiation Protocol (SIP) Extensions for Blocking VoIP Spam Using PSTN Validation", Marc Petit-Huguenin, Jonathan Rosenberg, Cullen Jennings, 11-Jan-12, Verification Involving PSTN Reachability (ViPR) is a new technique for inter-domain federation of SIP calls. ViPR makes use of the PSTN as an introduction mechanism to verify the correctness of mappings from phone numbers to domains. The PSTN introduction mechanism can also be used as a technique for blocking spam - a SIP caller is only authorized when its calling domain has previously called that same number over the PSTN. This document describes an extension to SIP which enables authorization of SIP calls based on a prior PSTN introduction. "A SAVI solution for WLAN", Jun Bi, Jianping Wu, You Wang, Tao Lin, 4-Apr-12, This document describes a source address validation solution for WLAN enabling 802.11i or other security mechanisms. This mechanism snoops NDP and DHCP to bind IP address with MAC address, and relies on the security of MAC address guaranteed by 802.11i or other mechanisms to filter IP spoofing packets. It can work in the special situations described in the charter of SAVI workgroup, such as multiple MAC addresses on one interface. This document describes three different deployment scenarios, with solutions for migration of mapping entries when hosts move from one access point to another. "Suite B Profile for Datagram Transport Layer Security / Secure Real-time Transport Protocol (DTLS-SRTP)", Kevin Igoe, Michael Peck, 15-Feb-12, The United States government has published guidelines for "NSA Suite B Cryptography", which defines cryptographic algorithm policy for national security applications. This document describes the use of Suite B cryptography with the Datagram Transport Layer Security (DTLS) protocol, the Secure Real-Time Transport Protocol (SRTP), and the Secure Real-Time Transport Control Protocol (SRTCP) to provide a robust architecture for securing real-time data. "True mobility of MobileIPv6", Mohd. Altamash, 9-Apr-12, This document enhances the mobility of Mobile node's home agent (HAMN) and correspondence node's home agent (HACN) along with the mobility of Mobile Node (MN) and Correspondence Node (CN). Hence this document shows true and complete mobility of MobileIPv6 protocol. "Analysis of Bidirectional Forwarding Detection (BFD) Security According to KARP Design Guide", Manav Bhatia, Dacheng Zhang, 25-Jan-12, This document analyzes the Bidirectional Forwarding Detection protocol (BFD) according to the guidelines set forth in section 4.2 of draft-ietf-karp-design-guide. "The With-MAC key-wrapping algorithm for Cryptographic Message Syntax", Jonathan Herzog, Roger Khazan, 2-Mar-12, This document describes a new key-wrapping algorithm to be used in the EnvelopedData, AuthenticatedData and AuthEnvelopedData structures of the Cryptographic Message Syntax. Because these structures do not provide data-origin authentication, a recipient cannot cryptographically verify that the plaintext received was the plaintext encapsulated by the message's original sender. The With- MAC key-wrapping algorithm allows an EncryptedKey value to hold both a wrapped symmetric key and a MAC value on the data to be authenticated. When used in EnvelopedData, AuthenticatedData and AuthEnvelopedData structures, therefore, these structures can achieve data-origin authentication (in some circumstances) using only symmetric-key algorithms. This is useful in cases where the structures must be generated by entities without certified digital- signature keys. "Indicating Character Encoding and Language for HTTP Header Field Parameters", Julian Reschke, 18-Dec-11, By default, message header field parameters in Hypertext Transfer Protocol (HTTP) messages cannot carry characters outside the ISO- 8859-1 character set. RFC 2231 defines an encoding mechanism for use in Multipurpose Internet Mail Extensions (MIME) headers. This document specifies an encoding suitable for use in HTTP header fields that is compatible with a profile of the encoding defined in RFC 2231. "RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs", John Lindsay, Derrick Rea, 7-Mar-12, This document specifies a scheme for packetizing Standard apt-X, or Enhanced apt-X, encoded audio data into Real-time Transport Protocol (RTP) packets. The document describes a payload format that permits transmission of multiple related audio channels in a single RTP payload, and a means of establishing Standard apt-X and Enhanced apt-X connections through the Session Description Protocol (SDP). "claimSigning Extended Key Usage (EKU)", Chris Louden, Dave Silver, Matt King, Matt Tebo, Patrick Patterson, Wendy Brown, 27-Dec-11, This document specifies an Extended Key Usage (EKU) value which indicates that the certificate holder is authorized to sign security tokens to assert claims, or attributes, about a subject. When a certificate that asserts the claimSigning EKU signs a claim, the owner of the service holding that certificate is asserting that a statement about the subject is true. For example, a IdP secure token service (STS) would use an X.509 certificate containing the claimSigning EKU to sign SAML assertions containing an identifier and attributes about a user. This EKU value would allow for a separation between the designation that a given Identity belongs within a given Federation, and the empowerment of that entity within the federation to sign claims.. This approach allows for greater flexibility for the operators of Federated systems and for Certification Authorities and avoids the overloading of other, already established methods (such as Assurance Level designation via certificatePolicy OID). "Standardised ECC Cipher Suites for TLS", Peter Gutmann, 22-Nov-11, This document describes a set of standard ECC cipher suites for TLS that simplify the complex selection procedure described in the existing ECC RFC, simplifying implementation and easing interoperability problems. "Transmission of IPv6 Packets over DECT Ultra Low Energy", Peter Mariager, Jens Petersen, 2-May-12, DECT Ultra Low Energy is a low power air interface technology that is defined by the DECT Forum and specified by ETSI. The DECT air interface technology has been used world-wide in communication devices for more than 15 years, primarily carrying voice for cordless telephony but has also been deployed for data centric services. The DECT Ultra Low Energy is a recent addition to the DECT interface primarily intended for low-bandwidth, low-power applications such as sensor devices, smart meters, home automation etc. As the DECT Ultra Low Energy interface inherits many of the capabilities from DECT, it benefits from long range, interference free operation, world wide reserved frequency band, low silicon prices and maturity. There is an added value in the ability to communicate with IPv6 over DECT ULE. This document describes how IPv6 is transported over DECT ULE using 6LoWPAN techniques. "Use Cases for ALTO within CDNs", Stefano Previdi, Grant Watson, Jan Medved, Nabil Bitar, Ben Niven-Jenkins, 7-Dec-11, For some time, Content Distribution Networks (CDNs) have been used in the delivery of some Internet services (e.g. delivery of websites, software updates and video delivery) as they provide numerous benefits including reduced delivery cost for cacheable content, improved quality of experience for end users and increased robustness of delivery. In order to derive the optimal benefit from a CDN it is preferable to deliver content from the servers (caches) that are "closest" to the End User requesting the content, where "closest" may be as simple as "geographical or network distance" combined with CDN server load within a location, but may also consider other more complex combinations of metrics and CDN or Network Service Provider (NSP) policies. There are a number of different ways in which a CDN may obtain the necessary network topology and/or cost information to allow it to serve End Users from the most optimal servers/locations, such as static configuration, passively listening to routing protocols directly, active probing of underlying network(s), or obtaining topology and cost by querying an information service such as the ALTO map & cost services. This document describes the use cases for a CDN to be able to obtain network topology and cost information from an ALTO server(s). "WebSocket Per-frame Compression", Takeshi Yoshino, 9-Mar-12, This specification defines a general per-frame compression scheme for the WebSocket Protocol and one specific compression extension using DEFLATE. This scheme compresses the "Application data" part of WebSocket data frames using specified compression algorithm. Please send feedback to the hybi@ietf.org mailing list. "An IKEv2 Extension for Supporting ERP", Yoav Nir, Wenson Wu, 20-May-12, This document describes an extension to the IKEv2 protocol that allows an IKE Security Association (SA) to be created and authenticated using the EAP Re-authentication Protocol extension as described in RFC 5296bis. NOTE TO RFC EDITOR: Replace 5296bis in the previous paragraph with the RFC number assigned to draft-ietf-hokey-rfc5296bis (now in the RFC Editor queue) "OAuth Dynamic Client Registration Protocol", Thomas Hardjono, Maciej Machulak, Eve Maler, Christian Scholz, 26-Apr-12, This specification proposes an OAuth Dynamic Client Registration protocol. "Multicast Support for 6rd", Behcet Sarikaya, 26-Mar-12, This memo specifies 6rd's multicast component so that IPv6 hosts can receive multicast data from IPv6 servers. In AMT based encapsulation solution, AMT Gateway at the 6rd Customer Edge router uses AMT protocol to establish a tunnel interface with AMT Relay at the 6rd Border Relay and this tunnel is used to exchange MLD messages to establish multicast state at AMT Relay so that AMT Relay can tunnel IPv6 multicast data to IPv6 hosts connected to AMT Gateway. In 6rd Translation Multicast based solution, the protocol is based on proxying MLD at the 6rd Customer Edge router and then translating MLD messages to IGMP messages and sending them upstream to a network which supports IPv4 multicast. 6rd Border Relay is multicast router and IGMP-MLD translator. It translates IGMP join back to MLD join message and sends it to multicast source. IPv6 Multicast data received at 6rd Border Relay is translated into IPv4 multicast data and then sent to IPv4 multicast tree downstream to 6rd Customer Edge which translates back to IPv6 multicast data then delivers to the hosts. "GSS-API pre-authentication for Kerberos", Alejandro Perez-Mendez, Fernando Pereniguez-Garcia, Gabriel Lopez-Millan, Rafael Lopez, 4-Jan-12, This document describes a pre-authentication mechanism for Kerberos based on the Generic Security Service Application Program Interface (GSS-API), which allows a Key Distribution Center (KDC) to authenticate clients by using any GSS mechanism. "DS-Lite Management Information Base (MIB)", Yu Fu, Sheng Jiang, Yong Cui, Jiang Dong, 24-Apr-12, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines managed objects for DS-Lite. "Operational Guidance for IPv6 Deployment in IPv4 Sites using ISATAP", Fred Templin, 9-May-12, 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). "Rapid Transition of IPv4 contents to be IPv6-accessible", Qiong Sun, Dong Liu, Qin Zhao, Qian Liu, Chongfeng Xie, Xing Li, Jacni Qin, 12-Mar-12, This document describes deployment practice of IPv4/IPv6 translation technologies for data center transition, aiming at rapidly increasing the amount of IPv6 accessible contents for users from IPv6 Internet while preserving the continuity of IPv4 service delivery. System based on this design has been deployed in production network to provide transition service for several ICP websites. "RADIUS Extensions for Port Set Configuration and Reporting", Dean Cheng, Jouni Korhonen, Mohamed Boucadair, 16-Apr-12, 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. "Extension to VPLS for E-Tree", Yuqun Cao, 29-Jan-12, This document proposes an approach to support Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) in Virtual Private LAN Service [RFC4761] [RFC4762]. The proposed solution is characterized by breaking pseudowire setup between Leaf endpoints in E-Tree instance to fulfill the specific E-Tree requirement: Leaf cannot communicate with Leaf. Backward compatibility is also considered in this document. "ICCP extension for the MSP application", Hongjie Hao, Weiqiang Cheng, Ma Yuxia, Wanming Cao, Yu jinghai, 15-May-12, This document specifies some extensions on Inter-Chassis Communication Protocol(ICCP) to support inter-chassis linear multiplex section protection(MSP) that is described in G.841. Linear multiplex section protection(MSP) is used to protect Synchronous Digital Hierarchy (SDH) links which could be used as attachment circuits to dual-home to two or more PEs. In this case, ICCP is introduced to support the configuration and state synchronization between two chassises. "A Taxonomy on Private Use Fields in Protocols", Chris Lonvick, 12-Feb-12, This document attempts to provide some clarification for the way that private use fields have been used in protocols developed in the IETF. It is strictly a taxonomy of what has been published and offers a minimal amount of advice about how to design or use private use options. "MPLS-TP Linear Protection Applicability to MS-PW", Daniel Cohn, Rafi Ram, Ma Yuxia, Masahiro Daikoku, 4-Jan-12, One of the requirements of the MPLS transport profile [RFC5654] is to provide linear protection for transport paths, which include both LSPs and PWs. The functional architecture described in [SurvivFwk] is applicable to both LSP and PWs, however [LinearProt] does not explicitly describe mechanisms for PW protection in MPLS-TP. This document extends the applicability of the linear protection mechanism described in [LinearProt] to MPLS-TP segmented PWs as defined in [RFC6073]. "RTCP XR for Summary Statistics Metrics Reporting", Glen Zorn, Roland Schott, Wenson Wu, Rachel Huang, 27-Feb-12, This document defines three RTCP XR Report Blocks and associated SDP parameters that allows the reporting of loss, duplication and discard summary statistics metrics for use in a range of RTP applications. "RTCP XR Blocks for Synchronization Delay and Offset Metrics Reporting", Hitoshi Asaeda, Rachel Huang, Wenson Wu, 19-Apr-12, This document defines two RTCP XR Report Blocks and associated SDP parameters that allow the reporting of synchronization delay and offset metrics for use in a range of RTP applications. "Multiple Topology Routing Extensions for Transparent Interconnection of Lots of Links (TRILL)", Vishwas Manral, Donald Eastlake, Mingui Zhang, Ayan Banerjee, 30-Dec-11, This document describes optional extensions to the TRILL protocol's use of IS-IS (Intermediate System to Intermediate Systems). These extensions support multiple topologies (MT) within the same TRILL campus and protocol instance of IS-IS. "Some Extensions to Port Control Protocol (PCP)", Mohamed Boucadair, Reinaldo Penno, Dan Wing, 24-Apr-12, This document extends Port Control Protocol (PCP) with new functionalities. "Definitions of Managed Objects for 6rd", Lei Cai, Jacni Qin, Shishio Tsuchiya, 3-Feb-12, This document defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing 6rd devices. "Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks", Gonzalo Salgueiro, Hadriel Kaplan, James Polk, Laura Liess, Parthasarathi R, Paul Jones, Roland Jesske, Salvatore Loreto, 30-Jan-12, This document specifies the requirements for an end-to-end session identifier in IP-based multimedia communication networks. This identifier would enable endpoints, intermediate devices, and management and monitoring systems to identify a session end-to-end, associate multiple endpoints with a given multipoint conference, track communication sessions when they are redirected, and associate one or more media flows with a given communication session. "Fundamental Architecture of Services Provider's network Transitioning to IPv6 (FAST6) -- PPPoE Broadband Access", Cancan Huang, GuoLiang Yang, Zhijing Peng, 10-Jan-12, Although there have already been some transition solutions and technologies, it is still lack of a complete solution for large scale broadband ISPs based on the network architecture considering service providers' requirements and constraints in the real world. This document proposes an IPv6 transitioning architecture, the FAST6, which is based on the common broadband network architecture and providing IPv6 transition solutions going through the whole transition period. "Inter-Carrier OAM Requirements", Oscar de Dios, Michael Georgiades, David Berechya, Filippo Cugini, 24-Nov-11, This draft specifies requirements for inter-carrier OAM supporting end-to-end OAM functionality and mechanisms development in a multi- operator environment. It reviews the already proposed OAM requirements addressed in IETF [RFC5706, RFC5860], ITU-T [Y.1730], MEF [MEFOAM] and IEEE [IEEE1, IEEE2] which were mainly proposed on a per transport technology basis. This document specifies additional requirements for the inter-carrier OAM operations. "Linked Cache Invalidation", Mark Nottingham, Mike Kelly, 24-Nov-11, This memo defines Web link types that invalidate HTTP caches, along with an HTTP cache-control extension that allows caches that understand those link types to use responses containing them. Together, these mechanisms offer a way to avoid use of a response that has become stale due to another request that changes server-side state. Collectively, this is referred to as Linked Cache Invalidation (LCI). "Security Implications of the Use of IPv6 Extension Headers with IPv6 Neighbor Discovery", Fernando Gont, 12-Jan-12, This document analyzes the security implications of using IPv6 Extension Headers with Neighbor Discovery (ND) messages. It updates RFC 4861 such that use of the IPv6 Fragmentation Header is forbidden in all Neighbor Discovery messages, thus allowing for simple and effective counter-measures for Neighbor Discovery attacks. Finally, it discusses the security implications of using IPv6 fragmentation with SEcure Neighbor Discovery (SEND), and provides advice such that the aforementioned security implications are mitigated. "SP URN", Penn Pfautz, 17-Feb-12, This document requests a service provider identifier URN namespace. "LDP Outbound Label Bindings Filtering", Kamran Raza, Sami Boutros, Pradosh Mohapatra, 1-May-12, The Label Distribution Protocol (LDP) allows one Label Switching Router (LSR) to advertise to another a set of "bindings" between MPLS labels and "Forwarding Equivalence Classes" (FECs). Suppose LSR2 is advertising a set of label bindings to LSR1. Frequently, LSR1 does not need to know all of LSR2's label bindings, and LSR1 may be configured to disregard bindings in which it has no interest. This document defines an "Outbound Label Bindings Filtering" (OLF) mechanism that allows LSR1 to inform LSR2 dynamically of the set of FECs for which it needs to receive label bindings. LSR2 then applies this filter before sending its label bindings to LSR1. In addition to the generic aspects of this mechanism, this document also specifies the format for the outbound label binding filter for the "Address Prefix FEC" type. "Network Configuration Protocol Light (NETCONF Light)", Juergen Schoenwaelder, Kent Watsen, Mehmet Ersue, Vladislav Perelman, 18-Jan-12, This document describes a profile of the NETCONF protocol called NETCONF Light. This profile modularizes the NETCONF protocol and allows devices to announce that they only support a subset of the NETCONF protocol operations. This is useful in situations where devices are either too resource constrained to support all NETCONF operations or where devices are gradually updated from proprietary configuration interfaces to support NETCONF. "Expand NAT TCP/UDP ports deferring IPv4 Exhaustion", Jianping Sun, 2-May-12, This document describes the TCP/UDP port extension (EPORT) model to enhance Network Address Translation (NAT)capability. EPORT based NAT helps service provider and enterprise to save mass public IPv4 addresses with enough application sessions offered at same time. "RTP Payload Format for G.711.0", Michael Ramalho, Paul Jones, Noboru Harada, Muthu Perumal, Miao Lei, 1-Mar-12, 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 two storage mode formats for G.711.0. A media type registration for this RTP payload format is also included. "GSS-EAP pre-authentication for Kerberos", Alejandro Perez-Mendez, Rafael Lopez, Fernando Pereniguez-Garcia, Gabriel Lopez-Millan, 8-Mar-12, This draft defines an alternative to the standard cross-realm operation in Kerberos, to allow users from an organization can obtain a TGT from the KDC of a different one, both belonging to the same AAA-based federation. This proposal makes use of the GSS-API pre- authentication for Kerberos and the GSS-API Mechanism for the Extensible Authentication Protocol to carry out the required functionality. "Delay-Tolerant Networking (DTN) Bundle Protocol Application Framework", Marc Blanchet, 12-Mar-12, The current Bundle Protocol specifications define the syntax of service identifiers but do not identify how to make them interoperable. For example, there are currently no way to map a service identifier to a specific Bundle payload format for an application agent. This document proposes an application framework enabling interoperable implementations and deployments of the Bundle Protocol. It also creates a service identifier registry for the Bundle Protocol. "Cloud Service Broker", Shao Weixiang, Hu Jie, Bhumip Khasnabish, 26-Mar-12, This document introduces a Cloud Service Broker (CSB) entity to provide brokering functions between different Cloud Service Providers and Cloud Service consumers. "Syslog Extension for Cloud Using Syslog Structured Data", Gene Golovinsky, Sam Johnston, Dominik Birk, 26-Mar-12, This document provides an open and extensible log format to be used by any cloud entity or cloud application to log and trace activities that occur in the cloud. The logs and traces can be utilized for billing, charging, and debugging purposes. In addition, these logs and traces are equally applicable for cloud infrastructure (IaaS), platform (PaaS), and application (SaaS) services. CloudLog is different in content, but not in nature from the traditional logging as it takes in account transient nature of Identities and resources in the cloud. "Home Agent Initiated Flow Binding for Mobile IPv6", Hidetoshi Yokota, Dae-Sun Kim, Behcet Sarikaya, Frank Xia, 22-Dec-11, There are scenarios in which the home agent needs to trigger flow binding operations towards the mobile node such as moving a flow from one access network to another based on the network resource availability. In order for the home agent to be able to initiate interactions for flow bindings with the mobile node, this document defines new signaling messages and sub-options for Mobile IPv6. Home agent initiated flow bindings are supported for both IPv4 and IPv6 enabled mobile nodes. "State Migration", Gu Yingjie, Chen Li, Kai Li, Zhuo Zhiqiang, Dacheng Zhang, 4-Mar-12, In accompany with the migration of a Virtual Machine (VM), state associated with the VM located on the Hypervisors and the network side devices (e.g., Firewalls) need to be updated in order to guarantee that the services executed on the migrated VM will not be disrupted. VM vendors have their own ways to migrate VM's state on Hypervisors, and so this is out the scope of this draft.This draft introduces the background of state migration on network devices using several application scenarios and tries to specify a clear scope for the future standardization work on state migration on network devices. "Requirements of GMPLS Extensions for Energy Efficient Traffic Engineering", Satoru Okamoto, 27-Feb-12, 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, 17-May-12, 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. "Use Cases for High Bandwidth Query and Control of Core Networks", Greg Bernstein, Young Lee, 12-Mar-12, This draft describes two generic use-cases that illustrate application layer traffic optimization applied to high bandwidth core networks. The type of information and interactions needed to perform various optimizations is described. In addition, extensions to the existing ALTO protocol are suggested that provide this functionality. "MPLS-TP Operations, Administration, and Management (OAM) Identifiers Management Information Base (MIB)", Sam Aldrin, Venkatesan Mahalingam, Kannan Sampath, Thomas Nadeau, Sami Boutros, Ping Pan, 16-Apr-12, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes Operations, Administration, and Management (OAM) identifiers related managed objects for Multiprotocol Label Switching (MPLS) based Transport Profile (TP). "Encoding of Data Structure (DS) in the Path Computation Element Communication Protocol (PCEP)", Dhruv Dhody, Udayasree Palle, 17-Feb-12, The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement for P2P and P2MP scenarios. Backward-Recursive PCE-Based Computation (BRPC) [RFC5441] defines VSPT [Virtual Shortest Path Tree] as a default de-facto data structure for PCRep message in inter-domain scenarios. AS PCE will get used in newer scenarios like inter-domain, protection, P2MP etc. As well as PCE is being explored to be used in Cross Stratrum Optimization (CSO) environment (see [CSO-PCE]). Limiting PCEP protocol to just one data structure limits the usage of PCEP. Its important to keep PCEP generic enough to use differnt data structure and apply different algorithms. This document defines extensions to the PCE communication Protocol (PCEP) to allow multiple data structures. Extensions are defined for PCE to indicate the set of Data Structure (DS) it supports; also PCC/ PCE can indicate in a path computation request the required DS, and a PCE can report in a path computation reply the Data Structure that was used in the path reply message. "Supporting explicit-path per destination in Path Computation Element Communication Protocol (PCEP) P2MP Path Request Message.", Dhruv Dhody, Udayasree Palle, 15-Feb-12, The ability to determine paths of point-to-multipoint (P2MP) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) is one the key requirements for Path Computation Element (PCE). [RFC6006] and [PCE-P2MP-PROCEDURES] describes these mechanisms for intra and inter domain environment. Explicit Path in this document refers to the configured list of network elements that MUST be traversed or MUST be excluded in the final path computation. This should not be confused with the RSVP terminology. Network elements can further be strict or loose hop. This document describes extensions to the PCE communication Protocol (PCEP) to define explicit-path per destination in P2MP context. "MPLS-TP 1toN Protection", Eric Osborne, Fei Zhang, Yaacov Weingarten, 12-Mar-12, 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 elaborated on in the MPLS-TP Survivability Framework document [SurvivFwk]. The basic protocol for linear protection was specified in the MPLS-TP Linear Protection document [LinProt] but is limited to 1+1 and 1:1 protection. This document extends the protocol defined there to address the additional functionality necessary to support scenarios of a single protection path 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. "Security Framework for Virtualized Data Center Services", Suren Karavettil, Bhumip Khasnabish, Ning So, Wei Dong, 30-Dec-11, This document discusses the requirements and technology gaps related to security in the virtualized data center services (VDCS). The objective is to ensure end-to-end security for various types of carrier services built on virtualized infrastructure. The issues covered in this draft are focused on confidentiality and integrity of the services in the virtualized environment; including but not limited to infrastructure (IaaS), platform (PaaS), and application (SaaS) services. This draft also takes into account transient nature of identity, resources and connectivity in the virtualized environment. "WebRTC Codec and Media Processing Requirements", Cary Bran, Cullen Jennings, Jean-Marc Valin, 12-Mar-12, This document outlines the codec and media processing requirements for WebRTC client application and endpoint devices. "A SNMP MIB to manage black-link optical interface parameters of DWDM applications", Ruediger Kunze, Dharini Hiremagalur, 6-Mar-12, This memo defines a portion of the Management Information Base (MIB) used by Simple Network Management Protocol (SNMP) in TCP/IP- based internets. In particular, it defines objects for managing Optical parameters associated with Wavelength Division Multiplexing (WDM) systems or characterized by the Optical Transport Network (OTN) in accordance with the Black-Link approach defined in ITU-T Recommendation G.698.2. [ITU.G698.2] The MIB module defined in this memo can be used for Optical Parameters monitoring and/or configuration of the endpoints of Black Links. "IPv6 Support Within IETF work", Wesley George, Chris Donley, Lee Howard, 21-Feb-12, This document recommends that IETF formally require its standards work to be IP version agnostic or to explicitly include support for IPv6, with some exceptions. It recommends that future IPv4 work be limited to solving documented operational problems identified through deployment experience. "A framework for Management and Control of G.698.2 optical interface parameters", Ruediger Kunze, Gert Grammel, Hans-Juergen Schmidtke, 9-Mar-12, This document provides a framework that describes a solution space for the control and management of optical interfaces parameters according to the Black Link approach as specified by ITU-T [ITU G.698.2]. In particular, it examines topological elements and related network management processes to operate this construct. This framework is scoped to address the Optical Channel (OCh)-layer covered by G.698.2. The focus is on enabling the wavelength provisioning process in a black link approach irrespective on how it is triggered i.e. by EMS, NMS or GMPLS. This document covers management as well as control plane considerations in different management cases of a single channel DWDM interface as defined by ITU-G.698.2. The purpose is to identify the necessary information elements and processes to be used by control or management devices for further processing. Hence wavelength routing and selection processes as defined e.g. in WSON are beyond the scope of this document. "Incremental Label Announcement Extensions for LDP", Alton Lo, Keyur Patel, Vanson Lim, 1-Jan-12, The current LDP Graceful Restart (GR) mechanism specified in RFC3478 requires a complete re-advertisement of the LDP label binding information across a session restart, even though complete label binding information might be preserved. In this document we specify extensions to LDP graceful restart in order to support avoiding unnecessary transmission of the label binding information preserved across a session restart, thus accelerating the router re-convergence. More specifically, we describe a version number based batching mechanism for keeping track of the label binding information across a session restart. The new 1) LDP ILA capability TLV, 2) LDP VERSION ID TLV and 3) LDP ILA Version message type, is introduced for checkpointing the label binding version maintained for a neighbor. We also specify procedures for handling label binding table version update across a session restart. "Node redundancy provisioning for VPLS Inter-domain", Zhihua Liu, Lizhong Jin, Ran Chen, 9-Mar-12, In many VPLS deployment based on [RFC4762], inter-domain has been deployed without node redundancy, or only with node redundancy in one domain. This document describes how to deploy inter-domain VPLS based on [RFC4762] with node redundancy in both domain. The draft reuses the existing protocols without introducing any new protocols. "Provisioning Credentials for CoAP Applications using EAP", Subir Das, Yoshihiro Ohba, 9-Mar-12, This document first discusses the use cases where CoAP (Constrained Application) requires a dynamic mechanism for provisioning credentials for DTLS-PSK (Pre-Shared Key) ciphersuites and PSK mode of IKEv2 and then provides an EAP (Extensible Authentication Protocol) based framework to enable such scenarios. "Applicability of LDP Label Advertisement Mode", Kamran Raza, Sami Boutros, Luca Martini, Nicolai Leymann, 13-Jan-12, An LDP speaker negotiates the label advertisement mode with its LDP peer at the time of session establishment. Although different applications sharing the same LDP session may need different modes of label distribution and advertisement, there is only one type of label advertisement mode that is negotiated and used per LDP session. This document clarifies the use and the applicability of session's negotiated label advertisement mode, and categorizes LDP applications into two broad categories of negotiated mode-bound and mode-independent applications. The document also suggests an update to RFC5036 and RFC4447 to remove any ambiguity and conflict in the area of using correct label advertisement mode for a given application. "ISATAP Updates", Fred Templin, 9-May-12, Many end user sites in the Internet today still have predominantly IPv4 internal infrastructures. These sites range in size from small home/office networks to large corporate enterprise networks, but share the commonality that IPv4 continues to provide operational 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 discusses updates to the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) to better accommodate these needs. "Energy Aware IPv6 Neighbor Discovery Optimizations", Samita Chakrabarti, Erik Nordmark, Margaret Wasserman, 12-Mar-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 and machine-to-machine communications, there is a desire for optimizing legacy IPv6 Neighbor Discovery protocol to be more efficient in terms of number of signaling messages in the network. Efficient IPv6 Neighbor Discovery is useful for energy-efficient networks and as well for overlay networks such as VLANs with large number of nodes. This document describes a method of optimizations by reducing periodic multicast messages, frequent Neighbor Solicitation messages and discusses interoperability with legacy IPv6 nodes. It also addresses the ND denial of service issues by introducing node Registration procedure. "Issues in Identifier Comparison for Security Purposes", Dave Thaler, 8-May-12, Identifiers such as hostnames, URIs, and email addresses are often used in security contexts to identify security principals and resources. In such contexts, an identifier supplied via some protocol is often compared against some policy to make security decisions such as whether the principal may access the resource, what level of authentication or encryption is required, etc. If the parties involved in a security decision use different algorithms to compare identifiers, then failure scenarios ranging from denial of service to elevation of privilege can result. "RBridges: TRILL Link Data Optimizations", Radia Perlman, Donald Eastlake, Anoop Ghanwani, 14-Jan-12, Under certain circumstances, it is possible to encode TRILL (TRansparent Interconnection of Lots of Links) Data frames so as to make more efficient use of communications links. This document specifies two such optional optimizations. One, called Compact Format, improves the compactness of encoding in the case where a TRILL link is a point-to-point Ethernet link. The other, called Specific Addressing, optionally decreases the burden on multi-access TRILL links for multi-destination TRILL Data frames under some circumstances. This document updates RFC 6325. "In-Band Authentication Extension for Protocol Independent Multicast (PIM)", Manav Bhatia, Dacheng Zhang, 8-Mar-12, Existing security mechanisms for the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol mandates to use 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 is not applied. "Non-Normative Synonyms in RFCs", Tony Hansen, Dave Crocker, 16-May-12, Specifications in RFCs contain normative keywords, as defined in RFC 2119, to signify requirements, permission or prohibitions. These include MUST, SHOULD and MAY, which are commonly recorded in all CAPITALS (but need not be). The words are sometimes also intended with non-normative meaning; this different usage can be confusing. Happily there are adequate alternatives for non-normative meanings. For such situations, this document provides some alternatives to the normative vocabulary of RFC 2119. "User-Managed Access (UMA) Core Protocol", Thomas Hardjono, 1-Apr-12, This specification defines the User-Managed Access (UMA) core protocol. This protocol provides a method for users to control access to their protected resources, residing on any number of host sites, through an authorization manager that governs access decisions based on user policy. "Motivation for developing Stateless Automatic IPv4 over IPv6 Encapsulation / Decapsulation Technology (SA46T)", Naoki Matsuhira, 3-Jan-12, This document describe a motivation for developing IPv4 over IPv6 encapsulation / decapsulation solution from standing position of Stateless Autimatic IPv4 over IPv6 Encapsulation / Decapsulation Technology (SA46T) and SA46T with address sharing (SA46T-AS). "Cisco Specific Information Elements reused in IPFIX", Andrew Yourtchenko, Paul Aitken, Benoit Claise, 12-Mar-12, This document describes some additional Information Elements of Cisco Systems, Inc. that are not listed in RFC3954. "Guidance for Light-Weight Implementations of the Internet Protocol Suite", Carsten Bormann, 24-Jan-12, Implementation of Internet protocols on small devices benefits from light-weight implementation techniques, which are often not documented in an accessible way. This document provides a first outline of and some initial content for the Light-Weight Implementation Guidance document planned by the IETF working group LWIG. "Best practices for HTTP-CoAP mapping implementation", Angelo Castellani, Salvatore Loreto, Akbar Rahman, Thomas Fossati, Esko Dijk, 27-Apr-12, This draft aims at being a base reference documentation for HTTP-CoAP proxy implementors. It details deployment options, discusses possible approaches for URI mapping, and provides useful considerations related to protocol translation. "Multicast Filtering Practices", Tim Chown, Leonard Giuliano, 12-Mar-12, Operators of multicast networks may apply various filters to multicast traffic at boundary routers or on MSDP peerings. The aim of this text is to discuss appropriate filtering policies, as well as documenting existing filtering practices, with a view to generating some discussion towards producing guidance on best filtering practice. "RSVP-TE Extensions for Lock Instruct and Loopback in MPLS Transport Profile", Jie Dong, Mach Chen, Zhenqiang Li, 8-Mar-12, This document specifies extensions to RSVP-TE to support lock instruct and loopback mechanism for MPLS-TP LSPs. The mechanisms are intended to be applicable to other aspects of MPLS as well. "Directory Assisted RBridge Edge", Linda Dunbar, Donald Eastlake, Radia Perlman, Igor Gashinsky, 11-Mar-12, RBridge edge nodes currently learn the mapping between MAC addresses and their corresponding RBridge edge nodes by observing the data packets traversed through. When ingress RBridge receives a data packet with its destination address (MAC&VLAN) unknown, the data packet is flooded across RBridge domain. When there are more than one RBridge ports connected to one bridged LAN, only one of them can be designated as AF port for forwarding/receiving traffic for each LAN, the rest have to be blocked for that LAN. This draft describes the framework of using directory assisted RBridge edge to improve TRILL network scalability in data center environment. "Multiple Topology TRILL", Donald Eastlake, Mingui Zhang, Radia Perlman, Ayan Banerjee, Vishwas Manral, 10-Jan-12, The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol is a solution for least cost transparent frame routing in multi-hop networks with arbitrary topologies and link technologies, using IS-IS (Intermediate System to Intermediate System) link-state routing and encapsulation with a hop count. IS-IS supports multiple topology routing. This document specifies a TRILL data plane encoding and procedures to make use of such routing. "RBridge: Pseudo-Nickname", ZTE Corporation, fangwei hu, Radia Perlman, Donald Eastlake, 15-May-12, At the edg of TRILL campus, some RBridges provide end-station services to their attached end stations, these RBridges are called edge RBridges. To avoid potential frame duplication or loops in TRILL campus, only one edge RBridge is permitted to provide end- station services in a VLAN x at all times for its attached end stations. However, in some application scenarios, for example in Link Aggregation Group (LAG), more than one edge RBridge is required to provide end-station services to an end stations even in a VLAN, which causes the flip-flopping of the egress RBridge nickname for such an end node in remote RBridges' forwarding tables if nothing to do. In this document, the concept of Virtual RBridge, along with its pseudo-nickname, is introduced to fix the above problem. "TRILL: The ESADI Protocol", ZTE Corporation, fangwei hu, Radia Perlman, Donald Eastlake, 11-Apr-12, The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides least cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topologies and link technologies. TRILL supports the multi-pathing of both unicast and multicast traffic. Devices that implement the TRILL protocol are called RBridges (Routing Bridges) or TRILL Switches. The ESADI (End System Address Distribution Information) protocol is a VLAN (Virtual Local Area Network) scoped way that TRILL switches can communicate end station addresses to each other. An RBridge announcing VLAN-x connectivity (normally a VLAN-x appointed forwarder) and running the TRILL ESADI protocol can receive remote address information and/or transmit local address information for VLAN-x to other such RBridges. This document updates RFC 6325, specifically the documentation of the ESADI protocol. "CLEFIA Cipher Suites for Transport Layer Security (TLS)", Masanobu Katagi, 2-May-12, This document specifies a set of cipher suites for the Transport Security Layer (TLS) protocol to support the CLEFIA encryption algorithm as a block cipher. CLEFIA is a lightweight block cipher and suitable for constrained devices. "Some Measurements on World IPv6 Day from End-User Perspective", Ari Keranen, Jari Arkko, 4-Jan-12, During the World IPv6 Day on June 8th, 2011, several key content providers enabled their networks to offer both IPv4 and IPv6 services. Hundreds of organizations participated in this effort, and in the months and weeks leading up to the event worked hard on preparing their networks to support this event. The event was largely unnoticed by the general public, which is a good thing since it means that no major problems were detected. For the Internet, however, there was a major change on such a small timescale. This memo discusses measurements that the authors made from the perspective of an end-user with good IPv4 and IPv6 connectivity. Our measurements include the number of most popular networks providing AAAA records for their service as well as delay and connection failure statistics. "PMIP Based DMM Approaches", Dapeng Liu, Jun Song, Wen Luo, 12-Mar-12, This draft discusses a pmip based DMM solution "WSON Optical Interface Class", Giovanni Martinelli, Gabriele Galimberti, Lyndon Ong, Daniele Ceccarelli, Cyril Margaria, 6-Mar-12, Current work on wavelength switched optical network includes several considerations regarding the interface signal compatibility. In particular ingress and egress optical interfaces will require a check on several optical parameters to assess if the signal generated by the ingress interface can be compatible with the receiving interface. Current solution available encode all parameters in WSON protocol extensions while in this draft will propose an alternative method to keep into account the signal compatibility issue at protocol level. "Mutual Authentication Protocol for HTTP: KAM3-based Cryptographic Algorithms", Yutaka Oiwa, Hajime Watanabe, Hiromitsu Takagi, Tatsuya Hayashi, Yuichi Ioku, 18-May-12, This document specifies some cryptographic algorithms which will be used for the Mutual user authentication method for the Hyper-text Transport Protocol (HTTP). "Real-time Transport Control Protocol (RTCP) in Overlay Multicast", Varun Singh, Jegadish Devadoss, Joerg Ott, Igor Curcio, 8-Mar-12, The Real-time Transport Control Protocol(RTCP) is designed to operate along with Real-time Transport Protocol(RTP) in unicast, single- source multicast and any-source multicast environments. With the availability of overlay multicast and Application Layer Multicast(ALM), the suitability of RTCP in such environments need to be analyzed. The applicability of the existing RTCP reporting architectures in overlay multicast and ALM environments are investigated and the new features that may be required are discussed in this document. "DMM Comparison Matrix", Charles Perkins, Dapeng Liu, Wen Luo, 12-Mar-12, Distributed Mobility Management (DMM) is proposed as a way to enable scalable growth of mobile core networks so that network service providers can meet new requirements for performance and reduced operational expenditures. This requires reconsideration of existing approaches within the IETF and elsewhere in order to determine which if any such approaches may be used as part of a DMM solution. "Pseudowire Communities", Paul Kwok, Pranjal Dutta, Frederic JOUNAY, 20-May-12, [RFC4447]describes a set of procedures for Pseudowire set-up and maintenance using LDP as signaling protocol. [I-D.ietf-pwe3-dynamic-ms-pw] extends the mechanisms described in [RFC4447] for dynamic placement of multi- segment pseudowires. This document describes an extension to [RFC4447]procedures which may be used to pass additional information to S-PE/T-PEs when SS-PWs or MS-PWs are set-up. The intention of the proposed technique is to aid in policy administration, specifically during MS-PW set-up across various S-PEs. The proposed method is very generic so that it can support the management of various parameters or rules while setting up pseudowires with minimal overhead. "The Generalized Object Encoding (GOE) Approach for the Forward Erasure Correction (FEC) Protection of Objects and its Application to Reed- Solomon Codes over GF(2^^8)", Vincent Roca, Aline Roumy, Bessem Sayadi, 9-Mar-12, This document describes a Generalized Object Encoding (GOE) approach for the protection of one or multiple objects, in the context of a Content Delivery Protocol (CDP) like FLUTE/ALC, FCAST/ALC or FCAST/ NORM. Unlike [RFC5052], the GOE approach [GOE] decouples the definition of Generalized Objects over which FEC encoding takes place homogeneously, from the natural source object boundaries. This separation enables either an Unequal Erasure Protection (UEP) of different portions of a given source object, or an efficient and global protection of a set of potentially small files, depending on the way the Generalized Objects are defined. The present document first of all introduces the GOE approach. Then it defines the GOE Reed-Solomon FEC Scheme for the particular case of Reed-Solomon codes over GF(2^^8) and no encoding symbol group, the GOE equivalent to FEC Encoding ID 5 defined in RFC5510. "IPv6 Rapid Deployment (6rd) in a Large Data Center", Shishio Tsuchiya, Mark Townsley, Shuichi Ohkubo, 12-Mar-12, IPv6 Rapid Deployment (6rd) as defined in RFC 5969 focuses on rapid deployment of IPv6 by an access service provider which has difficulty deploying native IPv6. This document describes how 6rd can be used to deliver IPv6 within a Large Data Center. "Application Bridging for Federated Access Beyond web (ABFAB) Usability and User Interface Considerations", Rhys Smith, 29-Mar-12, The use of ABFAB-based technologies requires that each user's machine is configured with the user's identities. This will require something on that machine which will manage the user's identities and services. 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 consistency. "Extensions of Probabilistic Routing Protocol for Intermittently Connected Networks", Seok-Kap Ko, Ilkyun Park, Seung-Hun Oh, Byoung-Tak Lee, Yun Chung, 11-Mar-12, This document defines extensions of PRoPHET, a Probabilistic Routing Protocol using History of Encounters and Transitivity. The document presents two extensions of current PRoPHET draft-09. The first extension is to apply the contact duration to calculate the delivery predictability. The other is to provide a forward strategy which can alleviate the bundle starving problem by considering expiration of bundles. "Additional IPv4 Delegations for AS112 Nameservers", William Sotomayor, George Michaelson, Geoff Huston, Joe Abley, 4-Apr-12, This is a direction to IANA concerning the delegation of certain additional IPv4 zones to the AS112 project. "BGPSEC Design Choices and Summary of Supporting Discussions", Kotikalapudi Sriram, 5-Jan-12, This document has been written to capture the design rationale for the draft-00 version of BGPSEC protocol specification (I-D.ietf-sidr- bgpsec-protocol-00). It lists the decisions that have been made in favor of or against each design choice, and presents brief summaries of the arguments that aided the decision process. A similar document can be published in the future as the BGPSEC design discussions make further progress and additional design considerations are discussed and finalized. "Multipath Extensions for MPLS Traffic Engineering", Curtis Villamizar, 27-Feb-12, Extensions to OSPF-TE, ISIS-TE, and RSVP-TE are defined in support of carrying LSP with strict packet ordering requirements over multipath and and carrying LSP with strict packet ordering requirements within LSP without violating requirements to maintain packet ordering. LSP with strict packet ordering requirements include MPLS-TP LSP. OSPF-TE and ISIS-TE extensions defined here indicate node and link capability regarding support for ordered aggregates of traffic, multipath traffic distribution, and abilities to support multipath load distribution differently per LSP. RSVP-TE extensions either identifies an LSP as requiring strict packet order, or identifies an LSP as carrying one or more LSP that requires strict packet order at a given depth in the label stack, or identifies an LSP as having no restrictions on packet ordering except the restriction to avoid reordering microflows. In addition an extension indicates whether the first nibble of payload will reliably indicate whether payload is IPv4, IPv6, or other type of payload, most notably pseudowire using a pseudowire control word. "Context Transfer Protocol Extension for Multicast", Dirk Hugo, Hitoshi Asaeda, 9-Jan-12, This document describes an extension of the Context Transfer Protocol (CXTP) to support seamless IP multicast services with Proxy Mobile IPv6 (PMIPv6). "Federated Cross-Layer Access", Yinxing Wei, 12-Mar-12, Network stratum and application stratum form a federation to faciliate user's access. Network operator acts as Identity Provider (IdP), and application reuses underlying network's security capabilities to simlify application's access. This document is to introduce such federated cross-layer access use case and message flows. "Maximum Transmission Unit Extended Community for BGP-4", Qing Zeng, Jie Dong, 8-Mar-12, Proper functioning of path Maximum Transmission Unit (MTU) discovery [RFC1191] requires that IP routers have knowledge of the MTU for each link to which they are connected. As MPLS progresses, [RFC3988] specifies extensions to LDP in support of LDP LSP MTU discovery. For the LSP created using Border Gateway Protocol (BGP) [RFC3107], it does not have the ability to signal the path MTU to the ingress Label Switching Router (LSR). In the absence of this functionality, the MTU for the BGP LSP must be statically configured by network operators or by equivalent off-line mechanisms. This document defines the MTU Extended Community for BGP in support of BGP LSP MTU discovery. "Native IPv6 Behind NAT44 CPEs (6a44)", Remi Despres, Brian Carpenter, Dan Wing, Sheng Jiang, 23-Apr-12, In customer sites having IPv4-only CPEs, Teredo provides a last resort IPv6 connectivity [RFC4380] [RFC5991] [RFC6081]. However, because it is designed to work without involvement of Internet service providers, it has significant limitations (connectivity between IPv6 native addresses and Teredo addresses is uncertain; connectivity between Teredo addresses fails for some combinations of NAT types). 6a44 is a complementary solution that, being base on ISP cooperation, avoids these limitations. 6a44 uses specific prefixes assigned by local ISPs (rather than the anycast address used by Teredo, an evolution similar to that from 6to4 to 6rd). The specification is complete enough for actual deployment, including with independently written codes. "Mediated RSA cryptography specification for additive private key splitting (mRSAA)", Miroslaw Kutylowski, Przemyslaw Kubiak, Michal Tabor, Daniel Wachnik, 28-Apr-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]. "Adapted Multimedia Internet KEYing (AMIKEY): An extension of Multimedia Internet KEYing (MIKEY) Methods for Generic LLN Environments", Roger Alexander, Tzeta Tsao, 12-Mar-12, Multimedia Internet Keying (MIKEY) is a key management protocol used for real-time applications. As standardized within RFC3830 it defines four key distribution methods, including pre-shared keys, public-key encryption, and Diffie-Hellman key exchange, with allowances for ready protocol extension. A number of additional methods have been developed and continue to be built from the base protocol (see for example, RFC4442, RFC4563, RFC4650, RFC4738, RFC5410, RFC6043 and RFC6267. However, in spite of its extensibility and more general applicability, MIKEY and its related extensions have primarily focused on the support of the Secure Real-time Transport Protocol (SRTP). This document specifies a simple adaptation of the MIKEY specification to allow the base protocol and its various key management mode extensions to be readily applied in more general environments beyond the multimedia SRTP domain. In particular, the document defines a repurposing of the MIKEY multimedia crypto sessions structure and introduces a set of message extensions to the base specification to allow the MIKEY key management methods to be applied within Low-power and Lossy networks (LLNs) and other general constrained-device networks. "The Universal Voting Markup Language (UVML)", Erin Phillips, 7-Jan-12, This document describes the Universal Voting Markup Language (UVML), a syntax for the structured representation of opinion in free text. Using UVML, opinions can be encoded in text, image, or video, and reliably interpreted by either human readers or automated-agents. UVML supports both rating and ranking semantics. Ratings may be scored using symbols associated with the five most commonly used opinion dimensions: quality(*), importance(!), outlook($), support- opposition(+), and likelihood(%). In addition, UVML defines a syntax for optionally including a demographic signature by which voters can publish basic demographic information with their UVML votes. The design of UVML leverages cross-cultural sentiment and voting-systems scholarship. "Scalable BGP FRR Protection against Edge Node Failure", Ahmed Bashandy, Burjiz Pithawala, Keyur Patel, 5-Mar-12, Consider a BGP free core scenario. Suppose the edge BGP speakers PE1, PE2,..., PEn know about a prefix P/m via the external routers CE1, CE2,..., CEm. If the edge router PEi crashes or becomes totally disconnected from the core, it is desirable for a core router "P" carrying traffic to the failed edge router PEi to immediately restore traffic by re-tunneling packets originally tunneled to PEi and destined to the prefix P/m to one of the other edge routers that advertised P/m, say PEj, until BGP re-converges. In doing so, it is highly desirable to keep the core BGP-free while not imposing restrictions on external connectivity. Thus (1) a core router should not be required to learn any BGP prefix, (2) the size of the forwarding and routing tables in the core routers should be independent of the number of BGP prefixes,(3) there should be no special router (or group of routers) that handles restoring traffic or the need for one router to store the forwarding table of another router, (4) re-routing traffic without waiting for re-convergence must not cause loops, and (4) there should be no restrictions on what edge routers advertise what prefixes. For labeled prefixes, (6) the repairing core router must swap the label stack advertised by the failed edge router PEi for the prefix P/m with the label stack advertised for the same prefix by the edge router PEj before re- tunneling the packet to PEj "PW Endpoint Fast Failure Protection", Yimin Shen, Rahul Aggarwal, Wim Henderickx, 27-Feb-12, This document specifies a fast protection mechanism for pseudowires (PWs) against egress attachment circuit (AC) failure, egress PE failure, and 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 immediately upon a failure. In particular, the router at point of local repair (PLR) can redirect PW traffic to a protector via a bypass LSP in the order of tens of milliseconds, achieving fast protection that is comparable to RSVP fast-reroute. "Version Number and Rank Authentication", Amit Dvir, Laszlo Dora, Levente Buttyan, Tamas Holczer, 9-Jan-12, Designing a routing protocol for large low-power and lossy networks (LLNs), consisting of thousands of constrained nodes and unreliable links, presents new challenges. The IPv6 Routing Protocol for Low- power and Lossy Networks (RPL), have been developed by the IETF ROLL Working Group as a preferred routing protocol to provide IPv6 routing functionality in LLNs. Unfortunately, the currently available security services in RPL will not protect against a compromised internal node that can construct and disseminate fake messages. Therefore, in RPL special security care must be taken when the Destination Oriented Directed Acyclic Graph (DODAG) root is updating the Version Number by which reconstruction of the routing topology can be initiated. The same care also must be taken to prevent an internal attacker (compromised DODAG node) to publish decreased Rank value, which causes a large part of the DODAG to connect to the DODAG root via the attacker and give it the ability to eavesdrop or manipulate a large part of the network traffic. In this document, a new security service is described that prevents any misbehaving DODAG node from illegitimately increasing the Version Number or publish illegitimately decreased Rank values. "Generalized Label for Super-Channel Assignment on Flexible Grid", Iftekhar Hussain, Abinder Dhillon, Zhong Pan, Marco Sosa, Bert Basch, Steve Liu, Andrew Malis, 11-Mar-12, 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). "6bed4: Peer-to-Peer IPv6 on Any Internetwork", Rick van Rein, 11-Mar-12, The intention of 6bed4 is to support IPv6-only applications, even on IPv4-only networks. A specific area of concern is that of peer-to- peer protocols such as SIP or document exchange during a chat session. Such protocols are designed to run in any environment, which means that they cannot rely on IPv6 for themselves, or their peers. The 6bed4 tunnel mechanism ensures that IPv6 can be assumed on all peers, without a need to configure it explicitly. The 6bed4 mechanism is meant as a fallback mechanism for IPv6 connectivity on networks that do not support it natively, by running a tunnel over UDP and IPv4. The IPv4 address is used to support traceability of the traffic originator, which means that no user account or other configuration is needed. The tunnel mechanism builds on existing IPv6 mechanisms; it employs Stateless Address Autoconfiguration [RFC4862] to setup an IPv6 address on a 6bed4 Peer, and Neighbor Discovery [RFC4861] to find the most direct route to a remote 6bed4 Peer. "Loss and Delay Traffic Engineering Framework for MPLS", Xihua Fu, Vishwas Manral, Dave McDysan, Andrew Malis, Spencer Giacalone, Malcolm Betts, Qilei Wang, John Drake, 11-Apr-12, With more and more enterprises using cloud based services, the distances between the user and the applications are growing. A lot of the current applications are designed to work across LAN's and have various inherent assumptions. For multiple applications such as High Performance Computing and Electronic Financial markets, the response times are critical as is packet loss, while other applications require more throughput. [RFC3031] describes the architecture of MPLS based networks. This draft extends the MPLS architecture to allow for latency, loss and jitter as properties. It describes requirements and control plane implication for latency and packet loss as a traffic engineering performance metric in today's network which is consisting of potentially multiple layers of packet transport network and optical transport network in order to make a accurate end-to-end latency and loss prediction before a path is established. Note MPLS architecture for Multicast will be taken up in a future version of the draft. "Energy Management Terminology", John Parello, 12-Mar-12, 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, 23-Nov-11, This document specifies the guidelines for designing efficient composite routing metrics to be applied to the Routing for Low Power and Lossy Networks (RPL) routing protocol. "Default Router List Option for DHCPv6 (DRLO)", Alexandru Petrescu, Christophe Janneteau, Maximilien Mouton, 12-Mar-12, Neighbor Discovery protocol is currently considered as the best way for providing a default router to a client in IPv6 networks, typically using a Default Router List. Hence it was not considered necessary for DHCPv6 to have this feature. But, recently, some deployment scenarios expressed a need not to use Neighbor Discovery mechanisms. This draft specifies a new DHCPv6 option providing data necessary for a Client's Default Router List (address, lifetime, MAC address) (indirectly, through the Neighbour Cache). "Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs", Ping Pan, Rajiv Asati, Carlos Pignataro, 6-Dec-11, Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute mechanisms are commonly used to detect and isolate data plane failures in all MPLS LSPs including Pseudowire (PW) LSPs. The PW LSP Ping and Traceroute elements, however, are not specified for IPv6 address usage. This document extends the PW LSP Ping and Traceroute mechanisms so they can be used with IPv6 PWs, and updates RFC 4379. "Path Computation Element (PCE) Communication Protocol (PCEP) TCP port number changes", Vishwas Manral, 16-Apr-12, Path Computation Element (PCE) Communication Protocol (PCEP) defined in [RFC 5440] states that "All PCEP messages MUST be sent using the registered TCP port for the source and destination TCP port." This has however lead to a lot of restrictions for the implementation. With these considerations in mind this document updates the TCP behavior. "Miscellanoues Capabilities Negotiation in the Session Description Protocol (SDP)", Miguel Garcia, Simo Veikkolainen, Robert Gilman, 1-Mar-12, 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). "The Port Control Protocol in Dual-Stack Lite environments", Francis Dupont, Tina Tsou, Jacni Qin, 2-May-12, This document specifies the so-called "plain mode" for the use of the Port Control Protocol (PCP) in Dual-Stack Lite (DS-Lite) environments. "An Extension Language for the DNS", John Levine, 7-May-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 a line to a configuration file read by the DNS software, with no changed software. "The Continue Header Field for the Session Initiation Protocol (SIP)", Amardeep Sinha, Subhrajyoti De, Sunil Sinha, 2-Apr-12, Before placing a call, it is quite often useful for the Caller to know whether a Callee is in favorable state to receive a call or not. This document defines an optional tag "continue" and a header "Continue" to address the purpose. The "Continue" header field is to confirm the session continuity with the Callee from the Caller after an option for session continuity is placed by the Callee based on the unfavorable state of the Callee. This functionality is needed to resolve the unwillingness of the Callee to receive any call. An option is given to the Callee by the Service Provider or by the Handset Manufacturer or by the Carrier to establish this requirement. "A Method for Sharing Record Protocol Keys with a Middlebox in TLS", Yoav Nir, 26-Mar-12, This document contains a straw man proposal for a method for sharing symmetric session keys between a TLS client and a middlebox, so that the middlebox can decrypt the TLS-protected traffic. This method is an alternative to the middlebox becoming a proxy. "VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", T. Sridhar, Mike Bursell, Lawrence Kreeger, Dinesh Dutt, Chris Wright, Mallik Mahalingam, Kenneth Duda, Puneet Agarwal, 24-Feb-12, This document describes Virtual eXtensible Local Area Network (VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in cloud service provider and enterprise data center networks. "OAM tool for RBridges: Multi-destination Ping", Li Yizhou, Hao Weiguo, David Bond, Vishwas Manral, 3-May-12, Unicast and multi-destination data frame may follow the different path in TRILL network. We need the ping and traceroute like applications for the connectivity testing and fault isolation on the multi-destination path in addition to the unicast path. This document specifies the format and handling of the new TRILL OAM protocol messages and TLVs which can be used for the multi-destination OAM. "NFSv4.0 migration: Implementation experience and spec issues to resolve", Bill Baker, Charles Lever, David Noveck, Piyush Shivam, 16-Jan-12, The migration feature of NFSv4 provides for moving responsibility for a single filesystem from one server to another, without disruption to clients. Recent implementation experience has shown problems in the existing specification for this feature. This document discusses the issues which have arisen and explores the options available for curing the issues via clarification and correction of the NFSv4.0 specification. "Session Initiation Protocol (SIP) Rate Control", Eric Noel, Philip Williams, 12-Dec-11, The prevalent use of Session Initiation Protocol (SIP) [RFC3261] in Next Generation Networks necessitates that SIP networks provide adequate control mechanisms to maintain transaction throughput by preventing congestion collapse during traffic overloads. Already [draft-ietf-soc-overload-control-05] proposes a loss-based solution to remedy known vulnerabilities of the [RFC3261] SIP 503 (service unavailable) overload control mechanism. This document proposes a rate-based control solution to complement the loss-based control defined in [draft-ietf-soc-overload-control-05]. "A Google Congestion Control Algorithm for Real-Time Communication on the World Wide Web", Henrik Lundin, Stefan Holmer, Harald Alvestrand, 25-Apr-12, This document describes two methods of congestion control when using real-time communications on the World Wide Web (RTCWEB); one sender- based and one receiver-based. It is published to aid the discussion on mandatory-to-implement flow control for RTCWEB applications; initial discussion is expected in the RTCWEB WG's mailing list. "Extensions to the Path Computation Element Communication Protocol (PCEP) to compute service aware Label Switched Path (LSP).", Dhruv Dhody, Vishwas Manral, 14-Dec-11, In certain networks like financial information network (stock/ commodity trading) and enterprises using cloud based applications, Latency (delay), Latency-Variation (jitter) and Packet loss is becoming a key requirement for path computation along with other constraints and metrics. Latency, Latency-Variation and Packet Loss is associated with the Service Level Agreement (SLA) between customers and service providers. [MPLS-DELAY-FWK] describes MPLS architecture to allow latency, loss and jittering as properties. [OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS] describes mechanisms with which network performance information is distributed via OSPF and ISIS respectivily. This document describes the extension to PCEP to carry Latency, Latency-Variation and Loss as constraints for end to end path computation. "Security option extensions for DHCPv4", Emily Bi, Serge Manning, Marcus Wong, Yang Cui, 11-Mar-12, This document defines a new option that can be used by DHCP servers to exchange with DHCP clients specific security configuration information. This new option defines a standard parameter format and code so that there will be no ambiguity in interoperating the information being exchanged and that there will be no issues related to interoperability. It is an option definition extension for DHCPv4 which should be included in RFC 2132. "North-Bound Distribution of Link-State and TE Information using BGP", Hannes Gredler, Adrian Farrel, Jan Medved, Stefano Previdi, 12-Mar-12, In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including traffic engineering information. This is information typically distributed by IGP routing protocols within the network This document describes a mechanism by which links state and traffic engineering information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual links. The mechanism described is subject to policy control. Applications of this technique include Application Layer Traffic Optimization (ALTO) servers, and Path Computation Elements (PCEs). "SA46T Multicast Support", Naoki Matsuhira, 26-Mar-12, 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. "Feature Analysis Tool for stateless IPv4/IPv6 (MAP-T, MAP-E, 4rd)", Remi Despres, Simon Perreault, Jing Huang, 12-Mar-12, This document proposes a discussion tool for the Softwire meeting at IETF 83 in Paris. Significant differentiating features between the MAP approach (proposed standards MAP-T and MAP-E) and the unified approach (proposed standard 4rd) are presented in tabular format. Its purpose is to facilitate decision making, and is therefore temporary. "Implementing A+P in the provider's IPv6-only network", Xiaohong Deng, Mohammed Boucadair, Yiu Lee, Xiaohong Huang, Qin Zhao, 3-Mar-12, This memo describes an implementation of A+P in a provider's IPv6- only network. It provides details of the implementation, network elements, configurations and test results as well. Besides traditional port range A+P, a scattered port sets flavor of A+P is also implemented to verify feasibility of offering non-continuous port sets with A+P approach. The test results consist of the application compatibility test, UPnP 1.0 extensions and UPnP 1.0 friendly port allocation for A+P, port usage and BitTorrent behaviors with A+P. This memo focuses on the IPv6 flavor of A+P. "Client Link-layer Address Option in DHCPv6", Gaurav Halwasia, Cisco Systems, Wojciech Dec, 12-Mar-12, This document specifies the format and mechanism that is to be used for encoding client link-layer address in DHCPv6 messages by defining a new DHCPv6 Client Link-layer Address option. "Deterministic Address Mapping to Reduce Logging in Carrier Grade NAT Deployments", Chris Donley, Chris Grundemann, Vikas Sarawat, Karthik Sundaresan, 26-Mar-12, Many Carrier Grade NAT solutions require per-connection logging. Unfortunately, such logging is not scalable to many residential broadband services. This document suggests a way to manage Carrier Grade NAT translations in such a way as to significantly reduce the amount of logging required while providing traceability for abuse response. "TFRC-based Congestion Control for Saratoga", Wesley Eddy, Lloyd Wood, Will Ivancic, 26-Mar-12, 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, 26-Mar-12, 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. "Update of and Clarification to IANA Policy Definitions in BCP 26", Barry Leiba, 24-Apr-12, Section 4.1 of BCP 26 (RFC 5226) discusses possible IANA registration policies that might be used in documents with IANA actions, and defines some well-known policy terms. This document clarifies the usage of these terms, and discourages the use of overly restrictive registration policies. The author is working with IANA on an update to BCP 26, and this document's contents will be folded into that effort. While that's in process, this draft will be kept alive for reference. "DHCP Options for 3GPP Service", Guoyan Liu, Yangwei Tu, Chunhui Zhu, Wim Henderickx, Daniel Derksen, Laurent Thiebaut, 11-Mar-12, 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, 5-Mar-12, This document defines a new option that can be used by DHCP clients to send to DHCP servers. This new option includes some sub-options. It also defines standard parameter format and code so that there will be no ambiguity in interoperating the information being exchanged. It may be used for scenarios interworking with non-3GPP and 3GPP network. "Infrastructure Overlay", Marc Petit-Huguenin, 12-Mar-12, This document provides requirements for infrastructure overlays, a special kind of peer-to-peer overlay whose main purpose would be defeated if more than one instance would exist on the Internet. "Mesh Link Establishment", Richard Kelsey, 17-May-12, This document defines the mesh link establishment (MLE) protocol for establishing and configuring secure links in an ad hoc mesh radio network. Effective mesh networking using radio links requires identifying, configuring, and securing usable links to neighboring devices. In an ad hoc mesh network a device's neighbors may come and go as the network's membership and physical environment change. Newly usable links need to be identified and configured automatically, where configuration values can include link-layer addresses, transmit and receive modes, security parameters, and so forth. MLE includes the option of securing the configuration messages themselves, as link-layer security is typically not available prior to configuration. "The MessageBroker WebSocket Subprotocol", Mark Hapner, Clebert Suconic, 27-Mar-12, The WebSocket protocol [I-D.ietf-hybi-thewebsocketprotocol] provides a subprotocol extension facility. The MessageBroker WebSocket Subprotocol (MBWS) is a WebSocket Subprotocol used by messaging clients to send messages to, and receive messages from an internet message broker (herein called a message broker). A message broker is a messaging intermediary that queues messages sent by its clients for asynchronous delivery to its clients. Messages are addressed to message-broker-specific address names. Clients send messages to addresses and consume messages from addresses. Clients do not send messages directly to other clients. Message brokers provide a range of functionality that is outside the scope of MBWS. Typically an internet message broker provides a REST API for working with this functionality; such as configuring client credentials; setting client access controls; configuring address routing; etc. MBWS limits its scope to the definition of a WebSocket subprotocol that provides a full duplex, reliable message transport protocol between message brokers and their clients; and, between message brokers. Since reliable message transport is often independent of a broker's particular features, MBWS can be used as the message transport protocol for a wide range of message brokers. The MBWS subprotocol defines a binary message frame and a text message frame. Both types of frame carry the same protocol; however, the protocol bindings differ slightly. The binary frame is a WebSocket binary message that contains an MBWS binary header followed by a binary message body. The text frame is a WebSocket UTF-8 text message that contains an MBWS text header followed by a text message body. "Lightweight Directory Access Protocol (LDAP): Schema for Printer Services", Pat Fleming, Ira McDonald, 20-May-12, 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.JPS3), and IEEE-ISTO PWG IPP Everywhere (PWG 5100.EVE). "Software-Defined Network (SDN) Problem Statement and Use Cases for Data Center Applications", Ping Pan, Thomas Nadeau, 12-Mar-12, Software Defined Network (SDN) is an overlay architecture that presents the underlying transport network to the applications and services for monitoring, and provisioning at abstraction level. In this memo, we outline some of the problems, and present an architecture outline. We will present a few applications to validate the problems and the architecture framework. "IPv6 Prefix Assignment in Small Networks", Fred Baker, Ralph Droms, 7-Mar-12, It is necessary to allocate prefixes in small networks, which include residential and Small Office/Home Office (SOHO) networks in a manner that minimizes or eliminates manual configuration. This note suggests an approach. "Multihoming with IPv6-to-IPv6 Network Prefix Translation (NPTv6)", Ronald Bonica, Fred Baker, Margaret Wasserman, Gregory Miller, Warren Kumari, 13-Apr-12, RFC 6296 introduces IPv6-to-IPv6 Network Prefix Translation (NPTv6). By deploying NPTv6, a site can achieve addressing independence without contributing to excessive routing table growth. Section 2.4 of RFC 6296 proposes an NPTv6 architecture for sites that are homed to multiple upstream providers. By deploying the proposed architecture, a multihomed site can achieve access redundancy and load balancing, in addition to addressing independence. This memo proposes an alternative NPTv6 architecture for hosts that are homed to multiple upstream providers. The architecture described herein provides transport-layer survivability, in addition to the benefits mentioned above. In order to provide transport-layer survivability, the architecture described herein requires a small amount of additional configuration. This memo updates RFC 6296. "Secure Password Ciphersuites for Transport Layer Security (TLS)", Dan Harkins, Dave Halasz, 8-Mar-12, This memo defines several new ciphersuites for the Transport Layer Security (TLS) protocol to support certificate-less, secure authentication using only a simple, low-entropy, password. The ciphersuites are all based on an authentication and key exchange protocol that is resistant to off-line dictionary attack. "BGP-signaled end-system IP/VPNs.", Pedro Marques, Luyuan Fang, Ping Pan, Amit Shukla, Maria Napierala, Nabil Bitar, 11-Mar-12, This document describes how the control plane specified by BGP/MPLS IP VPNs [RFC4364] can be used to provide a network virtualization solution for end-systems that meets the requirements of large scale data-centers. It specifies how the control and forwarding functions of a Provide Edge (PE) device described in [RFC4364] can be separated such that the forwarding function can be implemented in end-systems themselves. The solution is applicable to any encapsulation that can deliver packets across an IP network as a tunneled IP datagram plus a 20-bit label. "Content Distribution Network Interconnection (CDNI) Metadata Interface", Kevin Ma, 26-Apr-12, Content publishers (CPs) often use multiple Content Delivery Networks (CDNs) to deliver content to consumers. Though existing interactions between CPs and individual CDNs are beyond the scope of CDN interconnection (CDNI), it is important to understand the management capabilities and features available with existing non-interconnected multi-CDN deployments. Before migrating to CDNI, CPs must first assess the suitability of CDNI as a replacement for their existing non-interconnected multi-CDN deployments. CDN feature configuration and capability advertisement and enforcement is likely to occur through the CDNI metadata interface (MI). This document describes an approach to implementing the CDNI MI through the use of an extensible metadata model and a light-weight HTTP-based API. "LDP Bindings Refresh", Andre Pelletier, Kamran Raza, 1-May-12, 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. "SMTP in an IPv4/IPv6 dual stack Environment", S Moonesamy, 22-May-12, This memo discusses about SMTP in an IPv4/IPv6 dual stack environment. It documents the algorithm initially specified in RFC 3974 which is used in several SMTP implementations. "Generalized Labels for the Flexi-Grid in Lambda-Switch-Capable (LSC) Label Switching Routers", Daniel King, Adrian Farrel, Yao Li, Fei Zhang, Ramon Casellas, 12-Mar-12, A new flexible wavelength grid ("flexi-grid") is being developed within the ITU-T Study Group 15 to allow selection and switching of individual lambdas chosen flexibly from a detailed, fine granularity grid of available wavelengths. This document updates the definition of GMPLS lambda labels to support the flexi-grid. This document updates RFC 3471 and updates RFC 6205. "Traffic classification in end-system IP VPNs.", Pedro Marques, Luyuan Fang, Ping Pan, Amit Shukla, Maria Napierala, 10-Apr-12, When IP VPNs are used to interconnect end-systems [I-D.marques-l3vpn- end-system] it may be desirable to introduce traffic control rules at a finer level of granularity than an IP destination address. This document extends the end-system IP VPN specification with support for fine grain traffic classification, filtering and redirection rules. It applies the existing BGP IP VPN flow specification dissemination mechanism [RFC5575] to end-system IP VPNs in order to provide the ability to control IP packets that match a specific pattern, which may include fields other than the IP destination address. "IS-IS Traffic Engineering (TE) Metric Extensions", Stefano Previdi, Spencer Giacalone, David Ward, John Drake, Alia Atlas, Clarence Filsfils, 9-Mar-12, In certain networks, such as, but not limited to, financial information networks (e.g. stock market data providers), network performance criteria (e.g. latency) are becoming as critical to data path selection as other metrics. This document describes extensions to IS-IS TE [RFC5305] such that network performance information can be distributed and collected in a scalable fashion. The information distributed using ISIS TE Express Path can then be used to make path selection decisions based on network performance. Note that this document only covers the mechanisms with which network performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document. "Enhanced Duplicate Address Detection", Carlos Pignataro, Eli Dart, Hemant Singh, Rajiv Asati, Wes Beebee, Wesley George, 5-Jan-12, Appendix A of the IPv6 Duplicate Address Detection (DAD) document in RFC 4862 discusses Loopback Suppression and DAD. However, RFC 4862 does not settle on one specific automated means to detect loopback of Neighbor Discovery (ND of RFC 4861) messages used by DAD. Several service provider communities have expressed a need for automated detection of looped backed ND messages used by DAD. This document includes mitigation techniques and then outlines the Enhanced DAD algorithm to automate detection of looped back IPv6 ND messages used by DAD. For network loopback tests, the Enhanced DAD algorithm allows IPv6 to self-heal after a loopback is placed and removed. Further, for certain access networks the document automates resolving a specific duplicate address conflict. "New Performance Metrics Composition Framework for Multiparty Services", Tiziano Ionta, 6-Apr-12, 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. "IPv4 Residual Deployment via IPv6 - Unified Solution (4rd)", Remi Despres, Reinaldo Penno, Yiu Lee, Gang Chen, Jacni Qin, 28-Mar-12, The 4rd automatic tunneling mechanism makes IPv4 Residual Deployment possible via IPv6 networks without maintaining for this per-customer states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment of 6rd). To cope with the IPv4 address shortage, customers can be assigned IPv4 addresses with restricted port sets. In some scenarios, 4rd-capable customer nodes can exchange packets of their IPv4-only applications via stateful NAT64s that are upgraded to support 4rd tunnels (in addition to their IP/ICMP translation of RFC6145). "Using the IPv6 Flow Label for Server Load Balancing", Brian Carpenter, Sheng Jiang, Willy Tarreau, 6-Mar-12, This document describes how the IPv6 flow label can be used in support of layer 3/4 load distribution and balancing for large server farms. "MN Status Option for Proxy Mobile IPv6", Yangwei Tu, Chunhui Zhu, Carlos Bernardos, Carl Williams, 13-Apr-12, The NETEXT Working Group is working on Proxy Mobile IPv6 extensions to support flow mobility, i.e., the ability of movement of selected flows from one access technology to another. This document extends the Proxy Binding Update signaling to convey mobile node's status information, that can be used by the local mobility anchor to decide when and how perform flow mobility. "Modem Link Properties Advertisement Protocol", Will Ivancic, Lloyd Wood, Rajiv Asati, Daniel Floreani, Dan Shell, 16-Apr-12, Nework devices and applications are increasingly connected to a variety of smart modems whose incoming and outgoing link rates can be varied over time to suit the channel characteristics. Such rate changes can result from use of adaptive coding and modulation. The link rate and conditions offered by the modem to connected devices therefore vary. In order for connected devices and applications to get the most out of the modem's link capacity, it is necessary for the applications and connected devices to condition traffic. Thus, they need some knowledge of the modem's link conditions. This document describes one simple method for a modem to advertise link rate and other characteristics, via UDP messages, and discusses alternative approaches to communicating this information. While the mechanism in this document is described in the context of a modem, it can also be broadly applied to other scenarios such as cryptographic devices. "Relay-Supplied DHCPv6 Precedence Options", Tirumaleswar Reddy, Prashanth Patil, Dan Wing, 15-Apr-12, Network configuration of hosts is currently relatively static with little consideration of dynamic network characteristics. The network infrastructure is aware of dynamic network characteristics. This specification extends DHCPv6 so that the DHCPv6 relay agent can influence a host's configuration. "Multiple RTP Sessions on a Single Lower-Layer Transport", Magnus Westerlund, Colin Perkins, 12-Mar-12, This document specifies how multiple RTP sessions are to be multiplexed on the same lower-layer transport, e.g. a UDP flow. It discusses various requirements that have been raised and their feasibility, which results in a solution with a certain applicability. A solution is recommended and that solution is provided in more detail, including signalling and examples. "Securing Header Fields with S/MIME", Laurent Cailleux, Chris Bonatti, 10-Apr-12, 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'. "RSVP-TE Signaling Extensions in support of Flexible Grid", Fatai Zhang, Oscar de Dios, Daniele Ceccarelli, 12-Mar-12, This memo describes the signaling extensions of GMPLS control of flexible grid network. "Problem Statement for Renumbering IPv6 Hosts with Static Addresses", Brian Carpenter, Sheng Jiang, 27-Feb-12, This document analyses the problems of updating the IPv6 addresses of hosts in enterprise networks that for operational reasons require static addresses. "RPL adaptation for asymmetrical links", Pascal Thubert, 9-Dec-11, The Routing Protocol for Low Power and Lossy Networks defines a generic Distance Vector protocol for Low Power and Lossy Networks, many of which exhibit strongly asymmetrical characteristics. This draft proposes an extension for that optimizes RPL operations whereby upwards and downwards direction-optimized RPL instances are associated. "Multicast Support for 4rd", Behcet Sarikaya, 9-Mar-12, This memo specifies 4rd technology's multicast component so that IPv4 hosts can receive multicast data from IPv4 servers over an IPv6 network. In 4rd Translation Multicast solution, IGMP messages are translated into MLD messages at the CE router which is IGMP/MLD Proxy and sent to the network in IPv6. 4rd Border Relay does the reverse translation and joins IPv4 multicast group for 4rd hosts. Border Relay as multicast router receives IPv4 multicast data and translates the packet into IPv6 multicast data using 4rd-U and sends downstream on the multicast tree. Member CEs receive multicast data, translate it back to IPv4 and transmit to the hosts. In AMT based encapsulation solution, AMT Gateway at the 4rd Customer Edge router uses AMT protocol to establish a tunnel interface with AMT Relay at the 4rd Border Relay and this tunnel is used to exchange IGMP messages to establish multicast state at AMT Relay so that AMT Relay can tunnel IPv4 multicast data to IPv4 hosts connected to AMT Gateway. "Key Management for Pairwise Routing Protocol", Mahesh Jethanandani, Brian Weis, Keyur Patel, Dacheng Zhang, Sam Hartman, 8-Mar-12, When running routing protocols such as BGP or RSVP-TE, two routers need to exchange routing messages in a unicast (one-to-one) fashion. In order to authenticate these messages using symmetric cryptography, a secret key needs to be established. This document defines a Router Key Management Protocol for establishing and managing such keys for routing protocols. "Encrypting PANA AVPs", Alper Yegin, Robert Cragie, 10-Apr-12, This document specifies a mechanism for delivering PANA (Protocol for Carrying Authentication for Network Access) AVPs (Attribute-Value Pairs) in encrypted form. "Reactions to Signaling from ECN Support for RTP/RTCP", Ken Carlberg, 12-Mar-12, This document presents recommendations for response to Congestion Experience (CE) notifications by real time applications that have negotiated end-to-end support of Explicit Congestion Notification (ECN). This document is a follow-on effort of [draft-rtp-ecn], which specifies the signaling used to provide ECN support for RTP/RTCP flows. "BGP Persistence", James Uttaro, Adam Simpson, Rob Shakir, Clarence Filsfils, Pradosh Mohapatra, Bruno Decraene, John Scudder, Yakov Rekhter, 12-Mar-12, For certain AFI/SAFI combinations it is desirable that a BGP speaker be able to retain routing state learned over a session that has terminated. By maintaining routing state forwarding may be preserved. This technique works effectively as long as the AFI/SAFI is primarily used to realize services that do not depend on exchanging BGP routing state with peers or customers. There may be exceptions based upon the amount and frequency of route exchange that allow for this technique. Generally the BGP protocol tightly couples the viability of a session and the routing state that is learned over it. This is driven by the history of the protocol and it's application in the internet space as a vehicle to exchange routing state between administrative authorities. This document addresses new services whose requirements for persistence diverge from the Internet routing point of view. "RTSP Extension for Substream Control", Peiyu Yue, 1-Mar-12, This document defines extensions to RTSP 2.0 protocol, including header "SubstreamCtrl", feature tag "Play.substream" , and related new status codes. These extensions enables the playback control of a media stream on substream basis. "HOST_ID TCP Options: Implementation & Preliminary Test Results", Elie Abdo, Mohamed Boucadair, Jaqueline Queiroz, 13-Jan-12, This memo documents the implementation of the HOST_ID TCP Options. It also discusses the preliminary results of the tests that have been conducted to assess the technical feasibility of the approach as well as its scalability. Several HOST_ID TCP options have been implemented and tested. "GMPLS-UNI BCP", Vishnu Beeram, Igor Bryskin, Wes Doonan, John Drake, Gert Grammel, Manuel Paul, Ruediger Kunze, Friedrich Armbruster, Oscar de Dios, 12-Mar-12, This document pools together the best current practices that are being used to apply the GMPLS Overlay model at the User-Network Interface (UNI) reference point (as defined in [G.8080]) "DHCPv6 class based prefix", Cisco Systems, Gaurav Halwasia, Sindhura Bandi, Sri Gundavelli, Hui Deng, 12-Mar-12, DHCPv6 defines class based allocation of IA_NA and IA_TA IPv6 addresses. This document extends DHCPv6 prefix delegation with class based prefix allocation. It defines a new prefix class option to classify a prefix. It defines the behavior of a DHCPv6 client requesting a prefix to include the class of the prefix to be allocated and the DHCPv6 server behavior to select and offer a prefix from a given class. It discusses how IA_NA can be requested and assigned from a specific prefix class. "IPv6 Guidance for Internet Content and Application Service Providers", Brian Carpenter, Sheng Jiang, 22-Feb-12, This document provides guidance and suggestions for Internet Content Providers and Application Service Providers who wish to offer their service to both IPv6 and IPv4 customers. Many of the points will also apply to any enterprise network preparing for IPv6 users. "The CLEFIA Cipher Algorithm and Its Use with IPsec", Masanobu Katagi, 23-Apr-12, This document describes the use of the CLEFIA block cipher algorithm in conjunction with several different modes of operation within IKE and IPsec. "Analysis and recommendation for the ULA usage", Bing Liu, Sheng Jiang, Cameron Byrne, 12-Mar-12, This document describes use cases where ULA address may be beneficially used. "A Multiplexing Extension for WebSockets", John Tamplin, Takeshi Yoshino, 28-Feb-12, The WebSocket Protocol [RFC6455] requires a new transport connection for every WebSocket connection. This presents a scalability problem when many clients connect to the same server, and is made worse by having multiple clients running in different tabs of the same user agent. This extension provides a way for separate logical WebSocket connections to share an underlying transport connection. Please send feedback to the hybi@ietf.org mailing list. "ICMP based OAM Solution for TRILL", Tissa Senevirathne, Dinesh Dutt, Vishwas Manral, Sam Aldrin, 6-Jan-12, This document presents a solution suite for TRILL data plane monitoring and failure detection. Methods presented herein allow in- cooperating IP payloads, exercising multi-paths, verifying multicast trees, locating end stations, virtual segments and diagnosing connectivity problems. ICMP protocol is proposed as framework for error reporting. Document also presents network wide health monitoring, distribution and reporting methods that are intended for efficient troubleshooting. "OSPFv3 Auto-Configuration", Acee Lindem, Jari Arkko, 10-Mar-12, OSPFv3 is a candidate for deployments in environments where auto- configuration is a requirement. One such environment is the IPv6 home network where users expect to simply plug in a router and have it automatically use OSPFv3 for intra-domain routing. This document describes the necessary mechanisms for OSPFv3 to be self-configuring. "NETCONF Over Transport Layer Security (TLS)", Mohamad Badra, 28-Apr-12, The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to secure NETCONF exchanges. This document obsoletes RFC 5539. "OSPF Topology-Transparent Zone", Huaimo Chen, Renwei Li, Gregory Cauchie, Ning So, 12-Mar-12, 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. "Benchmarking Methodology for Evaluating the Security Effectiveness of Content Aware Devices", Kenneth Green, Tom Alexander, 4-Mar-12, This document defines a methodology for evaluating the ability of content-aware network devices to correctly detect and block malicious or administratively disallowed traffic flows. This benchmark addresses the issue of classification accuracy under well defined conditions. It is not concerned with measuring forwarding performance which is covered by other BMWG documents. "Experiences from IPv6-Only Networks with Transition Technologies in the WIDE Camp Spring 2012", Hiroaki Hazeyama, Ruri Hiromi, Tomohiro Ishihara, Osamu Nakamura, 12-Mar-12, This document reports and discusses issues on IPv6 only networks and IPv4/IPv6 transition technologies through our experiences on the 2nd experiment on the WIDE camp. The second experiment was held from March 4th to March 8th, 2012. We tried to live in commercial IPv6 networks with four kinds of IPv4/IPv6 transition technologies, DNS64/ NAT64, 4RD, 464XLAT and SA46T. In this -01.txt aims to report results of the 2nd experiment and to share issues / problems on the IPv4 / IPv6 transition that we met. "Privacy Considerations for Internet Protocols", Alissa Cooper, Hannes Tschofenig, Bernard Aboba, Jon Peterson, John Morris, 12-Mar-12, This document offers guidance for developing privacy considerations for IETF documents and aims to make protocol designers aware of privacy-related design choices. Discussion of this document is taking place on the IETF Privacy Discussion mailing list (see https://www.ietf.org/mailman/listinfo/ietf-privacy). "Transparent Interconnection of Lots of Links (TRILL) over IP", Margaret Wasserman, Donald Eastlake, Dacheng Zhang, 12-Mar-12, The Transparent Interconnection of Lots of Links (TRILL) protocol is implemented by devices called Routing Bridges (RBridges). TRILL supports both point-to-point and multi-access links and is designed so that a variety of link protocols can be used between RBridge ports. This document standardizes methods for encapsulating TRILL in UDP/IP(v4 or v6) to provide a unified TRILL campus. "Automagic peering at IXPs.", Warren Kumari, Keyur Patel, John Scudder, 23-Apr-12, This document describes a method for automatically establishing BGP peering sessions at an Internet exchange point. Creation of these peering sessions is facilitated by a host. "Transparent Interconnection of Lots of Links (TRILL) over MPLS Pseudo Wires", Lucy Yong, Donald Eastlake, Sam Aldrin, Jon Hudson, 12-Mar-12, This informational document describes ways to interconnect TRILL RBridges by using MPLS Pseudo Wire (PW) services with existing TRILL and MPLS standards so as to form a unified TRILL campus. "Alert Metadata Protocol (AMP)", Matt Lepinski, Karen Seo, Richard Barnes, 4-May-12, Recipients of emergency alerts need to discover information about local alert distribution servers, and to register contact points where they can receive alerts. This document defines a mechanism for IP networks to advertise a local alert server, and a protocol that devices on the network can use to retrieve local information and register information about themselves. Please send feedback to the atoca@ietf.org mailing list. "Transport of CoAP over SMS, USSD and GPRS", Markus Becker, Kepeng Li, Koojana Kuladinithi, Thomas Poetsch, 1-Mar-12, 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. "Duplicating RTP Streams", Ali Begen, Colin Perkins, 10-Mar-12, 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 media streams, or RTP Control Protocol (RTCP) rules. "Cloud Networking: Framework and VPN Applicability", Nabil Bitar, Florin Balus, Marc Lasserre, Wim Henderickx, Ali Sajassi, Luyuan Fang, Yuichi Ikejiri, Mircea Pisica, 18-May-12, Cloud Computing has been attracting a lot of attention from the networking industry. Some of the most publicized requirements are related to the evolution of the Cloud Networking Infrastructure to accommodate a large number of tenants, efficient network utilization, scalable loop avoidance, and Virtual Machine Mobility. This draft describes a framework for cloud networking, highlighting the applicability of existing work in various IETF Working Groups (e.g., RFCs and drafts developed in IETF L2VPN and L3VPN Working Groups) to cloud networking, and the gaps and problems that need to be further addressed. That is, the goal is to understand what may be re-used from the current protocols and call out requirements specific to the Cloud space that need to be addressed by new standardization work with proposed solutions in certain cases. "ICMP Handling in IPv6-to-IPv6 Network Prefix Translation", Steven Blake, Terry Moes, 12-Mar-12, NPTv6 is a stateless, transport-agnostic IPv6-to-IPv6 Network Prefix Translation function that provides the address-independence benefit associated with IPv4-to-IPv4 NAT without some of that mechanism's drawbacks. NPTv6 is intended to be deployed in environments where a host might not know its "external" network prefix(es). In such an environment, a NPTv6 device must also translate network prefixes present in in-bound and out-bound ICMPv6 error message payloads. This document describes the required processing of ICMPv6 error messages. "HTTP-COAP Proxy Discovery using Link-format", Zehn Cao, Yuanchen Ma, Hui Deng, 12-Mar-12, This document discusses the problem of HTTP-COAP proxy discovery and proposes a method of using Link-format to do the job. "IS-IS Extended Sequence number TLV", Uma Chunduri, Wenhu Lu, Albert Tian, Naiming Shen, 12-Mar-12, 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, 12-Mar-12, This document analyzes the threats applicable for Intermediate system to Intermediate system (IS-IS) routing protocol and security gaps according to the KARP Design Guide. This document also provides specific requirements to address the gaps with both manual and auto key management protocols. "Using IKEv2 with TCP-AO", Uma Chunduri, Albert Tian, Joseph Touch, 12-Mar-12, This document describes a mechanism to secure TCP-based pairwise Routing Protocol (RP) associations using the IKEv2 Key Management Protocol (KMP) integrated with TCP-AO. A Gatekeeper (GK) mechanism is introduced to allow TCP-AO to coordinate with IKEv2 without fundamental modification to either. This document also introduces extensions to IKEv2 and its Security Associations to enable its key negotiation to support TCP-AO. The document also includes a summary of IKEv2 authentication methods available for peer authentication for use in protecting routing protocols. "The LLN 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, 22-Apr-12, This document describes the LLN Ad hoc On-Demand - Next Generation (LOADng) distance vector routing protocol, a reactive routing protocol intended for use in Low power and Lossy Networks (LLN). The protocol is derived from AODV (RFC3561) and extended for use in LLNs. "CalDAV Managed Attachments", Cyrus Daboo, Arnaud Quillaud, 2-May-12, This document defines how CalDAV servers can provide server managed collections to allow attachments associated with iCalendar data, to be stored and managed on the server. "OSPFTE extension to support GMPLS for Flex Grid", Iftekhar Hussain, Rajan Rao, Abinder Dhillon, 23-Nov-11, This document specifies the extension to TELINK LSA of OSPF routing protocol [RFC4203] [3] in support of GMPLS [1] for flex-grid networks [2]. "Pseudowire Redundancy on S-PE", Jie Dong, Haibo Wang, 9-Mar-12, This document describes Multi-Segment Pseudowire (MS-PW) protection scenarios in which the pseudowire redundancy is provided on the Switching-PE (S-PE). Signaling of preferential forwarding defined in [I-D.ietf-pwe3-redundancy-bit] is reused. "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", Donald Eastlake, Ayan Banerjee, Anoop Ghanwani, Radia Perlman, Dinesh Dutt, 10-Mar-12, The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides optimal pair-wise data frame forwarding without configuration in multi-hop networks with arbitrary topology, and support for multipathing of both unicast and multicast traffic. This document specifies the data formats and code points for the IS-IS extensions to support TRILL. These data formats and code points may also be used by technologies other than TRILL. This document obsoletes RFC 6326. "Algorithms for computing Maximally Redundant Trees for IP/LDP Fast- Reroute", Alia Atlas, Gabor Envedi, Andras Csaszar, 12-Mar-12, A complete solution for IP and LDP Fast-Reroute using Maximally Redundant Trees is presented in [I-D.ietf-rtgwg-mrt-frr- architecture]. This document describes an algorithm that can be used to compute the necessary Maximally Redundant Trees and the associated next-hops. "Naming Things with Hashes", Stephen Farrell, Dirk Kutscher, Christian Dannewitz, Borje Ohlman, Ari Keranen, Phillip Hallam-Baker, 6-May-12, This document defines a set of ways to identify a thing using the output from a hash function, specifying URI, URL, binary and human "speakable" formats for these names. The various formats are designed to support, but not require, a strong link to the referenced object such that the referenced object may be authenticated to the same degree as the reference to it. "A URN Namespace for Digital Television Group (DTG)", Mykyta Yevstifeyev, Will Godfrey, 27-Jan-12, This document describes a Uniform Resource Name (URN) namespace which is maintained by the Digital Television Group (DTG) for naming persistent resources (specifically, various DTG specifications). "IP VPN Scaling Considerations", Wesley George, Rob Shakir, 6-Mar-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. "The Named Information (ni) URI Scheme: Optional Features", Phillip Hallam-Baker, Rob Stradling, Stephen Farrell, Dirk Kutscher, Borje Ohlman, 23-Apr-12, This document specifies optional things that one can do with "ni" URIs and related names. Those include an additional hash algorithm for handling dynamic content, some specific query-strong parameters for ni URIs and a mechanism for embedding ni URIs into QR codes. "Internet Exchange Route Server Operations", Nick Hilliard, Elisa Jasinska, Robert Raszuk, Niels Bakker, 24-Apr-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. "Multicast Proxy in IPv6/IPv4 Transition", Sheng Jiang, Dujuan Gu, Yu Fu, Bing Liu, 26-Apr-12, During the long co-existing period of IPv6 and IPv4, the interoperation between IPv6 network and IPv4 network is essential. Multicast services across IPv6 and IPv4 networks are also needed. Besides the packet-based multicast translation mechanism, this document describes a multicast proxy solution. The solution is a multicast deployment for transition scenario. It does not propose any new protocol or protocol modification/extension for multicast. The multicast proxy is deployed at the border of IPv6/IPv4 networks. It is mainly based on content cache. Without packet-based translation, it acquires the content data from IPvX network, caches the data, and multicasts the data in IPvY network. It acts as a multicast leaf in the IPvX network where the data source locates while acting as a multicast source in IPvY network where the multicast client locates. "Diameter Group Signaling", Mark Jones, 7-Mar-12, In large network deployments, a single Diameter peer can support over a million concurrent Diameter sessions. Recent use cases have revealed the need for Diameter peers to apply the same operation to a large group of Diameter sessions concurrently. The Diameter base protocol commands operate on a single session so these use cases could result in many thousands of command exchanges to enforce the same operation on each session in the group. In order to reduce signaling, it would be desirable to enable bulk operations on all (or part of) the sessions managed by a Diameter peer using a single or a few command exchanges. This document specifies the Diameter protocol extensions to achieve this signaling optimization. "Requirements for Interworking WebRTC with Current SIP Deployments", Hadriel Kaplan, 22-Nov-11, The IETF RTCWEB WG has been discussing how to interwork WebRTC with deployed SIP equipment and domains. Doing so may require an Interworking Function middlebox in the media-plane. This document lists some WebRTC-to-SIP use-cases, the WebRTC requirements to support such, and the complexity involved in interworking if the requirements cannot be met. "Corresponding Auto Names for IPv6 Addresses", Hiroshi Kitamura, Shingo Ata, 7-Mar-12, This document discusses notion and actual mechanisms of Corresponding Auto Names for IPv6 Addresses. With this mechanism, all IPv6 addresses (even if they are link-local scoped addresses) can obtain their own Names, and it will be able to use Names anywhere instead of IPv6 Addresses. IPv6 address is too long and complicated to remember, and it is very nuisance to type a literal IPv6 address manually as an argument of applications. Also, it is very difficult for human beings to tell which IPv6 address is set to which actual IPv6 node. In this sense, literal IPv6 address information can be called meaningless information for human beings. In order to solve above problems and to make the information meaningful, mechanisms called Corresponding Auto Names for IPv6 addresses is introduced. They will become human friendly information. By applying a simple naming rule to the Auto Names (e.g., use the same Auto Name Prefix for IPv6 addresses that are set to the same interface (node)), this will contribute to help people to understand which IPv6 address / Name indicates which actual IPv6 node and provide meaningful information. "Service Selection for Mobile IPv6", Jouni Korhonen, Ulf Nilsson, Vijay Devarapalli, 12-Mar-12, In some Mobile IPv6 deployments, identifying the mobile node or the mobility service subscriber is not enough to distinguish between multiple services possibly provisioned to the said mobile node and its mobility service subscription. A capability to specify different services in addition to the mobile node identity can be leveraged to provide flexibility for mobility service providers on provisioning multiple services to one mobility service subscription. This document describes a Service Selection Mobility Option for both conventional Mobile IPv6 and Proxy Mobile IPv6 that is intended to assist home agents and local mobility agents to make a specific service selection for the mobility service subscription during the binding registration procedure. This specification updates RFC5213 and obsoletes RFC5149. "Real-Time Transport Protocol (RTP) Usage for Telepresence Sessions", Jonathan Lennox, Paul Witty, Allyn Romanow, 12-Mar-12, This document describes mechanisms and recommended practice for transmitting the media streams of telepresence sessions using the Real-Time Transport Protocol (RTP). "Per-Host Locators for Distributed Mobility Management", Marco Liebsch, 12-Mar-12, Mobile operators consider the distribution of mobility anchors to enable offloading some traffic from their core network. In scope of a solution for Distributed Mobility Management is the maintenance of IP sessions and IP address continuity when mobile nodes get a new mobility anchor assigned during handover. This document proposes the use of identifier-locator split concepts to achieve optimal routing of data packets to a mobile node's current mobility anchor. The use of per-host locator IP addresses allows translation of addresses within the mobile operator network to route packets to the mobile node's current mobility anchor, while address translation is kept transparent to the communication endpoints. "Quality of Service Option for Proxy Mobile IPv6", Marco Liebsch, Pierrick Seite, Hidetoshi Yokota, Jouni Korhonen, Sri Gundavelli, 12-Mar-12, 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. "MPLS-TP protection for interconnected rings", Guoman Liu, Yaacov Weingarten, 26-Apr-12, According to the ring protection Requirements in RFC 5654, Requirement 93 : When a network is constructed from interconnected rings, MPLS-TP MUST support recovery mechanisms that protect user data that traverses more than one ring. This includes the possibility of failure of the ring-interconnect nodes and links,so this document will describle all kinds of interconnected ring Scenarios and several protection solutions for recovery the failure of the ring-interconnect nodes and Links. . This document is a product of a joint Internet Task Force(IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. "dhcp option for CoAP Proxy Discovery", Yuanchen Ma, Xuan He, Zehn Cao, 12-Mar-12, CoAP utilizes DNS to discovery the IP address of the CoAP server. However DNS is heavy for the most resource constrained end-points. In this case the assistance from CoAP proxy or research directory (RD) is needed for CoAP transaction. This specification proposes to define one new dhcp option for proxy/RD discovery for the most resource constrained end-points. "Network-based Inter-domain handover Support for Proxy Mobile IPv6", Zhengming Ma, Ke Wang, Fei Zhang, 4-Jan-12, [RFC5213] prompts the Inner-domain handover of the MN in Proxy Mobile IPv6(PMIPv6).This document describes network-based Inter-domain handover functionality and corresponding mobility options for PMIPv6.This document strictly abides by the three principle describes in PMIPv6: (a)The movement of MN is transparent to CN. (b)MN doesn't participate in any mobility-related signaling.LMA and MAG are responsible for managing IP mobility on behalf of the host. (c)This document is compatible with RFC5213. The points of this document are as follows: (1) Concepts: The MN's Home Agent(HA) ,Home Address (HoA) and Care-of address(CoA) is not only for user but also for the specific session.MN initiating a session uses the address assigned by the LMA which the MN is registered at the moment as the HoA for the session.The user initiating a session uses the address assigned by the LMA which the MN moves to as the CoA for the session. (2) Binding Cache:Every local mobility anchor must maintain two Binding Cache entries for each currently registered mobile node. One is Inner-domain BCE,the other is Inter-domain BCE. Inner-domain BCE maintains the binding between MN's Proxy-CoA and MN's HoA. Inter- domain BCE maintains the bingding between CN's HoA and CN's CoA. (3)Communication:For the user initiating a session or accepting a session,no matter how it moves,the HoA for the session is unchanged,the source address of the data packets is the user's own HoA,and the destination address of the the data packets is the HoA of CN.The local mobility anchor will check all the packets received from the mobile access gateway.If both the source address of the data packets is the MN's HoA recorded in Inner-domain BCE,and the CN's HoA and CoA recorded in Inter-domain BCE are the same,the LMA will route the packets directly to CN as described in RFC5213.Otherwise, according to looking up the Inter-domain BCE,LMA gets the CoA of CN. Then ,LMA encapsulates the packets to route to CN.On receiving a packet from a correspondent node with the destination address matching a mobile node's home network prefix(es), the CN's LMA MUST first check the source address and the destination address of the data packets,if the source address of the data packets is MN's HoA recorded in Inter-domain BCE and the destination address is CN's HoA recorded in Inner-domain BCE ,the CN'LMA will forward the packets to the right MAG directly as described in RFC5213.Otherwise, CN'LMA will remove the outer header before forwarding the packet. Then,LMA looks up the Inner-domain BCE to forward the packets to the right MAG. (4)Updates:When MN moves to visited LMA(MN-vLMA),MN-vLMA will do three things. Firstly MN-vLMA will assign a MN-CoA for MN and build up the Inner- domain BCE for MN. Secondly,MN-vLMA will sends message to MN-hLMA to get the HoA of CN .Then,MN-vLMA builds up the binding between CN-HoA and CN-HoA in the Inter-domain BCE.Thirdly, MN-vLMA sends message to CN-LMA wiht the MN-CoA and MN-HoA included in the message to help CN- LMA updating the Inter-domain BCE for MN. Compared with "draft-ma-netext-pmip-handover-00.txt", this document is compatible with RFC5213 and the LMA described in this document should decide if it is necessary to encapsulate the packets.In other word,if MN and CN are both in their home domain,they will communicate just as the way described in RFC5213 and otherwise they will communicate in the way described in this document. "DHCPv6 Options for Mapping of Address and Port", Tomasz Mrugalski, Mohamed Boucadair, Xiaohong Deng, Ole Troan, Congxiao Bao, 23-Jan-12, Generic mechanism for mapping between an IPv4 prefix, address or parts of thereof, and transport layer ports and an IPv6 prefix or address is specified in [I-D.mdt-softwire-mapping-address-and-port]. This is a companion document that specifies provisioning mechanism of MAP rules. It defines DHCPv6 options which are meant to be used between Customer Edge (CE) devices and DHCPv6 server to obtain necessary parameters to configure MAP rules. Since specification of MAP architecture is still expected to evolve, DHCPv6 options may have to evolve too to fit the revised MAP specification. "Mapping of Address and Port (MAP)", Congxiao Bao, Ole Troan, Satoru Matsushima, Tetsuya Murakami, Xing Li, 30-Jan-12, This document describes a generic mechanism for mapping between IPv4 addresses and IPv6 addresses and transport layer ports. "URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol", Suhas Nandakumar, Gonzalo Salgueiro, Paul Jones, Marc Petit-Huguenin, 12-Mar-12, 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. "Constrained Application Autoconfiguration", Johanna Nieminen, Basavaraj Patil, Teemu Savolainen, Markus Isomaki, Zach Shelby, Carles Gomez, Mehmet Ersue, 12-Mar-12, The number and types of devices that are Internet connected continues to grow. Sensors, appliances, utility meters, medical devices etc. are Internet connected for various reasons. Many of these newer devices are constrained in terms of processing power, memory, communication capability and, available power. Devices such as sensors and similar very small devices often lack a proper user interface and hence configuring even the most basic parameters for enabling Internet connectivity on these is extremely difficult. Some of the existing configuration protocols can help in autoconfiguring various parameters of the IP stack needed for Internet connectivity. However this is not sufficient if the devices are using a web service application. There is a need for additional information such as service provider name and username/password etc. for authentication etc. A configuration protocol solution for resource constrained devices is needed in order to enable the potential enabled by Internet connectivity. This document outlines the use cases and requirements for user friendly configuration of such information on a constrained device, and specifies a Constrained Application Protocol (CoAP) based mechanism to meet the requirements. "HTTP Authentication Extensions for Interactive Clients", Yutaka Oiwa, Hajime Watanabe, Hiromitsu Takagi, Boku Kihara, Tatsuya Hayashi, Yuichi Ioku, 18-May-12, This document specifies a few extensions of HTTP authentication framework for interactive clients. Recently, fundamental features of HTTP-level authentication is not enough for complex requirements of various Web-based applications. This makes these applications to implement their own authentication frameworks using HTML Forms and other means, which becomes one of the hurdles against introducing secure authentication mechanisms handled jointly by servers and user- agent clients. The extended framework fills gaps between Web application requirements and HTTP authentication provisions to solve the above problems, while maintaining compatibility against existing Web and non-Web uses of HTTP authentications. "Stateless DS-Lite", Reinaldo Penno, Alain Durand, Lionel Hoffmann, Axel Clauberg, 12-Mar-12, This memo define a simple stateless and deterministic mode of operating a carrier-grade NAT in both a NAT44 and DS-Lite environment. "CDNI Footprint Advertisement", Stefano Previdi, Francois Le Faucheur, Francois Le Faucheur, Jan Medved, Le Faucheur, 8-Mar-12, This document describes the use of BGP for Content Delivery Networks (CDNs) in order to advertise information about footprint and connectivity to footprint in the context of CDNI. "SMTP Service Extension for Greylisting Operations", Hector Santos, Evan Harris, 27-Apr-12, GREYLIST is a SMTP extension to formalize the widely supported Greylisting mail filtering method and to help support SMTP rejected transports by following a new formal structured 4yz server temporary rejection response by including a "retry=time-delay" tag string which SMTP clients can use to optimize the rescheduling of the mail delivery attempts. With adoption, network overhead reduction in wasteful mail delivery attempts will be realized. "The Use of G-IKEv2 for Multicast Router Key Management", Paulina Tran, Brian Weis, 11-Mar-12, The G-IKEv2 key management protocol protects group traffic, usually in the form of IP multicast communications between a set of network devices. This memo defines extensions to G-IKEv2 allowing it to protect the communications of routing protocols using a one-to-many or many-to-many communications model. "An Inquiry into the Nature and the Causes of Web Insecurity", Mike Hanson, Hannes Tschofenig, Sean Turner, 9-May-12, The year 2011 has been quite exciting from a Web security point of view: a number of high-profile security incidents have gotten a lot of press attention but also new initiatives, such as the National Strategy for Trusted Identities in Cyberspace (NSTIC), had been launched to improve the Web identity eco-system. The NSTIC strategy paper, for example, observes problems with Internet security due to the widespread usage of low-entropy passwords and the lack of widely deployed authentication and attribute assurance services. With this memorandum we try to develop a shared vision for how to deal with the most pressing Internet security problems. "Measuring IPv6 Traffic in BitTorrent Networks", Martin Defeche, Eric Vyncke, 2-Mar-12, This document is a follow-up of a University thesis which aims to measure the evolution over time of IPv6 traffic and to analyze the geographical distribution of IPv6 nodes. The first measurements were done during the Summer 2009 using a specific-purpose program which connects to the BitTorrent peer-to-peer network and this document adds measurements done with the same program but in October 2011 and February 2012. The study was made in Peer-to-Peer (P2P) networks because they are responsible for a big part of Internet traffic and because their structure and functioning permit a rapid discovery of a large number of nodes from all over the world. In addition, the P2P users are more likely to be interested by IPv6 as IPv6 does not have the same NAT problems as IPv4. "Port Control Protocol (PCP) Authentication Mechanism", Margaret Wasserman, Sam Hartman, Dacheng Zhang, 11-Mar-12, An IPv4 or IPv6 host can use the Port Control Protocol (PCP) to flexibly manage the IP address and port mapping information on Network Address Translators (NATs) or firewalls, to facilitate communications with remote hosts. However, the un-controlled generation or deletion of IP address mappings on such network devices may cause security risks and should be avoided. In some cases the client may need to prove that it is authorized to modify, create or delete PCP mappings. This document proposes an in-band authentication mechanism for PCP that can be used in those cases. The Extensible Authentication Protocol (EAP) is used to perform authentication between PCP devices. "Transport Options for Clue", Stephan Wenger, Marshall Eubanks, Roni Even, Gonzalo Camarillo, 12-Mar-12, This memo describes the assumption and the proposed options for the coding and transport of CLUE messages as outlined in version 01 of the framework draft. "Multiple Synchronization sources (SSRC) in RTP Session Signaling", Magnus Westerlund, Bo Burman, Fredrik Jansson, 26-Apr-12, RTP has always been a protocol that supports multiple participants each sending their own media streams in an RTP session. Unfortunately many implementations are designed only for point to point voice over IP with a single source in each end-point. Even client implementations aimed at video conferences have often been built with the assumption around central mixers that only deliver a single media stream per media type. Thus any application that wants to allow for more advance usage where multiple media streams are sent and received by an end-point has an issue with legacy implementations. This document describes the problem and proposes a signalling solution for how to use multiple SSRCs within one RTP session and at the same time handle the legacy issues. "RTP Multiplexing Architecture", Magnus Westerlund, Bo Burman, Colin Perkins, 12-Mar-12, Real-time Transport Protocol 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, the Synchronization Source Identifier (SSRC), and the payload type. The focus is put on the first two, trying to give guidance and source material for an analysis on the most suitable choices for the application being designed. "RTP Media Stream Pause and Resume", Azam Akram, Bo Burman, Daniel Grondal, Magnus Westerlund, 15-May-12, With the increased popularity of real-time multimedia applications, users demand more control over communication sessions. This document describes how a receiver in a multimedia conversation can pause and resume incoming data from a sender by sending real-time feedback messages when using Real-time Transport Protocol (RTP) for real time data transport. This document extends the Codec Control Messages (CCM) RTCP feedback package by adding a group of new real-time feedback messages used to pause and resume RTP data streams. "Extensible Bandwidth Attribute for SDP", Tomas Frankkila, Magnus Westerlund, Bo Burman, 24-Apr-12, Knowledge of what bandwidths the end-points intend to use is important both for the other end-point and for resource allocation in various types of networks. This is especially important for wireless access networks which typically have quite limited resources. The bandwidth attribute in Session Description Protocol (SDP), 'b=AS', is today quite widely used to define the bandwidth that the end-points intends to use, in various types of sessions. This document will show that the existing bandwidth attribute, such as 'b=AS', although widely used in todays scenarios, has limitations that make it hard or even impossible for the end-points to express their intentions accurately when it comes to bandwidth usage. To solve the identified problems, this document defines a new extensible SDP bandwidth attribute 'a=bw' which enables more detailed control over the bandwidth declarations, request, and allocations. With the new bandwidth attribute it is possible to define different scopes in the session setup and then negotiate the bandwidth individually for each scope. "Cross Stratum Optimization Architecture for Optical as a Service", Hui Yang, Yongli Zhao, Jie Zhang, Young Lee, Yi Lin, Fatai Zhang, 23-Apr-12, Data centers based applications provide a wide variety of services such as cloud computing, video gaming, grid application and others. Currently application decisions are made with little information concerning underlying network used to deliver those services so that such decisions cannot be the most optimal from both network and application resource utilization and quality of service objectives. This document presents a novel architecture of Cross Stratum Optimization for application and network resource in dynamic optical networks. Several global load balancing strategies are proposed and demonstrated by experiments in Optical as a Service experimental environment. "RADIUS Accounting Extensions for Traffic Statistics", Leaf Yeh, 5-Mar-12, This document specifies the RADIUS extensions of attributes for the traffic statistics with different type, which can be used to support the differentiated accounting policies and traffic recording on the AAA server. "GMPLS OSPF-TE Extensions in support of Flexible Grid in DWDM Networks", Fatai Zhang, Xian Zhang, Ramon Casellas, Oscar de Dios, Daniele Ceccarelli, 11-Mar-12, This memo describes the OSPF-TE extensions in support of GMPLS control for flexi-grid in DWDM networks. "RBridge Aggregation", Mingui Zhang, Donald Eastlake, 2-May-12, TRILL supports multi-access TRILL links that can have multiple RBridges attached. This draft specifies RBridge Aggregation that enables concurrent data forwarding by multiple RBridges for the end stations in the same VLAN on a TRILL link without partition. RBridge Aggregation offers active/active multi-homing to multi-access TRILL links, which improves their reliability and increases the access bandwidth of RBridge campus. "TRILL IS-IS MTU Negotiation", Mingui Zhang, Xudong Zhang, Donald Eastlake, 13-Dec-11, The IETF TRILL protocol provides least cost pair-wise layer 2 data forwarding by using IS-IS link state routing. This document defines a new link MTU size negotiation mechanism to update the TRILL documents "Routing Bridges (RBridges): Base Protocol Specification" and "Routing Bridges (RBridges): Adjacency". "OSPF-TE Protocol Extension for Constraint-aware RSA in Flexi-Grid Networks", Jie Zhang, Yongli Zhao, Ziyan Yu, Xuefeng Lin, Dajiang Wang, Xihua Fu, 25-Apr-12, ITU-T Study Group 15 has introduced a new flexible grids technology of DWDM network which is an effective solution to improve the efficiency of spectrum resource utilization. This memo extends the OSPF-TE protocol to support constraint-aware routing and spectrum assignment (RSA) in flexi-grid networks. "Protection Mechanisms for Label Distribution Protocol P2MP/MP2MP Label Switched Paths", Quintin Zhao, Emily Chen, Tao Chou, Daniel King, 12-Mar-12, Service providers continue to deploy real-time multicast applications using Multicast LDP (mLDP) across MPLS networks. There is a clear need to protect these real-time applications and to minimize switching times in the event of failure. This document outlines the requirements, procedures and extensions to facilitate mLDP Point-to-Multipoint (P2MP) and Multipoint-to- Multipoint (MP-to-MP) LSP protection within an MPLS network. "PCEP Protocol Extension for spectrum utilization optimization in Flexi- Grid Networks", Yongli Zhao, Jie Zhang, Tiantian Peng, Xiaosong Yu, Xuping Cao, Dajiang Wang, Xihua Fu, 25-Apr-12, Flexi-grid networks overcomes the fixed grid channel of Wavelength Switched Optical Network(WSON) by flexible spectrum to allow non- uniform and dynamic allocation of spectrum based on the demand of the incoming services' LSP. Flexi-grid networks is an effective solution to solve the problem of efficient spectrum utilization. Because the client LSP needs to be assigned contiguous spectrum in flexi-grid networks, there will be two problems that would affect spectrum utilization, i.e. RSA and fragmentation. We introduce two kinds of methods which can improve the spectrum utilization further, and some related PCEP extensions are defined in this document. "Initial Congestion Exposure (ConEx) Deployment Examples", Bob Briscoe, 13-Mar-12, This document gives examples of how ConEx deployment might get started, focusing on unilateral deployment by a single network. "An HTTP-based Decade Resource Protocol", Wang Danhua, Hongqiang Liu, Yang Yang, 12-Mar-12, This document explorers the design of an HTTP-based DECADE Resource Protocol (DRP), which can be used for content and resource management between a DECADE Client and a DECADE Server, or between two DECADE Servers. We identify the function entities, and present initial protocol message flow and syntax design. The purpose of this document is to get design discussion started, not to provide a complete solution. "BFD Management Information Base (MIB) extensions for MPLS and MPLS-TP Networks", Sam Aldrin, Venkatesan Mahalingam, Kannan Sampath, Thomas Nadeau, 23-Apr-12, This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it extends the BFD Management Information Base BFD- STD-MIB and describes the managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol for MPLS and MPLS-TP networks. "Device to Database Protocol for White Space", Subir Das, John Malyar, Dan Harasty, 12-Mar-12, This document describes the `White Space Device` to `Database` interface protocol features and functionalities and shows in Appendix A how they are consistent with the protocol requirements specified in [I-D.ietf-paws-problem-stmt-usecases-rqmts]. "mLDP Extensions for Multi Topology Routing", IJsbrand Wijnands, Kamran Raza, 9-Jan-12, The Multi-Topology Routing (MTR) enables service differentiation through class-based forwarding. IGP protocols (OSPF and IS-IS) have already been extended to setup MTR. In order to deploy mLDP in an MTR setup, mLDP is also required to become topology-aware. This document specifies extensions to mLDP to support Multi-Topology Routing. "JSON Reference", Paul Bryan, Kris Zyp, 9-Mar-12, JSON Reference allows a JSON value to reference another JSON value in a JSON document. "Licklider Transmission Protocol (LTP), Compressed Bundle Header Encoding (CBHE), and Bundle Protocol IANA Registries", Keith Scott, Stephen Farrell, 24-Feb-12, The DTNRG research group has defined the experimental Licklider Transmission Protocol (LTP) [RFC5326] and the Compressed Bundle Header Encoding (CBHE) [RFC6260] mechanism for the 'ipn' URI scheme. Finally, RFC5050 [RFC5050] defines values for the Bundle Administrative Record Type. All of these describe fields that are subject to a registry. For the purpose of its research work, the group has created ad-hoc registries. As the specifications are stable and have multiple interoperable implementations, the group would like to hand off the registries to IANA for official custody. This document describes the actions needed to be executed by IANA. "IETF Email List Archiving, Web-based Browsing and Search Tool Requirements", Robert Sparks, 29-Feb-12, The IETF makes heavy use of email lists to conduct its work. Participants frequently need to search and browse the archives of these lists, and have asked for improved search capabilities. The current archive mechanism could also be made more efficient. This memo captures the requirements for improved email list archiving and searching systems. "Internet International Bank Account Number (IIBAN)", Walter Stanish, 13-Apr-12, 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]. "SCSV for TLS Client Credential Protection", Mohamad Badra, 27-Mar-12, This document defines a special Signaling Cipher Suite Value (SCSV) "TLS_IDENTITY_PROTECTION_SCSV" to add client credential protection to the TLS protocol. "Access Control Protocol (ACP)", Karel Burda, I Strasil, T Pelka, P Stancik, 5-Dec-11, Access Control Protocol (ACP) is a protocol for unified implementation of various methods for computer device access control. The protocol allows two devices to negotiate required assets, negotiate an authentication method, do authentication, deliver the access parameters and do accounting, all within one so called "transaction". Separate transactions can be joined so that more devices can be added to the access control operation. "A general SAVI-based source address validation and traceback framework for 4over6 transition scenarios", Hui Deng, Guangwu Hu, Jun Bi, Mingwei Xu, Fan Shi, 8-May-12, Many proposals have been presented for preventing IP spoofing from occurring in network. An outstanding of them is the SAVI (Source Address Validation Improvement) proposal which was advocated by IETF SAVI workgroup for solving this problem from user access switch. SAVI Working Group is developing standardize mechanisms that prevent nodes attached to the same IP link from spoofing each other's IP addresses, and achieve IP source address validation at a finer granularity. However, up to now, to the best of our knowledge, none of them has focused on the scenarios of 4over6 transition, that is, IPv4 packets transit IPv6 network and arrive at other edge IPv4 network(s). With the boom of IPv6 networks, this issue becomes more and more urgent. In addition, since 4over6 plans are plenty and various, one solution cannot meet all requirements of these plans. This document describes a framework of IP source address validation and traceback for 4over6 transition scenarios, which extract out the essential and mutual properties from these plans and form corresponding sub-solution for each property. When one 4over6 plan is combined by some of them, the solution of IP source address validation and traceback for this plan are directly comprised of the combination of corresponding sub- solution. Thus, the most exciting advantage of this framework is that it is a once for all solution no matter how 4over6 plans changes. "Certificate Revocation List (CRL) Extensions for Backward-Compatible Whitelist Provision", Kyle Hamilton, 22-Nov-11, We describe two extensions to the Certificate Revocation List v2 to more strongly identify revoked and legitimately issued certificates. This creates a means for non-CA OCSP responders which are fed by CRL and can parse these extensions to presume that unlisted or non- matching certificates from that Issuer are REVOKED rather than UNKNOWN, as well as creating a means by which the Issuer can provide digest values for stronger certificate authentication. Placing issuance data within the CRL in some ways violates the original intent of the CRL, but CRLv2 has places for Extensions. It is a logical extension to permit existing buildout to address newly- exploited vulnerabilities in the model. A new crlEntryExtension is defined to permit the optional provision of several hashes of each certificate on the list of revoked certificates. In addition, a new crlExtension is defined to provide serial numbers and hashes of issued certificates. Neither of these extensions needs to be marked critical, and the original semantics are preserved for existing clients. Notably, no data format or protocol of PKIX can currently utilize any extra hashes to provide any extra authentication or security. Nevertheless, until there is a standard way for the CA issuer to provide these digest values, it's impossible to build anything which uses them. The downside: Whitelist CRLs with strong certificate authentication data are *huge*. The canonical 1MB CRL example would, if extended with this extra information, balloon to at a minimum 2.5MB (presuming random 20-byte serial numbers) to a single-digest maximum of approximately 400MB. CAs are encouraged not to alter their current CRL production, and produce these extensions only when needed by a certificate status server or consuming client. "SAVI Requirements and Solutions for ISP IPv6 Access Network", Fan Shi, Hui Deng, Liang Zhu, Guangwu Hu, 8-May-12, An Internet Service Provider (ISP) is always confronted with many security threats based on IP address spoofing. Unfortunately, the Internet architecture fails to provide the defense mechanism. Source Address Validation Improvement (SAVI) was developed to prevent IP source address spoofing which can enable impersonation and malicious traffic redirection. Thus, 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. "Multi-hop Ad Hoc Wireless Communication", Emmanuel Baccelli, Charles Perkins, 23-May-12, This document describes some characteristics of communication between nodes in a multi-hop ad hoc wireless network. These are not requirements in the sense usually understood as applying to formulation of a requirements document. Nevertheless, protocol engineers and system analysts involved with designing solutions for ad hoc networks must maintain awareness of these characteristics. "The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)", Inaki Castillo, Jose Millan, Victor Pascual, 16-Apr-12, 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 SIP (Session Initiation Protocol) entities and enables usage of the SIP protocol in new scenarios. "The "U" Encoding for Encoded-Words in Email", John Klensin, 24-Nov-11, The "Encoded Word" conventions have been used extensively in email headers and elsewhere to permit the encoding of non-ASCII characters where only ASCII ones are normally permitted. The existing specification defines only two kinds of encoding, one of which cannot be understood easily by people and the other of which has been widely discredited. This document specifies a third encoding that is easily accessible by users and much more closely tied to contemporary practices. The current version of the proposal is intended for possible discussion in the EAI, IRI, and PRECIS WGs to see if it sheds light on other issues being discussed in those WGs. It is not, at this point, proposed for adoption. "Receiver driven trasport protocol for CONET ICN", Stefano Salsano, Matteo Cancellieri, Andrea Detti, 25-Nov-11, Let us consider an Information Centric Networking (ICN) solution, in which an End Node requests for a content sending "content requests" (or "interest packets"). The content is provided back to the requestor by the "origin" node or by an intermediate node that had cached the content. The content is usually divided into "chunks" that can be individually requested, sent back to the requester, cached into intermediate nodes. The sending rate of content requests can be adjusted in order to perform congestion control, implementing a receiver driven transport protocol. As it can be useful to have large chunks (significantly larger than the Maximum Tranfer Unit across the network), the trasport protocol should also be used to further segment the chunks rather than relying to IP fragmentation. In this memo we define a receiver driven trasport protocol for ICN, which relies on the CONET ICN solution described in a companion draft. "The "nomap" Network Identifier Suffix", Bjoern Hoehrmann, 26-Nov-11, This memo defines a method for network operators to indicate that information about their network is broadcast only to allow legitimate participants in the network to connect or re-connect to them, and that other uses of such information are to be avoided. ""Unified MPLS Framework"", Loa Andersson, Riccardo Martinotti, 25-Jan-12, This document is framework for Unified MPLS. "LISP Delegated Database Tree", Vince Fuller, Darrel Lewis, 12-Mar-12, 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. "Audio/telephone-event Codes for Operator Services and SIT Tones", John Haluska, 30-Nov-11, This document provides additional information on the use of several specific event codes related to North American Operator Services and Special Information Tones that have been registered in the IANA "audio/telephone-event" registry. "Session Description Protocol (SDP) Alternate Connectivity (ALTC): Use Cases", Mohamed Boucadair, 1-Dec-11, This memo identifies a set of use cases which motivate the specification of Session Description Protocol (SDP) Alternate Connectivity (ALTC) attribute. These use cases are specific to IPv4/ IPv6 co-existence, IPv4/IPv6 interworking and IPv6 migration. Both IPv6-related unicast and multicast are covered. ""From" and other Message Header Fields as SPF Policy Scopes", Julian Mehnle, 1-Dec-11, This document defines a new modifier for the SPF e-mail authentication protocol allowing the SPF record for a domain to be declared as being applicable to message identities other than the MAIL FROM identity, such as the "From" or "Sender" message header identities. "ALTO Incremental Updates", Nico Schwan, Bill Roome, 12-Mar-12, The goal of Application-Layer Traffic Optimization (ALTO) is to bridge the gap between network and applications by provisioning network related information. This allows applications to make informed decisions, for example when selecting a target host from a set of candidates. Therefore an ALTO server provides network and cost maps to its clients. This draft discusses options on how to provide incremental updates for these maps, with the goal of reducing the amount of data needed for transmitting the maps. "Analysis of Comparisons between OpenFlow and ForCES", Zhiliang Wang, Tina Tsou, Jing Huang, Xingang Shi, Xia Yin, 12-Mar-12, While both ForCES and OpenFlow follow the basic idea of separations of forwarding plane and control plane in network elements, they have some technical differences. This document analyzes the differences between OpenFlow and ForCES technically from the aspects of goals, architecture, forwarding model and protocol interface. The two techniques can learn much from each other in their standardization process. "Allocation of an Associated Channel Code Point for Use by ISOEG Self- Destruct OAM", Doug Evil, 3-Dec-11, This document assigns an Associated Channel Type code point for carrying Self-Destruct Operations, Administration, and Management messages in the MPLS Generic Associated Channel (G-ACh). "Extending TRILL over WAN", XiaoLan Wan, XiaoPeng Yang, 6-Dec-11, TRILL is a key technology for large-scale layer 2 networking within data center, most enterprises have multiple data centers in different physical sites, TRILL over WAN(ToW) provides a scalable and simple solution that interconnect multiple TRILL networks to form a single TRILL domain using the currently deployed enterprise or service provider networks. This document provides an overview of this solution. "Representing IPv6 Zone Identifiers in Uniform Resource Identifiers", Brian Carpenter, Robert Hinden, 8-Feb-12, This document describes how the Zone Identifier of an IPv6 scoped address can be represented in a Uniform Resource Identifier that includes a literal IPv6 address. It updates RFC 3986 and RFC 4007. "Basic Requirements for Customer Edge Routers - multihoming and transition", Mark Townsley, Ole Troan, 16-Dec-11, This document specifies general IPv6 multihoming and specific 6rd transitioning requirements for an IPv6 Customer Edge (CE) router. It also provides an illustrative implementation model for IPv4 multihoming in order to support shared IPv4 transition mechanisms that utilize IPv6 as a transport for IPv4. "Why RTP Sessions Should Be Content Neutral", Harald Alvestrand, 9-Dec-11, This document is not intended for publication as an RFC. It gives the underpinning arguments for why the idea that RTP sessions and MIME top level types are related is a deeply broken paradigm, and that we need to get away from it. These arguments are solely the opinion of the listed author. "Modification to Default Value of SOL_MAX_RT", Ralph Droms, 17-Jan-12, This document updates RFC 3315 by redefining the default value for SOL_MAX_RT and defining an option through which a DHCPv6 server can override the client's default value for SOL_MAX_RT with a new value. "Address Acquisition For Multicast Content When Source and Receiver Support Differing IP Versions", Tina Tsou, 11-Dec-11, In a typical IP television (IPTV) system, the receiver acquires information about available program content, the subscriber selects a program to watch, and the receiver signals to the network to begin receiving the program in the form of multicast content. The program content information is typically XML-encoded, can be transmitted in multiple segments, possibly over multiple channels, but includes media stream descriptions for the individual program descriptions that may also be XML-encoded or may use the Session Description Protocol (SDP, RFC 4566). The media stream descriptions provide multicast group and unicast source addresses that are used in the subsequent signalling to the network. During the transition from IPv4 to IPv6, scenarios can occur where the IP version supported by the receiver differs from that supported by the source. This memo examines and evaluates alternative strategies for allowing the receiver to acquire addresses in such scenarios in the version it supports. "Content Distribution Network Interconnection (CDNI) Metadata Interface", Xiaomei Liu, Lakshminarayanan Gunaseelan, Xiaoyan He, Jincheng Li, 19-Dec-11, The Metadata Interface is one of the core interfaces defined by the IETF Content Distribution Network Interconnection (CDNI) Working Group. The primary function of the CDNI Metadata Interface is to allow interconnected CDNs to communicate metadata in order to ensure content delivery and content acquisition. This document defines the metadata exchange protocol between an upstream CDN and a downstream CDN for the content delivery. It also defines metadata objects especially condition metadata object for CDNI. "Problem Statement of IPv4 Private Addressing Support for Fixed Mobile Convergence over IPSec Tunneling", Tricci So, 12-Dec-11, IPSec IKEv2, RFC 5996 [RFC5996], has been adopted by many standardized network solutions to provide the secure transport between network elements over third party's infrastructure. For example, the emerging Fixed Mobile Convergence (FMC) network solution that involves Femtocell deployment requires the mobile operator's Femtocell AP to leverage the IPSec IKEv2 to support mutual authentication and remote IP address configuration as well as other auto configuration support over the broadband fixed network (BBF) of which the mobile and fixed networks may be operated by two different operators. Most of today broadband fixed networks are still relying on the IPv4 private addressing plan to support its attached devices including the mobile operator's Femtocell AP. Hence, the private IPv4 addressing and Network Address and Port Translation (NA(P)T) support mostly likely stays for many years to come. In FMC interworking scenario, there is a need for the mobile network to pass on it mobile subscribers' policies to the broadband fixed network (BBF) to maintain the service level agreement (SLA) and to support remote network management. In addition, a broadband fixed network (BBF) may partnership with more than one mobile operator. Therefore it is important for the BBF and the mobile network to be able to overcome the limitation of the private IPv4 addressing and to be able to identify the user's subscription as well as to determine the location of the Femtocell AP that serves its mobile user over the BBF network. This document presents the problems for the IPSec tunneling support with private IPv4 addressing for FMC interworking and proposes a simple extension to the IKEv2 to resolve the issues. "Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces", Manav Bhatia, Sami Boutros, Marc Binderberger, Jeffrey Haas, 1-Feb-12, This document proposes a mechanism to run BFD on Link Aggregation Group (LAG) interfaces. It does so by running an independent BFD async session on every LAG member link. The mechanism allows to verify the link connectivity, either in combination with or in absence of LACP, with a shorter detection time than what LACP offers. The connectivity check can also cover elements of layer 3. A dedicated well-known UDP port is introduced that all BFD packets over member links use to disambiguate those from ordinary BFD packets. "Throttling RAs on constrained interfaces", Pascal Thubert, 13-Dec-11, In a large switched topology with either many routers or routers that transmit a high rate of multicast advertisements per router, as suggested to support mobile nodes, the cost of distributing the many resulting multicast messages to certain classes of devices might be prohibitive. This is the case of a device that runs on batteries, or a device that is reachable over a wireless interface. For this device, it can be beneficial to filter a certain amount of multicast messages such as the Router Advertisement while preserving the functionality expected in the IPv6 Neighbor Discovery Protocol. "Forcing Fragmentation of IPv6 Packets", Mark Andrews, 22-Jan-12, Extend The Advanced Sockets API for IPv6 (RFC 3542) to provide a mechanism to force a Fragment header to be added to a packet. "DNS and UDP Fragmentation", Mark Andrews, 22-Jan-12, This document provides advice to DNS developers about sending DNS UDP messages and Path MTU Discovery. "Multiprotocol Label Switching Transport Profile Ring Protection", Yu jinghai, Yuefeng Ji, Guoman Liu, 14-Dec-11, according to RFC 5654 MPLS-TP Requirement, there is a paragraph for recovery requirements just as section 2.5.6.1 in RFC5654 describles: within the context of recovery in MPLS-TP networks,the optimization criteria considered in ring topologies are as follows: 1 minimize the number of OAM entities that are needed to trigger the recovery operation; 2 Minimize the number of elements of recovery in the ring; 3 Minimize the number of labels required for the protection paths across the ring; 4 minimize the amount of control and management plane transactions during maintenance operation. this document will describle two types of ring protection solutions to implement these requirements. "Prefix Delegation for Hierarchy Mobile IPv6", Zhengming Ma, Lin Wang, 14-Dec-11, This document explains how network mobility and DHCPv6-based Prefix Delegation works with hierarchy mobile IPv6. It is an extension of HMIPv6 and allows a mobile network to attach to a MAP via a mobile router. It also makes use of the mechanism of DHCPv6PD to assign mobile network prefix (es) to the mobile router which plays the role of requesting router. "IF-MAP schema for IP VPNs.", Pedro Marques, 14-Dec-11, This document defines the metadata schema used to define the route exchange policies of an IP VPN network. Information elements conforming to this schema can be distributed using the IF-MAP [if- map] specification. The schema is applicable both to the standard BGP IP VPN [RFC4364] deployments within service provider environments as well as end-system [I-D.marques-l3vpn-end-system] based deployments. "Mapping of VCard 4 Properties to LDAP objectclasses and attributes", Ciny Joy, Cyrus Daboo, 15-Dec-11, This specification describes a mapping of standard VCard 4 properties to standard LDAP objectclasses and attributes. "NARA : Network Architecture with Recursive Addressing", Dae Kim, 15-Dec-11, This document describes network architecture based on recursive addressing. The Internet is modeled as a network of autonomous sites, each being a collection of nodes. Each site is named by a site address drawn from a global number space while each node is named by a node address drawn from a number space local to each site. Routing among sites depends solely on site addresses while that within each site on node addresses. Flat routing to render inherent mobility as well as mapped routing to additionally cope with table size are proposed. The model can recursively repeat itself both outwards and inwards in the network, enabling its applicability, for example, to inter-planetary as well as body area networks. "Processing of IPv6 "atomic" fragments", Fernando Gont, 15-Dec-11, IPv6 allows packets to contain a Fragment Header, without the packet being actually fragmented into multiple pieces. Such packets typically result from hosts that have received an ICMPv6 "Packet Too Big" error message that advertises a "Next-Hop MTU" smaller than 1280 bytes, and are currently processed by hosts as "fragmented traffic". By forging ICMPv6 "Packet Too Big" error messages an attacker can cause hosts to employ "atomic fragments", and the launch any fragmentation-based attacks against such traffic. This document discusses the generation of the aforementioned "atomic fragments", the corresponding security implications, and formally updates RFC 2460 and RFC 5722 such that the attack vector based on "atomic fragments" is completely eliminated. "Security Implications of IPv6 options of Type 10xxxxxx", Fernando Gont, 15-Dec-11, When an IPv6 node processing an IPv6 packet does not support an IPv6 option whose two-highest-order bits of the Option Type are '10', it is required to respond with an ICMPv6 Parameter Problem error message, even if the Destination Address of the packet was a multicast address. This feature provides an amplification vector, opening the door to an IPv6 version of the 'Smurf' Denial-of-Service (DoS) attack found in IPv4 networks. This document discusses the security implications of the aforementioned options, and formally updates RFC 2460 such that this attack vector is eliminated. Additionally, it describes a number of operational mitigations that could be deployed against this attack vector. "Managing the Address Generation Policy for Stateless Address Autoconfiguration in IPv6", Fernando Gont, 15-Dec-11, This document describes an operational problem that arises due to the impossibility of managing the address generation policy employed by hosts participating in IPv6 Stateless Address Autoconfiguration (SLAAC). Additionally, it specifies a new field in the Prefix Information option of Router Advertisement messages, such that routers can advertise, for each network prefix included in a Router Advertisement message, the desired address generation policy to be used for SLAAC. "Security Implications of Predictable Fragment Identification Values", Fernando Gont, 29-Mar-12, IPv6 specifies the Fragment Header, which is employed for the fragmentation and reassembly mechanisms. The Fragment Header contains an "Identification" field which, together with the IPv6 Source Address and the IPv6 Destination Address of the packet, identifies fragments that correspond to the same original datagram, such that they can be reassembled together at the receiving host. The only requirement for setting the "Identification" value is that it must be different than that of any other fragmented packet sent recently with the same Source Address and Destination Address. Some implementations simply use a global counter for setting the Fragment Identification field, thus leading to predictable values. This document analyzes the security implications of predictable Identification values, and updates RFC 2460 specifying additional requirements for setting the Fragment Identification, such that the aforementioned security implications are mitigated. "A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)", Fernando Gont, 31-Mar-12, This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that addresses configured using this method are stable within each subnet, but the Interface Identifier changes when hosts move from one network to another. The aforementioned method is meant to be an alternative to generating Interface Identifiers based on IEEE identifiers, such that the benefits of stable addresses can be achieved without sacrificing the privacy of users. "Specification of a Provider-Managed Adaptive Function Between a Multicast Receiver and a Provider Network Supporting a Different IP Version", Cathy Zhou, Tom Taylor, Jianping Sun, 12-Mar-12, Discussion of the problem of multicast transition has brought out a number of scenarios that are the most likely to be encountered in practice. In some of these scenarios the IP version supported by the multicast receiver differs from that supported by the provider network to which it is attached. In such cases an adaptation function is required between the receiver and the network, to mediate the signalling and data flows between them. This memo uses the term "Type 1 Adaptation Function" (AF1) for such a function. It is written for the purpose of specifying the functions performed by an AF1. The scope of this memo is limited to the case where flows are unidirectional, from a designated set of sources to a designated (and normally much more numerous) set of receivers. The IP television (IPTV) case falls within this scope. "Applicability of Access Node Control Mechanism to WLAN based Broadband Networks", Xiangqing Chang, Yang Shi, Tom Taylor, 16-Dec-11, The purpose of this document is to provide applicability of Access Node Control Mechanism ,as described in [ANCP-FRAMEWORK],to WLAN based broadband access. The need for an Access Node Control Mechanism between a Network Access Server (NAS) and an WLAN Access Node is described.The Access Node Control Mechanism is also extended for WLAN. "An AODV Extension for Stable Route Selection", Sanghyun Ahn, Hyun Yu, 18-Dec-11, This document describes an enhancement on AODV that can allow a route with more stable intermediate nodes to be selected. For this, a new field, called the 'RouteStability' field, is introduced in the RREQ message and in the AODV routing table entry. "A Centralized MANET DNS Mechanism", Sanghyun Ahn, 18-Dec-11, This document describes a Domain Name System (DNS) mechanism for the MANET based on the centralized DNS mechanism used in the wired Internet. In order to adapt to the dynamic topology changes of the MANET, the mechanism handles the movement of the DNS server and the MANET merge/partition. "IPv6 Router Advertisement Option for NTP Server Configuration", Manav Bhatia, Dacheng Zhang, Dacheng Zhang, 19-Dec-11, This document specifies a new IPv6 Router Advertisement option to allow IPv6 routers to advertise Network Time Protocol version 4 or greater server location information to IPv6 hosts. "Experiences from Cross-Area Work at the IETF", Jari Arkko, 20-Dec-11, This memo discusses the reasons for IETF work on topics that cross area boundaries. Such cross-area work presents challenges for the organization of the IETF as well as on how interested parties can participate the work. The memo also provides some suggestions on managing these challenges. "Accurate ECN Feedback in TCP", Mirja Kuehlewind, Richard Scheffenegger, 21-Dec-11, Explicit Congestion Notification (ECN) is an IP/TCP mechanism where network nodes can mark IP packets instead of dropping them to indicate congestion to the end-points. An ECN-capable receiver will feedback this information to the sender. ECN is specified for TCP in such a way that only one feedback signal can be transmitted per Round-Trip Time (RTT). Recently new TCP mechanisms like ConEx or DCTCP need more accurate feedback information in the case where more than one marking is received in one RTT. "Internationalized Domain Name Mapping Extension for the Extensible Provisioning Protocol (EPP)", Francisco Obispo, Luis Munoz, 21-Dec-11, This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning of Internationalized Domain Names (IDN) stored in a shared central repository. This mapping extends the EPP domain name mapping to provide additional features required to implement registrations of domain names in characters sets other than ASCII. "Specification of an Adaptation Function Between Two Multicast Networks Supporting Different IP Versions", Tom Taylor, Cathy Zhou, 21-Dec-11, In some transitional multicast scenarios, the multicast signalling and content have to pass across network boundaries where one network supports IPv4, the other, IPv6. An adaptation function is required at the boundary to support such a scenario. This memo uses the term "Type 2 Adaptation Function" (AF2) for such a function. "A Mechanism for Negotiating Multi-Stream Continuous Presence Video in SIP", Adel Mostafa, 23-Dec-11, The NextGen video conferencing clients require multiple concurrent video streams to provide a User eXperience (UX) in which multiple participants can be viewed at the same time, this user experience is called Continuous Presence (CP) video. The multi-stream CP video provides more client control of the UX and less processing on the conference server since the video streams are relayed by the server rather than mixed to compose a CP video stream. The client CP layout, processing power and bandwidth limitations require a per stream bandwidth and resolution to be negtiated in the SIP Offer/ Answer with the conference server. Standard methods are used to achieve this negotiation in addition to a new SDP parameter. This document explains the methodology and solution to achieve this in SIP and SDP. "An AR-level solution support for Distributed Mobility Management", Zhengming Ma, Xun Zhang, 26-Dec-11, The number of mobile users and their traffic demand is expected to be ever-increasing in future years, and this growth can represent a limitation for deploying current mobility management schemes that are intrinsically centralized, e.g., Mobile IPv6 and Proxy MIPv6. This evolution in user traffic demand is tackled by a different approach for IP mobility, called Distributed Mobility Management, which is focusing on moving the mobility anchors from the core network and pushing them closer to the users, at the edge of the network. The work presented here copes with the distributed approach, describing a novel solution for distributed mobility management support in a flat architecture without central mobility anchors. This document strictly abides by the two principles: (a)The movement of MN is transparent to CN. (b)MN doesn't participate in any mobility-related signaling.MAAR and AAA are responsible for managing IP mobility on behalf of the host. "Working Group Consensus", S Moonesamy, 26-Dec-11, This memo discusses about Working Group rough consensus within the IETF. "Root Name Server Operational Requirements", Root Committee, 6-Feb-12, As the Internet has become critical to the world's social and economic infrastructure, attention has focused on the correct, safe, reliable, and secure operation of the Internet infrastructure itself. The DNS is considered a crucial part of that technical infrastructure. The root domain and its authoritative name servers are a part of that technical infrastructure. The primary focus of this document is to provide guidelines for secure, stable, and resilient authoritative name service for the root zone. Additionally it will look into some specifics for the operation of the name servers. Other operators of authoritative name servers such as those for generic top-level domains (gTLDs), country code top-level domains (ccTLDs) and other zones may also find this document useful. "Requirements for Mobility and Interconnection of Virtual Machine and Virtual Network Elements", Bhumip Khasnabish, Bin Liu, 28-Dec-11, In this draft, we discuss the issues and requirements related to migration, mobility, and interconnection of Virtual Machines (VMs)and Virtual Network Elements (VNEs). We also describe the limitations of various types of virtual local area networking (VLAN) and virtual private networking (VPN) techniques that are traditionally expected to support such migration, mobility, and interconnection. "Moving Authentication Header (AH) to Historic", Manav Bhatia, 29-Dec-11, This document recommends retiring Authentication Header (AH) and discusses the reasons for doing so. It recommends moving RFC 4302 to Historic status. "Evaluation of Proposed Homenet Routing Solutions", Lee Howard, 29-Dec-11, This document evaluates the various proposals for routing in an unmanaged home network. "Homenet Routing Requirements", Lee Howard, 29-Dec-11, This document describes the requirements for routing in an unmanaged home network. "Load sharing support for MAGs in Proxy Mobile IPv6", Haisheng Jiang, 29-Dec-11, Proxy Mobile IPv6 (PMIPv6) is standardized by IETF to supply mobility management for mobile nodes (MN) in a local small area. When the numbers of MNs which attaching to the same MAG is very large, it will cause the problem that the arrival rate of data traffic is far surpass the process capacity of the MAG. So the MAG will suffer from process bottleneck. The IETF is working on optimization for PMIPv6. This document proposes a load sharing solution for MAGs by migrating the Picked Mobile Node (PMN) to some MAGs without overload to sharing the traffic load, which can relieve stress of the overloaded MAG and improve the performance of PMIPv6 network. "p2mp pw protection for mpls-tp network", Yu jinghai, Guoman Liu, Tu XiaoPing, Xu Xueqiong, 29-Dec-11, According to one protection Requirement in RFC 5654, Requirement 63 :It MUST be possible to provide protection for the MPLS-TP data plane without any IP forwarding capability in the MPLS-TP data plane. and it requires mpls-tp date plane should be independent of its control plane. so it is necessary for the 1:1 protection of p2mp pw to have a return path to coordinate the switch state between root node and each leaf node. for the above problem statement, the document provides a solution to protect p2mp pw by using one leaf node as protector for another leaf node. so it may avoid setting up a return path for each leaf node. This document is a product of a joint Internet Task Force(IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. "IKEv2 Configuration Payload Extension for Private IPv4 Support for Fixed Mobile Convergence", Tricci So, 7-Feb-12, IPSec IKEv2, RFC 5996 [RFC5996], has been adopted by many standardized network solutions to provide the secure transport between network elements over third party's infrastructure. For example, the emerging Fixed Mobile Convergence (FMC) network solution that involves Femtocell deployment requires the mobile operator's Femtocell AP to leverage the IPSec IKEv2 to support mutual authentication and remote IP address configuration as well as other auto configuration support over the broadband fixed network (BBF) of which the mobile and fixed networks may be operated by two different operators. Most of today broadband fixed networks are still relying on the IPv4 private addressing plan to support its attached devices including the mobile operator's Femtocell AP. Hence, the private IPv4 addressing and Network Address and Port Translation (NA(P)T) support mostly likely stays for many years to come. In FMC interworking scenario, there is a need for the mobile network to pass on it mobile subscribers' policies to the broadband fixed network (BBF) to maintain the service level agreement (SLA) and to support remote network management. In addition, a broadband fixed network (BBF) may partnership with more than one mobile operator. Therefore it is important for the BBF and the mobile network to be able to overcome the limitation of the private IPv4 addressing and to be able to identify the user's subscription as well as to determine the location of the Femtocell AP that serves its mobile user over the BBF network. This document presents the problems for the IPSec tunneling support with private IPv4 addressing for FMC interworking and proposes a simple extension to the IKEv2 to resolve the issues. "Resource Reservation Protocol - Traffic Engineering(RSVP-TE) Extensions for Inter-AS P2MP TE LSPs", KeJun Li, 29-Dec-11, [RFC4875] describes extensions to RSVP-TE protocol for building a P2MP TE LSP in MPLS/GMPLS network environment.However, [RFC4875] doesn't specify path selecting problem of inter-AS P2MP TE LSP.This document specifies an inter-AS P2MP path computation method based on extentions to RSVP-TE Protocol. "Datacenter Solution Approaches", Ashish Dalela, 30-Dec-11, There are many approaches to addressing virtualized datacenter scaling problems. Examples of these approaches include, L2 vs. L3 forwarding, host-based vs. network-based solutions, fat-access and lean-core vs. fat-core and lean-access, flat addressing vs. encapsulation, protocol learning vs. directories for location discovery, APIs vs. protocols for orchestration, etc. Different solutions being proposed today take one or more of these approaches in combination, although sometimes the question of approach itself may not be settled. Given the multiple facets of the datacenter problem, and many approaches to solve each problem, it becomes hard to discuss a solution when some approaches may be acceptable while others are not. This document discusses the pros and cons of various approaches. The goal is not to describe a specific solution, but to evaluate the various approaches. This document concludes with a set of recommendations on which approaches are most optimal for a holistic solution to the entire problem set. "Datacenter Network and Operations Requirements", Ashish Dalela, 30-Dec-11, The problems of modern datacenters are rooted in virtualized host scaling. Virtualization implies VM mobility, which may be intra- datacenter or inter-datacenter. Mobility may cross administrative boundaries, such as across private-public domains. A public datacenter may be multi-tenant, extending several private networks into the public domain. Running these massively scaled, virtualized, multi-tenant datacenters poses some unique networking and operational challenges. This document describes these challenges. "Hierachical PCE Extensions for Inter-Domain Point-to-Multipoint Path Computation", KeJun Li, 30-Dec-11, The hierachical Path Computation Element (PCE) architecture defined in [PCE-HIERARCHY-FWK] allows the optimum sequence of domains to be selected, and the optimum end-to-end path to be derived through the use of a hierarchical relationship between domains. This document defines the hierachical PCE (H-PCE) extensions for the purpose of implementing inter-domain P2MP Path Computation. "Avoiding Authentication Header (AH)", Manav Bhatia, 1-Jan-12, This document recommends retiring Authentication Header (AH) and discusses the reasons for doing so. It recommends that AH must not be used for new applications and protocols, since Encapsulating Security Payload (ESP) using NULL encryption algorithm provides the same level of security in most real deployments. "CoRE Interfaces", Zach Shelby, Matthieu Vial, 7-Mar-12, This document defines well-known REST interface descriptions for Batch, Sensor, Parameter and Actuator types for use in contrained web servers using the CoRE Link Format. A short reference is provided for each type that can be efficiently included in the interface description attribute of the CoRE Link Format. These descriptions are intended to be for general use in resource designs or for inclusion in more specific interface profiles. In addition, this document defines the concept of Function Set to guide the creation of RESTful profiles. "Service Orchestration Protocol (SOP) Requirements", Ashish Dalela, Mike Hammer, 3-Jan-12, Cloud services need to interoperate across cloud providers, service vendors and private/public domains. To enable this interoperability, there is need for a standard protocol for exchanging service information. This draft describes requirements for such a protocol. Current cloud implementations expose application level APIs, which are not syntactically and semantically compatible with each other. One approach to interoperate cloud services is to standardize the protocol while leaving the API definition implementation specific. Standard protocols have been used widely in the Internet and can be extended to cloud. Use of such protocols is compatible with existing cloud APIs, which can exchange information in a standard protocol. New APIs may also be developed using a standard protocol. By this, it would be possible to interoperate diverse APIs across service providers, service vendors and service users. "Service Description Framework (SDF)", Ashish Dalela, Mike Hammer, 3-Jan-12, Cloud services need to interoperate across providers, vendors and private/public domains. To enable this interoperability, there should be a standard way to exchange service information. The purpose of this document is to detail different kinds of information necessary to describe services. We identify the following kinds of service- dependant information needed for any kind of service: - Method for naming services and identifying service classes. - Method for describing syntax for properties of service classes. - Method for defining semantics in a service class, by establishing "Service Orchestration Protocol", Ashish Dalela, Mike Hammer, 3-Jan-12, Cloud services need to interoperate across cloud providers, service vendors and private/public domains. To enable this interoperability, there is need for a standard wire-format for exchanging service information. This document describes a Service Orchestration Protocol (SOP) to be used as a standard wire-format for cloud exchanges. Similar to widely used protocols like HTTP, SIP and SMTP, SOP uses text-based messages, which are easily extensible and may be inspected at cloud proxies. While SOP carries service-independent information, service-dependant information is attached as a Service Description Framework [SDF] payload to SOP packets. This is similar to how HTML is transported over HTTP. SDF is a XML schema for describing services. SOP and SDF enable any kind of service to be discovered and orchestrated across private and public domains. Simple protocol compliance tests can be employed to ensure interoperability across domains. SOP wire-formats can be used with existing cloud APIs. Using these, it would be possible to interoperate diverse APIs and cloud services across service providers, service vendors and service users. "SOP Network Architecture", Ashish Dalela, Mike Hammer, 3-Jan-12, Cloud services need to interoperate across cloud providers, service vendors and private/public domains. To enable this interoperability, there is need for network level deployment architecture to connect users and providers. This document describes functionality partitioning in network deployment and the different advantages of using distributed functionality deployments. "SOP Message Flows", Ashish Dalela, Mike Hammer, 3-Jan-12, This document describes the Service Orchestration Protocol (SOP) message flows for some important service orchestration scenarios. The flows contain complete packet information including both SOP and Service Description Framework (SDF) payloads. The message flows in this document are by no means exhaustive, but they carry sufficient information using which other flows can be easily constructed. The deployment scenarios for services are varied, and it is not possible to cover every possible scenario. Nevertheless, those flows will follow closely the information given in this document. "BCP for ARP-ND Scaling for Large Data Centers", Igor Gashinsky, Linda Dunbar, Warren Kumari, 3-Jan-12, This draft is intended to document some simple well established practices which can scale ARP/ND in data center environment. "Hashed Password Exchange", Steven Bellovin, 11-Mar-12, Many systems (e.g., cryptographic protocols relying on symmetric cryptography) require that plaintext passwords be stored. Given how often people reuse passwords on different systems, this poses a very serious risk if a single machine is compromised. We propose a scheme to derive passwords limited to a single machine from a typed password, and explain how a protocol definition can specify this scheme. "DNS Security (DNSSEC) Authenticated Denial of Existence", R. Gieben, 4-Jan-12, The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record for authenticated denial of existence, and the NSEC3 resource record for hashed authenticated denial of existence. This document introduces an alternative resource record, NSEC4, which similarly provides authenticated denial of existence. It permits gradual expansion of delegation-centric zones, just like NSEC3 does. With NSEC4 it is possible, but not required, to provide measures against zone enumeration. NSEC4 reduces the size of the denial of existence response and adds Opt-Out to unhashed names. "A Route Optimization solution support for Distributed Mobility Management", Xun Zhang, Zhengming Ma, 4-Jan-12, The mobile users and their traffic demands are expected to be ever- increasing in future years, and this growth will impose a limitation for deploying current mobility management schemes that are intrinsically centralized, e.g., Mobile IPv6 and Proxy MIPv6. This evolution in user traffic demand can be tackled by a different approach for IP mobility, called Distributed Mobility Management, which is focusing on moving the mobility anchors from the core network and pushing them closer to the users, at the edge of the network. Following this idea, in our proposal, the central anchor is being deployed in the access router of the mobile node(MN). That is, the first elements that provide IP connectivity to a set of MNs are also the mobility managers for those MNs. In the following, we will call MAAR (Mobility anchor and Access Router). This draft strictly abides by the three principles: (1) The MN doesn't participate in any mobility-related signaling.MAAR and AAA are responsible for managing IP mobility on behalf of the host. (2) The MN's movement is transparent to the communication node (CN).The Home Address (HoA) and Care-of address (CoA) are not for users but for specific sessions in this draft.A MN initiates a session by using the MN's address assigned by a MAAR which the MN is registered as the HoA for this session.The MN's address assigned by a new MAAR which the MN moves to its access link as the CoA for the session. (3) The MN can directly forward packages to the CN and the packages don't need to pass the home mobility anchor. It can reduce the heavy burdens on home mobility anchor and maintain all the continuity of the conversation. "Support of fragmentation of RADIUS packets", Alejandro Perez-Mendez, Rafael Lopez, Fernando Pereniguez-Garcia, Gabriel Lopez-Millan, Diego Lopez, Alan DeKok, 29-Feb-12, This document describes a mechanism providing fragmentation support of RADIUS packets that exceed the 4 KB limit. "IRON Applicability for Multiple Interface Nodes", Fred Templin, 4-Jan-12, The Internet Routing Overlay Network (IRON) is a new internetworking and routing architecture that addresses important issues including routing scaling, network renumbering, mobility management, mobile networks, multihoming, traffic engineering, NAT traversal and security. In this document, we focus on IRON's applicability for multiple interface (mif) nodes. "RTCP XR Report Block for One Way Delay metric Reporting", Kevin Gross, Mario Montagud, 5-Jan-12, This document defines an RTCP XR Report Block that allows the reporting of One Way Delay metrics for use in a range of RTP applications. "vCard KIND:device", Gonzalo Salgueiro, Joe Clarke, Peter Saint-Andre, 17-Apr-12, This document defines a value of "device" for the vCard KIND property so that the vCard format can be used to represent computing devices such as appliances, computers, or network elements (e.g., a server, router, switch, printer, sensor, or phone). "Neighbor Discovery Enhancements for DOS mititgation", Warren Kumari, 8-Jan-12, In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of Neighbor Discovery can be vulnerable to denial of service attacks whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial of attacks can be launched intentionally (by an attacker), or result from legitimate operational tools that scan networks for inventory and other purposes. As a result of these vulnerabilities, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing ipv6 transported flows may be interrupted. This document describes possible modifications to the traditional [RFC4861] neighbor discovery protocol for improving the resilience of the neighbor discovery process as well as an alternative method for maintaining ND caches. "ILNP Architectural Description", R. Atkinson, SN Bhatti, 17-May-12, This document provides an Architectural description and the Concept of Operations for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This is a product of the IRTF Routing RG. "Multicast Geo-Distribution Control", Huajin Jeng, Yakov Rekhter, 9-Jan-12, Consider a content provider that wants to deliver a particular content to a set of customers/subscribers, where the provider and the subscribers are connected by an IP service provider. This document covers two areas needed to accomplish this: (1) providing the content provider with the information of whether it can use the multicast connectivity service provided by the IP service provider to deliver a particular content to a particular set of subscribers, and (2) providing the content provider with a mechanism to restrict delivery of a given content to a particular set of the subscribers. "Media Multihoming in SIP Sessions", Rohit verma, 9-Jan-12, This document discusses the requirements and procedures to achieve the multihoming of media for voice over IP sessions using the transport layer protocol as signaling Control Transmission Protocol. Media is an essential part of any voice over IP session. SIP (RFC 3261) is a text based signaling protocol and Multihoming using SIP can be achieved by using the SCTP as a transport protocol (RFC 4168), therefore the application level resiliency can be guaranteed even in case of any middle node or terminal failures. But any voice over IP or multimedia session is nearly insignificant, if the media path is broken during a call and is waiting for a timeout which further shall lead to a call drop.A complete solution to Multihoming can be achieved if a system is capable of a performing the failovers at both application and media plane and still maintaining the session irrespective of the application or media path failures or at least to detect a signaling or media path failure and terminate the session rather than waiting for timeouts. The requirement of Multihoming in media can also be derived from the fact that in any voice, video or data session, the signaling and call setup time use to be incomparably short than that of real media session at media plane. Therefore providing the resiliency at the signaling level does not provide the guaranteed and best effort service from a media session point of view as not only signaling but media is an integral part of it. "Multicast Transition Overview", Hitoshi Asaeda, Marshall Eubanks, Tina Tsou, Stig Venaas, 12-Mar-12, IPTV providers must serve content to their customers during the period of transition from IPv4 to IPv6. During this period, the content provider may support only one version of IP while the customer's receiver device supports only the other. Likewise, the network between the provider and its customer may include segments supporting only one version of IP or another. This document provides an overview of the multicast transition problem. It also provides an overview of the solution space. The solution space is characterized by an adaptation function (AF) that provides an interface between IPv4 and IPv6 multicast domains. This document also discusses various multicast use cases which may occur during IPv6 transitioning. These use cases motivate the solution space discussion and the requirements that appear at the end. "Mitigating Teredo Rooting Loop Attacks", Fernando Gont, 10-Jan-12, Recently, a number of routing loop vulnerabilities were discovered in the Teredo mechanism, which typically result in a Denial of Service of the involved systems, possibly also affecting the intervening networks. This document describes a number of security checks that can be performed by Teredo hosts and Teredo servers such that these vulnerabilities are eliminated. "Privacy Terminology and Concepts", Marit Hansen, Hannes Tschofenig, Rhys Smith, Alissa Cooper, 12-Mar-12, Privacy is a concept that has been debated and argued throughout the last few millennia. Its most striking feature is the difficulty that disparate parties encounter when they attempt to precisely define it. In order to discuss privacy in a meaningful way, a tightly defined context is necessary. The specific context of privacy used within this document is that of personal data in Internet protocols. Personal data is any information relating to a data subject, where a data subject is an identified natural person or a natural person who can be identified, directly or indirectly. A lot of work within the IETF involves defining protocols that can potentially transport (either explicitly or implicitly) personal data. This document aims to establish a consistent lexicon around privacy for IETF contributors to use when discussing privacy considerations within their work. Note: This document is discussed at https://www.ietf.org/mailman/listinfo/ietf-privacy "DNS Resource Records for ILNP", R. Atkinson, SN Bhatti, Scott Rose, 17-May-12, This note describes additional optional Resource Records for use with the Domain Name System (DNS). These optional resource records are for use with the Identifier-Locator Network Protocol (ILNP). This document is a product of the IRTF Routing RG. "ILNP Engineering Considerations", R. Atkinson, SN Bhatti, 17-May-12, This document describes common (i.e. version independent) engineering details for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing RG. "ICMP Locator Update message for ILNPv4", R. Atkinson, SN Bhatti, 17-May-12, This note defines an experimental ICMP message type for IPv4 used with the Identifier-Locator Network Protocol (ILNP). The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP. The ICMP message defined herein is used to dynamically update Identifier/Locator bindings for an existing ILNP session. This is a product of the IRTF Routing RG. "ICMP Locator Update message for ILNPv6", R. Atkinson, SN Bhatti, 17-May-12, This note specifies an experimental ICMPv6 message type used with the Identifier-Locator Network Protocol (ILNP). The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP. This message is used to dynamically update Identifier/Locator bindings for an existing ILNP session. This is a product of the IRTF Routing RG. "IPv6 Nonce Destination Option for ILNPv6", R. Atkinson, SN Bhatti, 17-May-12, The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP. ILNP has multiple instantiations. This document describes an experimental Nonce Destination Option used only with ILNP for IPv6 (ILNPv6). This document is a product of the IRTF Routing RG. "IPv4 Options for ILNPv4", R. Atkinson, SN Bhatti, 17-May-12, This document defines 2 new IPv4 options that are used only with ILNP for IPv4 (ILNPv4). ILNP is is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing RG. "MAP Translation (MAP-T) - specification", Congxiao Bao, Xing Li, Yu Zhai, Tetsuya Murakami, Wojciech Dec, 9-Mar-12, This document specifies the "Mapping of Address and Port" (MAP) double stateless translation based solution (MAP-T) for providing IPv4 hosts connectivity to and across an IPv6 domain. "Email Policy Service Trust Processing", Jim Schaad, 12-Mar-12, Write Me "Auto-Configuration of Designated VLANs", Mingui Zhang, Liangliang Ma, Xudong Zhang, 10-Jan-12, When RBridges are connected by a bridge LAN link, they need to select out a Designated VLAN to be used for PDU exchange and TRILL data forwarding. This document specifies an approach for RBridges to automatically determine a Designated VLAN on a LAN link for default configured RBridges. When a DVLAN has to be changed for the sake of a better connectivity of a LAN link, RBridges can change their Designated VLAN with least traffic interruption according to the soft Designated VLAN change method. "Signalling Media Stream ID in the Session Description Protocol", Harald Alvestrand, 25-Jan-12, This document specifies how the association between the RTP concept of SSRC and the WebRTC concept of "media stream" / "media stream track" is carried using SDP signalling. This document is an input document for discussion. It should be discussed in the RTCWEB WG list, rtcweb@ietf.org. "TRILL: Traffic Engineering", Jacni Qin, Donald Eastlake, Radia Perlman, 11-Jan-12, This document specifies the control plane procedures to support Traffic Engineering (TE) in the TRILL protocol. Traffic Engineering permits management configuration of the path followed by certain unicast frames in a TRILL campus. "RADIUS Attribute for MAP", Peter Deacon, Sheng Jiang, Yu Fu, 11-Jan-12, Mapping of Address and Port (MAP) is a stateless mechanism for running IPv4 over IPv6-only infrastructure. It provides both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co- existing period. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) MAP options has been defined to configure MAP Customer Edge (CE). However, in many networks, the configuration information may be stored in Authentication Authorization and Accounting (AAA) servers while user configuration is mainly from Broadband Network Gateway (BNG) through DHCPv6 protocol. This document defines a Remote Authentication Dial In User Service (RADIUS) attribute that carries MAP configuration information from AAA server to BNG. The MAP RADIUS attribute are designed following the simplify principle. It provides just enough information to form the correspondent DHCPv6 MAP option. "The SEAL IPv6 Destination Option", Fred Templin, 13-Jan-12, The Subnetwork Encapsulation and Adaptation Layer (SEAL) provides a mid-layer header designed for the encapsulation of an inner network layer packet within outer network layer headers. SEAL also supports a transport mode of operation, where the inner payload corresponds to an ordinary transport layer payload. However, SEAL can also provide benefit when used as an IPv6 destination option that contains a digital signature inserted by the source. The source can thereafter use the signature to verify that any ICMPv6 messages received actually came from a router on the path, while destinations that share a secret key with the source can verify the signature to ensure data origin authentication. "Internet+ Architectural Framework", Jean-Francois Morfin, 27-Mar-12, This memo acknowledges the change of scale in network and people centricities within the whole digital ecosystem. It shows how the Internet technology can sustain the resulting network and societal effects in scaling itself from the end to end Internet to a fringe to fringe fully optional and compatible Internet+ which strictly conforms to the Internet architecture and RFCs. It introduces the Internet+ architectural framework and the IUTF to document it. It explores a transition that can be seamlessly immediate and will probably start a complete review and extension of the Internet schemas towards the semiotic Internet (Intersem). "Miscellaneous CoAP Group Communication Topics", Esko Dijk, Akbar Rahman, 13-Jan-12, This document contains miscellaneous text around the topic of group communication for the Constrained Application Protocol (CoAP). The first part contains, for reference, text that was removed from the Group Communication for CoAP draft. The second part describes group communication and multicast functionality that may be input to future standardization in the CoRE WG. "Optional Advanced Deployment Scenarios for ILNP", R. Atkinson, SN Bhatti, 17-May-12, This document provides an Architectural description and the Concept of Operations of some optional advanced deployment scenarios for the Identifier-Locator Network Protocol (ILNP), which is an evolutionary enhancement to IP. None of the functions described here is required for the use or deployment of ILNP. Instead, it offers descriptions of engineering and deployment options that might provide either enhanced capability or convenience in administration or management of ILNP-based systems. "ARP Extension for ILNPv4", R. Atkinson, SN Bhatti, 17-May-12, This document defines an Address Resolution Protocol (ARP) extension to support ILNP for IPv4 (ILNPv4). ILNP is is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing RG. "Stateless IPv6 delivery within IPv4 (V6 via V4)", Peter Tattam, 15-Jan-12, This document describes a method for transmitting IPv6 packets directly to and from IPv4 hosts via the IPv4 network in a stateless manner using an IPv4 header option and transponders. Additionally described is a mechanism to automatically locate IPv6 network transponders via well known IPv4 and IPv6 network prefixes. "RTCP message for Receiver Estimated Maximum Bitrate", Harald Alvestrand, 17-Jan-12, This document proposes an RTCP message for use in experimentally- deployed congestion control algorithms for RTP-based media flows. "Trace Fields in mail-related specifications", S Moonesamy, 17-Jan-12, The memo provides background information about trace fields in mail standards. It discusses about the use of trace fields in mail- related specifications. "Overlay Path Option for IP and TCP", Brandon Williams, 29-Mar-12, Data transport through overlay networks often uses either connection termination or network address translation (NAT) in such a way that the public IP addresses of the true endpoint machines involved in the data transport are invisible to each other. This document describes IPv4, IPv6, and TCP options for communicating this information from the overlay network to the endpoint machines. "Labels for Common Location-Based Services", Andrea Forte, Henning Schulzrinne, 18-Jan-12, This document creates a registry for describing the types of services available at a specific location. The registry is expected to be referenced by other protocols that need a common set of service terms as protocol constants. In particular, we define location-based service as either a point at a specific geographic location (e.g., bus stop) or a service covering a specific region (e.g., pizza delivery). "CDNi Content De-duplication Optimization", WeiYi Jin, Wei Wang, ZhenWu Hao, Yu Meng, 18-Jan-12, Some CDNi deployments are likely to lead to content repetition in the same dCDN. This document gives the cases and then discusses the optimization approach to de-duplicate of the repeated content in CDNi network. To implement the optimization, the enhancement to CDNi metadata model and interface is required. "Mail Header Trace Fields", S Moonesamy, John Levine, 22-Jan-12, SMTP mail software adds trace fields to messages as they pass through the mail system. This memo provides background information about trace fields in mail standards. It discusses the use of trace fields in mail-related specifications. It updates the definition of trace header fields, and adds trace field information to the relevant registries. "IKEv2 Configuration Payload Extension for Notarizing Femtocell in Mobile Core Network", Zaifeng Zong, 18-Jan-12, IPSec IKEv2, RFC 5996 [RFC5996], has been adopted by many standardized network solutions to provide the secure transport between network elements over third party's infrastructure. Today Femtocell deployment requires the mobile operator's Femtocell AP (FAP) to leverage the IPSec IKEv2 to support mutual authentication and data protection between the insecure Femtocell, which typically deployed in customer's premise, and its corresponding mobile core network. A known security threat exists in Femto architecture for failing to validate the FAP's identity and information provided by FAP at the mobile operator's core network. This document reviews this security threat and proposes a simple extension of the IKEv2 to resolve the issue. "On Firewalls in Internet Security", Fred Baker, 20-Jan-12, There is an ongoing discussion regarding the place of firewalls in security. This note is intended to capture and try to make sense out of it. "Using PCP to Find an External Address in an NPTv6 Network", Fred Baker, Dan Wing, 20-Jan-12, This note describes an approach to finding the set of External Addresses associated with an Internal Address. Requirements "Link Management Protocol Extensions for Grid Property Negotiation", Yao Li, Ramon Casellas, Yu Wang, 7-Mar-12, The recent updated version of ITU-T [G.694.1] has introduced the flexible-grid DWDM technique, which provides a new tool that operators can implement to provide a higher degree of network optimization than is possible with fixed-grid systems. This document describes the extensions to the Link Management Protocol (LMP) to negotiate link grid property between the adjacent DWDM nodes before the link is brought up. "Extending the Application-Layer Traffic Optimization (ALTO) Protocol", Enrico Marocco, Vijay Gurbani, 20-Jan-12, The Application-Layer Traffic Optimization (ALTO) protocol is designed to allow entities with knowledge about the network infrastructure to export such information to applications that need to choose one or more endpoints to connect to among large sets of logically equivalent ones. The primary use case for the ALTO protocol was peer-to-peer applications for file sharing, video streaming and realtime communications, usually running on end-user devices. However, a number of other applications executing in more controlled environments may also benefit from the information that can be exported through the ALTO protocol. The use cases that have received significant attention include Content Delivery Networks (CDNs), distributed applications running in large datacenters, as well as systems made of inter-communicating ALTO servers. To apply ALTO to these new use cases, this document aims to foster a discussion to determine if, and how, the ALTO protocol could be extended to provide a simple yet useful view of a computational environment that goes beyond the static (or near static) network topology and cost map information. "IPv4-Embedded IPv6 Multicast Address Format", Mohamed Boucadair, Jacni Qin, Yiu Lee, Stig Venaas, Xing Li, Mingwei Xu, 23-Jan-12, This document specifies an extension to the IPv6 multicast addressing architecture to be used in the context of IPv4-IPv6 interconnection. In particular, this document defines an address format for IPv4- embedded IPv6 multicast addresses. This address format can be used for IPv4-IPv6 translation or encapsulation schemes. This document updates RFC4291. "Support of SDES in WebRTC", Oscar Ohlsson, 23-Jan-12, Which key management protocols to support has been lively debated in WebRTC on several occasions. This document explains the benefits of SDES and argues why allowing it as an alternative option has little impact on security. "Session Initiation Protocol (SIP) Load balancing survey", Parthasarathi Ravindran, Vijay Gurbani, Paul Erkkila, 23-Jan-12, SIP Load balancing across a farm of SIP servers can be done today, but without generally agreed upon principles on how to best do accomplish this. Confounding the problem is that a SIP farm may consist of hosts with varying capabilities, example, a SIP proxy, a back-to-back user agent (B2BUA), a public-switched telephone system (PSTN) gateway, SIP Media servers etc. The capabilities and processing capacity on hosts in the farm may be different, sometimes vastly, from each other. This document present the survey of existing literature and common practice on SIP load balancing. "RTCWEB Generic Identity Provider Interface", Eric Rescorla, 12-Mar-12, Security for RTCWEB communications requires that the communicating endpoints be able to authenticate each other. While authentication may be mediated by the calling service, there are settings in which this is undesirable. This document describes a generic mechanism for leveraging existing identity providers (IdPs) such as BrowserID or OAuth to provide this authentication service. "Traceflow", Balaji Venkataswami, Richard Groves, Peter Hoose, 24-Jan-12, This document describes a new OAM protocol - TraceFlow that captures information pertaining to a traffic flow along the path that the flow takes through the network. TraceFlow is ECMP and link-aggregation aware and captures the information about constituent members through which the traffic flow passes. TraceFlow gathers information that is relevant to the flow such as outgoing interface Layer 3 address, Next-hop to which the packet of the flow is forwarded, effect of network policies such as access control lists on the flow. This draft requires the Traceflow protocol to be processed by Layer 3 devices only. Devices such as Layer 2 devices, MPLS LERs/LSRs along the way are passed through without any processing as if in a pass-through mode. IP tunnels such as IP-in-IP, IP-in-GRE mechanisms are expected to pass the Traceflow packets through them using the pass through mode. For achieving its purpose Traceflow advocates the use of a specific UDP destination port to be assigned from IANA. "CoAP Proxy Encode-To Option", Guido Moritz, 24-Jan-12, The scope of this document is to propose a new option to be used in conjunction with the CoAP proxy mechanisms. Several content types can be converted stateless into each other. The conversion may result in much more efficient representation of the resource. But currently no mechanism exists to indicate the proxy to perform the compression. "A PMIPv6-based solution for Distributed Mobility Management", Carlos Bernardos, Antonio de la Oliva, Fabio Giust, Telemaco Melia, Rui Costa, 12-Mar-12, The number of mobile users and their traffic demand is expected to be ever-increasing in future years, and this growth can represent a limitation for deploying current mobility management schemes that are intrinsically centralized, e.g., Mobile IPv6 and Proxy Mobile IPv6. For this reason it has been waved a need for distributed and dynamic mobility management approaches, with the objective of reducing operators' burdens, evolving to a cheaper and more efficient architecture. This draft describes multiple solutions for network-based distributed mobility management inspired by the well known Proxy Mobile IPv6. "MPLS Transport Profile Linear Protection MIB", Kingston Selvaraj, Vishwas Manral, Daniel King, 26-Jan-12, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing MPLS Transport Profile (MPLS-TP) Linear Protection. "Text Encodings of Some Security Related Structures", Simon Josefsson, 27-Jan-12, This document describe and discuss the text encodings of Public-Key Infrastructure using X.509 (PKIX) Certificates, PKIX Certificate Revocation Lists (CRLs), PKCS #10 Certificate Request Syntax, PKCS #7 structures, and Attribute Certificates. The text encodings are well- known, implemented by several applications and libraries, and is widely deployed. This document is intended to articulate the de- facto rules that existing implementations operate by, and to give recommendations that will promote interoperability going forward. "Unified User-Agent String (UUAS)", Mateusz Karcz, 27-Jan-12, User-Agent is a header used by certain protocols, e.g. HTTP. Unified User-Agent String is intended to unification of that complicated strings. "MAP Encapsulation (MAP-E) - specification", Ole Troan, Satoru Matsushima, Tetsuya Murakami, 27-Jan-12, This document specifies the "Mapping of Address and Port" (MAP) encapsulation based solution (MAP-E) with an automatic tunneling mechanism for providing IPv4 connectivity service to end users over a service provider's IPv6 network. "Problem Statement of SAVI Beyond the First Hop", Jun Bi, Bingyang Liu, 23-May-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 techniques for source address validation beyond the first hop (SAVI-BF) may be needed to complement SAVI. In the document, we analyze the problems of the current SAVI-BF technique, and discuss the directions we can explore to improve SAVI-BF. "SRV record query extension for XMPP", Akari Harada, Hirotaka Sato, Nobuo Ogashiwa, Yoshihiro Suzuki, 29-Jan-12, According to RFC 6120, XMPP clients should use SRV records within the connection establishment process to servers. There are two purposes for using SRV records. The one is to advertise the FQDN of at least one server to clients to establish an initial TCP connection. The other purpose is to advertise at least two or more FQDN with priority and weight information to clients to accomplish load balancing, a redundant server environment and so on. However, most standard resolver libraries of recent client OSs don't support SRV record resolution. Furthermore, many DNS hosting services also don't support SRV records. This document proposes a solution that enables a server and client to achieve load balancing and a redundant server environment in case SRV records cannot be used. Moreover, the proposed IQ-result message can include minimum wait time to reconnect, allowing clients to reconnect after the most suitable wait time avoiding congestion. "Reporting Unobserved Fields in IPFIX", Paul Aitken, 30-Jan-12, The IPFIX protocol is designed to export information about observations, and lacks a method for reporting that observations are unavailable. This document discusses several methods for reporting when fields are unavailable, reviews the advantages and disadvantage of each, and recommends methods which should be used. "Experiences with RPL: IPv6 Routing Protocol for Low power and Lossy Networks", Thomas Clausen, Axel Verdiere, Jiazi Yi, Ulrich Herberg, Yuichi Igarashi, 16-Apr-12, With RPL - the "IPv6 Routing Protocol for Low-power Lossy Networks" - having been published as a Proposed Standard after a ~2-year development cycle, this document presents an evaluation of the resulting protocol, of its applicability, and of its limits. The documents presents a selection of observations of the protocol characteristics, exposes experiences acquired when producing various prototype implementations of RPL, and presents results obtained from testing this protocol - by way of network simulations, in network testbeds and in deployments. The document aims at providing a better understanding of possible weaknesses and limits of RPL, notably the possible directions that further protocol developments should explore, in order to address these. "Network Virtualization Overlay Control Protocol Requirements", David Black, Dinesh Dutt, Lawrence Kreeger, Murari Sridhavan, Thomas Narten, 30-Jan-12, The document draft-narten-nvo3-overlay-problem-statement-01 discusses the needs for network virtualization using overlay networks in highly virtualized data centers. The problem statement outlines a need for control protocols to facilitate running these overlay networks. This document outlines the high level requirements to be fulfilled by the control protocols. "Routes Optimization for PMIPv6 Multicast", Juan Liu, Wen Luo, Wei Yan, 30-Jan-12, To support IP multicasting in PMIPv6 domain, MULTIMOB WG has issued several proposals including the base solution,dedicated schemes and direct routing which requires all communications to go through the local mobility anchor(LMA),the dedicated server and the native multicasting infrastructure ,respectively. As this can be suboptimal, localized routing (LR) allows multicast source attached to the same or different mobile access gateways(MAG) with mobile node to send multicast data by using localized forwarding or a direct tunnel between the gateways without any dedicated devices or dependence of the native multicasting infrastructure. This document describes multicast routes optimazition mechanisms for localized routing.The MAG and the LMA are the mobility entities defined in the PMIPv6 protocol and act as PIM-SM routers. "Reverse Path Forwarding Check under Multiple Topology TRILL", Mingui Zhang, 30-Jan-12, Multi-homing (RBridge Aggregation) is a promising approach to increase the reliability and access bandwidth of TRILL edge. Active- active forwarding in multi-homing allows multiple RBridges forward data frames for VLAN-x on a LAN link, which creates the possibility that multicast frames from a specific ingress RBridge may arrive at multiple incoming ports of a remote RBridge. This violates the Reverse Path Forwarding Check and multicast frames arrives at unexpected incoming ports will be discarded by this RBridge. This document makes use of multiple topology TRILL to solve this problem. Multiple topology TRILL provides physical separation of traffic from different members of aggregation. Multicast frames from aggregation members comply with the Reverse Path Forwarding Check per topology. "SADI: Semantic Automated Discovery and Integration", Ben Vandervalk, E. McCarthy, Mark Wilkinson, 31-Jan-12, This document describes Semantic Automated Discovery and Integration (SADI), a set of best practices for implementing stateless web services that consume RDF data as input and generate RDF data as output. The goal of SADI is to establish conventions that will enable a much higher level of interoperability between web services from independent providers than is currently possible under the widespread use of WSDL/XML and RESTful services. Under SADI, interoperability depends on the shared use of predicate vocabularies, rather than the shared use of particular XML schemas, JSON structures, or ad hoc data formats. Through the use of OWL to describe service input and output datatypes, SADI enables: i) automated discovery of services that provide data or computations of interest, and ii) automated matchmaking between local data and available services. By iterative application of the former two capabilities, SADI enables semi-automated construction of arbitrarily complex workflows across independent service providers. "Definitions of Managed Objects for 4rd", Yu Fu, Sheng Jiang, Jiang Dong, Peng Wu, 31-Jan-12, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines managed objects for 4rd. "A CoAP REST API for XMPP Publish-Subscribe", Klaus Hartke, 31-Jan-12, The REST API defined in this document enables Constrained Application Protocol (CoAP) clients to interact with Extensible Messaging Protocol (XMPP) Publish-Subscribe services by delegating the task of creating, retrieving, updating and deleting pubsub items and nodes to a CoAP/XMPP proxy. "Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs", Yakov Rekhter, Rahul Aggarwal, 31-Jan-12, When IP multicast trees created by PIM-SM in ASM mode need to pass through an MPLS domain, it may be desirable to map such trees to Point-to-Multipoint Label Switched Paths. This document describes how to accomplish this in the case where such Point-to-Multipoint Label Switches Paths are established using mLDP. Specification of Requirements "Security Descriptions Extension for Media Streams", Sujing Zhou, Tian Tian, 26-Mar-12, This document provides an extension to the cryptographic attribute (RFC 4568) defined for Session Description Protocol (RFC 4566) to enhance end-to-end communication security, so that some scenarios, e.g., forking and re-targeting can especially benefit from the extension. The usage of the provided extension in Secure Real-time Transport Protocol (SRTP, RFC3711) is also defined in this document. "CDNi Content De-duplication Optimization", WeiYi Jin, Wei Wang, ZhenWu Hao, Yu Meng, 1-Feb-12, Some CDNi deployments are likely to lead to content repetition in the same dCDN. This document gives the cases and then discusses the optimization approach to de-duplicate of the repeated content in CDNi network. To implement the optimization, the enhancement to CDNi metadata model and interface is required. "Distributed Mobile IPv6", Behcet Sarikaya, 1-Feb-12, As networks are moving towards flat architectures, a distributed approach is needed to Mobile IPv6. This document defines a distributed mobility management protocol. Protocol is based on Mobile IPv6 and its extensions for multiple care of address registration, flow mobility and dual stack mobile IPv6 with minimum extensions. Control and data plane separation is achieved by separating Home Agent functionalities into the control and data planes. "Tiny Fragments in IPv6", Vishwas Manral, 2-Feb-12, IPv6 fragmentation allows fragments to be sent only by the source of a packet. The Fragment header is used by an IPv6 source to send a packet larger than would fit in the path MTU to its destination. Firewalls generally use 5-tuples to filter out packets. However there are cases where fragmentation can be used to disguise TCP packets from IP filters used in routers and hosts. This document specifies where tiny fragments can be issues. "Constructing protection paths for inter-AS, inter-sub-AS P2MP TE-LSPs", Balaji Venkat, Gaurav Raina, 2-Feb-12, Constructing primary and backup explicit path Point-to-Multipoint Label Switched Paths is important from the point of view of providing protection switching in case the primary fails. It is absolutely essential that the backup P2MP LSPs constructed do not share risk with any of the links and nodes of the primary path. In the case of inter-AS P2MP TE-LSPs or in the case of inter-sub-AS (in the case of BGP-Confederations being deployed) P2MP TE-LSPs where BGP confederations are deployed within an AS, such protection switching can be provided by calculating primary and backup multicast distribution trees (read P2MP TE-LSPs) that dont intersect with each other. In this paper we propose a method by which inter-sub-AS P2MP TE-LSPs (hence even inter-AS P2MP TE-LSPs) can be constructed by first finding the AS level topology of the network (be it inter-AS or inter-sub-AS within a single AS) in question and secondly to compute the paths in such a way that they dont intersect or if necessary in the worst case partially intersect each other. The proposed scheme is explained with an example and subsequent discussion is done to elucidate its benefits to multicast in particular. "A More Granular Web Origin Concept", Yoav Nir, 5-Mar-12, This document defines an HTTP header that allows the partitioning of a single origin (as defined in RFC 6454) into multiple origins, so that the same origin policy applies among them. The header introduced in this document allows a portal to specify that resources that appear to be from the same origin should, in fact, be treated as though they are from different origins, by extending the 3-tuple of the origin to a 4-tuple. A compliant user agent is expected to apply the same-origin policy according to the 4-tuple rather than the 3-tuple. "Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers", Marc Petit-Huguenin, Suhas Nandakumar, Gonzalo Salgueiro, Paul Jones, 12-Mar-12, This document specifies the syntax of Uniform Resource Identifier (URI) schemes for the Traversal Using Relays around NAT (TURN) protocol. It defines two URI schemes that can be used to provision the configuration values needed by the resolution mechanism defined in [RFC5928]. "A Convention for HTTP Access to JSON-Based Resources", Paul Bryan, 15-Feb-12, A convention for accessing JSON representations of resources via HTTP, promoting a uniform interface across multiple disparate resources and reuse of software components. "Distributed Mobility Anchoring", Pierrick Seite, Philippe Bertin, 3-Feb-12, Most existing IP mobility solutions are derived from Mobile IP principles where a given mobility anchor maintains Mobile Nodes (MNs) binding up-to-date. Data traffic is then encapsulated between the mobility anchor and the MN or its Access Router. These approaches are usually implemented on a centralised architectures where both MN context and traffic encapsulation need to be processed at a central network entity, i.e. the mobility anchor. However, one of the trend in mobile network evolution is to "flatten" mobility architecture by confining mobility support in the access network, e.g. at the access routers level, keeping the rest of the network unaware of the mobility events and their support. This document discusses the deployment of a Proxy Mobile IP approach in such a flat architecture. The solution allows to dynamically distribute mobility functions among access routers. The goal is also to dynamically adapt the mobility support of the MN's needs by applying traffic redirection only to MNs' flows when an IP handover occurs. "Multi-Stream Media Conferencing", Magnus Westerlund, Bo Burman, 3-Feb-12, This memo describes a multimedia multi-party conferencing architecture based on use of multiple Real-Time Transport Protocol (RTP) streams. "Requirements for Labeled NFS", David Quigley, James Morris, Jarrett Lu, Stephen Smalley, Thomas Haynes, 9-Feb-12, This Internet-Draft outlines high-level requirements for the integration of flexible Mandatory Access Control (MAC) functionality into NFSv4.2. It describes the level of protections that should be provided over protocol components and the basic structure of the proposed system. It also gives a brief explanation of what kinds of protections MAC systems offer. "Requirements and Framework for Unified MPLS Sub-Network Interconnection", David Allan, 11-Mar-12, The definition of a transport profile for MPLS means that MPLS network architectures will emerge that combines both managed and control plane driven MPLS sub-networks and requires interconnection of same to achieve a unified MPLS architecture. This document generalizes the problem of sub-network interconnect, discusses issues in general and suggests ways forward. "Challenges in Smart Object Security: too many layers, not enough ram", Michael Richardson, 7-Feb-12, This is a position paper for the pre-IETF83 Workshop on Smart Object Security. The author contends that layer-2 security solutions are not only in-adequate, but may in fact be harmful when deployed into smart object systems. While layer-2 security services may be valuable, they must be channel bound up to the layer-7 application layer. "MPTCP Proxies and Anchors", Georg Hampel, Thierry Klein, 8-Feb-12, MPTCP proxies and anchors are network-based functions, which support MPTCP connections. The MPTCP proxy provides multipath support for MPTCP-capable hosts on behalf of their MPTCP-unaware peers. This facilitates incremental deployment of MPTCP. The MPTCP anchor permits subflow establishment for MPTCP connections when direct interaction between end hosts fails. This permits tolerance to local IP protocol restrictions and it provides robustness in case of break- before-make mobility events. MPTCP proxies and anchors are especially suited for wireless access environments. "IP Address Schemes for Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces", Manav Bhatia, Marc Binderberger, Sami Boutros, Nobo Akiya, 8-Feb-12, This document describes techniques which can be used by a router to obtain or discover remote neighbor IP address in order to establish micro Bidirectional Forwarding Detection (BFD) sessions [BFD-ON-LAGS]. "Reducing Power Consumption using BGP", Shankar Raman, Balaji Venkat, Gaurav Raina, 2-May-12, In this paper, we propose a framework to reduce the aggregate power consumption of the Internet using a collaborative approach between Autonomous Systems (AS). We identify the low-power paths among the AS and then use Traffic Engineering (TE) techniques to route the packets along the paths. Such low-power paths can be identified by using the 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. "Radio to Router Interface Framework and Requirements", Bow-Nan Cheng, David Ward, Leonid Veytser, 10-Feb-12, In highly dynamic, heterogeneous radio MANET environments where links are constantly changing, standardizing information exchange between the radio and router such that routers can make informed routing decision based on link layer information over heterogeneous link types becomes a key area to address. This document defines the basic framework for radio-to-router interface communications as well as requirements and considerations for evaluating radio-to-router interface technologies for use in MANETs. "Automatic VLAN allocation in E-tree", Ran Chen, 27-Mar-12, This document proposes to use automatically allocated VLAN ID to indicate E-Tree attribute. For the E-Tree requirement, please refer to [I-D.ietf-l2vpn-etree-reqt] for detail. "Mapping RTP streams to CLUE media captures", Roni Even, 12-Mar-12, This document describes mechanisms and recommended practice for mapping RTP media streams defined in SDP to CLUE media captures. "CDNI Logging Interface", Gilles Bertrand, Stephan Emile, 13-Feb-12, This memo specifies the Logging interface between a downstream CDN (dCDN) and an upstream CDN (uCDN). It introduces a framework, an architecture design and a set of new requirements. Then it drafts an information model. "NAT64 Operational Experiences", Gang Chen, Zhen Cao, Cameron Byrne, Qibo Niu, 12-Mar-12, This document summarizes some stateful NAT64 deployment scenarios and operational experiences for NAT64-CGN and NAT64-CE. "IPv6 packet staining", Tyson Macaulay, 13-Feb-12, This document specifies the application of security staining on an IPv6 datagrams and the minimum requirements for IPv6 nodes staining flows, IPv6 nodes forwarding stained packets and interpreting stains on flows. The usage of the packet staining destination option enables proactive delivery of security intelligence to IPv6 nodes such as firewalls and intrusion prevention systems, and end-points such servers, workstations, mobile and smart devices and an infinite array of as- yet-to-be-invented sensors and controllers. "Extension to VPLS for E-Tree Using Multiple PWs", Rafi Ram, Daniel Cohn, Raymond Key, Puneet Agarwal, Joshua Rogers, 5-Mar-12, This document proposes a solution for Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) support in Virtual Private LAN Service using LDP Signaling (LDP-VPLS) [RFC4762],BGP signaling (BGP-VPLS) [RFC4761] or BGP auto-discovery (BGP-AD) [RFC6074]. The proposed solution is characterized by the use of two PWs between a pair of PEs. This solution is applicable for both VPLS and H-VPLS. "Representing CoRE Link Collections in JSON", Carsten Bormann, 14-Feb-12, Web Linking (RFC5988) provides a way to represent links between Web resources as well as the relations expressed by them and attributes of such a link. In constrained networks, a collection of Web links can be exchanged in the CoRE link format (I-D.ietf-core-link-format). Outside of constrained environments, it may be useful to represent these collections of Web links in JSON format (RFC4627). This specification defines a common format for representing Web links in JSON format. "Cross Stratum Optimization enabled Path Computation", Dhruv Dhody, Young Lee, Nicola Ciulli, Luis Contreras, Oscar de Dios, 8-Mar-12, Applications like cloud computing, video gaming, HD Video streaming, Live Concerts, Remote Medical Surgery, etc are offered by Data Centers. These data centers are geographically distributed and connected via a network. Many decisions are made in the Application space without any concern of the underlying network. Cross stratum application/network optimization focus on the challenges and opportunities presented by data center based applications and carriers networks together [CSO-DATACNTR]. Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. [RFC4655] explains the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document explains the architecture for CSO enabled Path Computation. "Conclusion of SenderID and SPF experiments", S Moonesamy, 15-Feb-12, This memo concludes the SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message (RFC4405), Sender ID: Authenticating E-Mail (RFC4406), Purported Responsible Address in E-Mail Messages (RFC4407) and Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 (RFC4408), experiments. "OSPF Extensions for Routing Constraint Encoding in Flexible-Grid Networks", Lei Wang, Yao Li, Guoying Zhang, 8-Mar-12, In Flexible-Grid networks, network elements and links may impose additional routing constraints, which cannot be ignored in Routing and Spectrum Assignment (RSA) process. This document describes the requirements of such constraints, and then provides efficient encodings to specify how the information is carried. "Public Key Checking Protocol", Stephen Farrell, 18-Feb-12, Some asymmetric key generation implementations do not use sufficient randomness giving rise to a number of bad public keys, for example with known factors, being used on the Internet. This memo specifies [[for now: just outlines]] an experimental protocol that could be used by a private key holder to talk to a responder that knows the values of (some of) those bad keys that have been seen in the wild. The protocol only allows a holder of the relevant private key to request information, as doing otherwise could weaken the overall security of the Internet and also considers confidentiality and privacy as important requirements, as information that a given bad public key is associated with a particular identifier could also weaken the security of the Internet. "Reverse DNS Naming Convention for CIDR Address Blocks", Joe Gersch, Dan Massey, Eric Osterweil, 2-May-12, The reverse DNS naming method is used to specify a complete IP address. At present there is no standard way for the reverse DNS to handle address ranges. As an example, there is no formal mechanism to define a reverse DNS name for the block of addresses specified by the IPv4 prefix 129.82.0.0/16. Defining such a reverse DNS naming convention would be useful for a number of applications. This draft proposes a naming convention for encoding CIDR address blocks into the reverse DNS namespace. "Security and Interoperability Implications of Oversized IPv6 Header Chains", Fernando Gont, Vishwas Manral, 5-Apr-12, The IPv6 specification allows IPv6 header chains of an arbitrary size. The specification also allows options which can in turn extend each of the headers. In those scenarios in which the IPv6 header chain or options are unusually long and packets are fragmented, or scenarios in which the fragment size is very small, the first fragment of a packet may fail to include the entire IPv6 header chain. This document discusses the interoperability and security problems of such traffic, and updates RFC 2460 such that all IPv6 packets are required to contain the entire IPv6 header chain within the first "assumed Path-MTU" bytes of the packet. "Capability Information Advertising for CDN Interconnection", Xiaoyan He, Spencer Dawkins, Ge Chen, Yunfei Zhang, Wei Ni, 6-Mar-12, This document describes protocol for capability information advertising which is used to communicate capability and status information among interconnected Content Delivery Networks (CDNs). "Routing Request Redirection for CDN Interconnection", Xiaoyan He, Spencer Dawkins, Ge Chen, Wei Ni, Yunfei Zhang, 21-Feb-12, The Request Routing Interface comprises the asynchronous advertisement of footprint and capabilities by a dCDN that allows a uCDN to decide whether to redirect particular user requests to that dCDN; and the synchronous operation of actually redirecting a user request. This document describes protocol for the part of user requests redirection. "Conditional observe in CoAP", Shitao Li, Jeroen Hoebeke, 11-Mar-12, CoAP is a RESTful application protocol for constrained nodes and networks. Through the Observe option, clients can observe changes in the state of resources. This document defines a new mechanism in CoAP Observe so that a CoAP client can conditionally observe a resource on a CoAP server, only being informed about state changes meeting a specific condition. Note Discussion and suggestions for improvement are requested, and should be sent to core@ietf.org. "Tunneling Compressed Multiplexed Traffic Flows (TCMTF)", Jose Saldana, Dan Wing, Julian Navajas, Muthu Perumal, 2-Mar-12, This document describes a method to improve the bandwidth utilization of network paths that carry multiple streams in parallel between two endpoints, as in voice trunking. The method combines standard protocols that provide compression, multiplexing, and tunneling over a network path for the purpose of reducing the bandwidth used when multiple streams are carried over that path. "Address Acquisition For Multicast Content When Source and Receiver Support Differing IP Versions", Tina Tsou, Axel Clauberg, Mohamed Boucadair, Stig Venaas, Qiong Sun, 12-Mar-12, 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 and evaluates alternative strategies for allowing the receiver to acquire multicast address information in the version it supports in such scenarios. Operators may find this review useful when planning their own transition strategy. "A Transparent Performance Enhancing Proxy Architecture To Enable TCP over Multiple Paths for Single-Homed Hosts", Tacettin Ayar, Berthold Rathke, Lukasz Budzisz, Adam Wolisz, 17-Feb-12, This draft complements the work of MPTCP by defining a TCP Splitter/ Combiner Architecture (SCA) that enables non-MPTCP-capable single- homed hosts to benefit from the multiple paths within Internet by means of performance enhancing proxies (PEPs) placed in the access networks. SCA Proxies (SCAPs) make use of multiple paths in a way which is completely transparent to end-hosts. Since the existence of the SCAPs is shielded from the TCP end-points, they can be deployed in the Internet as well as on the end-systems. "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. "List-Sequence header field for mailing lists", S Moonesamy, 19-Feb-12, The List-Sequence header field provides a standard location for identifying the sequence position of an individual message for a mailing list. "Practical Considerations and Implementation Experiences in Securing Smart Object Networks", Mohit Sethi, Jari Arkko, Ari Keranen, Heidi-Maria Rissanen, 26-Mar-12, This memo describes challenges associated with securing smart object devices in constrained implementations and environments. The memo describes a possible deployment model suitable for these environments, discusses the availability of cryptographic libraries for small devices, presents some preliminary experiences in implementing small devices using those libraries, and discusses trade-offs involving different types of approaches. "Session Initiation Protocol (SIP) Header Parameter for Debugging", Peter Dawes, 20-Feb-12, Networks that use SIP to start and stop sessions between their users will frequently be upgraded with software and hardware changes. Users will similarly frequently change their client software and the way they use the network. In order to allow troubleshooting and regression testing, it is useful to provide debugging as part of the network fabric. This draft describes an event package that provides debugging configuration to SIP entities and a SIP private header that triggers logging of SIP signalling and identifies logs at mulitiple SIP entities as belonging to a single end-to-end session. A list of related IETF drafts and non-IETF specifications is included to help develop this topic. "Original-Authentication-Results Header Field", Monica Chew, Murray Kucherawy, 20-Feb-12, This memo defines a message header field for relaying message authentication results. The new field differs from the existing Authentication-Results message header field in that it is specifically used to relay message authentication results from one administrative domain to another. "ALTO Caching and Subscription", Nandiraju Ravishankar, Sreekanth Madhavan, 21-Feb-12, The specification of the ALTO protocol uses map based approaches assuming that the information provided is static for a longer period of time. But in some cases network operators reallocate IP subnets from time to time which in turn changes the mapping partitions[I- D.ietf-alto-deployments]. Since the ALTO clients are unaware of the map information changes, clients need to query the servers for every service request and many such requests are redundant because the information was not changed. The purpose of this memo is to provide two mechanisms which will help the ALTO clients to be informed of the map information changes. a) ALTO clients cache the map information and the servers provide the expiration time for invalidation. b) ALTO clients can subscribe for event notifications from the server "Revised Definition of The GMPLS Switching Capability and Type Fields", Lou Berger, Julien Meuric, 22-May-12, GMPLS provides control for multiple switching technologies, and hierarchical switching within a technology. GMPLS routing and signaling use common values to indicate switching technology type. These values are carried in routing in the Switching Capability field, and in signaling in the Switching Type field. While the values using in these fields are the primary indicators of the technology and hierarchy level being controlled, the values are not consistently defined and used across the different technologies supported by GMPLS. This document is intended to resolve the inconsistent definition and use of the Switching Capability and Type fields by narrowly scoping the meaning and use of the fields. This document updates any document that uses the GMPLS Switching Capability and Types fields, in particular RFC 3471, RFC 4202, RFC 4203, and RFC 5307. "Multiple APN Support for Trusted Wireless LAN Access", Sri Gundavelli, Mark Grayson, Yiu Lee, Hui Deng, Hidetoshi Yokota, 22-Feb-12, This specification defines a mechanism for extending multiple APN/ home-network support for a mobile node. "Laminar TCP and the case for refactoring TCP congestion control", Matt Mathis, 21-Feb-12, The primary state variables used by all TCP congestion control algorithms, cwnd and ssthresh are heavily overloaded, carrying different semantics in different states. This leads to excess implementation complexity and poorly defined behaviors under some combinations of events, such as loss recovery during cwnd validation. We propose a new framework for TCP congestion control, and to recast current standard algorithms to use new state variables. This new framework will not generally change the behavior of any of the primary congestion control algorithms when invoked in isolation but will to permit new algorithms with better behaviors in many corner cases, such as when two distinct primary algorithms are invoked concurrently. It will also foster the creation of new algorithms to address some events that are poorly treated by today's standards. For the vast majority of traditional algorithms the transformation to the new state variables is completely straightforward. However, the resulting implementation will technically be in violation of all existing TCP standards, even if it is fully compliant with their principles and intent. "The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol(SRTP)", Woo-Hwan Kim, Jungkeun Lee, Dong-Chan Kim, Je-Hong Park, Daesung Kwon, 21-Feb-12, This document describes the use of the ARIA block cipher algorithm within the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for the Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). It details three modes of operation (CTR, CCM, GCM) and a SRTP Key Derivation Function for ARIA. "IMAP Access to IETF Email List Archives", Robert Sparks, 29-Feb-12, The IETF makes heavy use of email lists to conduct its work. This often involves accessing the archived history of those email lists. Participants would like to have the ability to browse and search those archives using standard IMAP clients. This memo captures the requirements for providing a service that would allow such browsing and searching. "Default Nickname Based Approach for Multilevel TRILL", Ayan Banerjee, Janardhanan Pathangi, Jon Hudson, Les Ginsberg, Sam Aldrin, Sameer Merchant, Tissa Senevirathne, 21-Feb-12, Multilevel TRILL allows the interconnection of multiple TRILL networks to form a larger TRILL network without proportionally increasing the size of the IS-IS LSP DB. In this document, an approach based on default route concept is presented. Also, presented in the document is a novel method of constructing multi- destination trees using partial nickname space. Methods presented in this document are compatible with the RFC6325 specified data plane operations. "IPv6 Prefix Mobility Management Properties", Jouni Korhonen, Basavaraj Patil, Sri Gundavelli, 11-Mar-12, This specification defines an extension to the IPv6 Neighbor Discovery protocol and its Prefix Information Option. The Prefix Information Option is extended with flag bits that describe the mobility management properties associated to the prefix. This specification updates RFC4861 and also updates RFC3484 Source Address Selection algorithm. "An AR-level solution support for Distributed Mobility Management", Zhengming Ma, Xun Zhang, 22-Feb-12, The number of mobile users and their traffic demand is expected to be ever-increasing in future years, and this growth can represent a limitation for deploying current mobility management schemes that are intrinsically centralized, e.g., Mobile IPv6 and Proxy MIPv6. This evolution in user traffic demand is tackled by a different approach for IP mobility, called Distributed Mobility Management, which is focusing on moving the mobility anchors from the core network and pushing them closer to the users, at the edge of the network. The work presented here copes with the distributed approach, describing a novel solution for distributed mobility management support in a flat architecture without central mobility anchors. This document strictly abides by the two principles: (a)The movement of MN is transparent to CN. (b)MN doesn't participate in any mobility-related signaling.MAAR and AAA are responsible for managing IP mobility on behalf of the host. "A Route Optimization solution support for Distributed Mobility Management", Xun Zhang, Zhengming Ma, 22-Feb-12, The mobile users and their traffic demands are expected to be ever- increasing in future years, and this growth will impose a limitation for deploying current mobility management schemes that are intrinsically centralized, e.g., Mobile IPv6 and Proxy MIPv6. This evolution in user traffic demand can be tackled by a different approach for IP mobility, called Distributed Mobility Management, which is focusing on moving the mobility anchors from the core network and pushing them closer to the users, at the edge of the network. Following this idea, in our proposal, the central anchor is being deployed in the access router of the mobile node(MN). That is, the first elements that provide IP connectivity to a set of MNs are also the mobility managers for those MNs. In the following, we will call MAAR (Mobility anchor and Access Router). This draft strictly abides by the three principles: (1) The MN doesn't participate in any mobility-related signaling.MAAR and AAA are responsible for managing IP mobility on behalf of the host. (2) The MN's movement is transparent to the communication node (CN).The Home Address (HoA) and Care-of address (CoA) are not for users but for specific sessions in this draft.A MN initiates a session by using the MN's address assigned by a MAAR which the MN is registered as the HoA for this session.The MN's address assigned by a new MAAR which the MN moves to its access link as the CoA for the session. (3) The MN can directly forward packages to the CN and the packages don't need to pass the home mobility anchor. It can reduce the heavy burdens on home mobility anchor and maintain all the continuity of the conversation. "VCCV MPLS-TP Connectivity Verification (CV) Capability Advertisement", Greg Mirsky, 22-Feb-12, This document specifies how use of proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile [RFC6428] affects operation and management function election for PW VCCV [RFC5085], [RFC5885]. "Composite Link USe Cases and Design Considerations", Andrew Malis, Curtis Villamizar, Dave McDysan, Lucy Yong, Ning So, 22-Feb-12, This document provides a set of use cases and design considerations for composite links. Composite link is a formalization of multipath techniques currently in use in IP and MPLS networks and a set of extensions to multipath techniques. Note: symmvo in the draft name is the initials of the set of authors: So, Yong, McDysan, Malis, Villamizar, Osborne. This paragraph will be removed when/if this document is adopted as a WG item. "Using ITU-T-based IDs for MPLS-TP On-demand Connectivity Verification", Zhenlong Cui, Rolf Winter, 23-Feb-12, This document defines how to use ICC-based MPLS-TP identifiers for on-demand connectivity verification (CV) analogous to RFC 6426. New TLVs are defined to support on-demand CV based on identifiers following ITU-T conventions. "Proposal for selecting the default-route according to source address", Guillaume Habault, Laurent Toutain, Etienne Santerre, 23-Feb-12, SDSA approach is to assure that packets, going out the multihomed site, have the correct source address, regarding to the ISP and thus to avoid the ingress filtering problem. In that purpose, SDSA takes into account the source address in the site routing decision for outgoing packets, when default-route is involved. "SPDY Protocol", Mike Belshe, Roberto Peon, 23-Feb-12, This document describes SPDY, a protocol designed for low-latency transport of content over the World Wide Web. SPDY introduces two layers of protocol. The lower layer is a general purpose framing layer which can be used atop a reliable transport (likely TCP) for multiplexed, prioritized, and compressed data communication of many concurrent streams. The upper layer of the protocol provides HTTP- like RFC2616 [RFC2616] semantics for compatibility with existing HTTP application servers. "IDNA2008 implementation report", Takahiro NEMOTO, Yoshiro Yoneya, 23-Feb-12, This document reports implementation experience of IDNA2008 and findings from the implementation. "Additional Link Relation Types", James Snell, 14-May-12, This specification defines a number of additional Link Relation Types that can used for a variety of purposes.. "A framework for the use of SPMEs for shared mesh protection", David Allan, Greg Mirsky, 24-Feb-12, Shared mesh protection allows a set of diversely routed paths with diverse endpoints to collectively oversubcribe protection resources. Under normal conditions no single failure will result in the capacity of the associated protection resources to be exhausted. When multiple failures occur such that more than one path in the set of paths utilizing shared protection resources is affected, the necessity arises of pre-empting traffic on the basis of business priority rather than application priority. This memo describes the use of SPMEs and TC marking as a means of indicating business priority for shared mesh protection. "Models for adaptive-streaming-aware CDN Interconnection", Ray van Brandenburg, 24-Feb-12, This documents presents thougths on the potential impact of supporting HTTP Adaptive Streaming technologies in CDN Interconnection scenarios. Our intent is to spur discussion on how the different CDNI interfaces should deal with content delivered using adaptive streaming technologies. "Certified Electronic Mail", Francesco Gennai, Luca Frosini, Alba Shahin, Claudio Petrucci, 2-Mar-12, This document specifies the requirements for a Certified Electronic Mail (CEM) system which provides people with proof of communication when exchanging emails, giving strong evidences to the users involved in the interchange. "A Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD)", Jaime Jimenez, Jose Lopez-Vega, Jouni Maenpaa, Gonzalo Camarillo, 29-Feb-12, This document defines a Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD). The CoAP Usage provides the functionality to federate Wireless Sensor Networks (WSN) in a peer-to-peer fashion. The CoAP Usage also provides a rendezvous service for CoAP Nodes and caching of sensor information. The RELOAD AppAttach method is used to establish a direct connection between nodes through which CoAP messages are exchanged. "CDNI Logging Formats for HTTP and HTTP Adaptive Streaming Deliveries", Francois Le Faucheur, Mahesh Viveganandhan, Kent Leung, 24-Feb-12, The interconnection of Content Distribution Networks (CDNs) is motivated by several use cases. CDN Interconnection can be achieved through four CDNI interfaces, one of which is the CDNI Logging interface. This document discusses CDNI logging formats for content deliveries performed using HTTP or HTTP adaptive streaming. "Offer/Answer Considerations for G.723 Annex A and G.729 Annex B", Muthu Perumal, Parthasarathi Ravindran, 24-Feb-12, [RFC4856] describes the annexa parameter for G723 and the annexb parameter for G729, G729D and G729E. However, the specification does not describe the offerer and answerer behavior when the value of the annexa or annexb parameter does not match in the SDP offer and answer. This document provides the offer/answer considerations for these parameters. "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Translation ("IGMP/MLD Translation")", Simon Perreault, Tina Tsou, 11-Apr-12, 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. "Pro-active connectivity monitoring for TRILL", Rohit Watve, Tissa Senevirathne, Gayatri Ramachandran, 24-Feb-12, Pro-active fault monitoring for TRILL monitors all the paths between any two given RBridges in the network. Number of paths to be monitored can be of exponential order based on the distance between two RBridges. In this document novel fault monitoring mechanism based on a distributed approach is presented. "Encoding mLDP FECs in the NLRI of BGP MCAST-VPN Routes", IJsbrand Wijnands, Eric Rosen, Uwe Joorde, 24-Feb-12, Many service providers offer "BGP/MPLS IP VPN" service to their customers. Existing IETF standards specify the procedures and protocols that a service provider uses in order to offer this service to customers who have IP unicast and IP multicast traffic in their VPNs. It is also desirable to be able to support customers who have MPLS multicast traffic in their VPNs. This document specifies the procedures and protocol extensions that are needed to support customers who use the Multicast Extensions to Label Distribution Protocol (mLDP) as the control protocol for their MPLS multicast traffic. Existing standards do provide some support for customers who use mLDP, but only under a restrictive set of circumstances. This document generalizes the existing support to include all cases where the customer uses mLDP, without any restrictions. "New IP address format", C.V. Sreeraj, 24-Feb-12, This document specifies new addressing format and routing technique for the IP (Internet Protocol).This is a hierarchical, scalable design , the source and destination address varies depending on the level of network. "mLDP Node Protection", IJsbrand Wijnands, Eric Rosen, Kamran Raza, Jeff Tantsura, Alia Atlas, 24-Feb-12, This document describes procedures to support node protection for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths (MP LSPs) built by LDP ("Label Distribution Protocol"), or simply mLDP. In order to protect a node N, the Point of Local Repair (PLR) LSR of N must learn the Merge Point (MPT) LSR(s) of node N such that traffic can be redirected to them in case node N fails. Redirecting the traffic around the failed node N depends on existing P2P LSPs originated from the PLR LSR to the MPT LSRs while bypassing LSR node N. "Connecting Disparate Data Center/PBB/Campus TRILL sites using BGP", Bhargav Bhikkaji, Balaji Venkataswami, Ramasubramani Mahadevan, Shivakumar Sundaram, Narayana Swamy, 25-Mar-12, 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. A few solutions have been proposed as in [1] in the recent past that have not looked at the PB-like functionality. These solutions have not dealt with the details as to how these services could be provided such that multiple TRILL sites can be inter-connected with issues like nick-name collisons for unicast and multicast being taken care of. It has been found that with extensions to BGP the problem statement which we will define below can be handled. Both control plane and data plane operations can be driven into the solution to make it seamlessly look at the entire set of TRILL sites as a single entity which then can be viewed as one single Layer 2 cloud. MAC moves across TRILL sites and within TRILL sites can be realized. This document / proposal envisions the use of BGP-MAC-VPN vrfs both at the IP cloud PE devices and at the peripheral PEs within a TRILL site providing Provider Backbone like functionality. We deal in depth with the control plane and data plane particulars for unicast and multicast with nick-name election being taken care of as part of the solution. "Preventing spoofing attacks in BGP-MPLS-VPN Inter-Provider Model-C", Bhargav Bhikkaji, Balaji Venkataswami, 2-Mar-12, In certain models of inter-provider Multi-Protocol-Label-Switching based Virtual Private Networks (MPLS-VPNs), spoofing attacks against VPN sites is a key concern. Unidirectional attacks towards VPN sites can compromise servers at the VPN sites and cause Denial-of-Service (DoS) situations. Currently, the inner labels associated with VPN sites are not encrypted during transmission. The Provider Edge (PE) router at the end to which the VPN customer is attached accepts any data packet with a valid label. This enables a man-in-the-middle attacker to spoof a packet to a specific site of a VPN. In this paper, we propose some secure techniques which provide security against such label-spoofing. These techniques ensure that an attacker would not be able to spoof labeled data packets. In order to make the proposed scheme robust, some additional steps are proposed over and above the initial steps specified. This makes the attacker to spend non-linear time to guess the right label for his unidirectional attacks to succeed. Our proposed technique can be applied to a specific type of inter-provider Border Gateway Protocol(BGP) based MPLS VPN and other existing variant where Multi-Protocol exterior- BGP (MP-eBGP) multi-hop is used. In future, if any other variant is proposed to use MP-eBGP multi-hop, our scheme can be used to protect against spoofing attacks. "Enterprise Incremental IPv6", Lee Howard, Tim Chown, KK Chittimaneni, Yanick Pouffary, Eric Vyncke, Victor Kuarsingh, 27-Feb-12, Enterprise network administrators worldwide are in various stages of preparing for or deploying IPv6 into their networks. The administrators face different challenges than operators of Internet access providers, and have reasons for different priorities. The overall problem for many administrators will be to offer Internet- facing services over IPv6, while continuing to support IPv4, and while introducing IPv6 access within the enterprise IT network. The overall transition will take most networks from an IPv4-only environment to a dual stack network environment and potentially an IPv6-only operating mode. This document helps provide a framework for enterprise network architects or administrators who may be faced with many of these challenges as they consider their IPv6 support strategies. "Intelligent Use Task Force", Jean-Francois Morfin, 5-Mar-12, The Intelligent Use Task Force (IUTF) has responsibility for organizing Dedicated Interest Groups (DIG) to research, document and validate solutions in the area of Intelligent Use Interfaces (IUI) between the various components of the whole digital ecosystem (WDE), the resulting intelligent global network (IGNet), the diversity of on-line facilitation services that their IUI and IGNet may bring to people and machines. This document describes the guidelines and procedures for the formation, operations, experimentations and publications of IUTF Dedicated Interest Groups and their internal and external relations with other SDOs (Standardization and Documentation Organizations). Its publication as an IETF Draft is part of the IUCG liaison. "CoAP Option Extension: Patience", Kepeng Li, Bert Greevenbosch, Esko Dijk, Salvatore Loreto, 27-Feb-12, 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. 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. "RTCWeb ROAP XMPP/Jingle Interworking", Kepeng Li, 27-Feb-12, This document proposes behavior of a RTCWeb signaling gateway for mapping message representations between RTCWeb Offer/Answer Protocol (ROAP) scheme and XMPP/Jingle messaging scheme. Such a signaling gateway is intended to translate ROAP to/from XMPP/Jingle [XEP-0166] for enabling use cases between a RTCWeb enabled browser and legacy mobile devices which use XMPP/Jingle for signalling. "RTP Payload Format for High Efficiency Video Coding", Thomas Schierl, Stephan Wenger, Ye-Kui Wang, Miska Hannuksela, 27-Feb-12, This memo describes an RTP payload format for High Efficiency Video Coding (HEVC) [HEVC], which is currently being developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC stream over a single as well as multiple RTP flows. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. "Multicast requirements for control over LLN", Peter Van der Stok, 12-Mar-12, This is a working document intended to focus discussion on requirements for multicast in Low-power and Lossy Networks in the area of M2M communication for control purposes. The Trickle algorithm, which uses re-broadcasting to assure that messages arrive at all destinations, is proposed as the ROLL multicast protocol. In this draft additional requirements on Trickle, such as timeliness and ordering, are motivated by building control. Re-broadcasting and timeliness can be mutually exclusive properties. To alleviate that problem, this draft considers minimizing re-broadcast by limiting the number of re-broadcasting devices in the wireless network. "EDNS Echo.", Warren Kumari, Roy Arends, 27-Feb-12, This document describes a DNS protocol extension to allow for arbritry data to be inserted into a DNS Request and have that same data be returned in a DNS Reply. "DNS Resource Records for BGP Routing Data", Joe Gersch, Dan Massey, Eric Osterweil, Lixia Zhang, 28-Feb-12, This draft proposes the creation 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 published data can be used in a variety of contexts and can be extended to include additional information. This work is part of an on-going effort and is accessible in an active testbed. "Highly Efficient Selective Acknowledgement (SACK) for TCP", Anthony Sabatini, 28-Feb-12, This memo expands on the Selective Acknowledgement Protocol described in RFC2018 to improve its performance and efficiency while reducing the delay involved in recovering lost segments. This leads to very reliable and efficient communications regardless of transit delay or high levels of lost segments due to noise or congestion. It introduces a fundamentally new way of looking at Selective Acknowledgement and uses this concept to improve the performance of the RFC2018 protocol. This memo proposes an implementation of the improved SACK and discusses its performance and related issues. "Real-Time Web Communication by using XMPP Jingle", Yoshihiro Suzuki, Nobuo Ogashiwa, 28-Feb-12, XMPP Jingle specification defines an XMPP protocol extension for managing peer-to-peer media sessions between two users. And XMPP Jingle can manage multi contents simultaneously in one Jingle stream, but in the XMPP world there is no common way to layout variable multi contents on each display. In this document, a solution to this issue is provided by using Web browser's layout function. This document describes a new concept to realize one of solutions of RTCWeb. Of course, "Web Browser" is used for Web application's frontend for real-time communication, and XMPP Jingle specification (XEP-166) is used as signaling protocol. And a simple mapping manner between jingle contents and HTML graphical elements enables to unite Web browser's layout function and Jingle's media content management function to realize RTCWeb functions. "Real-Time Web Communication by using XMPP Jingle", Yoshihiro Suzuki, Nobuo Ogashiwa, 28-Feb-12, XMPP Jingle specification defines an XMPP protocol extension for managing peer-to-peer media sessions between two users. And XMPP Jingle can manage multi contents simultaneously in one Jingle stream, but in the XMPP world there is no common way to layout variable multi contents on each display. In this document, a solution to this issue is provided by using Web browser's layout function. This document describes a new concept to realize one of solutions of RTCWeb. Of course, "Web Browser" is used for Web application's frontend for real-time communication, and XMPP Jingle specification (XEP-166) is used as signaling protocol. And a simple mapping manner between jingle contents and HTML graphical elements enables to unite Web browser's layout function and Jingle's media content management function to realize RTCWeb functions. "OSPF extensions for support wavelength range allocation in flexible grid supported network", Qilei Wang, Xihua Fu, 28-Feb-12, This document addresses the requirements and routing protocol extension of wavelength range allocation in flexible grid supported network in order to help spectrum utilization in the process of path computation. "Framework for GMPLS Control of Flexible Grid Network", Qilei Wang, Xihua Fu, 12-Mar-12, This document provides a framework for applying Generalized Multi- Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to control the flexible grid network base on the Wavelength Switched Optical Networks (WSONs). GMPLS control of WSON which is addressed in RFC6163 is out of the scope of this document. This document focuses on the topological elements changes and new path selection constraints that flexible grid technology takes. Impairments related technology is not covered in this document. "RTP Clock Source Signalling", Aidan Williams, Ray van Brandenburg, 28-Feb-12, NTP timestamps are used by several RTP protocols for synchronisation and statistical measurement. This memo specificies SDP signalling identifying NTP timestamp clock sources and SDP signalling identifying the media clock sources in a multimedia session. "Human-safe IPv6: Cryptographic transformation of hostnames as a base for secure and manageable addressing", Andrew Yourtchenko, Salman Asadullah, Mircea Pisica, 28-Feb-12, Although the IPv6 address space within a single /64 subnet is very large, the typical distribution of the addresses in this space is very non-uniform. This non-uniformity, together with the dictionary- based DNS brute-force enumeration, allows practical remote mapping of the IPv6 addresses in these subnets. This document proposes a technique which can be used to decrease the exposure of the server subnets to trivial scanning. As a side effect, the proposed technique allows to drastically simplify the address management. "Flow Identity Extension for HELD", Ray Bellis, 14-May-12, Identity Extensions using an IP address and port number to request a location based on an individual packet flow have been previously specified by the GEOPRIV Working Group. However certain kinds of NAT require that identifiers for both ends of the packet flow must be specified in order to unambiguously satisfy the location request. This document specifieds a Flow Identity Extension for the HTTP- Enabled Location Delivery (HELD) Protocol to support this requirement. "Practical solutions for encrypted synchronization protocol", Yang Cui, Manav Bhatia, Dacheng Zhang, 29-Feb-12, This informational document analyzes the accuracy issues with time synchronization protocols when time synchronization packets are encrypted during transmission. In addition, several candidate solutions on such issues are introduced. "A Stateless Transport Tunneling Protocol for Network Virtualization (STT)", Bruce Davie, Jesse Gross, 5-Mar-12, 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. "Representing registration policy for IDNs using XML", Kim Davies, 11-Mar-12, This memo describes a method of representing the registration policy that a zone administrator uses for registering Internationalised Domain Names using Extensible Markup Language (XML). These registry policies, commonly known as "IDN tables", are used to enforce and share policy on which specific code-points are permitted for registrations, and which alternative code-points are considered variants. "Publish and Monitor Options for CoAP", Thomas Fossati, Pierpaolo Giacomin, Salvatore Loreto, 10-Mar-12, This memo defines two additional Options for the Constrained Application Protocol (CoAP) especially targeted at sleepy sensors: Publish and Monitor. The Publish Option enables opportunistic updates of a given resource state, by temporarily delegating the authority of the Publish'ed resource to a Proxy node. The whole process is driven by the (sleepy) origin -- which may actually never need to listen. The Monitor Option complements the typical Observe pattern, enabling the tracking of a resource hosted by a node sleeping most of the time, by taking care of establishing and maintaining an Observe relationship with the (sleepy) origin on behalf of the (sleepy) client. "OSPF Version 2 as the Customer Edge/Customer Protocol for BGP/MPLS IP VPNs", David Freedman, 29-Feb-12, RFC4577 (OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP VPNs) proposes a mechanism for the use of the Open Shortest Path First V2 ("OSPF", RFC2328) protocol between the Provider Edge ("PE") and Customer Edge ("CE") routers within a BGP/MPLS IP Virtual Private Network ("IP/VPN", RFC4364). The standard provides for use of such a provider VPN to join discontiguous locations together, preserving the OSPF area and domain behaviour. This document describes a technique for utilising the same, IPVPN network infrastructure without the requirement to enable the OSPF protocol on the PE/CE interface and thus relieve the PE router of OSPF duties. "Sleepy Option for CoAP", Thomas Fossati, Pierpaolo Giacomin, Salvatore Loreto, Mirko Rossini, 29-Feb-12, This memo defines a framework for allowing asynchronous communication between sleepy sensors mediated by a supporting Proxy node. The Proxy acts as a store-and-forward agent that handles requests on behalf of a sleepy client, and buffers responses coming from the target origin until the requesting client wakes up and get the computation results. A new CoAP option, Sleepy, is defined to initiate and control the asynchronous exchange. "Formally Obsoleting some Historic IPv4 Options", Carlos Pignataro, Fernando Gont, 29-Feb-12, A number of IPv4 options have become obsolete in practice, but have never been formally obsoleted. This document obsoletes such IPv4 options, thus cleaning up the corresponding IANA registry, and serving as a basis for providing advice about the filtering of packets containing these options. "E-Tree Support in VPLS with BGP Signaling", Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, Florin Balus, Wim Henderickx, Ali Sajassi, 29-Feb-12, This document describes the extension to BGP signaling for the E-Tree support in BGP VPLS when the dual-VLAN model is used as in [Vpls- etree]. The BGP VPLS messages and their procedures remain almost the same as in [RFC4761], only a new extended community for E-Tree is proposed. "PIM MTU Hello Option for PIM Message Encapsulation", Hui Liu, Tina Tsou, 29-Feb-12, This memo introduces a new PIM Hello MTU Option which is carried in PIM Hello messages. The MTU option enables interface MTU information to be exchanged among PIM neighbors, and PIM messages to be encapsulated in an efficient and consistent way. "A framework for controlling Multitenant Isolation, Connectivity and Reachability in a Hybrid Cloud Environment", Masum Hasan, Abdelhadi Chari, David Fahed, Lew Tucker, Monique Morrow, Mark Malyon, 29-Feb-12, Multiple enterprises (tenants) consuming resources in a public Cloud shares the physical infrastructure of one or more DCs out of which the Cloud resources are serviced. Hence one of the major features that has to be supported in public Cloud DCs is multitenant isolation, which is realized via various DC isolation technologies, such as VLAN or VxLAN. In a hybrid Cloud environment where a public Cloud (more specifically off-premises public Cloud resources acquired by a tenant ) becomes an _extension_ of a tenant intranet or private Cloud, the multitenant isolation capability has to be extended beyond the public Cloud DCs. The multitenant isolation _domain_ has to span end-to-end from the tenant network or on-premises resources via the MAN/WAN and the public Cloud DC networks to tenant off-premises resources. While multitenant isolationI isolates one tenant from another (inter-hybrid Cloud isolation), an enterprise may desire controlled connectivity to a hybrid Cloud from another Cloud or network or tenant or select resources. In addition, there may be need for controlling direct reachability of resources within a hybrid Cloud itself (intra-hybrid Cloud). The tenant network may be connected to the public Cloud (DCs) over the Internet or a private IP/MPLS MAN/WAN owned or operated by a service provider, which also may support PPVPN (Provider Provided VPN) service, such as the L3 MPLS VPN. In this work we consider the latter type of network and describe a framework for supporting inter-hybrid Cloud multitenant isolation, inter-hybrid Cloud connectivity and intra-hybrid Cloud reachability. "End-to-End Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)", Matthew Miller, 29-Feb-12, This document defines a method of end-to-end object encryption for the Extensible Messaging and Presence Protocol (XMPP). "Constructing power optimal P2MP TE-LSPs within an AS", Balaji Venkat, Gaurav Raina, 29-Feb-12, 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. "CDN Interconnect Triggers", Rob Murray, Ben Niven-Jenkins, 29-Feb-12, This document proposes a mechanism for 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. "Happy IANA: Making Large-Scale Registries More User-Friendly", Mark Nottingham, 29-Feb-12, Suggestions for IANA registries that have a broad audience, particularly a non-IETF one. "PCP Server Discovery with IPv4 traffic offload for Proxy Mobile IPv6", Tirumaleswar Reddy, Prashanth Patil, Ravikumar Chandrasekaran, Dan Wing, 29-Feb-12, 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. "Formally Verifiable Networking Framework for SDN", Jin-Young Choi, 29-Feb-12, This document discusses formally verifiable networking framework for software-defined network (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. "New IP address structure", C.V. Sreeraj, 3-Apr-12, This document specifies new address structure and routing technique for the IP (Internet Protocol).This is a hierarchical, scalable design and the size of routing table is limited to 133053 routes. "CoRE Discovery, Naming, and Addressing", Peter Van der Stok, Kerry Lynn, Anders Brandt, 12-Mar-12, This is a working document intended to focus discussion and refine draft language for the CoAP protocol specification (or other proposed standards) in the areas of discovery, naming, and addressing. Requirements on discovery are motivated. Special emphasis is placed on group definition and discovery. Examples show how groups can be represented in CoAP Resource Directories or DNS-SD. "Another Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)", Sujing Zhou, Ruishan Zhang, 9-Apr-12, This document provides a support for multiple hash algorithms in Cryptographically Generated Addresses (CGAs) defined in RFC 3972. "LDP Extensions for Lock Instruct and Loopback of Pseudowire in MPLS Transport Profile", Jie Dong, Mach Chen, Greg Mirsky, 1-Mar-12, This document specifies extensions to the Label Distribution Protocol (LDP) to support provisioning of lock instruct and loopback mechanism for MPLS-TP Pseudowires. "Definitions of Managed Objects for MAP-E", Yu Fu, Sheng Jiang, Jiang Dong, Peng Wu, 1-Mar-12, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines managed objects for MAP-E. "BGP operations and security", Jerome Durand, Ivan Pepelnjak, Gert Doering, 1-Mar-12, This documents describes best current practices to manage securely BGP in a network. It will explain the basic policies ones should configure on BGP peerings to keep an healthy BGP table. This document will only focus on unicast and multicast tables (SAFI 1 and 2) for IPv4 and IPv6. Foreword A placeholder to list general observations about this document. "Multiple Interfaces IPsec Security Requirements", Daniel Migault, Carl Williams, 29-Mar-12, ISPs wants to take advantage of MIF Transport protocols like SCTP, MPTCP to enhance their End User's experience when the End User has been offloaded on WLAN. In addition, WLAN are untrusted so ISPs MUST Secure at least some of their End Users's communications. For various reasons IPsec is the protocol they choose to secure the communications. Currently, IPsec is not adapted to Multiple Interfaces Environment. IPsec can hardly be configured in a proper way which may result in breaking End Users' communications. At least, it makes it very hard for the End Users to combine Security with MIF enhancements. MOBIKE partly address the problem for a single Interface. This draft provides the problem statement and defines the IPsec Security Requirements for MIF. "Building power optimal Multicast Trees", Shankar Raman, Balaji Venkat, Gaurav Raina, Vasan Srini, 27-Mar-12, 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 Multicast Distribution trees 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 reduce power consumption on these routers bringing power consumption to optimality. In this paper, we propose a mechanism by which Multicast Distribution Trees are constructed for carrying multicast traffic across multiple routers within a given network. We propose that these Multicast Distribution Trees be built by using the information pertaining to power-replication capacity ratio available with fine grained components such as multicast capable line-cards of routers and multi-layer switches deployed within a network. "G.711.0 Compression Segments", Michael Ramalho, Dan Wing, Muthu Perumal, Noboru Harada, Hadriel Kaplan, 1-Mar-12, This document describes use cases for ITU-T Recommendation G.711.0 compression of ITU-T Recommendation G.711 payloads when deployed in transport system segments using the Real-Time Transport Protocol (RTP). ITU-T Rec. G.711.0 defines a lossless and stateless compression for G.711 packet payloads typically used in IP networks. Although the use of ITU-T Rec. G.711.0 can be negotiated end-to-end, being lossless and stateless it can also be applied as a compression mechanism "in-the-middle" of an end-to-end ITU-T G.711 negotiated session. These "in-the-middle" applications of ITU-T Rec. G.711.0 are called "G.711.0 Compression Segments" in this document. This document outlines considerations and best practices (a.k.a. use cases) for these "G.711.0 compression segments". "BGP attribute for QoS SLA advertisement", Shitanshu Shah, Keyur Patel, Sandeep Bajaj, 1-Mar-12, Out-of-band manual learning of SLA details and provisioning them in general can be complex work for network administrators. For example, Enterprise network administrators not only have to know what is their SLA, for voice, video etc application traffic, with their Provider, but they also require translating application groups to Classifier groups as per provider's definition as well translate SLA to vendor specific provisioning language. An in-band method of QoS signaling can help to simplify some of the complexities. An optional transitive BGP attribute proposed in this document intends 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. "TCP option for transparent Middlebox discovery", Andrew Knutsen, Anantha Ramaiah, 2-Mar-12, This document describes a TCP option for use by middleboxes to facilitate transparent detection of other middleboxes along the path of the TCP connection during the connection initiation phase. The option has no effect if an appropriate middlebox is not present on the path. The TCP end hosts are unaware of this option and its usage is strictly for use by TCP middleboxes. Multiple vendors of WAN optimization products have used similar (but incompatible and proprietary) mechanisms since at least 2004. Those existing vendor systems use multiple TCP option code points, all of which are officially unassigned by IANA. The goal of this memo is to standardize a single TCP option code point for this functionality. This memo is the product of discussion among some of the vendors currently using incompatible proprietary TCP options for middlebox discovery. It is a non-goal of this memo to achieve interoperability of middlebox discovery between multiple vendors. It needs to be noted that an earlier document [I-D.knutsen-tcpm-middlebox-discovery], is re-written as the current document after agreement from multiple vendors. "IANA Registry for RTCWeb Media Constraints", Daniel Burnett, 23-Apr-12, Specifications in W3C's Media Capture Task Force and WebRTC Working Group have need of a registry in which to maintain a list of HTML Media constraints. This document defines this registry. "A architecture of distributed mobility management using mip and pmip", Anthony Chan, 2-Mar-12, This draft proposes a distributed architecture of mobility management in terms of abstracted logical functions. Mobility management functions are abstracted into different logical functions: (1) allocation of home network prefixes or home addresses to mobile nodes; (2) location management which includes managing the IP addresses and locations of the mobile nodes; and (3) mobility routing which includes intercepting and forwarding packets. A distributed architecture can be contructed by providing the mobility routing functions in multiple networks in the data plane and a distributed database is used to host the location management function. This generalized architecture enables different distributed mobility designs using primarily the existing mobility protocols (MIP and PMIP) and their extensions. Several existing distributed mobility management proposals are briefly reviewed using this framework. It is expected that the different proposals, when expressed in terms of the generalized framework of logical functions, can interwork with each other as well as with the existing hierarchical deployments. "Requirements of distributed mobility management", Anthony Chan, 2-Mar-12, The traditional hierarchical structure of cellular networks has led to deployment models which are heavily centralized. Mobility management with centralized mobility anchoring in existing hierarchical mobile networks is quite prone to suboptimal routing and issues related to scalability. Centralized functions present a single point of failure, and inevitably introduce longer delays and higher signaling loads for network operations related to mobility management. To make matters worse, there are numerous variants of Mobile IP in addition to other protocols standardized outside the IETF, making it much more difficult to create economical and interoperable solutions. In this document we examine the problems of centralized mobility management and identify requirements for distributed and dynamic mobility management. "Dimensioning considerations for distributed mobility architecture", Elena Demaria, Loris Marchetti, 2-Mar-12, One of the main questions posed during recent discussions on distributed mobility architectures is if the distributed architecture can have advantages in terms of costs with respect to a centralized one. This draft describes a general method to calculate the costs of the centralized and distributed scenarios. Even if a simplified model has been used, some information can be earned. Each operator can use this model and his own costs to discover the optimal architecture based on traffic observed in the network. "ENUM Service Registration for Social Networking (SN) Services", Laurent Goix, Kepeng Li, 30-Mar-12, This document registers a Telephone Number Mapping (ENUM) service for Social Networking (SN). Specifically, this document focuses on provisioning 'acct:' URIs (Uniform Resource Identifiers) in ENUM. "IGMP/MLD Optimization in Wireless and Mobile Networks", Hui Liu, Mike McBride, 11-Mar-12, This document proposes a variety of optimization approaches for IGMP and MLD in wireless and mobile networks. It aims to provide useful guideline to allow efficient multicast communication in these networks using IGMP or MLD protocols. "Multicast in the Data Center Overview", Mike McBride, Hui Liu, 9-Mar-12, There has been much interest in issues surrounding massive amounts of hosts in the data center. There was a discussion, in ARMD, involving the issues with address resolution for non ARP/ND multicast traffic in data centers with massive number of hosts. This document provides a quick survey 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. "Authentication and Mobility Management in a Flat Architecture", Pete McCann, 2-Mar-12, Today's mobility management schemes make use of a hierarchy of tunnels from a relatively fixed anchor point, through one or more intermediate nodes, to reach the MN's current point of attachment. These schemes suffer from poor performance, scalability, and failure modes due to the centralization and statefulness of the anchor point(s). The dmm (Distributed Mobility Management) working group is currently chartered to investigate alternative solutions that will provide greater performance, scalability, and robustness through the distribution of mobility anchors. This document is an input to the dmm discussion. It outlines a problem statement for the existing mobility management techniques and goes on to propose (high-level) solutions to two of the most vexing problems: MN authentication and mobility management in a fully distributed, flat (non-hierarchical) access network. These two aspects are often treated separately in a layered architecture, but we argue there are important advantages to considering how these two functions can work in tandem to provide a simple and robust framework for the design of a wireless Internet Service Provider network. "Port Set Definition Algorithms Analysis", Tina Tsou, Tetsuya Murakami, Simon Perreault, 12-Mar-12, This memo analyses the some port set definition algorithms which encodes port set infomation into IPv6 address so as to support stateless IPv4 to IPv6 transition technologies, e.g. 4rd-U and MAP. "CoRE Mirror Proxy", Matthieu Vial, 2-Mar-12, This document introduces the concept of Mirror Proxy that enables sleeping devices to participate in a REST architecture despite the fact that they are not web servers. Most constrained devices may sleep during long periods preventing them from acting as traditional web servers. However as client-only endpoints they can rely on a Mirror Proxy to cache and serve the content they provide. "Problem Statement for Fixed Mobile Convergence", Li Xue, Behcet Sarikaya, Dirk Hugo, 12-Mar-12, The purpose of this document is to analyze the issues that have arisen so far and then to propose a set of requirements for the Fixed Mobile Convergence. The term Fixed Mobile Convergence spans several scenarios from true integration of fixed and mobile terminals, services, and network infrastructure on both technical and management level down to pure interworking between fixed and mobile networks in serving access for multi-interface terminals like todays' smartphones. In the interworking scenario, the mobile network passes on the mobile subscribers policies to the fixed broadband network in order to maintain the end-to-end service level agreement and to support remote terminal and access network management. Explicitly, the fixed broadband network must have partnership with the mobile network in Fixed Mobile Convergence interworking scenario. This document gives a brief overview of the assumed Fixed Mobile Convergence architecture and related works and then introduces several requirements based on the partnership in Fixed Mobile Convergence architecture, such as User Equipment identification and authentication, Femto Access Point management, device type identification and mobility considerations. "Passive IP Addresses", Fred Baker, Gunter Van de Velde, 3-Mar-12, This note suggests an approach to minimizing the attack surface of the network elements - routers, switches, and middleware - of a network. "Super-Channel Optical Parameters GMPLS Signaling Extensions", Iftekhar Hussain, Vinayak Dangui, Michael VanLeeuwen, Marco Sosa, 3-Mar-12, 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. "PMIPv6-based Distributed Mobility Management", Jaehwoon Lee, 3-Mar-12, This draft proposes a PMIPv6-based distributed mobility management by distributing the Localized Mobility Anchor (LMA) function to Mobile Access Gateway (MAGs). Here, the MAG that an MN firstly connects to the PMIPv6 domain becomes the MN's LMA, and other MAGs can find the address of the LMA of MN by using the address assigned to the MN. "Virtualized Application: Problem Statement", Kepeng Li, 11-Mar-12, Virtualized Application aims to enable the user device to remotely consume various applications on the network. This involves having all the virtualized applications hosted in the network and from there providing them to the users using cloud computing technologies like virtualization. This document tries to explain the problems to achieve the virtualized applications. "PCEP extensions for the computation of route offers with price", Gino Carrozzo, Giacomo Bernini, Giada Landi, 4-Mar-12, The PCE defined in RFC4655 is a functional entity generally confined in the control plane to elaborate explicit optimal routes with related costs to be installed as [G]MPLS tunnels/LSPs. The resulting route cost(s)/metric(s) are Traffic Engineering indicators used by the network administrator (carrier) to optimize the usage of its network resources. In this document a framework for the usage of PCE in cooperation with the Network Service and Business Plane (NSBP) is proposed, along with related PCEP extensions. The NSBP invokes this extended PCE (service PCE) to trigger the computation of network service offers with related price information. The price of a network connectivity service generally depends on strategic factors, but it could also be influenced by the amount of mobilized network resources (along the route), the ingress/egress interfaces/PoPs, etc. Therefore, it could be provided by an extended service-PCE as an additional route information. This document focuses on the extensions to the PCEP protocol in support of the computation of route prices for intra- and inter- domain network connectivity services. Mechanisms for elaborating and retrieving price information in the PCE are vendor-specific and out of the scope of this document. "Multipoint BFD for MPLS", Vikas Hegde, Chandrasekar R, 4-Mar-12, Recent proposals have extended the use of Bidirectional Forwarding Detection to detect data plane failures in multipoint networks. One desirable application of Multipoint BFD [MP-BFD] is to detect data path failures in point-to-multipoint Label Switched Paths (P2MP LSPs). The scope of this document is to discuss the applicability of multipoint BFD for fault detection in the data plane of P2MP LSPs. The document extends the techniques and mechanisms mentioned in [RFC5884] and applies them to MPLS P2MP environment. "Revised Validation Procedure for BGP Flow Specifications", James Uttaro, Clarence Filsfils, Pradosh Mohapatra, David Smith, 15-May-12, 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. "Requirements for IP/MPLS network transmission interruption duration", Peng Fan, Lianyuan Li, 4-Mar-12, 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. "Hitchhiker's guide to the Session Description Protocol (SDP)", Bert Greevenbosch, 4-Mar-12, The Session Initiation Protocol (SDP) is the subject of numerous specifications that have been produced by the IETF. It can be difficult to locate the right document, or even to determine the set of Request for Comments (RFC) about SDP. This specification serves as a guide to the SDP RFC series. It lists a current snapshot of the specifications under the SDP umbrella, briefly summarises each, and groups them into categories. Note Discussion and suggestions for improvement are requested, and should be sent to mmusic@ietf.org. "Web Real-Time Communication (RTCWEB): Monitoring Usage", Rachel Huang, Roni Even, 4-Mar-12, This document describes the monitoring aspect usage in RTCWeb. It also gives some guidelines for which RTCP XR metrics and extentions need to be supported. "Super-Channel Optical Parameters GMPLS Routing Extensions", Iftekhar Hussain, Abinder Dhillon, Marco Sosa, 4-Mar-12, 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. "Static pseudowire configuration checking using Generic Associated Channel (G-ACh) Advertisement Protocol", Lizhong Jin, Ran Chen, 4-Mar-12, This draft introduces a way to do static pseudowire configuration checking, so as to easy the trouble shooting of static PW in MPLS-TP. The idea is to use Generic Associated Channel (G-ACh) Advertisement Protocol (GAP) [I-D.ietf-mpls-gach-adv] in underlying PSN Tunnel to transfer PW configuration parameters, to achieve static PW configuration checking. "Congestion Control Requirements For Real Time Media", Randell Jesup, Harald Alvestrand, 4-Mar-12, Congestion control is needed for all data transported across the Internet, in order to promote fair usage and prevent congestion collapse. The requirements for interactive, point-to-point real time multimedia, which needs by low-delay, semi-reliable data delivery, are different from the requirements for bulk transfer like FTP or bursty transfers like Web pages, and the TCP algorithms are not suitable for this traffic. This document attempts to describe a set of requirements that can be used to evaluate other congestion control mechanisms in order to figure out their fitness for this purpose. "Use of Proxy Mobile IPv6 for Distributed Mobility Management", Ji Kim, Seok Koh, Hee Jung, Youn-Hee Han, 4-Mar-12, This document discusses how to use the Proxy Mobile IPv6 (PMIP) protocol for distributed mobility management. Specifically, we describe the two schemes of distributed mobility management: Signal- driven PMIP (S-PMIP) and Signal-driven Distributed PMIP (SD-PMIP). "Allocating and Retiring MPLS Reserved Labels", Kireeti Kompella, 4-Mar-12, There are a limited number of reserved labels defined for Multi- Protocol Label Switching. Thus one must be cautious in the allocation of new reserved labels, yet at the same time allow forward progress when a new reserved label is called for. This memo suggests some procedures to follow in the allocation and retirement of reserved labels. "Local Prefix Lifetime Management for Proxy Mobile IPv6", Jouni Korhonen, Teemu Savolainen, 4-Mar-12, This specification defines a protocol extension to Proxy Mobile IPv6 that enables prefix lifetime management for locally assigned prefixes within a Proxy Mobile IPv6 domain. A locally assigned prefix is managed by a Mobile Access Gateway and is always topologically anchored to the Mobile Access Gateway within the Proxy Mobile IPv6 domain. "DMM Dynamic Anchor Discussion", Dapeng Liu, Hui Deng, Wen Luo, 4-Mar-12, Distributed mobility management aims to distribute the mobility anchor to the access network level to avoid the centralized mobility anchor problem. By distributing the mobility anchor, the traffic can be distributed in an optimal way. There are many different proposals for DMM solution, one of those types of solution is called "dynamic anchor". This document analyses the limitations of current dynamic anchor solution and discusses the possible solution to overcome those limitations. "PMIP Based DMM Approaches", Wen Luo, Juan Liu, 8-Mar-12, Proxy Mobile IPv6 (PMIPv6) is standardized by IETF to supply mobility management for mobile nodes (MN). For supporting Distributed Mobility Management based on current PMIP standard, enhanced Proxy Mobile IPv6 (ePMIP) with two new logic functions is introduced in this draft . (1) Location Management Function (LMF), (2) Distributed Anchoring Function (DAF), including Distributed Routing sub-Function (DRF) and Distributed Mobility sub-Function (DMF). Basic call precedures and various of considerations are described in this draft. "Expressing Label Set in ERO", Cyril Margaria, Ramon Casellas, Oscar de Dios, 4-Mar-12, The paths chosen by Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) can be constrained using the Explicit Route (ERO) object and related sub-objects. Standard ERO sub-objects can specify the Autonomous System (AS), LSR Node Ids, Numbered or unnumbered TE links, downstream and upstream labels, and PCE path keys thus restricting which resources are to be used by a TE-LSP. The Explicit Label Control (ELC) in the explicit route object (ERO) allows both terminating an LSP on a particular outgoing port and label of an egress node, as well as restricting which label to use on any hop along the path determined by the route. However, currently, its not allowed to specify more than 2 labels (downstream and upstream label), and it is not possible to specify, for a given section or segment of a TE-LSP path, a set of labels to restrict which label to be allocated from a Set of candidate labels. This memo provides extensions to the RSVP-TE and PCEP protocols to support Label Sets in the form of ERO sub-objects, being applicable to ERO and ERO-like (IRO, RRO, XRO) sub-objects, extending the ELC concept to a set of candidate labels. "RSVP-TE Extensions for ECMP Tie-Breaking of Inter-Domain TE LSPs", Pradeep Jain, Kanwar Singh, Srikrishnan Venkataraman, 4-Mar-12, This document specifies RSVP-TE extensions that will communicate to all the ABRs that they need to explicitly perform a tie-breaking process to select a particular path if path calculation results in multiple equal-cost paths across different TE-Domains. This will help is efficient utilization of end-to-end network resources for Inter-Domain TE LSPs "STUN Usage for Consent Freshness", Muthu Perumal, Dan Wing, Hadriel Kaplan, 4-Mar-12, This document describes a STUN usage that enables WebRTC implementations to verify the peer consent for continuing to receive traffic on a candidate pair ICE is using for a media component after session establishment. Verification of peer consent is necessary to ensure that a malicious JavaScript cannot use the browser as a platform for launching attacks. This form of consent verification also serves the purpose of refreshing NAT bindings. "Scaling the Address Resolution Protocol for Large Data Centers (SARP)", Youval Nachum, Tal Mizrahi, Ilan Yerushalmi, 11-Mar-12, 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. "Investigation of Session Description Protocol (SDP) Usage for ControLling mUltiple streams for tElepresence (CLUE)", Allyn Romanow, Flemming Andreasen, Arun Krishna, 12-Mar-12, This draft investigates how SDP offer/answer can be used to communicate CLUE encoding and encoding group parameters. "A Translator For Protocol Independent Multicast (PIM) Interworking Between IPv4 and IPv6", Tom Taylor, Cathy Zhou, Qiong Sun, 12-Mar-12, This document characterizes the requirements and describes the methodology for a translator operating within a dual stack multicast router, allowing it to interoperate between Protocol Independent Multicast - Sparse Mode (PIM-SM, RFC 4601) with IPv4 and with IPv6. "IP multicast data plane failure detection", Tissa Senevirathne, Nataraj Bacthu, Raghava Sivaramu, Sam Aldrin, Donald Eastlake, 4-Mar-12, ICMP Based multicast messaging infrastructure is presented in this document. Messages presented in this document is intended to be utilized for troubleshooting multicast data plane connectivity issues as well as identify multicast routers performing different roles, such as Rendezvous Point (RP), Designated Router etc. "hop-by-hop extension header update", Zhonghua Chen, Sreenatha Setty, Tina Tsou, 12-Mar-12, The Hop-by-Hop Options header is used to convey optional information that must be examined by every node along a packet's delivery path. This document updates RFC2460, removing the requirement that source nodes must process the Hop-by-Hop extension header, on the basis that it imposes a performance impact with no advantages. "DTLS Encapsulation of SCTP Packets for RTCWEB", Randell Jesup, Salvatore Loreto, Randall Stewart, Michael Tuexen, 4-Mar-12, The Stream Control Transmission Protocol (SCTP) is a transport protocol originally defined to run on top of the network protocols IPv4 or IPv6. This memo document specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol. SCTP over DTLS is used by the RTCWeb protocol suite for transporting non- media data between browsers. "Two Dimensional IP Routing Architecture", Mingwei Xu, Jianping Wu, Shu Yang, Dan Wang, 4-Mar-12, This document describes Two Dimensional IP (TwoD-IP) routing, a new Internet routing architecture which makes forwarding decisions based on both source address and destination address. This presents a fundamental extension from the current Internet, which makes forwarding decisions based on the destination address, and provides shortest single-path routing towards destination. Such extension provides rooms to solve fundamental problems of the past and foster great innovations in the future. We present the TwoD-IP routing framework and its two underpinning schemes. The first is a new hardware-based forwarding table structure for TwoD-IP, FIST, which achieves line-speed lookup with acceptable storage space. The second is a policy routing protocol that flexibly diverts traffic. "SMTPUTF8 Capability Indicator", Jiankang Yao, Sean Shen, 4-Mar-12, Key RFCs for internationalized email addresses specify the basic protocols for using them. The SMTP client can only know the SMTP server's ability by EHLO command. In order to help the internationalized email address delivery, this document suggests to add the new DNS RR type for internationalized email protocols. Through this RR type, the SMTP client can know whether the destination SMTP server can support the SMTPUTF8 ability before sending the EHLO command to the server. "DNSSEC KSK rollover failure recovery practices", Yoshiro Yoneya, 4-Mar-12, This document intend to consider best practice for quick recovering from DNSSEC DS registration failure. "Applicability of Stateful Path Computation Element (PCE)", Fatai Zhang, Xian Zhang, Young Lee, Ramon Casellas, Oscar de Dios, 4-Mar-12, The Path Computation Element (PCE) provides a solution for Traffic Engineering (TE) based path calculation in large, multi-domain, multi-region, or multi-layer networks. Depending on whether a PCE keeps information about LSPs and reserved resource usage in the network or not, it can be categorized as either stateful or stateless. This memo describes general considerations for stateful PCE(s) and examines its applicability through a number of typical scenarios. It shows how stateful PCE(s) can be applied to facilitate these applications. "TRILL Data Center Interconnect", Sam Aldrin, Donald Eastlake, Tissa Senevirathne, Ayan Banerjee, Santiago Alvarez, 5-Mar-12, This document presents a solution suite for TRILL data center sites to be connected over WAN networks. TRILL protocol is primarily designed to work within intra-data centers. Connecting different sites over WAN using overlay tunnel protocols is the primary method employed at present. Though this presents a simple mechanism to extend the LAN sites to be interconnected, it also brings in the problem of scalability for TRILL nicknames exchanged between sites, latency, duplication of traffic etc. This draft proposes a way to extend the TRILL sites without having to reveal the data of the LAN like customer MAC's or provide MAC's over the WAN, but to establish connections between various sites by extending routing protocol to exchange minimal information, thus reducing the information flow to the required sites only. Document also proposes BGP routing protocol extensions as an example to establish paths and information about the essential RBridges nicknames, over WAN networks like MPLS. "Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extension for signaling Objective Function and Metric Bound", Zafar Ali, George Swallow, Clarence Filsfils, Luyuan Fang, Ruediger Kunze, 12-Mar-12, When using GMPLS control plane, the ingress node may need to request remote node to perform route computation or expansion. In such cases, ingress node needs to convey the required objective function for the path computation algorithm to the remote node, so that the remote node can perform the route computation or expansion. Similarly, there are cases the ingress needs to indicate a TE metric bound for the loose segment which is expanded by the remote node(s). This document defines extensions to the RSVP-TE Protocol to allow an ingress node to request the required objective function for the path computation, as well as a metric bound to influence route computation decisions at a remote node(s). "Include Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", Zafar Ali, George Swallow, Clarence Filsfils, Ori Gerstel, Ruediger Kunze, 12-Mar-12, There are scenarios in which it is required that two or more LSPs or segments of LSPs 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. "Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extension for recording TE Metric of a Label Switched Path", Zafar Ali, George Swallow, Clarence Filsfils, Ruediger Kunze, 12-Mar-12, 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 an LSP. "Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) LSP Route Diversity using Exclude Routes", Zafar Ali, George Swallow, Clarence Filsfils, Matt Hartley, Ori Gerstel, Gabriele Galimberti, Ruediger Kunze, Julien Meuric, 12-Mar-12, [RFC4874] 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 ingress node. This document specifies signaling for additional route exclusions based on LSPs currently existing or expected to exist within the network. "Minimum Requirements for Physical Layout of Home Networks", Jari Arkko, Ari Keranen, 5-Mar-12, Support for network technology in buildings varies greatly depending on the age of the building, but the ease of building a home network is also highly dependent on the chosen wiring, power, and equipment space designs. As networking technology evolves at a fast pace, it is important to choose designs that are expected to be useful for a long time. While there are many cabling, equipment, and protocol standards, only limited standards exist for the physical network layout for new buildings. This memo sets a baseline requirements that new, single-family dwellings must at least satisfy in order to benefit from advances in networking technology. Standardizing network technology for buildings is a challenging task, however. This memo has been submitted for the home networking working group at the IETF as one forum that the authors were able to find that cares about the home network as a system. However, in general the IETF has expertise only on protocols, not on the physical medium. Advice is sought on what existing standards already address this problem, what standardization efforts may be under way in the world, and if work remains, what the right forum to discuss these matters might be. "An Architecture for Multicast Protection Using Maximally Redundant Trees", Alia Atlas, Robert Kebler, IJsbrand Wijnands, Andras Csaszar, Gabor Envedi, 5-Mar-12, 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. "IS-IS Extension for BGP FRR Protection against Edge Node Failure", Ahmed Bashandy, 5-Mar-12, Consider a BGP free core scenario where traffic is tunneled between edge routers. Suppose the edge BGP speakers PE1, PE2,..., PEn know about a prefix P/m via the external routers CE1, CE2,..., CEm. If the edge router PEi crashes or becomes totally disconnected from the core, it desirable for a core router "P" that is carrying traffic to the failed edge router PEi to immediately restore traffic by re- routing packets originally tunneled to PEi and destined to the prefix P/m to one of the other edge routers that advertised P/m, say PEj, until BGP re-converges. If the packets originally flowing to the failed edge router PEi are labeled, then the repairing core router P router must swap the label advertised by the failed edge router PEi for the prefix P/m with the label advertised for the same prefix by the edge router PEj before re-routing the packet through an LSP terminating PEj. The document proposes an extension to IS-IS protocol to inform core routers about the repair edge router PEj and, for labeled packets, the label that needs to be pushed/swapped before sending the packet into the tunnel terminating on PEj "LDP Extension for FRR Edge Node Protection in BGP-Free LDP Core", Ahmed Bashandy, Kamran Raza, 5-Mar-12, Consider a BGP free core scenario with LDP running in the core. Suppose the edge BGP speakers PE1 and PE2 know about a prefix P/m via the external routers CE1 and CE2. If the edge LSR PE1 crashes or becomes totally disconnected from the core, it is desirable for a core LSR "P", that is carrying traffic to the failed edge LSR PE1, to immediately restore traffic by re-routing packets destined to the prefix P/m from the LSP terminating on PE1 to be forwarded over the LSP terminating on PE2, until BGP reconverges. If the packets originally flowing to the failed edge LSR PE1 are BGP labeled, then the repairing core LSR P must swap the label (corresponding to prefix P/m) advertised by the failed edge LSR PE1 with the label advertised for the same prefix by the edge LSR PE2 before re-routing the packets through an LSP terminating on PE2. To implement BGP edge node protection in a BGP-free LDP core, this document proposes an extension to LDP. This extension allows an LDP speaker running on a Edge LSR Node (e.g. PE1) to inform the LDP speakers running on core LSRs about the "Repair" edge LSR (e.g. PE2), as well as Repair LSR's label for prefix P/m, if any. "Using Only Link-Local Address in Network Core", Michael Behringer, Eric Vyncke, 5-Mar-12, This document proposes to use only IPv6 link-local addresses on infrastructure links between routers, wherever possible. It discusses the advantages and disadvantages of this approach to aide the decision process for a given network, "PMIPv6-based distributed anchoring", Carlos Bernardos, Juan Zuniga, 5-Mar-12, 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. "CDN Footprint Discovery", Gilles Bertrand, 5-Mar-12, Interconnected CDNs need to exchange information on the set of end- users to which they can deliver content. This information is commonly referred to as "CDN Footprint". This memo presents use cases for CDN Footprint Discovery in CDNI. It provides a survey of existing work on the subject and a set of additional requirements for controlling the exchange of Footprint information. "MAC Address Withdrawal over Static Pseudowire", Siva Sivabalan, Sami Boutros, Neil McGill, 5-Mar-12, This document specifies a mechanism to signal MAC address withdrawal notification using PW Associated Channel (ACH). Such notification is useful when statically provisioned PWs are deployed in VPLS/H-VPLS environment. This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. "Lightweight Service Simplification via DNS", Zehn Cao, Feng Cao, Yuanchen Ma, Hui Tian, 5-Mar-12, This memo discusses a lightweight service simplification method via DNS. Instead of storing the information on the Web infrastructure, the service provider can store them on the DNS servers. By expressing these information in the DNS Resource Records, the requester can get these information directly during the DNS name resolution, without the need of accessing any web resource. This way eliminates the overhead caused by TCP handshake and HTTP get/ response, and can be served as a lightweight information provisioning method. "The Architecture of Open Security Capability", Zehn Cao, Hui Deng, Judy Zhu, 5-Mar-12, This position paper introduces an architecture of opening the operator's security capability to third party smart object applications. With this architecture, the authentication, integrity and encryption capabilities can be wrapped up as Application Programming Interfaces and provided to third party application developers. So the third party applications do not have to spare energy on these basic security functionalities. As a consequence, the barrier for new applications is lowered, and it avoids the need of providing security by multiple applications and hence saves the computing and communication resources on constrained nodes. Note: This document is submitted for the IAB Workshop on Smart Object Security on March 23, 2012, Paris. "Requirements for ControLling mUltiple streams for tElepresence (CLUE) signaling.", Stephane Cazeaux, Emmanuel Bertin, Bruno Chatras, 27-Mar-12, This document defines requirements relating to the design of CLUE signaling. This document also proposes two alternative design approaches to CLUE signaling. "Guard Bands requirements for GMPLS controlled optical networks", Daniele Ceccarelli, Giulio Bottari, Nicola Sambo, Fatai Zhang, Ramon Casellas, 5-Mar-12, The continuous increase of flexibility and bit rate in optical networks has higher and higher impacts on inter-channel effects (e.g. Cross-phase modulations). This effect leads to the introduction of Guard Bands between adjacent light paths in order to reduce the inter-channel detrimental effects. This document provides requirements for the devolpment of protocol extensions to support Generalized Multi-Protocol Label Switching (GMPLS) and Path Computation Element (PCE) management of Guard Bands. "The Applicability of the PCE to Computing Protection and Recovery Paths for Single Domain and Multi-Domain Networks", Huaimo Chen, 5-Mar-12, The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. 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. "Cases Study- PCP Deployment in Mobile Network", Gang Chen, Zhen Cao, 5-Mar-12, This memo provided two cases study, when PCP is deployed in mobile network. Some motivation of deployment PCP in mobile network was described and justification for each deployment case was stated. Corresponding to each mode, the document discussed some features to address operational issues. That might potentially cause some extension on PCP protocol level. "Using ITU-T-based IDs for MPLS-TP Proactive Connectivity Verification", Zhenlong Cui, Rolf Winter, 5-Mar-12, This document defines how to use ICC-based Multiprotocol Label Switching Transport Profil(MPLS-TP) identifiers for proactive connectivity verification (CV) analogous to RFC 6428. New TLVs are defined to support proactive CV based on identifiers following ITU-T conventions. "Route Leaks -- Definitions", Brian Dickson, 5-Mar-12, The Border Gateway Protocol, version 4, (BGP4) provides the means to advertise reachability for IP prefixes. This reachability information is propagated in a peer-to-peer topology. Sometimes routes are announced to peers for which the local peering policy does not permit. And sometimes routes are propagated indiscriminantly, once they have been accepted. This document considers the situations that can lead to routes being leaked, and tries to find acceptable definitions for describing these scenarios. The purpose of these definitions is to facilitate analysis of what a route leak is, and what the scope of the problem space for route leaks is. This, in turn, is intended to inform a requirements document for detection of (and prevention of) route leaks. And finally, the definitions and requirements are intended to allow proposed solutions which meet these criteria, and to facilitate evaluation of proposed solutions. The fundamental objective is to "solve the route leaks problem". "Route Leaks -- Requirements for Detection and Prevention thereof", Brian Dickson, 5-Mar-12, The Border Gateway Protocol, version 4, (BGP4) provides the means to advertise reachability for IP prefixes. This reachability information is propagated in a peer-to-peer topology. Sometimes routes are announced to peers for which the local peering policy does not permit. And sometimes routes are propagated indiscriminantly, once they have been accepted. This document is a requirements document for detection of (and prevention of) route leaks. Together with the definitions document, it is intended to suggest solutions which meet these criteria, and to facilitate evaluation of proposed solutions. The fundamental objective is to "solve the route leaks problem". "Route Leaks -- Proposed Solutions", Brian Dickson, 5-Mar-12, The Border Gateway Protocol, version 4, (BGP4) provides the means to advertise reachability for IP prefixes. This reachability information is propagated in a peer-to-peer topology. Sometimes routes are announced to peers for which the local peering policy does not permit. And sometimes routes are propagated indiscriminantly, once they have been accepted. This document considers the situations that can lead to routes being leaked, and tries to find acceptable definitions for describing these scenarios. The purpose of these definitions is to facilitate discussion on what a route leak is, and what the scope of the problem space for route leaks is. This, in turn, is intended to inform a requirements document for detection of (and prevention of) route leaks. And finally, the definitions and requirements are intended to allow proposed solutions which meet these criteria, and to facilitate evaluation of proposed solutions. The fundamental objective is to "solve the route leaks problem". "Customer Edge Router Identification Option", Chris Donley, Chris Grundemann, 5-Mar-12, Several addressing mechanisms supporting DHCPv6 Prefix Delegation in home networks require identification of the customer edge router (CER) as the demarcation between the customer network and the service provider network. This document reserves a DHCPv6 option to identify the CER. "Path Computation Element (PCE) Traffic Engineering Database (TED) Requirements", Olivier Dugeon, Julien Meuric, Richard Douville, Ramon Casellas, Oscar de Dios, 12-Mar-12, The Path Computation Element (PCE) working group (WG) has produced a set of RFCs to standardize the behavior of the Path Computation Element as a tool to help MPLS-TE and GMPLS LSP tunnels placement. In the PCE architecture, a main assumption has been done concerning the information that the PCE needs to perform its computation: the Traffic Engineering Database (TED) contains all pertinent and suitable information regarding the network that is in the scope of a PCE. Nevertheless, the TED requirements as well as the TED information have not yet been formalized. In addition, some recent RFC (like the Backward Recursive Path Computation procedure) or WG draft (like draft-ietf-pce-hierarchy ...) suffer from a lack of information in the TED, leading to a non optimal result or to some difficulties to deploy them. This memo tries to identity some TED requirements for the PCE. It is split in two main section: the identification of the specific information to be stored in the TED and how it may be populated. "Transparent Interconnection of Lots of Links (TRILL) Support of the Link Layer Discover Protocol (LLDP)", Donald Eastlake, Anoop Ghanwani, 5-Mar-12, The Link Layer Discovery Protocol (LLDP, IEEE Std 802.1AB) is a one- way, unacknowledged protocol for the announcement of a station's capabilities to its peers. The set of peers that receive these frames and the scoping of the frame, such as whether or not it traverses certain types of bridges, is primarily determined by the destination MAC address of the LLDP frame. This document specifies TRILL (Transparent Interconnection of Lots of Links) support of LLDP and updates RFC 6325. "NAT traversal for LISP", Vina Ermagan, Dino Farinacci, Darrel Lewis, Jesper Skriver, Fabio Maino, Chris White, 26-Mar-12, 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, 12-Mar-12, 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 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. "Home Network Autoconfiguration via DHCPv6 Relay", Chris Grundemann, Chris Donley, 12-Mar-12, This document describes a method for efficiently delegating subnets of an IPv6 prefix among home routers while simultaneously creating functional routing tables in all home routers without the need for a routing protocol. "HTTP Header Content Security Policy", Adam Barth, Tobias Gondrom, 5-Mar-12, To communicate the Content Security Policy (CSP) as defined by the W3C, the web server needs to send a HTTP header to the browser (client) to inform it about the content security policies that SHALL be applied on the client. This draft outlines the header to communicate the CSP with its fields. The definition of the semantic of the directives will be done by the Web Application Security Working Group at the W3C. "Service Provider Wi-Fi Services Over Residential Architectures", Sri Gundavelli, Mark Grayson, Pierrick Seite, Yiu Lee, 29-Apr-12, 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. "The Reachability Method (RM) DNS Resource Record", Ted Hardie, 5-Mar-12, This draft proposes a DNS resource record for providing adjunct reachability methods for network hosts or resources which are only accessible within limited reachability domains. "Datagram Transport Layer Security in Constrained Environments", Klaus Hartke, Olaf Bergmann, 12-Mar-12, We consider some obstacles in implementing Datagram Transport Layer Security (DTLS) in constrained environments, and present some ideas for a constrained version of DTLS that is friendly to constrained nodes and networks. "EAP Mutual Cryptographic Binding", Sam Hartman, Margaret Wasserman, Dacheng Zhang, 5-Mar-12, 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. "Suite B Ciphersuites for the Bundle Security Protocol", Kelley Burgin, Angela Hennessy, 5-Mar-12, This document proposes eight ciphersuites for the Bundle Security Protocol (BSP), similar to the four suites specified in RFC 6257. The eight new ciphersuites provide compatibility with the United States National Security Agency's Suite B specifications. "Suite B Profile for the Bundle Security Protocol", Kelley Burgin, Angela Hennessy, 5-Mar-12, The United States Government has published guidelines for "NSA Suite B Cryptography" dated July, 2005, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using Suite B cryptography in the Bundle Security Protocol (BSP) Since many of the Suite B algorithms enjoy uses in other environments as well, the majority of the conventions needed for the Suite B algorithms are already specified in other documents. This document references the source of these conventions, with some relevant details repeated to aid developers that choose to support Suite B. "Ciphers in Use in the Internet", David McGrew, Sean Shen, 5-Mar-12, This note catalogs the ciphers in use on the Internet, to guide users and standards processes. It presents the security goals, security analysis and results, specification, intellectual property considerations, and publication dates of each cipher. Background information and security guidance is provided as well. "Combined Use of the Session Initiation Protocol (SIP) and the eXtensible Messaging and Presence Protocol (CUSAX)", Emil Ivov, Enrico Marocco, 5-Mar-12, This document describes current 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 complimenting subsets of features from each of the protocols. Typically such subsets would include telephony oriented from SIP and instant messaging and presence capabilities from XMPP. This specification does not define any new protocols or syntax for neither SIP nor 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 us should be preferred to the mechanisms provided natively by each protocol like 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, 5-Mar-12, 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. This minor protocol has applicability to other bidirectional uses of SCTP. "Transporting PTP messages over MPLS networks using a link local addressing", Sebastien Jobert, 5-Mar-12, This document introduces a method for transporting PTP messages over an MPLS network supported by an Ethernet physical layer. The MPLS layer itself is not used to carry the PTP messages with this method; instead, a link local Ethernet channel is used. Several advantages related to this method are highlighted in this document. The method targets in particular telecom applications requiring accurate phase/time synchronization, with "link-by-link" PTP architectures, where all the network nodes support a PTP function, such as Boundary Clock or Transparent Clock. "Pre-congestion notification in mobile networks", Sebastien Jobert, Isabelle Hamchaoui, 5-Mar-12, Mobile networks may be divided into two main segments: the radio segment, and the wireline segment. This document highlights that the algorithms leading to pre-congestion notification (e.g. ECN marking) are usually significantly different for these two segments, and not defined or documented in general over the radio segment. It also explains that using ECN bits leads to having a unique signal for notifying a pre-congestion related to two separate segments with very different notification algorithms. Some consequences are questioned, as well as the potential benefits of being able to identify where the congestion comes from. This document finally discusses the possibility to take into account the radio conditions of the terminals when counting the volume of congestion over the radio segment. "JSON Web Encryption JSON Serialization (JWE-JS)", Michael Jones, 12-Mar-12, The JSON Web Encryption JSON Serialization (JWE-JS) is a means of representing encrypted content using 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 enumerated in the separate JSON Web Algorithms (JWA) specification. The JSON Serialization for related digital signature and HMAC 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, 12-Mar-12, The JSON Web Signature JSON Serialization (JWS-JS) is a means of representing content secured with digital signatures or Hash-based Message Authentication Codes (HMACs) using 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 HMACs to be applied to the same content (unlike JWS). Cryptographic algorithms and identifiers used with this specification are enumerated 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. "Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication", Hadriel Kaplan, Emil Ivov, Dan Wing, 5-Mar-12, This document describes behavior of signalling intermediaries in 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. "Update on Candidate Address Selection for Interactive Connectivity Establishment (ICE)", Ari Keranen, Jari Arkko, 5-Mar-12, This document revisits the rules on how candidate addresses are selected and combined when the Interactive Connectivity Establishment (ICE) NAT traversal method is used. This document updates RFCs 5245 and 6544. "More Raw Public Keys for IKEv2", Tero Kivinen, Paul Wouters, Hannes Tschofenig, 5-Mar-12, 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. "Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for Internationalized Domain Name (IDN) Variants", Ning Kong, Jiagui Xie, Hongtao Li, Wil Tan, XiaoDong Lee, 5-Mar-12, This document describes an extension of Extensible Provisioning Protocol (EPP) domain name mapping for the provisioning and management of Internationalized Domain Name (IDN) Variants. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of IDN variants. "Diameter End-to-End Security: Keyed Message Digests, Digital Signatures, and Encryption", Jouni Korhonen, Hannes Tschofenig, 5-Mar-12, This document defines an extension for end to end authentication, integrity and confidentiality protection of Diameter Attribute Value Pairs. The solutions focuses on protecting Diameter Attribute Value Pairs and leaves the key distribution solution to a separate specification. The integrity protection can be introduced in a backward compatible manner to existing application. The confidentiality protection requires an explicit support from an application, thus is applicable only for newly defined applications. Terminology "SPB Deployment Considerations", Roger Lapuh, Paul Unbehagen, Peter Ashwood-Smith, Phillip Taylor, 26-Mar-12, Based on live deployments and three interoperability events, this document provides advice to network operators about best practices when implementing IEEE 802.1aq Shortest Path Bridging (SPB) networks. It is principally addressed to system integrators and solution providers, including those that do not yet support SPB. Some advice to implementers is also included. The intention of the advice is to facilitate multi vendor network deployments as well as provide guidance for new installations. "Framework for DC Network Virtualization", Marc Lasserre, Florin Balus, Thomas Morin, Nabil Bitar, Yakov Rekhter, Yuichi Ikejiri, 12-Mar-12, Several IETF drafts relate to the use of overlay networks to support large scale virtual data centers. This draft provides a framework for Network Virtualization over L3 (NVO3) and is intended to help plan a set of work items in order to provide a complete solution set. It defines a logical view of the main components with the intention of streamlining the terminology and focusing the solution set. "Indicating the Immersive User Agent Capability in the Session Initiation Protocol (SIP)", Glen Lavers, Paul Jones, Gonzalo Salgueiro, 5-Mar-12, This document defines and registers with IANA the new 'immersive' media feature tag for use with the Session Initiation Protocol (SIP). This media feature tag can be used to route calls to a device that can provide an immersive communication experience, such as a Telepresence system. "Indicating the Immersive User Agent Capability in the Session Initiation Protocol (SIP)", Glen Lavers, Paul Jones, Gonzalo Salgueiro, 5-Mar-12, This document defines and registers with IANA the new 'immersive' media feature tag for use with the Session Initiation Protocol (SIP). This media feature tag can be used to route calls to a device that can provide an immersive communication experience, such as a Telepresence system. "Protocol to Access White Space database: PAWS framework data model", Lei Zhu, 5-Mar-12, Portions of the radio spectrum that are allocated to a licensed, primary use but are unused or unoccupied at specific locations and times are defined as "white space". In this document the framework of PAWS is introduced, which includes framework of PAWS, protocol stack, definition of interface, parameters and schema running over interface, and security considerations. The realization of database and the calculation of protected contour are not considered in this framework draft. "Populating the DNS Reverse Tree for DHCP Delegated Prefixes", Ted Lemon, 5-Mar-12, This document describes three alternatives for populating the DNS reverse tree for prefixes delegated using DHCP, and provides mechanisms for implementing each alternative. "Real-Time Transport Protocol (RTP) Topology Considerations for Offer/ Answer-Initiated Sessions.", Jonathan Lennox, 5-Mar-12, This document discusses a number of considerations related to the topologies of Real-Time Transport Protocol (RTP) sessions initated using the Session Description (SDP) unicast Offer/Answer Model, especially as applied to source-multiplexed sessions. The primary observation is that certain topologies cannot be created by unicast SDP Offer/Answer. Notably, the it is not possible to negotiate the topology that RFC 5117 calls Topo-Transport-Translator (or "relay"). As a consequence of this limitation, certain topological assumptions can safely be made for RTP sessions initiated using unicast SDP Offer/Answer; and therefore, certain optimizations to RTP are possible in such sessions. This document also describes the optimizations that these assumptions make possible. "Load Balancer Function Discription", Chen Li, Lianyuan Li, 5-Mar-12, This document presents a functional description of the load balancer. The Load Balancer (LB) is a network device to distribute workload across multiple servers, network links, central processing units, disk drives, or other resources, to achieve optimal resource utilization, maximize throughput, minimize response time, and avoid overload. "Private Enterprise Number (PEN) practices and registration procedures", Pearl Liang, Alexey Melnikov, 5-Mar-12, Private Enterprise Numbers (PENs), are assigned as part of the technical protocol parameters and are frequently used in the management of network connected equipment or software via SNMP-based network management systems, LDAP, DIAMETER or GSS-API. This document discusses what a Private Enterprise Number (PEN) is, common uses and registration procedures. The registration procedures include instructions for obtaining a new Private Enterprise Number, modification to existing numbers and removal. "Data Streaming Subscription in DECADE", Hongqiang Liu, 12-Mar-12, This document describes a potential performance issue in DECADE to support real-time applications. It shows the current content hashing based naming scheme might harm the performance when the content data is generated in real time and low propagation latency of the data is required. This draft propose a new naming scheme and protocol, subscribe/unsubscribe, for real-time applications to address the problem caused by content hashing. DECADE clients use subscribe/ unsubscribe to express their interests to receive data streaming. DECADE servers pro-actively push stream data to eligible clients, which saves the time consumed on exchanging the hashing of new generated data. "Address Selection for DMM", Dapeng Liu, Hui Deng, Juan Liu, 12-Mar-12, In DMM scenario, it is possible for the MN to have multiple mobility anchor points and corresponding prefixes. In that case, MN needs to know the type of the addresses then it can select the right one for application to use. This document describes a mechnism to extend RA message to carry a flag which can be used to identify the nature of the prefix. "Mobility API Extension for DMM", Dapeng Liu, Hui Deng, 5-Mar-12, RFC 5014 specifies extension to socket API to allow application to specify the preference among multiple source addresses. draft-liu-dmm-address-selection-00 proposes to extend router advertisment message to carry the prefix type information. The mobile node can learn the prefix type information from the router advertisment message. This document proposes an extension to RFC 5014 to enable the application to select the DMM related prefixes. "DC Migration to IPv6", Zhonghua Chen, Diego Lopez, Tina Tsou, Cathy Zhou, 12-Mar-12, This document describes the issues, possible solutions, and opportunities in Data Center (DC) migration from IPv4 to IPv6. It 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 deployed on the DC infrastructure. Apart from facilitating the migration procedure itself, the mechanisms outlined here are intended to make this migration 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. "ISIS Transaction TLV", Wenhu Lu, Albert Tian, 5-Mar-12, ISIS local updates may require multiple LSPs to convey. Receiving routers, whose decision processes are without such knowledge, may generate incorrect routing table updates based on the partial set of LSPs it receives and hence the traffic outage before they are corrected by another run of the decision process. This memo describes a method that makes the decision process more informed so that the interim results can be minimized or avoided. "Extended Multicast DNS", Kerry Lynn, Don Sturek, 5-Mar-12, Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional unicast DNS server. Extended mDNS (xmDNS) extends the specification of mDNS to site-local scope in order to support multi-hop LANs that forward multicast packets but do not provide a unicast DNS service. Like mDNS, xmDNS designates a portion of the DNS namespace to apply to the site-local network and specifies rules for its use. "Receiver-Driven Multicast Traffic Engineered Label Switched Paths", Renwei Li, Quintin Zhao, Christian Jacquenet, 5-Mar-12, This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the setup of Receiver-Driven Traffic Engineered(TE) point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP)Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS)networks. "Terminal Test of IPv6 support and DNS Query", Qiongfang Ma, Tianle Yang, 5-Mar-12, This document introduces the terminal test under the WLAN environment .The test includes the ability for terminal to obtain IPv6 address, the sequence of DNS records query and termina behaviors in the condition of DNS records abnormal, for example DNS records are incorrect or absent. Several personal computers and smart phones with different operational system have been tested. The test results have been discussed and to share with internet community. "Potential Use Cases of Internet Congestion Control Research", Dave McDysan, 5-Mar-12, This draft proposes some use cases for consideration by the iccrg. These use cases are in addition to and/or complement those described by the conex working group[UseCases]. The conex working group had determined that these use cases were out of scope of the current charter, and/or could potentially be built out of the conex abstract mechanism. The focus of the use cases in this draft is on forms of congestion exposure that involve resources other than queues and timeframes other than real-time. Background and motivation for these use cases is first discussed. Expanded material on the usage tier/volume use case is also provided. "Mapping of Address and Port (MAP) - Deployment Considerations", Qiong Sun, Maoke Chen, Gang Chen, Chunfa Sun, Tina Tsou, 5-Mar-12, This document describes when and how an operator uses the technique of Mapping of Address and Port (MAP) for the IPv4 residual deployment in the IPv6-dominant domain. "Username and Password Preparation Algorithms", Peter Saint-Andre, Alexey Melnikov, 5-Mar-12, This document describes how to prepare Unicode strings representing user names and passwords, primarily for purposes of comparison. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN and SCRAM-SHA-1), as well as other protocols that exchange simple user names or passwords. This document obsoletes RFC 4013. "Building power shortest inter-Area TE LSPs using pre-computed paths", Shankar Raman, Balaji Venkat, Gaurav Raina, 11-Mar-12, 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. "DHCPv6 Failover Design", Tomasz Mrugalski, Kim Kinnear, 12-Mar-12, DHCPv6 defined in [RFC3315] does not offer server redundancy. This document defines a design for DHCPv6 failover, a mechanism for running two servers on the same network with capability for either server to take over clients' leases in case of server failure or network partition. This is a DHCPv6 Failover design document, it is not protocol specification document. It is a second document in a planned series of three documents. DHCPv6 failover requirements are specified in [requirements]. A protocol specification document is planned to follow this document. "Approaches to Distributed mobility management using Mobile IPv6 and its extensions", Basavaraj Patil, Carl Williams, Jouni Korhonen, 5-Mar-12, Mobility solutions at the IP layer have been specified in the IETF for IPv4 and IPv6. These solutions include host and network based mobility. All of the mobility protocols enable IP session continuity by providing the mobile host with an IP address or prefix that remains constant even as the host moves and attaches to different access networks and points of attachment. Mobile hosts are anchored at a gateway via a tunnel and the address/prefix provided to the host via the gateway remains unchanged across mobility events. All IP sessions initiated or terminated at a mobile host are anchored via the gateway. A gateway centric approach such as Mobile IP, raises certain concerns in terms of cost and efficiency. A mobility model wherein the network entities enabling mobility are distributed is a way of alleviating the concerns of a gateway centric approach. This document considers ways to alleviate anchored mobility issues with approaches that could be considered in a deployment. "Options for Abfab-based Kerberos pre-authentication", Alejandro Perez-Mendez, Josh Howlett, 12-Mar-12, Kerberos is widely used for authentication within organisations. It is not, however, commonly used for authentication between domains or realms ("cross-realm operation"). Abfab is a new architecture, based on the AAA framework, that provides a mechanism for federating authentication between realms. AAA protocols are already widely used for federating authentication for network access scenarios today. It has been proposed that Abfab could be used to provide a mechanism yielding cross-realm functionality for Kerberos. This document discusses two alternative models with the aim of informing and facilitating discussion. "A Framework and Data Model for Queries about Telephone-Related Queries (TeRQ)", Jon Peterson, 5-Mar-12, 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 data model for querying and responding to requests concerning telephone numbers and call routing that allows a richer expression of both questions and answers. "Network Mobility with Proxy Mobile IPv6", Alexandru Petrescu, Michael Boc, Christophe Janneteau, 5-Mar-12, The Proxy Mobile IPv6 protocol supports Mobile Hosts moving independently, but not Mobile Routers in charge of moving networks. This draft addresses this problem. The goal is to allow bidirectional communication between a Local Fixed Node (in the moving network) and a Correspondent Node (situated arbitrarily somewhere in the Internet). First, a mechanism of "prefix division" is presented, whereby the Home Network Prefix typically assigned by PMIPv6 to a MH is used by MR to form Mobile Network sub-Prefix(es); they are used by LFNs within the moving network to form addresses; this avoids changes in the PMIPv6 protocol specification. A second mechanism proposes enhancements to the use of the DHCPv6 Prefix Delegation protocol entities informing the PMIPv6 entities about the allocated MNP; this is achieved by equaling MNID and DUID. "Service Distribution using OSPF", Padma Pillay-Esnault, Burjiz Pithawala, Derek Yeung, 5-Mar-12, The Open Shortest Path First (OSPF) protocol is used to carry data on behalf of other services using the Opaque Link State Advertisements. The protocol's flooding mechanism is well suited to cover the data propagation requirements of services such as Traffic Engineering. The current mechanism cannot scale for a large number of services nor satisfy some of their new set of requirements. This document describes a new mechanism in OSPF to support service and data distribution for a large number of services, computation of preferred service access points and a controlled service data exchange. "New Differentiated Services Code Point Assignments for Rich Media Traffic", James Polk, 5-Mar-12, 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-12, 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. "ALTO Cost Schedule", Sabine Randriamasy, Nico Schwan, 5-Mar-12, The goal of Application-Layer Traffic Optimization (ALTO) is to bridge the gap between network and applications by provisioning network related information. This allows applications to make informed decisions, for example when selecting a target host from a set of candidates. The ALTO problem statement [RFC5693] considers typical applications as file sharing, real-time communication and live streaming peer-to-peer networks. Recently other use cases focused on Content Distribution Networks and Data Centers have emerged [draft-jenkins-alto-cdn-use-cases-01]. The present draft proposes to extend the cost information provided by the ALTO protocol. The purpose is to broaden the decision possibilities of applications to not only decide 'where' to connect to, but also 'when' to connect. This is useful to applications that have a degree of freedom on when to schedule data transfers, such as non-instantaneous data replication between data centers. The draft therefore specifies a new cost mode, called the "schedule" mode. In this mode the ALTO server offers cost maps that contain link ratings that are valid for a given timeframe (e.g. hourly) for a period of time (e.g. a day). Besides the functional time-shift enhancement providing multi-timeframe cost values the extansion also allows the saving of a number of ALTO transactions and thus resources on the ALTO server and clients. "BGPSEC router key roll-over as an alternative to beaconing", Roque Gagliano, Keyur Patel, Brian Weis, 5-Mar-12, The current BGPSEC draft documents do not specifies a key roll-over process for routers. This document describes a possible key roll- over process and explores its impact to mitigate replay attacks and eliminate the need for beaconing in BGPSEC. "Preparation and Comparison of Nicknames", Peter Saint-Andre, 5-Mar-12, This document describes how to prepare and compare Unicode strings representing nicknames, primarily as used within textual chatrooms. This profile is intended to be used by chatroom technologies based on both the Extensible Messaging and Presence Protocol (XMPP) and the Message Session Relay Protocol (MSRP). "TCP Segment Caching", Pasi Sarolahti, Joerg Ott, Colin Perkins, 5-Mar-12, This document describes Content- and Cache-Aware TCP (CATCP) that allows caching of TCP segments to be re-used between different connections transmitting same data. When there is redundant data to multiple receivers, this can lead to significant load reductions and performance improvements. "Protocol for Communication between White Space Device and White Space Database", Donald Joslyn, Robin Roberts, 5-Mar-12, This document defines an application protocol for WSDB services provided to TV Band Devices (TVBDs). The protocol complies with FCC Rules/Requirements [FCC 10-174] and in the context of operating an FCC certified database, it also complies with requirements defined by IETF PAWS [IETF-PAWS-03]. We believe this protocol can be easily extended to include the remaining requirements not already satisfied from the IETF PAWS requirements. "Definition of Managed Objects for Virtual Machines Controlled by a Hypervisor", Juergen Schoenwaelder, Tina Tsou, Cathy Zhou, 5-Mar-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 virtual machines controlled by a hypervisor. "RTP Stream Information Export using IPFIX", Hendrik Scholz, 5-Mar-12, This draft defines a set of Information Elements and matching Templates to convey RTP media stream information in IPFIX packets. The Information Elements describe the RTP header and payload characteristics of the RTP stream either for the entire duration of the monitored stream or for a smaller time slice. "CDNI Request Routing with ALTO", Jan Seedorf, 9-Mar-12, Network Service Providers (NSPs) are currently considering to deploy Content Delivery Networks (CDNs) within their networks. As a consequence of this development, there is a need for interconnecting these local CDNs. The necessary interfaces for inter-connecting CDNs are currently being defined in the Content Delivery Networks Interconnection (CDNI) WG. This document focusses on the Request Routing Interface of CDNI, and more specifically on how the solutions currently being defined in the Application Layer Traffic Optimization (ALTO) WG can improve CDNI request routing. The overall intention behind this document is to foster discussions (in the CDNI as well as in the ALTO WG) regarding if, how, and under what conditions ALTO can be useful to optimize CDNI request routing. As basis for this discussion, this document provides concrete examples of how ALTO can be integrated within CDNI request routing and in particular in the process of selecting a downstream CDN. The examples in this document are based on the use cases and examples currently being discussed in the CDNI WG. "Infrastructure-to-application information exposure from an ALTO-CDNI Perspective", Jan Seedorf, 5-Mar-12, Recently, there has been a discussion on "Infrastructure-to- Application Information Exposure" and the related communications requirements in fully controlled (e.g. data centers) or partially controlled environments (e.g. CDN). One possibility to expose infrastructure information to applications in the aforementioned environments is to use yet-to-be-defined ALTO extensions. This draft discusses requirements for such ALTO extensions for a specific use case: Request Routing in CDN Interconnection (CDNI). "IP Multicast Use Case Analysis for PMIPv6.based Distributed Mobility Management", Sergio Figueiredo, Rui Aguiar, Seil Jeon, 12-Mar-12, As mobile networks are moving towards distributed mobility management, the application of IP multicast is needed to provide efficient content delivery on the network. This document describes use cases when IP multicast is applied on PMIPv6-based DMM, and analyzes problems focused on user plane issues. "The +exi Media Type Suffix", Zach Shelby, 29-Mar-12, Efficient XML Interchange (EXI) is an XML representation technique specified by the W3C to provie a binary alternative to the standard text XML representation. This document defines a new Structure Syntax Suffix "+exi" for use in a specific class of protocols, where "exi" content-type encoding or the generic "application/exi" Media Type are not applicable. "RSVP Setup Protection", Yimin Shen, Yuji Kamite, 5-Mar-12, RFC 4090 specifies an RSVP facility-backup fast reroute mechanism that can protect LSPs against link and node failures. This document extends the mechanism to provide "setup protection" for LSPs during initial Path message signaling time. In particular, it enables a router to reroute an LSP via a bypass LSP, when there is a link or node failure along the desired path. "CDNI Request Routing: Footprint and Capabilities Semantics", Jan Seedorf, Jon Peterson, Stefano Previdi, 5-Mar-12, This document tries to capture the semantics of the "Footprint and Capabilities Advertisment" part of the CDNI Request Routing interface, i.e. the desired meaning and what "Footprint and Capabilities Advertisment" 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 Advertisment" within CDNI Request Routing. "Accessing Cloud Services", Yaakov Stein, Yuri Gittik, Monique Morrow, Luyuan Fang, Wim Henderickx, 5-Mar-12, 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 extensions for CDNi", Emile Stephan, Selim Ellouze, 5-Mar-12, The selection of a downstream CDN by an upstream CDN is based on multi-dimensional criteria such as the number of hops, the performance of the connections between the user-agent and downstream CDNs and the availability of downstream CDNs resources. Various protocols, such as BGP or ALTO, may be used by an upstream CDN to collect footprints and interconnection preferences of downstream CDNs. This draft introduces several extensions to the ALTO protocol for CDN interconnection. "Asserting Administrative Policies and Boundaries in DNS Zones", Andrew Sullivan, 12-Mar-12, Some security policies on the Internet depend on the idea of the "domain policy" or "zone policy". It is difficult to discover such policies, and it is harder to do so in a way that does not subject operators of domains to others' assertions. This memo describes the problem, and proposes a mechanism for solving it. "Deployment Considerations for Lightweight 4over6", Qiong Sun, Chongfeng Xie, Yiu Lee, 12-Mar-12, 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. "A Framework for control of Flex Grid Networks", Sharfuddin Syed, Rajan Rao, Marco Sosa, Biao Lu, Bert Basch, Andrew Malis, 25-Apr-12, This document provides a framework for applying the Generalized Multi-Protocol Label Switching (GMPLS) architecture and protocols to a Flex-Grid capable optical switching layer. "Emergency Services Functionality with the Extensible Messaging and Presence Protocol (XMPP)", Hannes Tschofenig, 5-Mar-12, The Extensible Messaging and Presence Protocol (XMPP) is a technology that enjoys widespread deployment in the instant messaging application domain. While many features for XMPP had been standardized in the IETF as well as in the XMPP Standards Foundation emergency services functionality was not part of it. This document aims to initiate a discussion about the necessary emergency services functionality for XMPP. "BFD Support DS-Lite", Tina Tsou, 26-Mar-12, In DS-Lite, the tunnel is not associated with any state information, which makes it difficult to manage and diagnose. Some tools may be used to resolve this problem. "BFD Support DS-Lite", Tina Tsou, 26-Mar-12, In DS-Lite, the tunnel is not associated with any state information, which makes it difficult to manage and diagnose. Some tools may be used to resolve this problem. "IP/IPVPN services with IEEE 802.1aq SPB networks", Paul Unbehagen, Roger Lapuh, Peter Ashwood-Smith, 5-Mar-12, This document describes a compact method of using a IEEE 802.1aq Shortest Path Backbone Bridging (SPB) network to natively enable and carry IP and IPVPN services on native Ethernet links. Further this documents the extensions to SPB's control protocol, IS-IS, required to allow it to be a single mechanism for providing all these services types. On its own SPB provides virtual Ethernet networks; utilizing IS-IS to create loop free Ethernet topologies that forward Ethernet traffic using a standard Ethernet header. This document shows how the same SPB network can also be leveraged to provide IP based services. "EAP Attributes for WiFi - EPC Integration", Ravi Valmikam, Rajeev Koodli, 5-Mar-12, 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. "Context Transfer for Multicast support in Distributed Mobility Management (DMM)", Dirk Hugo, Hitoshi Asaeda, Pierrick Seite, 5-Mar-12, This document describes a context transfer based concept to support overarching IP multicast services applicable to various existing approaches for Distributed Mobility Management. "Operational Security Considerations for IPv6 Networks", KK Chittimaneni, Merike Kaeo, Eric Vyncke, 5-Mar-12, Network managers know how to operate securely IPv4 network: whether it is the Internet or an enterprise internal network. IPv6 presents some new security challenges. RFC 4942 describes the security issues in the protocol but network managers need also a more practical, operation-minded best common practices. This document analyzes the operational security issues in all places of a network (service providers, enterprises and residential users) and proposes technical and procedural mitigations techniques. "Codec Operation Point RTCP Extension", Magnus Westerlund, Bo Burman, Laurits Hamm, 5-Mar-12, The Audio-Visual Profile with Feedback (AVPF) specification defines a framework and messages for fast feedback and media control over RTCP. The Codec Control Messages (CCM) specification defines an extension to AVPF, by specifying additional messages for codec control and feedback. This specification extends CCM, by specifying messages that let participants dynamically communicate a set of codec configuration parameters, which enables better optimization of resource efficiency and quality of media transmission. "LISP-DDT Database Transfer", Glen Wiley, 12-Mar-12, This draft describes a protocol for transferring a LISP Delegated Database Tree (LISP-DDT) between DDT nodes and for notifying DDT nodes that the database has changed. In the absence of a formally defined protocol the LISP-DDT database is transferred using files containing device configuration commands. This protocol provides for transferring a complete database or the deltas between two versions of the database. This document does not describe the use of DDT as part of the LISP mapping service. "On Lightweight and Embedded IP Programming Interfaces", Carl Williams, Geoffrey Mulligan, 5-Mar-12, This document takes a look at various aspects of Application Programming Interfaces (APIs) used in embedded sensors and controller applications such as IP Smart Objects and IP based Wireless Sensor Networks. These devices may be interconnected via many different types of media, including 802.15.4 (lowpans), power line control (PLC), RS485, but the common characteristic is that the devices have extremely limited code space and memory space for both the stack and application. Just as there is no one single API for IP networking stacks today (though the "Berkeley sockets" might be considered de- facto standard) there is not likely to be a single standard in the embedded space, but there can be some common understanding about facilities that can and should be provided to the application developer. "SIP Identity using Media Path", Dan Wing, Hadriel Kaplan, 5-Mar-12, This document defines a new SIP identity mechanism which creates a signature over a certain subset of SIP headers and certain subset of SDP lines. This this mechanism works with trickling ICE candidates and works across zero or more Session Border Controllers. "DECADE Use Cases", Xue Haiwei, Wang Danhua, 5-Mar-12, The objective of DECADE is to provide storage access to Content Distribution Applications to improve their efficiency and reduce load on the network infrastructure. In this document, we outline several potential use cases (not technical solutions) for DECADE. These use cases may provide motivations for DECADE. Interactions within DECADE and between DECADE Servers and DECADE Clients are described at an abstract level so as to not constrain future protocol development. "Mitigating aggregated traffic of DHCP discover messages", Tianle Yang, Qiongfang Ma, 5-Mar-12, This document defines a new option DIS_MAX_RT which can mitigate aggregated traffic caused by discover messages the client sends to the server. "RADIUS Option for DHCPv6 Relay Agents on Broadband Access Server", Leaf Yeh, Mohamed Boucadair, Ted Lemon, 25-Apr-12, The DHCPv6 RADIUS option provides a communication mechanism between relay agent and the server. This mechanism can help the centralized DHCPv6 server to select the right configuration for the client based on the authorization information received from a separate RADIUS server which is not located at the same place of DHCPv6 server in the cases where the NAS acts as DHCPv6 relay agent and RADIUS client simultaneously. "VLAN based Tree Selection for Multi-destination Frames", Li Yizhou, Hao Weiguo, Somnath Chatterjee, 5-Mar-12, TRILL uses distribution trees for multi-destination traffic. In fat tree structure, it is very possible that the distance from an ingress RBridge to multiple tree roots are the same. Therefore the minimum distance comparison may not help much in the tree selection decision. Multiple trees can be used by an ingress RBridge. 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 up to the total number of distribution trees in the campus. If finer granularity filtering such as L2/L3 multicast address is used, then the multicast forwarding table size further increases dramatically. TRILL multicast forwarding table size is limited in hardware/silicon implements and sometimes L3 multicasting shares the same table with it. This document specifies a VLAN based tree selection mechanism to reduce the multicast forwarding table size. No data plane change is required. "Revealing hosts sharing an IP address using ICMP Echo Request", Andrew Yourtchenko, 5-Mar-12, When an IP address is shared among several subscribers -- with a NAT or with an application-level proxy -- it is impossible for the server to differentiate between different clients. Such differentiation is valuable in several scenarios. This memo describes a technique to differentiate TCP and UDP clients sharing an IP address. The proposed method uses an ICMP Echo Request packet, which allows for more information about the user mapping to be transmitted than in the case of using the TCP option - and allows the use with UDP and other protocols. "Human-safe IPv6: Cryptographic transformation of hostnames as a base for secure and manageable addressing", Andrew Yourtchenko, Salman Asadullah, Mircea Pisica, 5-Mar-12, Although the IPv6 address space within a single /64 subnet is very large, the typical distribution of the addresses in this space is very non-uniform. This non-uniformity, together with the dictionary- based DNS brute-force enumeration, allows practical remote mapping of the IPv6 addresses in these subnets. This document proposes a technique which can be used to decrease the exposure of the server subnets to trivial scanning. As a side effect, the proposed technique allows to drastically simplify the address management. "Framework for GMPLS and PCE Control of Spectrum Switched Optical Networks", Fatai Zhang, Young Lee, Oscar de Dios, Ramon Casellas, Daniele Ceccarelli, 5-Mar-12, A new flexible grid of DWDM has been developed within the ITU-T Study Group 15 to allow a more efficient spectrum allocation. In such environment a data plane connection is switched based on the allocated variable width optical spectrum frequency slot. This new switching capability is referred to as Spectrum Switched Optical Networks (SSON). This draft describes the framework for the application of a GMPLS control plane to a SSON. "Comparison of DECADE with CDNi", Peng Zhang, 5-Mar-12, This document gives a brief comparison of DECADE and CDNi, two working groups on content delivery. CDNi aims at overcoming the limited resource and footprints of a single CDN by interconnecting multiple CDNs. While DECADE is mainly concerned with reducing the last-mile bandwidth bottleneck and inter-domain traffics with in- network storage. This in-network storage can also be utilized by Content Service Providers (CSPs) as a CDN, whose footprints be across multiple Internet Service Providers (CSPs). In this sense, DECADE can also be a possible approach to overcome the limited footprints of a single CDN. This document attempts to gain some understanding on the relationship of these two solutions. "DNS-Test-Result", Juan Zhang, Lanfang Ren, Lianyuan Li, 5-Mar-12, This document introduces performance test results of DNS, and makes some analysis about the test results. "Multicast transition path optimization in IPv4 and IPv6 networks", Qiong Sun, Cathy Zhou, 5-Mar-12, 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 paths. 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, Shoji Noguchi, 6-Mar-12, This document specifies the format and contents of Domain Name Registration Data (DNRD) Escrow deposits. Specified in Extensible Markup Language (XML), the mapping defines Registration Data Escrow (RDE) deposit syntax and semantics. "Mechanisms for Directory Assisting RBridge", Linda Dunbar, Radia Perlman, Igor Gashinsky, Donald Eastlake, 6-Mar-12, This draft describes the mechanisms of using directory server(s) to assist RBridge edge in data center environment. "Trust Router Problem Statement", Josh Howlett, Margaret Wasserman, 26-Mar-12, This document is a problem statement for a Trust Router Protocol. A Trust Router Protocol is needed to support large, multihop ABFAB federations, without the need for credentials to be configured for every pair of Identity Providers and Relying Parties. "IRR & Routing Policy Configuration Considerations", Danny McPherson, Shane Amante, Eric Osterweil, 6-Mar-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. "Requirements for Combined Protection and Restoration", Evelyne Roch, Lyndon Ong, 6-Mar-12, This Internet-Draft proposes requirements for combinations of rerouting and protection schemes that are of interest to carrier networks. "Revertive Recovery Requirements", Evelyne Roch, Lyndon Ong, 6-Mar-12, This draft identifies requirements for support of full rerouting recovery scheme in a revertive manner. "Issues with End-point dependent mapping", Senthil Sivakumar, 6-Mar-12, Some NAT devices implement the End-point dependent mapping and filtering behavior. This document describes the issues that would arise with End-point dependent mapping and filtering behavior. "TFTP Windowsize Option", Patrick Masotta, 14-May-12, 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]. "Diffie-Hellman Proof-of-Possession Algorithms", Jim Schaad, Hemma Prafullchandra, 29-Apr-12, This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair and one method for producing an integrity check value from an Elliptic Curve key pair. This behavior is needed for such operations as creating the signature of a PKCS #10 certification request. These algorithms are designed to provide a proof-of-possession rather than general purpose signing. "Plasma Service CMS Processing", Jim Schaad, 8-Mar-12, 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. In [EPS-WS-TRUST] a new model has been presented where a third party is used as the enforcement point of the label. This document provides the details needed to implement the new Plasma model in the CMS infrastructure. Additional benefits of using the Plasma module include moving responsibility of building lock boxes to the server and determining, based on policy, who should be a message recipient. The document describes and details how the encryption process is performed, defines a new lock box attribute to hold the information needed to valid the label and to obtain the keys needed to decrypt the message. The document does not cover the protocol between the client and the Plasma policy enforcement server. "Simple Cloud Identity Management: Protocol 1.0", Chuck Mortimore, Morteza Ansari, Trey Drake, Kelly Grizzle, Erik Wahlstroem, 15-Mar-12, The Simple Cloud Identity Management (SCIM) specification is designed to make managing user identity in cloud based applications and services easier. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. It's intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols. In essence, make it fast, cheap, and easy to move users in to, out of, and around the cloud. "Simple Cloud Identity Management: Core Schema 1.0", Chuck Mortimore, Patrick Harding, Paul Madsen, Trey Drake, 15-Mar-12, The Simple Cloud Identity Management (SCIM) specification is designed to make managing user identity in cloud based applications and services easier. The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols. In essence, make it fast, cheap, and easy to move identity in to, out of, and around the cloud. This document provides a platform neutral schema and extension model for representing users and groups in JSON and XML formats. This schema is intended for exchange and use with cloud service providers. Additional binding documents provide a standard REST API, SAML binding, and use cases. "Interconnecting multiple TRILL sites deploying Traffic Engineering", Balaji Venkataswami, Bhargav Bhikkaji, Narayana Swamy, 25-Mar-12, This document specifies the control plane procedures to support Traffic Engineering (TE) across TRILL sites where such sites are interconnected using [1] with the help of a Layer 3 core running IP+GRE or IP+MPLS. Traffic Engineering permits usage of a set of links that possess a certain characteristic like specified bandwidth, cost or even MTU. This draft aims at addressing how unicast frames travelling from one TRILL site to another across a Layer 3 core that supports IP+GRE and/or IP+MPLS can make use of the TE calculated paths in the sending site as well as the receiving site where such TE paths are pre-computed in both sites and need a mechanism to inter- link them together. "LISP-DDT Referral Internet Groper (RIG)", Dino Farinacci, Amit Jain, Isidor Kouvelas, Darrel Lewis, 25-Mar-12, A simple tool called the LISP-DDT Referral Internet Groper or 'rig' can be used to query the LISP-DDT hierarchy. This draft describes how the 'rig' tool works. "LISP Traffic Engineering Use-Cases", Dino Farinacci, Parantap Lahiri, Michael Kowal, 25-Mar-12, This document describes how LISP re-encapsulating 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, 25-Mar-12, This document describes an end-to-end Session Identifier for use in IP-based Multimedia Communication systems that enables endpoints, intermediate devices, and management systems to identify a session end-to-end, associate multiple endpoints with a given multipoint conference, track communication sessions when they are redirected, and associate one or more media flows with a given communication session. "Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks", Paul Jones, Gonzalo Salgueiro, James Polk, Parthasarathi Ravindran, Laura Liess, Roland Jesske, Salvatore Loreto, Hadriel Kaplan, 25-Mar-12, This document specifies the requirements for an end-to-end session identifier in IP-based multimedia communication networks. This identifier would enable endpoints, intermediate devices, and management and monitoring systems to identify a session end-to-end, associate multiple endpoints with a given multipoint conference, track communication sessions when they are redirected, and associate one or more media flows with a given communication session. "Securing Model-C Inter-Provider VPNs with Label Hopping and TicToc", Shankar Raman, Balaji Venkat, Gaurav Raina, 25-Mar-12, 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 for calculating when it must have left the that peer at the Provider Edge Router at the near end / receiving end. "PIM ECMP Redirect based on Linecard Replication Capacity and Power", Shankar Raman, Balaji Venkat, Gaurav Raina, 25-Mar-12, This work derives itself from [1] which proposes a ECMP redirect from a PIM upstream neighbor that instructs or advices the PIM downstream neighbor to choose another of its own ECMP links between the former and the latter. What we propose in this document is a criterion based on power consumed in the linecards that comprise the ECMP links between the former and the latter. Also the multicast replication capacity available within the said linecards which form the ECMP links between the two is taken into consideration while making a ECMP redirect. A PIM router uses RPF procedure to select an upstream interface and router to build forwarding state. When there are equal cost multiple paths (ECMP), existing implementations often use hash algorithms to select a path. Such algorithms do not allow the spread of traffic among the ECMPs according to administrative metrics. This usually leads to inefficient or ineffective use of network resources. This document introduces the ECMP Redirect, a mechanism to improve the RPF procedure over ECMPs. It allows ECMP path selection to be based on administratively selected metrics, such as data transmission delays, path preferences and routing metrics. "Power Based Topologies and TE-Shortest Power Paths in OSPF", Shankar Raman, Balaji Venkat, Gaurav Raina, Vasan Srini, 14-Apr-12, 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. "A Robust Solution for PMIPv6-based Distributed Mobility Management", Hong-Ke Zhang, 25-Mar-12, Proxy Mobile IPv6 (PMIPv6) is a network-based centralized mobility management protocol, which has many disadvantages for utilizing the centralized anchor LMA. As networks are moving towards flat architectures, a distributed approach is needed to PMIPv6. This document defines a robust solution for PMIPv6-based distributed mobility management which ensures the robustness by organizing the distributed anchors (MAARs) into a Chord ring. "TCP option space extension", Anantha Ramaiah, 26-Mar-12, The document goals are as follows: Firstly, this document summarizes the motivations for extending TCP option space. Secondly, It tries to summarize the various known issues that needs to be taken into account while extending the TCP option space. Thirdly, it briefly provides a short summary of the various TCP option space proposals that has been proposed so far. Some additional proposals which includes variations to the existing proposals are also presented. The goal of this document is to rejuvenate the discussions on this topic and eventually to converge on a scheme for extending TCP option space. "VM to VTEP maps topology discovery in VXLAN based data centers", Balaji Venkataswami, Bhargav Bhikkaji, 26-Mar-12, This document proposes a method by which in a VXLAN environment the ARP tables of each VTEP having an active VM belonging to a particular tenant where such active VMs are distributed amongst several VTEPs in a data center or across data centers are walked through and the collation of the location of such active VMs and the VTEPs they are located in is found for management and network resource planning purposes. "Learning CoAP separate responses by examples", Angelo Castellani, 26-Mar-12, This draft aims at providing interesting examples of CoAP separate responses that are useful to aid CoAP implementers on understanding possible rare situation incurring. "Digital Forensics Extension for IODEF", Christopher Inacio, 26-Mar-12, This extension to IODEF (RFC 5070) is designed to aid in the sharing and dissemination of digital forensics information. The goal is to allow a tool independent format to share information between organizations focused on digital forensics: drive images, file carving, metadata, and related hashes. As with IODEF and its extensions, it is defined using XML. "Definition and Use of DNSSEC Negative Trust Anchors", Jason Livingood, Chris Griffiths, 27-Mar-12, 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. "VPLS with Point-To-Multipoint LSPs Management Information Base", Pradeep Jain, Kanwar Singh, Ranganathan Boovaraghavan, 26-Mar-12, This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor multicast in VPLS using Point-to-Multipoint LSPs or VPLS- MCAST [I-D.ietf-l2vpn-vpls-mcast]. "HTTP Speed+Mobility", Rob Trace, Adalberto Foresti, Sandeep Singhal, Osama Mazahir, Henrik Nielsen, Brian Raymor, Ravi Rao, Gabriel Montenegro, 28-Mar-12, The design of HTTP--how every application and service on the web communicates today--can positively impact user experience, operational and environmental costs, and even the battery life of the devices you carry around. Improving HTTP starts with speed. Apps--not just browsers--should get faster too. More and more, apps are how people access web services, in addition to their browser. Improving HTTP should also make mobile better, particularly to ensure great battery life and low network cost on constrained devices. People and their apps should stay in control of network access. Finally, to achieve rapid adoption, HTTP 2.0 needs to retain as much compatibility as possible with the existing Web infrastructure. Done right, HTTP 2.0 can help people connect their devices and applications to the Internet fast, reliably, and securely over a number of diverse networks, with great battery life and low cost. This document describes "HTTP Speed+Mobility," a proposal for HTTP 2.0 that emphasizes performance improvements and security while at the same time accounting for the important needs of mobile devices and applications. The proposal starts from both the Google SPDY protocol and the work the IETF has done around WebSockets. The proposal is not a final product but rather is intended to form a baseline for working group discussion. "Measurement for P2P system", Jin Peng, Lifeng Le, Shihui Duan, 26-Mar-12, This document introduces general measurement research for p2p systems. In this document, it first gives the objects for measurement in p2p network, gives the methodology for p2p measurement and then describes the material measurement indexed for p2p network. "Multi Topology Encoding within TRILL data frames", Tissa Senevirathne, Ayan Banerjee, Les Ginsberg, Sam Aldrin, 26-Mar-12, Two alternative methods of encoding Multi Topology Identifier within the TRILL data frames are presented. Methods proposed herein do not require overloading TRILL RBridge nickname to encode Multi Topology Identifier. "The Last Mile Cache", Fredrik Danerklint, 26-Mar-12, The Last Mile Cache is a solution of how to cache content closer to the end user. "The 'profile' Link Relation Type", Erik Wilde, 15-Apr-12, This specification defines the 'profile' link relation type that allows resource representations to indicate that they are following one or more profiles. A profile is defined to not alter the semantics of the resource representation itself, but to allow clients to learn about additional semantics (constraints, conventions, extensions) that are associated with the resource representation, in addition to those defined by the media type and possibly other mechanisms. "Credential Protection Ciphersuites for Transport Layer Security (TLS)", Mohamad Badra, Ibrahim Hajjeh, 27-Mar-12, This document defines a set of cipher suites to add client credential protection to the Transport Layer Security (TLS) protocol. By negotiating one of those ciphersuites, the TLS clients will be able to determine for themselves when, how, to what extent and for what purpose information about them is communicated to others. The ciphersuites defined in this document can be used only when public key certificates are used in the client authentication process. "Relaxing RSVP Loop Checking", Steve Balls, Jonathan Hardwick, Cyril Margaria, 23-May-12, This specification relaxes the rules governing loop checking within RSVP. These were originally defined in [RFC3209] and are too strict for the requirements of today's data planes. "Title", Ray Bellis, 27-Mar-12, This document specifies a method for a DNS client to request additional DNS record types to be delivered alongside the primary record type specified in the question section of a DNS query. "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", Gert Grammel, John Drake, Gabriele Galimberti, Ruediger Kunze, 27-Mar-12, 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].[ITU.G698.2] "SCIM Targeted Resource Extension", Phil Hunt, 27-Mar-12, The core SCIM 1.0 specification is intended to provide updates to a single cloud-based application. This extension specifies an extended API definition which allows a single SCIM endpoint to support updates to multiple cloud-based applications. These extensions enable network relationships such as proxy updates, and hub-to-hub-to-spoke relationships in addition to the hub-spoke relationship defined in the core SCIM 1.0 specification. "A Guide to the HTTP/1.1 Document Series", Murray Kucherawy, 27-Mar-12, This document introduces a series of documents that comprise the definition of HTTP/1.1, providing a short summary of the content of each of those. "CoAP Streaming", Salvatore Loreto, Oscar Novo, 27-Mar-12, This specification defines a simple mechanism for streaming media data from a server to a client in a constrained network over CoAP. The mechanism take advantage of the observer design pattern described in CoAP, extending it, to support streaming media transfer between nodes. Note Discussion and suggestions for improvement are requested, and should be sent to core@ietf.org. "Using Datagram Transport Layer Security (DTLS) For Interactivity Connectivity Establishment (ICE) Connectivity Checking: ICE-DTLS", Martin Thomson, 27-Mar-12, Interactivity Connectivity Establishment (ICE) connectivity checking using the Datagram Transport Layer Security (DTLS) handshake is described. The DTLS handshake provides sufficient information to identify valid candidates and establish consent. "CoRE Roadmap and Implementation Guide", Carsten Bormann, 5-Apr-12, 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. The current version -00 of this document is an early draft that is intended to spark the further collection of relevant information. "The IMAP Move Extension", Arnt Gulbrandsen, 29-Mar-12, The MOVE extension provides a new command, UID MOVE, which moves one or more messages from the selected mailbox to a named mailbox. "Reducing Power Consumption using BGP path selection", Shankar Raman, Balaji Venkat, Gaurav Raina, Vasan Srini, 2-May-12, In this paper, we propose a framework to reduce the aggregate power consumption of the Internet using a collaborative approach between Autonomous Systems (AS). We identify the low-power paths among the AS and then use 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. "Proposal for a Network-Friendly HTTP Upgrade", Willy Tarreau, Amos Jeffries, Andrien de Croy, 28-Mar-12, This document proposes an upgrade to HTTP messaging which aims at being faster, more robust and more friendly to mobile networks than the current version, while retaining the same semantics and offering a high enough compatibility level to make it possible to implement highly efficient gateways between existing implementations and this presently described version, thus offering a smooth upgrade path for legacy applications. "Issues with multiple stateful DHCPv6 options", Ole Troan, Bernie Volz, 28-Mar-12, [RFC3315] was not written with the expectation that other stateful DHCPv6 options would be developed. [RFC3633] shoe-horned the new options for Prefix Delegation options for DHCPv6 into DHCPv6. Implementation experience of the CPE model described in [RFC6204] has shown multiple issues with the DHCPv6 protocol in supporting multiple stateful options. "CoAP Alive Message", Angelo Castellani, Salvatore Loreto, 29-Mar-12, In the context of a Constrained RESTful Environment (CoRE), hosts could frequently be energy-constrained and be turned off the vast majority of time for energy-saving purposes. In the case of a CoAP server, while it is offline, it is neither available to serve requests. Clients desiring to access its resources have no way to understand when they will find it up again. This specification provides a simple new message that gives to a CoAP server the ability to signal its current availability in the network. "Design Considerations for an IPv6 CE Router", Chris Donley, 29-Mar-12, This document describes design considerations for IPv6 CE routers. "Processing of TCP segments with Mirrored End-points", Fernando Gont, 29-Mar-12, This document describes a problem found in some popular implementations regarding the processing of TCP segments in which the local endpoint is equal to the remote endpoint. Additionally, it formally updates RFC 793 clarifying how this scenario should be handled. "Processing of IP Security/Compartment and Precedence Information by TCP", Fernando Gont, 29-Mar-12, This document discusses the security and interoperability problems that may arise as a result of the processing of IP security/ compartment and precedence information by TCP. Additionally, it formally updates RFC 793 such that these issues are mitigated. "LLN Fragment Forwarding and Recovery", Pascal Thubert, Jonathan Hui, 29-Mar-12, 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. "FTP TYPE Extension for Internationalized Text", John Klensin, 30-Mar-12, The traditional FTP protocol includes a TYPE command to specify the data representation. That command has values for ASCII and EBCDIC text, plus binary ("IMAGE") transmission. As the Internet becomes more international, there is a growing requirement to be able to transmit textual data, encoded in Unicode, in a way that is independent of the coding and line representation forms of particular operating systems. This memo specifies a new FTP representation TYPE value for Unicode data. "The application/merge-patch Media Type", James Snell, 30-Mar-12, This specification defines the application/merge-patch media type and it's intended use with the HTTP PATCH method defined by RFC 5789; as well as the "application/json+merge-patch" variation that defines the "Merge Patch" semantics for JSON documents. "Fundamental Architecture of Services Provider's network Transitioning to IPv6 (FAST6)", GuoLiang Yang, Yangchun Li, Cancan Huang, 30-Mar-12, 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 solve 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-12, A protocol for the fair selection and random distribution of a single winner in a game with an arbitrary number of players is described. "Multiple Path IP Security", Xiangyang Zhang, 1-Apr-12, This document presents one approach to enhance data protection when transmitting IPsec datagrams across the insecure networks. The method affords the stronger protection to the traffic by splitting it among a set of sub-tunnels. All the Security Associations (SAs) are set up independently for all sub-tunnels. Both the sending and receiving entity combine all the sub-tunnels to one clustered tunnel. As different sub-tunnel uses different crypto key materials and processing parameters, it may achieve the stronger protection of the traffic across the insecure networks. In addition, it could possibly bring more benefits in terms of the network control. "Standardized interval support in BFD", Nobo Akiya, Marc Binderberger, 25-Apr-12, This document defines a set of interval values that we call "Standard intervals". Values of this set must be supported for transmitting BFD control packets and for calculating the detection time in the receive direction when the value is equal or larger than the fastest, i.e. lowest, interval a particular BFD implementation supports. This solves the problem of finding an interval value that both BFD speakers can support while allowing a simplified implementation as seen for hardware-based BFD. "Modeling JSON Text with YANG", Ladislav Lhotka, 2-Apr-12, This document defines rules for mapping data models expressed in YANG to JSON text. It does so by specifying a procedure for translating the subset of YANG-compatible XML documents to JSON text, and vice versa. "Mail Accepted by Previous Sending", Hubert Ryckelynck, 14-May-12, Mail Accepted by Previous Sending defines a mechanism by which incoming unsollicited mails may be rejected or penalized by a MTA if their sender address domains has never been a destination for the outgoing mails treated by this MTA. "Definition of Managed Objects for the Manet Essential Connected Dominating Set (E-CDS) Process", James Nguyen, Robert Cole, 3-Apr-12, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring 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. "The 'describes' Link Relation Type", Erik Wilde, 3-Apr-12, This specification defines the 'describes' link relation type that allows resource representations to indicate that they are describing another resource. In contexts where applications want to associate described resources and description resources, and want to build services based on these associations, the 'describes' link relation type provides the opposite direction of the 'describedby' link relation type, which already is a registered link relation type. "LDP Adjacency Capabilities", Pranjal Dutta, Mustapha Aissaoui, 5-Apr-12, This document defines method for negotiation of a set of capabilities specific to a Label Distribution Protocol (LDP) Hello Adjacency. The document uses the TLVs for the LDP Capabilities defined in [RFC5561] to be used for exchanging capabilities over LDP Hello Adjacencies. The Hello Adjacency capabilities can be thought of as "Traffic Forwarding Capabilities" (TFC). Some capabilties already exist that can be re-used for hello adjacency specific capabilities and it is likely that some may be defined in future. This document defines the mechanism to advertise LDP TFCs for a hello adjacency as well as mechanism to enable and disable TFCs after a hello adjacency is formed between LDP peers. "LDP Version 2", Pranjal Dutta, Mustapha Aissaoui, 5-Apr-12, The Label Distribution Protocol (LDP) is a protocol defined for distributing labels for Multi-Protocol Label Switching (MPLS) and its procedures are defined in [RFC5036] . LDP has been one of the most deployed MPLS signaling protocols. [RFC5036] defines LDP version 1 and this document introduces LDP version 2 to full-fill various operational needs when LDP is deployed for IPV6 networks. LDP version 1 procedures can support IPV6 Label Switch Path (LSP) setup and this document enhances those procedures in Version 2. "Multiple LDP Instances", Pranjal Dutta, Mustapha Aissaoui, 5-Apr-12, This document defines an extension to Label Distribution Protocol (LDP) [RFC5036] for implementation of multiple LDP instances in a network node, where all such instances share the common data plane. Multiple LDP instances provide a method for operators for fate separation of various LDP FEC Types as well as for network segmentation. The methods defined in this extension are backward compatible with procedures defined in [RFC5036] "File Transfer Protocol HASH Command for Cryptographic Hashes", Anthony Bryan, Tim Kosse, Daniel Stenberg, 6-Apr-12, 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. "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for DHCPv4 over IPv6 Transport", Tomasz Mrugalski, Peng Wu, 6-Apr-12, [I-D.ietf-dhc-dhcpv4-over-ipv6] defines a way for communication between legacy DHCPv4 clients with DHCPv4 servers over IPv6-only transport. It requires the deployment of Client Relay Agent (CRA) that transmits messages to IPv6-Transport Server (TSV) or IPv6- Transport Relay Agent (TRA). The deployed CRA must know the address of a TSV or TRA to forward incoming client's messages. This document defines an DHCPv6 option that may be used to provision the TSV or TRA location to CRAs. "Multipart Media Type Encoding for CoAP", Thomas Fossati, 8-Apr-12, This memo defines a new media type encoding that can be used to combine several different media types into a single CoAP message- body. "Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines", Stephen Trowbridge, Eliot Lear, Scott Bradner, 19-Apr-12, This document provides guidance to aid in the understanding of collaboration on standards development between the International Telecommunication Union -- Telecommunication Standardization Sector (ITU-T) and the Internet Society (ISOC) -- Internet Engineering Task Force (IETF). It is an update of and obsoletes RFC 3356. The updates reflect changes in the IETF and ITU-T since RFC 3356 was written. The bulk of this document is common text with ITU-T Supplement 3 to the ITU-T A-Series Recommendations. Note: This was approved by ITU-T TSAG on xx July 2012 as a Supplement to the ITU-T A-Series of Recommendations (will be numbered as A-Series Supplement 3). "Session Initiation Protocol (SIP) Extension for logging and debugging", Adarsh Kaithal, 8-Apr-12, The current mechanisms to debug issues in SIP network are not very efficient. It requires to enable debugging logs across different devices, recreate the problem and then collect the logs. The idea is to provide a solution to automatically enable relevant logs (SIP messages and any other debugging logs meaningful to SIP devices), and also to indicate where the logs are to be collected or stored. The enabling of logs will happen at all the SIP devices(upstream or downstream). This will help to get the logs from all the SIP devices in a Common logging format (CLF). The solution extends SIP to provide the infrastructure to enable logging for upstream and downstream devices with each server deciding how much troubleshooting information it wants to log - with freedom to simply ignore requests if required. This document specifies a new header called "Log-Me" Header in all the SIP messages. "Use Cases and Requirements for JSON Object Signing and Encryption (JOSE)", Richard Barnes, 9-Apr-12, 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. "vCard representation of resources for calendaring and scheduling services", Ciny Joy, Cyrus Daboo, Mike Douglass, 9-Apr-12, This specification describes the vCard representation of resources for calendaring and scheduling. A resource in the scheduling context is any shared entity that can be scheduled by a calendar user, but does not control its own attendance status. "Signal 3D format", Bert Greevenbosch, Hui Yu, 9-Apr-12, This document introduces the SDP attribute "3dFormat", which provides format description of stereoscopic 3D video. In addition, the grouping mechanism for SDP is extended to cater for stereoscopic 3D video. Note Discussion and suggestions for improvement are requested, and should be sent to mmusic@ietf.org. "SDP attribute to signal parallax", Bert Greevenbosch, Hui Yu, 9-Apr-12, This document introduces a "ParallaxInfo" attribute in SDP. This attribute can be used in stereoscopic applications, to signal the depth positioning of 2D media data within the 3D space. Note Discussion and suggestions for improvement are requested, and should be sent to mmusic@ietf.org. "A Uniform Resource Name (URN) Namespace for Eurosystem Messaging", Miriam Ortseifen, Gunnar Dickfeld, 10-Apr-12, This document describes a Uniform Resource Name (URN) namespace that is ma- naged by Deutsche Bundesbank (member of ESCB) for usage within messages standardized by the Eurosystem. "A Commentary on 4rd-U Architecture and Semantics", Maoke Chen, 10-Apr-12, 4rd-U is proposed as an effort of unifying encapsulation and double translation solutions for the softwire of IPv4 over IPv6 domain. This attempt introduces new behaviors in the Internet transition architecture as well as semantics other than that of well-known Internet protocols. This documents provides a commentary on the semantic changes and their impacts. "The Create-Form and Edit-Form Link Relations", Ioseb Dzmanashvili, 16-May-12, RFC 5988 [RFC5988] defined the way of indicating resources on the Web. This specification defines link relation types which may be used to express the relationships between a resource and an input form for constructing data submissions. 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 ). "Additional Definitions of Managed Objects for Network Address Translators (NAT)", Simon Perreault, Tina Tsou, Senthil Sivakumar, 11-Apr-12, 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. "Semantic Content Packages (SCP)", Chris Wilper, 13-Apr-12, This document specifies Semantic Content Packages, an experimental data structure and associated format for storing and transmitting a named set of RDF statements with a set of content streams. Packages can be arranged as a set of files in a directory hierarchy or serialized into a single stream for transmission and archival storage. For the latter, a new ZIP-based media type, application/scp, is defined. "Hitchhiker's guide to the Session Description Protocol (SDP)", Bert Greevenbosch, 15-Apr-12, The Session Initiation Protocol (SDP) is the subject of numerous specifications that have been produced by the IETF. It can be difficult to locate the right document, or even to determine the set of Request for Comments (RFC) about SDP. This specification serves as a guide to the SDP RFC series. It lists a current snapshot of the specifications under the SDP umbrella, briefly summarises each, and groups them into categories. Note Discussion and suggestions for improvement are requested, and should be sent to mmusic@ietf.org. "LSP Attribute in ERO", Cyril Margaria, Dirk Schroetter, Giovanni Martinelli, 18-Apr-12, LSP attributes can be specified or recorded for whole path, but they cannot be specified as part of an Explicit Route Object (ERO). This document extend the semantic for RSVP ERO object with a new subobject to carry LSP attributes. "Host Scanning in IPv6 Networks", Fernando Gont, 19-Apr-12, IPv6 offers a much larger address space than that of its IPv4 counterpart. The standard /64 IPv6 subnets can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than their IPv4 counterparts. As a result, it is widely assumed that it would take a tremendous effort to perform host scanning attacks against IPv6 networks, and therefore IPv6 host scanning attacks have long been considered unfeasible. This document analyzes the IPv6 address configuration policies implemented in most popular IPv6 stacks, and identifies a number of patterns in the resulting addresses lead to a tremendous reduction in the host address search space, thus dismantling the myth that IPv6 host scanning attacks are unfeasible. "Grazed and Lightweight Open Protocol (GaLOP), v. 1.0", Lukasz Ruminski, Michal Kutzner, Adrian Dymek, Szymon Kwiatkowski, Marcin Langa, 30-Apr-12, 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. "Requirements for Operations, Administration and Maintenance (OAM) in TRILL", Tissa Senevirathne, David Bond, Sam Aldrin, Li Yizhou, Rohit Watve, Anoop Ghanwani, Naveen Nimmu, Radia Perlman, Tal Mizrahi, 4-May-12, OAM (Operations, Administration and Maintenance) is a general term used to identify functions and toolsets to troubleshoot and monitor networks. This document presents, OAM Requirements applicable to TRILL. Also presented in this document is the proposed frame structure for TRILL OAM messages. "Data Transmission Over Out-of-Band Alternative Tranports for AFS-3", Andrew Deason, 20-Apr-12, This document describes an extension to AFS-3 which allows data transfer over arbitrary alternative transports to the traditional Rx RPC over UDP, and describes a method of using TCP as one such alternative transport. This document describes new wire structures and Rx RPCs for the 'afsint' protocol in AFS-3. Internet Draft Comments Comments regarding this draft are solicited. Please include the AFS-3 protocol standardization mailing list (afs3-standardization@openafs.org) as a recipient of any comments. "Transmission Scheduling of IPv6 Packets over IEEE 802.15.4 Networks-- - Extension for Industrial Application Space", Heng Wang, Ping Wang, Chao Zhou, 20-Apr-12, These years, wireless technologies, including the application of 6LoWPAN protocol, are more and more been applied in industrial environment to improve productivity and safety of the plants. In spite of the fact that [RFC4944] has introduced the methods of transmitting IPv6 packets over IEEE 802.15.4 networks, industrial automation field, either process automation or factory automation, has its special characteristics and requirements. If 6LoWPAN is been used in industrial environment, some change SHOULD be made in the adaption layer. This document defines a Scheduling Header, to make the adaption layer meet the requirements of industrial scheduling for transmission of IPv6 packets over IEEE 802.15.4 networks. Additionally, this document also provides an application example of Scheduling Header. "BGP Extensions for Multicast VPN Fast Upstream Failover", Pradeep Jain, Kanwar Singh, Jayant Kotalwar, Nehal Bhau, Clayton Hassen, 21-Apr-12, This document defines BGP extensions and procedures that allows use of BFD for Multi Point Networks for fast detection and failover for upstream faults in Multicast VPNs. The upstream failures addressed in this proposal can be failure of any node between the Root PE and Leaf PE or failure between the Multicast Source and Root PE. "Re-ECN: A Framework for adding Congestion Accountability to TCP/IP", Bob Briscoe, Arnaud Jacquet, Toby Moncaster, Alan Smith, 22-Apr-12, This document describes a framework for using a new protocol called re-ECN (re-inserted explicit congestion notification), which can be deployed incrementally around unmodified routers. Re-ECN allows accurate congestion monitoring throughout the network thus enabling the upstream party at any trust boundary in the internetwork to be held responsible for the congestion they cause, or allow to be caused. So, networks can introduce straightforward accountability for congestion and policing mechanisms for incoming traffic from end- customers or from neighbouring network domains. As well as giving the motivation for re-ECN this document also gives examples of mechanisms that can use the protocol to ensure data sources respond correctly to congestion. And it describes example mechanisms that ensure the dominant selfish strategy of both network domains and end- points will be to use the protocol honestly. Note concerning Intended Status: If this draft were ever published as an RFC it would probably have historic status. There is limited space in the IP header, so re-ECN had to compromise by requiring the receiver to be ECN-enabled otherwise the sender could not use re-ECN. Re-ECN was a precursor to chartering of the IETF's Congestion Exposure (ConEx) working group, but during chartering there were still too few ECN receivers enabled, therefore it was decided to pursue other compromises in order to fit a similar capability into the IP header. "Re-ECN: Adding Accountability for Causing Congestion to TCP/IP", Bob Briscoe, Arnaud Jacquet, Toby Moncaster, Alan Smith, 22-Apr-12, This document introduces re-ECN (re-inserted explicit congestion notification), which is intended to make a simple but far-reaching change to the Internet architecture. The sender uses the IP header to reveal the congestion that it expects on the end-to-end path. The protocol works by arranging an extended ECN field in each packet so that, as it crosses any interface in an internetwork, it will carry a truthful prediction of congestion on the remainder of its path. It can be deployed incrementally around unmodified routers. The purpose of this document is to specify the re-ECN protocol at the IP layer and to give guidelines on any consequent changes required to transport protocols. It includes the changes required to TCP both as an example and as a specification. It briefly gives examples of mechanisms that can use the protocol to ensure data sources respond sufficiently to congestion, but these are described more fully in a companion document. Note concerning Intended Status: If this draft were ever published as an RFC it would probably have historic status. There is limited space in the IP header, so re-ECN had to compromise by requiring the receiver to be ECN-enabled otherwise the sender could not use re-ECN. Re-ECN was a precursor to chartering of the IETF's Congestion Exposure (ConEx) working group, but during chartering there were still too few ECN receivers enabled, therefore it was decided to pursue other compromises in order to fit a similar capability into the IP header. "AFS-3 Directory Object Type Definition", Thomas Keiser, 23-Apr-12, Directory lookups in the AFS-3 distributed file system are supported by defining a canonical encoding for a directory object, and transmitting all--or part--of that object from a file server to its clients so that clients may resolve paths into AFS file IDs (FIDs). This memo describes the AFS-3 directory object wire encoding. Internet Draft Comments Comments regarding this draft are solicited. Please include the AFS-3 protocol standardization mailing list (afs3-standardization@openafs.org) as a recipient of any comments. "Offer/Answer Considerations for G.723 Annex A and G.729 Annex B", Muthu Perumal, Parthasarathi Ravindran, 23-Apr-12, [RFC4856] describes the annexa parameter for G723 and the annexb parameter for G729, G729D and G729E. However, the specification does not describe the offerer and answerer behavior when the value of the annexa or annexb parameter does not match in the SDP offer and answer. This document provides the offer/answer considerations for these parameters. "RESTful interface for the Extensible Provisioning Protocol", Maarten Wullink, Marco Davids, R. Gieben, 23-Apr-12, This document specifies a 'RESTful interface for EPP' (REPP) with the aim to improve efficiency and interoperability of EPP systems. This document includes a new EPP Protocol Extension as well as a mapping of [RFC5730] XML-commands to an HTTP based (RESTful) interface. Existing semantics and mappings as defined in [RFC5731], [RFC5732] and [RFC5733] are largely retained and reusable in RESTful EPP. With REPP, no session is created on the EPP server. Each request from client to server will contain all of the information necessary to understand the request. The server will close the connection after each HTTP request. "Security Implications of IPv6 on IPv4 Networks", Fernando Gont, 26-Apr-12, This document discusses the security implications of native IPv6 support and IPv6 transition/co-existence technologies on "IPv4-only" networks, and describes possible mitigations for the aforementioned issues. "DNS Server Statistics Management Information Base (MIB)", Simon Perreault, Jacques Latour, Jake Zack, 24-Apr-12, This memo defines a portion of the Management Information Base (MIB) for monitoring statistics of DNS servers. "IPv6 RA Options for Multiple Interface Next Hop Routes", Behcet Sarikaya, 24-Apr-12, 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, 25-Apr-12, IPv6 defines a minimum MTU of 1280 bytes. Many link layers are more limited in their choice of packet size. Typically, IP adaptation layers for these link layers define a segmentation or fragmentation scheme to transport larger IP packets in multiple link layer packets. Often, adaption layer fragmentation schemes reduce some performance metric, such as the packet delivery rate. Where application or transport protocols have a choice, 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 later fragmentation schemes are often designed to be "transparent", i.e. there is no way at higher layers to find out 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, as well as an indication of preferred packet sizes. 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. "Obsoleting the Endpoint Identifier (EID) Option", Fernando Gont, 26-Apr-12, This document formally obsoletes the IPv6 Endpoint Identification (EID) option (hex value 0x8a), thus cleaning up the corresponding IANA registry, and possibly serving as a basis for providing advice about the filtering of packets containing this option. "X.509v3 Extension: OCSP Stapling Required", Phillip Hallam-Baker, 3-May-12, The purpose of the TLS Security Policy extension is to prevent downgrade attacks that are not otherwise prevented by the TLS protocol. In particular, the TLS Security Policy extension may be used to mandate support for revocation checking features in the TLS protocol such as OCSP stapling. "Encapsulating MPLS in UDP", KuiKe Building, Marshall Eubanks, Lucy Yong, 27-Apr-12, This document specifies one additional IP-based encapsulation technology for MPLS packets referred to as MPLS-in-UDP, which is intended to facilitate load-balancing the traffic of various MPLS applications such as MPLS-based L2VPN and L3VPN in the core of IP- enabled packet switch networks. "Dynamic Host Configuration Protocol (DHCP) Options for Port Set Assignment", Peng Wu, Yiu Lee, Qiong Sun, Ted Lemon, 28-Apr-12, Due to the exhaustion of global IPv4 address space, there are demands arising for IPv4 address sharing between end users. In such context, different users can employ the same address, but different ports. This document defines two DHCP options for assigning a set of ports to a device. One is used for allocating continuous port set, while the other is designed for non-continuous port set allocation. "RTCWEB Resolution Negotiation", Harald Alvestrand, 30-Apr-12, This draft offers a proposal for a fragment of the SDP usage rules for RTCWEB: Requirements for supporting resolution negotiation. It proposes to use SDP both for initial and within-call resolution configuration, and suggests that COP should be mentioned as an optional, not mandatory, mechanism. "3D Video in the Session Description Protocol (SDP)", Pedro Capelastegui, 30-Apr-12, This document defines a mechanism to describe 3D video streams in the Session Description Protocol (SDP). This includes 3D video streams composed of multiple video views, or of a combination of views and depth maps. Several 3D video formats are supported, including simulcast, video-plus-depth, and frame-packing. A new decoding dependency, "3dd", is defined, describing the association between media stream belonging to a 3D video stream. In addition, a new SDP media-level attribute, "3dvFormat", is defined, describing the format used by media streams within a 3D video stream. "OCSP Digest Extension", Phillip Hallam-Baker, Rob Stradling, 3-May-12, The OCSP digest extension creates a strong cryptographic binding between an OCSP token and the certificate it asserts a status value for. Support for the digest identifier extension permits a certificate issuer to employ a high assurance cryptographic digest function such as SHA2 to attest to the authenticity of their certificates in a fashion that is fully downwards compatible with legacy clients that only support SHA1. "Transport Layer Security (TLS) Encrypted Handshake Extension", Marsh Ray, 3-May-12, This specification defines a Transport Layer Security (TLS) extension which allows endpoints to negotiate the use of encryption with forward secrecy at the beginning of the handshake. Two levels of functionality are defined. Implementations are free to support one or both levels, with the first level incurring no additional computational or round-trip overhead. The TLS cryptographic calculations are unchanged. "PMIPv6 Operation on Shared Links", Behcet Sarikaya, 3-May-12, This document describes Proxy Mobile IPv6 (PMIPv6) operation on shared links such as IEEE 802.11. Two solutions of providing point- to-point link operation on the shared links are compared. Advantages and disadvantages of each solution are identified. "Behavior of BitTorrent service in PCP-enabled networks with Address Sharing", Mohamed Boucadair, Tao Zheng, Xiaohong Deng, Jaqueline Queiroz, 4-May-12, This document describes the behavior of BitTorrent service in the context of PCP-enabled address sharing functions. It provides an overview of the used testbed and main results of the tests that have been conducted in order to assess the limitations of an architecture based on shared IP addresses. "Extension to the Path Computation Element Communication Protocol for Enhanced Errors and Notifications", Helia Poullyau, Remi Theillaud, 4-May-12, This document defines new error and notification TLVs for the PCE Communication Protocol (PCEP) [RFC5440]. It identifies the possible PCEP behaviors in case of error or notification. Thus, this draft extends error and notification types in order to associate predefined PCEP behaviors. "Asserting Administrative Boundaries of Origin Using DNS Zones", Andrew Sullivan, 4-May-12, Some clients on the Internet make inferences about the administrative relationships among servers on the Internet based on the domain names of those servers. Examples include decisions about acceptance of cookies and about cross-document information sharing in ECMAScript DOM. Perhaps unfortunately, real administrative boundaries in the DNS are not possible to detect, and therefore these inferences can go wrong in several ways. Mitigation strategies deployed so far will not scale. The solution to this is to provide a way to make an explicit assertion about the relationships between different domain names. "Use of the IPv6 Flow Label within an LLN", Pascal Thubert, 9-May-12, This document present how the Flow Label can be used inside a LLN as a replacement to the RPL option and provides rules for the root to set and reset the Flow Label when forwarding between the inside of RPL domain and the larger Internet, in both direction. This new operation aims at saving an IPv6 in IPv6 encapsulation within the RPL domain that is required with the RPL option for all packets that reach outside of the RPL domain. "Edge multicast replication for BGP IP VPNs.", Pedro Marques, Luyuan Fang, Derick Winkworth, Yiqun Cai, 7-May-12, In data-center networks it is common to use Clos network topologies [clos] in order to provide a non-blocking switched network. In these topologies it is often not desirable to provide native IP multicast service. This document defines a multicast replication algorithm along with its control and data forwarding procedures that provides a multicast service for a BGP IP VPN network without assuming that the underlying infrastructure supports IP multicast. "Alternate Tunnel Source Address for LMA and Home Agent", Charles Perkins, 7-May-12, Widely deployed mobility management systems for wireless communications have isolated the path for forwarding data from the control plane signaling for mobility management. To realize this requirement with Mobile IP requires that the control functions of the home agent be addressable at a different IP address than the source IP address of the tunnel between the home agent and mobile node. Similar considerations hold for mobility anchors implementing Hierarchical Mobile IP or PMIP. "Using the IPv6 Flow Label for Server Load Balancing", Brian Carpenter, Sheng Jiang, Willy Tarreau, 8-May-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. "RTP and Leap Seconds", Kevin Gross, Ray van Brandenburg, 23-May-12, This document discusses issues that arise when RTP sessions span (UTC) leap seconds. It updates RFC 3550 to describe how RTP senders and receivers should behave in the presence of leap seconds. "Requirements for OAM tools that enable flow Analysis", Janardhanan Pathangi, Balaji Venkataswami, Richard Groves, Peter Hoose, 8-May-12, This document specifies Operations and Management (OAM) requirements that improve on the traditional OAM tools like Ping and Traceroute. These requirements have arisen from the fact that more details than given by Ping and Traceroute are required while troubleshooting or doing performance and network planning. These requirements have been gathered from network operators especially from data centers where the networks have slightly different characteristics compared to regular campus/carrier networks. "Home Documents for HTTP APIs", Mark Nottingham, 9-May-12, This document proposes a "home document" format for non-browser HTTP clients. "SA46T Address Translator", Naoki Matsuhira, Katsuhiro Horiba, Yukito Ueno, Osamu Nakamura, 10-May-12, This document specifies SA46T Address Translator (SA46T-AT) specification. SA46T-AT enable access to IPv4 only host from IPv6 host. IPv4 host is identified as SA46T global address in IPv6 address space. The address assigned to IPv4 host may be global IPv4 address or private IPv4 address. SA46T-AT does not support access to IPv6 host from IPv4 only host. "Representing phonetics for Japanese names in Atom feeds", Murata Makoto, 17-May-12, This specification introduces an attribute for representing phonetics for Japanese names such as author names and article titles. It is intended to be used together with the Atom Syndication Format [RFC4287] and OPDS(Open Publication Distribution System)[OPDS], which is based on Atom. "Architecture of PSN Independent Overlay Network(PION)", Lizhong Jin, Bhumip Khasnabish, 11-May-12, This draft introduces PSN independent overlay network (PION) architecture for intra- and inter-datacenter (DC) connections. The motivations, protocol layers, applications, and etc, for PION are also discussed. PION provides a virtualized underlying-PSN- independent network in order to maximize the reuse of IETF protocol definitions and implementations. The inter- and intra-DC connection provided by PION could be from endpoint to endpoint, or endpoint to network, or network to network. The packet transport capabilities provided by the overlay network are determined by the capability of the underlying PSN. "BGP Tunnel Address Prefix Attribute and Tunnel Address Prefix Extended Community", KuiKe Building, 11-May-12, This document describes a new BGP attribute referred to as Tunnel Address Prefix Attribute and a new BGP address specific extended community referred to as Tunnel Address Prefix Extended Community, both of which are intended for facilitating the load-balancing of IP/GRE tunneled traffic (e.g., L3VPN-over-GRE traffic) in the core of IP-enabled Packet Switch Networks (PSN). "Proposal for Canonical and Other Formats for RFCs", Paul Hoffman, 17-May-12, This document proposes a modernized text-based canonical format for RFCs that explicitly allows external art as a normative part of the RFC. If the RFC Editor chooses this format, they will also publish non-canonical versions of RFCs in order to accomodate the largest target audience of readers. Having a simple, stable canonical format and a varying number of non-canonical formats that can change over time allows the RFC Editor to add useful formats, particularly in HTML, that can keep up with the needs of all RFC readers. "Bundle Protocol Query Extension Block", Stephen Farrell, Aidan Lynch, Dirk Kutscher, Anders Lindgren, 14-May-12, The Bundle Protocol (BP) provides store-and-forward networking for Delay- and Disruption-Tolerant Networks. This document defines the BP query extension block (BPQ) which allows applications to query the stores of nodes on the path along which a bundle containing a bundle query extension block is routed. "Supercharged Codes", Erik Stauffer, BZ Shen, Soumen Chakraborty, Djordje Tujkovic, Jing Huang, Kamlesh Rath, 15-May-12, 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. "LACNIC's Redirection Service for Number Resource RESTful WHOIS Queries", Carlos Martinez, Arturo Servin, Dario Gomez, Gerardo Rada, 16-May-12, The traditional WHOIS protocol has several important shortcomings, and over the past few years several approaches to a better WHOIS have been discussed and proposed. Among these shortcomings, different registries operate different WHOIS services. For users this implies that several WHOIS queries to different registries may be necessary in order to obtain data for a given resource. This document describes a proof-of-concept redirection service for RESTful WHOIS queries as implemented by LACNIC. This service allows users to query a single WHOIS service and be redirected to the authoritative registry. The main goal of this document is to encourage discussion on the topics of Joint WHOIS services and query redirection in a RESTful WHOIS world. The solution implemented by LACNIC proposed here applies to numbering resources (IPv4, IPv6 and autonomous system numbers). "Preventing cross-protocol attacks in TLS protocol", Nikos Mavrogiannopoulos, 16-May-12, This memo proposes a fix in the TLS ServerKeyExchange message signature, to prevent cross-protocol attacks. "Automated XML Content Data Exchange and Management", David Waltermire, 16-May-12, TBD... "Codec Control for WebRTC", Magnus Westerlund, Bo Burman, 16-May-12, This document proposes how WebRTC should handle media codec control between peers. With media codec control we mean such parameters as video resolution and frame-rate. This includes both initial establishment of capabilities using the SDP based JSEP signalling and during ongoing real-time interactive sessions in response to user and application events. The solution uses SDP for initial boundary establishment that are rarely, if ever changed. During the session the RTCP based Codec Operations Point (COP) signaling solution is used for dynamic control of parameters enabling timely and responsive controls. "DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers", Fernando Gont, 17-May-12, This document specifies a mechanism for protecting hosts connected to a broadcast network against rogue DHCPv6 servers. The aforementioned mechanism is based on DHCPv6 packet-filtering at the layer-2 device on which the packets are received. The aforementioned mechanism has been widely deployed in IPv4 networks ('DHCP snooping'), and hence it is desirable that similar functionality be provided for IPv6 networks. "LACNIC's Redirection Service for Number Resource RESTful WHOIS Queries", Carlos Martinez, Arturo Servin, Dario Gomez, Gerardo Rada, 17-May-12, The traditional WHOIS protocol has several important shortcomings, and over the past few years several approaches to a better WHOIS have been discussed and proposed. Among these shortcomings, different registries operate different WHOIS services. For users this implies that several WHOIS queries to different registries may be necessary in order to obtain data for a given resource. This document describes a proof-of-concept redirection service for RESTful WHOIS queries as implemented by LACNIC. This service allows users to query a single WHOIS service and be redirected to the authoritative registry. The main goal of this document is to encourage discussion on the topics of Joint WHOIS services and query redirection in a RESTful WHOIS world. The solution implemented by LACNIC proposed here applies to numbering resources (IPv4, IPv6 and autonomous system numbers). "Diameter Overload Control Requirements", Eric McMurry, Ben Campbell, 17-May-12, 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 mechanisms provided by Diameter are not sufficient for this purpose. This document describes the limitations of the existing mechanisms, and provides requirements for new overload management mechanisms. "Systematic Rate-independent Reed-Solomon (SR-RS) Erasure Correction Scheme", BZ Shen, Erik Stauffer, Kamlesh Rath, 17-May-12, This document specifies a systematic rate-independent Reed-Solomon (SR-RS) Erasure correction scheme. The two properties, systematic and rate-independent, are fulfilled by Lagrange polynomial interpolation. When the number of output symbols is fixed this scheme essentially generates a Reed-Solomon (RS) code. Therefore, based on the MDS (maximum distance separable) property of RS code, this erasure correction scheme is optimal (ideal). Also in this document, a two-step fast recovering (decoding) algorithm using fast Walsh-Hadamard transform is presented for the proposed erasure correction scheme. This algorithm achieves the time complexity O(n*log2(n)), or linear if penalization implementation, such as multi-core processor, is allowed. "ISATAP Tunnel MTU", Fred Templin, 18-May-12, The ISATAP tunnel MTU is currently recommended to be set to 1480 or less. This is to avoid IPv4 fragmentation within the tunnel, but requires the ISATAP tunnel ingress interface to drop any IPv6 packet larger than 1480 bytes and return an ICMPv6 Packet Too Big (PTB) message. Concerns for operational issues with both IPv4 and IPv6 Path MTU Discovery point to the possibility of MTU-related black holes when a packet is dropped due to an MTU restriction, so dropping packets is considered highly undesirable. Fortunately, the "Internet cell size" is 1500 bytes, i.e., the minimum MTU configured by the vast majority of links in the Internet. This document therefore presents a method to boost the ISATAP MTU to 1500 bytes. "6rd Tunnel MTU", Fred Templin, 18-May-12, The 6rd tunnel MTU is currently recommended to be set to 1480. This is to avoid IPv4 fragmentation within the tunnel, but requires the 6rd tunnel ingress interface to drop any IPv6 packet larger than 1480 bytes and return an ICMPv6 Packet Too Big (PTB) message. Concerns for operational issues with both IPv4 and IPv6 Path MTU Discovery point to the possibility of MTU-related black holes when a packet is dropped due to an MTU restriction, so dropping packets is considered highly undesirable. Fortunately, the "Internet cell size" is 1500 bytes, i.e., the minimum MTU configured by the vast majority of links in the Internet. This document therefore presents a method to boost the 6rd MTU to 1500 bytes. "Recommendations for the use of whitelists for email senders transmitting email over IPv6", Terry Zink, 23-May-12, This document contains a plan for how providers of email services can manage one aspect of the problem of email abuse over IPv6. Spammers can send mail from a very large range of IPv6 addresses, and this will make current antispam blocklisting technology less effective. This is because email receivers will have to maintain excessively large lists of IP blocklists which either consume too many resources, or will become stale and therefore ineffective as spammers quickly discard one IP address and move onto the next one. This document recommends that during the transition of email from IPv4 to IPv6, email receivers implement a whitelisting option where they only allow email from permitted senders over IPv6 and reject email from everyone else sending email over IPv6. "Constructing inter-AS power shortest protection TE-LSPs using BGP", Shankar Raman, Balaji Venkat, Gaurav Raina, Vasan Srini, 20-May-12, 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. "Internet Architecture Design Principles Evolution", Papadimitriou Dimitri, Bernard Sales, Theodore Zahariadis, 20-May-12, The purpose of this draft is to extend RFC 1958 and RFC 3439 analysing the design principles that govern the Internet Architecture, evaluate how then have evolved since they were initially introduced and how we expect to evolve in the near future. We describe a number of design principle, discuss their implications on the Internet architecture, design and engineering. The work has been based on the outcome of the ad-hoc European Commission Future Internet Architecture (FIArch) group. "NVO3 Data Plane Requirements", Nabil Bitar, Marc Lasserre, Florin Balus, 21-May-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. "Network Architecture with Recursive Addressing", Chungnam University, 21-May-12, A network architecture based on recursive addressing is proposed. The Internet is modeled as a network of autonomous sites, each being a collection of nodes. Each site is named by a site address drawn from a global number space while each node is named by a node address drawn from a number space local to each site. Routing among sites depends solely on site addresses while that within each site on node addresses. Flat routing to render inherent mobility as well as mapped routing to additionally cope with table size are proposed. The model can recursively repeat itself both outwards and inwards in the network, enabling its applicability, for example, to inter- planetary as well as body area networks. "Update Notifications for Proxy Mobile IPv6", Suresh Krishnan, Sri Gundavelli, Marco Liebsch, Hidetoshi Yokota, Jouni Korhonen, 21-May-12, Proxy Mobile IPv6 (PMIPv6) is a network based mobility management protocol that enables IP mobility for a host without requiring its participation in any mobility-related signaling. This document proposes a mechanism for the Local Mobility Anchor to asynchronously notify the Mobile Access Gateway about changes related to the mobility session. "Generic Tunnel MTU Determination", Fred Templin, 22-May-12, The IPv6-over-IPv4 tunnel MTU as defined by "Basic Transition Mechanisms for IPv6" is currently recommended to be set to 1480 or less when static MTU determination is used. This is to avoid IPv4 fragmentation within the tunnel, but requires the tunnel ingress to drop any IPv6 packet larger than 1480 bytes and return an ICMPv6 Packet Too Big (PTB) message. Concerns for operational issues with both IPv4 and IPv6 Path MTU Discovery point to the possibility of MTU-related black holes when a packet is dropped due to an MTU restriction. Fortunately, the "Internet cell size" is 1500 bytes, i.e., the minimum MTU configured by the vast majority of links in the Internet. This document therefore presents a method to boost the tunnel MTU to 1500 bytes. "RTP and Leap Seconds", Kevin Gross, Ray van Brandenburg, 23-May-12, This document discusses issues that arise when RTP sessions span (UTC) leap seconds. It updates RFC 3550 to describe how RTP senders and receivers should behave in the presence of leap seconds. "Trust Assertions for Certificate Keys", Moxie Marlinspike, 23-May-12, This document defines TACK, a TLS Extension that enables a TLS server to assert the authenticity of its public key. A TACK contains a "TACK key" which is used to sign the public key from the TLS server's certificate. Hostnames can be "pinned" to a TACK key. TLS connections to a pinned hostname require the server to present a TACK containing the pinned key and a corresponding signature over the TLS server's public key. Web Authorization Protocol (oauth) ---------------------------------- "The OAuth 2.0 Authorization Framework", Eran Hammer-Lahav, David Recordon, Dick Hardt, 1-May-12, The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. "The OAuth 2.0 Authorization Protocol: Bearer Tokens", Michael Jones, Dick Hardt, David Recordon, 23-Apr-12, This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. "SAML 2.0 Bearer Assertion Profiles for OAuth 2.0", Chuck Mortimore, 3-May-12, This specification defines the use of a SAML 2.0 Bearer Assertion as a means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. "HTTP Authentication: MAC Access Authentication", Eran Hammer-Lahav, 8-Feb-12, This document specifies the HTTP MAC access authentication scheme, an HTTP authentication method using a message authentication code (MAC) algorithm to provide cryptographic verification of portions of HTTP requests. The document also defines an OAuth 2.0 binding for use as an access-token type. "OAuth 2.0 Threat Model and Security Considerations", Mark McGloin, Phil Hunt, Torsten Lodderstedt, 19-Feb-12, This document gives security considerations based on a comprehensive threat model for the OAuth 2.0 Protocol. "OAuth 2.0 Assertion Profile", Michael Jones, Brian Campbell, Yaron Goland, 2-May-12, This specification provides a general framework for the use of assertions as client credentials and/or authorization grants with OAuth 2.0. It includes a generic mechanism for transporting assertions during interactions with a token endpoint, as wells as rules for the content and processing of those assertions. The intent is to provide an enhanced security profile by using derived values such as signatures or HMACs, as well as facilitate the use of OAuth 2.0 in client-server integration scenarios where the end-user may not be present. This specification only defines abstract message flow and assertion content. Actual use requires implementation of a companion protocol binding specification. Additional profile documents provide standard representations in formats such as SAML and JWT. "An IETF URN Sub-Namespace for OAuth", Hannes Tschofenig, 3-Jan-12, This document establishes an IETF URN Sub-namespace for use with OAuth related specifications. "OAuth Dynamic Client Registration Protocol", Thomas Hardjono, Maciej Machulak, Eve Maler, Christian Scholz, 23-May-12, This specification proposes an OAuth Dynamic Client Registration protocol. "JSON Web Token (JWT)", Michael Jones, John Bradley, Nat Sakimura, 23-May-12, JSON Web Token (JWT) is a means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is digitally signed or MACed using JSON Web Signature (JWS) and/or encrypted using JSON Web Encryption (JWE). The suggested pronunciation of JWT is the same as the English word "jot". "JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0", Michael Jones, Brian Campbell, Chuck Mortimore, 23-May-12, This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. "OAuth Use Cases", George Fletcher, Torsten Lodderstedt, Zachary Zeltsan, 23-May-12, This document lists the OAuth use cases. The provided list is based on the Internet-Drafts of the OAUTH working group and discussions on the group's mailing list. Operations and Management Area Working Group (opsawg) ----------------------------------------------------- "An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms", Tal Mizrahi, Nurit Sprecher, Elisa Bellagamba, Yaacov Weingarten, 12-Mar-12, Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset that can be used for fault detection and isolation, and for performance measurement. OAM mechanisms have been defined for various layers in the protocol stack, and are used with a variety of protocols. This document presents an overview of the OAM mechanisms that have been defined and are currently being defined by the IETF. "Problem Statement for the Automated Configuration of Large IP Networks", Tina Tsou, Juergen Schoenwaelder, Yang Shi, Tom Taylor, GuoLiang Yang, 12-Mar-12, This memo discusses the steps required to bring a large number of devices into service in IP networks in an automated fashion. The goal of this document is to list known solutions where they exist and to identify gaps that require further specifications. "An Overview of the IETF Network Management Standards", Mehmet Ersue, Benoit Claise, 20-Mar-12, This document gives an overview of the IETF network management standards and summarizes existing and ongoing development of IETF standards-track network management protocols and data models. The document refers to other overview documents, where they exist and classifies the standards for easy orientation. The purpose of this document is on the one hand to help system developers and users to select appropriate standard management protocols and data models to address relevant management needs. On the other hand, the document can be used as an overview and guideline by other Standard Development Organizations or bodies planning to use IETF management technologies and data models. This document does not cover OAM technologies on the data-path, e.g. OAM of tunnels, MPLS-TP OAM, and Pseudowire as well as the corresponding management models. "CGN Deployment with BGP/MPLS IP VPNs", Victor Kuarsingh, John Cianfarani, 14-May-12, This document specifies a framework to integrate a Network Address Translation layer into an operator's network to function as a Carrier Grade NAT (also known as CGN or Large Scale NAT). CGN is a concept also described in [I-D.ietf-behave-lsn-requirements] and describes the model as a dual layer translation model. Although operators may wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near term needs may not be satisfied with an IPv6 deployment alone. This document provides a practical integration model which allows CGN to be integrated into the network meeting the connectivity needs of the customer while being mindful of not disrupting existing services and meeting the technical challenges that CGN brings. The model includes the use of BGP/MPLS IP VPNs defined in [RFC4364] as a tool to achieve this goal. This document does not intend to defend the merits of CGN. Operational Security Capabilities for IP Network Infrastructure (opsec) ----------------------------------------------------------------------- "Security Best Practices Efforts and Documents", Chris Lonvick, David Spak, 18-Apr-12, This document provides a snapshot of the current efforts to define or apply security requirements in various Standards Developing Organizations (SDO). "Recommendations for filtering ICMP messages", Fernando Gont, Guillermo Gont, Carlos Pignataro, 12-Mar-12, This document document provides advice on the filtering of ICMPv4 and ICMPv6 messages. Additionaly, it discusses the operational and interoperability implications of such filtering. Open Shortest Path First IGP (ospf) ----------------------------------- "OSPF Transport Instance Extensions", Acee Lindem, Abhay Roy, Sina Mirtorabi, 4-Apr-12, OSPFv2 and OSPFv3 include a reliable flooding mechanism to disseminate routing topology and Traffic Engineering (TE) information within a routing domain. Given the effectiveness of these mechanisms, it is convenient to envision using the same mechanism for dissemination of other types of information within the domain. However, burdening OSPF with this additional information will impact intra-domain routing convergence and possibly jeopardize the stability of the OSPF routing domain. This document presents mechanism to relegate this ancillary information to a separate OSPF instance and minimize the impact. "Routing for IPv4-embedded IPv6 Packets", Dean Cheng, Mohamed Boucadair, 28-Mar-12, This document describes routing packets destined to IPv4-embedded IPv6 addresses across IPv6 transit core using OSPFv3 with a separate routing table. "Security Extension for OSPFv2 when using Manual Key Management", Manav Bhatia, Sam Hartman, Dacheng Zhang, Acee Lindem, 24-Apr-12, The current OSPFv2 cryptographic authentication mechanism as defined in the OSPF standards is vulnerable to both inter-session and intra- session replay attacks when its uses manual keying. Additionally, the existing cryptographic authentication schemes do not cover the IP header. This omission can be exploited to carry out various types of attacks. This draft proposes changes to the authentication sequence number mechanism that will protect OSPFv2 from both inter-session and intra- session replay attacks when its using manual keys for securing its protocol packets. Additionally, we also describe some changes in the cryptographic hash computation so that we eliminate most attacks that result because OSPFv2 does not protect the IP header. "Hiding Transit-only Networks in OSPF", Yi Yang, Alvaro Retana, Abhay Roy, 1-May-12, A transit-only network is defined as a network connecting routers only. In OSPF, transit-only networks are usually configured with routable IP addresses, which are advertised in Link State Advertisements (LSAs) but not needed for data traffic. In addition, remote attacks can be launched against routers by sending packets to these transit-only networks. This document presents a mechanism to hide transit-only networks to speed up network convergence and minimize remote attack vulnerability. "OSPF Hybrid Broadcast and P2MP Interface Type", Nischal Sheth, Lili Wang, Jeffrey Zhang, 3-May-12, This document describes a mechanism to model a broadcast network as a hybrid of broadcast and point-to-multipoint networks for purposes of OSPF operation. Neighbor discovery and maintenance as well as LSA database synchronization are performed using the broadcast model, but the network is represented using the point-to-multipoint model in the router LSAs of the routers connected to it. This allows an accurate representation of the cost of communication between different routers on the network, while maintaining the network efficiency of broadcast operation. This approach is relatively simple and requires minimal changes to OSPF. This document updates both OSPFv2 [RFC2328] and OSPFv3 [RFC5340]. "OSPF Traffic Engineering (TE) Metric Extensions", Spencer Giacalone, David Ward, John Drake, Alia Atlas, Stefano Previdi, 18-May-12, In certain networks, such as, but not limited to, financial information networks (e.g. stock market data providers), network performance criteria (e.g. latency) are becoming as critical to data path selection as other metrics. This document describes extensions to OSPF TE [RFC3630] such that network performance information can be distributed and collected in a scalable fashion. The information distributed using OSPF TE Express Path can then be used to make path selection decisions based on network performance. Note that this document only covers the mechanisms with which network performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document. Peer-to-Peer Session Initiation Protocol (p2psip) ------------------------------------------------- "REsource LOcation And Discovery (RELOAD) Base Protocol", Cullen Jennings, Bruce Lowekamp, Eric Rescorla, Salman Baset, Henning Schulzrinne, 28-Mar-12, This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the kinds of data that must be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others. "A SIP Usage for RELOAD", Cullen Jennings, Bruce Lowekamp, Eric Rescorla, Salman Baset, Henning Schulzrinne, 17-Jan-12, This document defines a SIP Usage for REsource LOcation And Discovery (RELOAD), The SIP Usage provides the functionality of a SIP proxy or registrar in a fully-distributed system. The SIP Usage provides lookup service for AoRs stored in the overlay. The SIP Usage also defines GRUUs that allow the registrations to map an AoR to a specific node reachable through the overlay. The AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged. "P2PSIP Overlay Diagnostics", David Bryan, XingFeng Jiang, Roni Even, Haibin Song, 28-Dec-11, This document describes mechanisms for P2PSIP diagnostics. It defines extensions to the RELOAD P2PSIP base protocol RELOAD [I-D.ietf-p2psip-base] to collect diagnostic information, and details the protocol specifications for these extensions. Useful diagnostic information for connection and node status monitoring is also defined. The document also describes the usage scenarios and provides examples of how these methods are used to perform diagnostics in a P2PSIP overlay networks. "A Self-tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD)", Jouni Maenpaa, Gonzalo Camarillo, Jani Hautakorpi, 6-Jan-12, REsource LOcation And Discovery (RELOAD) is a peer-to-peer (P2P) signaling protocol that provides an overlay network service. Peers in a RELOAD overlay network collectively run an overlay algorithm to organize the overlay, and to store and retrieve data. This document describes how the default topology plugin of RELOAD can be extended to support self-tuning, that is, to adapt to changing operating conditions such as churn and network size. "Service Discovery Usage for REsource LOcation And Discovery (RELOAD)", Jouni Maenpaa, Gonzalo Camarillo, 1-Apr-12, REsource LOcation and Discovery (RELOAD) does not define a generic service discovery mechanism as part of the base protocol. This document defines how the Recursive Distributed Rendezvous (ReDiR) service discovery mechanism used in OpenDHT can be applied to RELOAD overlays to provide a generic service discovery mechanism. "An extension to RELOAD to support Direct Response Routing", Yunfei Zhang, Ning Zong, Roni Even, 29-Nov-11, This document proposes an optional extension to RELOAD to support direct response routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses reducing the overhead on intermediary peers and describes the potential cases where this extension can be used. "An extension to RELOAD to support Relay Peer Routing", Ning Zong, Roni Even, Yunfei Zhang, 29-Nov-11, This document proposes an optional extension to RELOAD to support relay peer routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses reducing the overhead on intermediary peers and describes the potential cases where this extension can be used. Protocol to Access WS database (paws) ------------------------------------- "Protocol to Access White Space database: PS, use cases and rqmts", Scott Probasco, Basavaraj Patil, 11-May-12, Portions of the radio spectrum that are assigned to a particular use but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing additional transmissions (which may or may not be licensed) in white space is a technique to "unlock" existing spectrum for new use. An obvious requirement is that these additional transmissions do not interfere with the assigned use of the spectrum. One approach to using the white space spectrum at a given time and location is to verify with a database for available channels. This document describes the concept of TV White Spaces. It also describes the problems that need to be addressed to enable white space spectrum for additional uses, without causing interference to currently assigned use, by querying a database which stores information about the channel availability at any given location and time. A number of possible use cases of white space spectrum and technology as well as a set of requirements for the database query protocol are also described. Audio/Video Transport Payloads (payload) ---------------------------------------- "RTP payload format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW)", Zheng Fang, 22-Feb-12, This document specifies real-time transport protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW). Three media type registrations are included for EVRC-NW RTP payload formats. In addition, a file format is specified for transport of EVRC-NW speech data in storage mode applications such as e-mail. "RTP Payload Format for the iSAC Codec", Tina le Grand, Paul Jones, Pascal Huart, Harald Alvestrand, 17-Apr-12, iSAC is a proprietary wideband speech and audio codec developed by Global IP Solutions, suitable for use in Voice over IP applications. This document describes the payload format for iSAC generated bit streams within a Real-Time Protocol (RTP) packet. Also included here are the necessary details for the use of iSAC with the Session Description Protocol (SDP). "RTP Payload Format for G.718 Speech/Audio", Glen Zorn, Yekui Wang, Ari Lakaniemi, 7-May-12, This document specifies the Real-Time Transport Protocol (RTP) payload format for the Embedded Variable Bit-Rate (EV-VBR) speech/ audio codec, specified in ITU-T G.718. A media type registration for this RTP payload format is also included. "RTP Payload Format for VP8 Video", Patrik Westin, Henrik Lundin, Michael Glover, Justin Uberti, Frank Galligan, 26-Mar-12, This memo describes an RTP payload format for the VP8 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. "RTP Payload Format for Bluetooth's SBC Audio Codec", Christian Hoene, Frans Bont, 4-Jan-12, This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the low complexity subband codec (SBC), which is the mandatory audio codec of the Advanced Audio Distribution Profile (A2DP) Specification written by the Bluetooth(r) Special Interest Group (SIG). The payload format is designed to be able to interoperate with existing Bluetooth A2DP devices, to provide high streaming audio quality, interactive audio transmission over the internet, and ultra-low delay coding for jam sessions on the internet. This document contains also a media type registration which specifies the use of the RTP payload format. Path Computation Element (pce) ------------------------------ "Extensions to the Path Computation Element communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering", Eiji Oki, Tomonori Takeda, Adrian Farrel, Fatai Zhang, 3-Jan-12, The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers through a process called inter-layer traffic engineering. PCE is a candidate solution for such requirements. The PCE communication Protocol (PCEP) is designed as a communication protocol between Path Computation Clients (PCCs) and PCEs. This document presents PCEP extensions for inter-layer traffic engineering. "Document:", Diego Caviglia, Fatai Zhang, Kenichi Ogaki, Tomohiro Otani, 5-Jan-12, The initial effort of PCE WG is specifically focused on MPLS (Multi- protocol label switching). As a next step, this draft describes functional requirements for GMPLS (Generalized MPLS) application of PCE (Path computation element). "Conveying Vendor-Specific Constraints in the Path Computation Element Protocol", Fatai Zhang, Adrian Farrel, Greg Bernstein, 1-Dec-11, The Path Computation Element Protocol (PCEP) is used to convey path computation requests and responses between Path Computation Clients (PCCs) and Path Computation Elements (PCEs), and also between cooperating PCEs. In PCEP the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation. The mechanisms defined for indicating objective functions include the capability to convey vendor-specific objective functions. This document defines a facility to carry vendor-specific constraints in PCEP. "PCEP Requirements for WSON Routing and Wavelength Assignment", Young Lee, Greg Bernstein, Jonas Martensson, Tomonori Takeda, Takehiro Tsuritani, Oscar de Dios, 23-Apr-12, This memo provides application-specific requirements for the Path Computation Element communication Protocol (PCEP) for the support of Wavelength Switched Optical Networks (WSON). Lightpath provisioning in WSONs requires a routing and wavelength assignment (RWA) process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical light path computation. Requirements for Optical impairments will be addressed in a separate document. "PCEP extensions for GMPLS", Cyril Margaria, Oscar de Dios, Fatai Zhang, 9-Mar-12, This memo provides extensions for the Path Computation Element communication Protocol (PCEP) for the support of GMPLS control plane. "Applicability of the Path Computation Element to Inter-Area and Inter-AS MPLS and GMPLS Traffic Engineering", Daniel King, Julien Meuric, Olivier Dugeon, Quintin Zhao, Oscar de Dios, Francisco Chico, 16-Jan-12, The Path Computation Element (PCE) may be used for computing services that traverse multi-area and multi-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) networks. This document examines the applicability of the PCE architecture, protocols, and protocol extensions for computing multi-area and multi-AS paths in MPLS and GMPLS networks. "PCE-based Computation Procedure To Compute Shortest Constrained P2MP Inter-domain Traffic Engineering Label Switched Paths", Quintin Zhao, Dhruv Dhody, Zafar Ali, Cisco Systems, Siva Sivabalan, Daniel King, Ramon Casellas, 2-May-12, The ability to compute paths for constrained point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) across multiple domains has been identified as a key requirement for the deployment of P2MP services in MPLS and GMPLS networks. The Path Computation Element (PCE) has been recognized as an appropriate technology for the determination of inter-domain paths of P2MP TE LSPs. This document describes the procedures and extensions to the PCE communication Protocol (PCEP) to handle requests and responses for the computation of inter-domain paths for P2MP TE LSPs. "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS", Daniel King, Adrian Farrel, 10-May-12, Computing optimum routes for Label Switched Paths (LSPs) across multiple domains in MPLS Traffic Engineering (MPLS-TE) and GMPLS networks presents a problem because no single point of path computation is aware of all of the links and resources in each domain. A solution may be achieved using the Path Computation Element (PCE) architecture. Where the sequence of domains is known a priori, various techniques can be employed to derive an optimum path. If the domains are simply-connected, or if the preferred points of interconnection are also known, the Per-Domain Path Computation technique can be used. Where there are multiple connections between domains and there is no preference for the choice of points of interconnection, the Backward Recursive Path Computation Procedure (BRPC) can be used to derive an optimal path. This document examines techniques to establish the optimum path when the sequence of domains is not known in advance. The document shows how the PCE architecture can be extended to allow the optimum sequence of domains to be selected, and the optimum end-to-end path to be derived through the use of a hierarchical relationship between domains. "PCEP Extensions for Stateful PCE", Edward Crabbe, Jan Medved, Robert Varga, Ina Minei, 28-Feb-12, The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for synchronization or PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable this functionality, providing stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP) via PCEP. "Standard Representation Of Domain Sequence", Dhruv Dhody, Udayasree Palle, Ramon Casellas, 22-May-12, The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement for P2P and P2MP scenarios. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems. This document specifies a standard representation and encoding of a domain sequence, which is defined as an ordered sequence of domains traversed to reach the destination domain. This document also defines new sub-objects to be used to encode domain identifiers. Congestion and Pre-Congestion Notification (pcn) ------------------------------------------------ "A PCN encoding using 2 DSCPs to provide 3 or more states", Toby Moncaster, Bob Briscoe, Michael Menth, 12-Mar-12, Pre-congestion notification (PCN) is a mechanism designed to protect the Quality of Service of inelastic flows within a controlled domain. It does this by marking packets when traffic load on a link is approaching or has exceeded a threshold below the physical link rate. This experimental encoding scheme specifies how three encoding states can be carried in the IP header using a combination of two DSCPs and the ECN bits. The Basic scheme only allows for three encoding states. The Full scheme provides 6 states, enough for limited end- to-end support for ECN as well. "Encoding 3 PCN-States in the IP header using a single DSCP", Bob Briscoe, Toby Moncaster, Michael Menth, 20-Apr-12, The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. The overall rate of the PCN-traffic is metered on every link in the PCN domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes pass information about these PCN-marks to decision points which then decide whether to admit or block new flow requests or to terminate some already-admitted flows during serious pre-congestion. This document specifies how PCN-marks are to be encoded into the IP header by re-using the Explicit Congestion Notification (ECN) codepoints within a PCN-domain. The PCN wire protocol for non-IP protocol headers will need to be defined elsewhere. Nonetheless, this document clarifies the PCN encoding for MPLS in an informational Appendix. The encoding for IP provides for up to three different PCN marking states using a single DSCP: Not-marked (NM), Threshold-marked (ThM) and Excess-traffic-marked (ETM). Hence, it is called the 3-in-1 PCN encoding. This document obsoletes RFC5696. "PCN Encoding for Packet-Specific Dual Marking (PSDM Encoding)", Michael Menth, Jozef Babiarz, Toby Moncaster, Bob Briscoe, 12-Mar-12, Pre-congestion notification (PCN) is a link-specific and load- dependent packet re-marking mechanism and provides in Differentiated Services networks feedback to egress nodes about load conditions within the domain. It is used to support admission control and flow termination decision in a simple way. This document proposes how PCN marks can be encoded into the IP header for packet-specific dual marking (PSDM). PSDM encoding provides three different codepoints: not-ETM, not-ThM, and PM. Excess-traffic-marking may re-mark not- ETM-packets to PM and threshold-marking may re-mark not-ThM-packets to PM. "PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation", Anna Charny, Fortune Huang, Georgios Karagiannis, Michael Menth, Tom Taylor, 11-May-12, Pre-congestion notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary node behaviours for a PCN-domain. The behaviour described here is that for a form of measurement-based load control using three PCN marking states, not- marked, threshold-marked, and excess-traffic-marked. This behaviour is known informally as the Controlled Load (CL) PCN-boundary-node behaviour. "Overview of Pre-Congestion Notification Encoding", Georgios Karagiannis, Kwok Chan, Toby Moncaster, Michael Menth, Philip Eardley, Bob Briscoe, 8-Mar-12, The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. On every link in the PCN domain, the overall rate of the PCN-traffic is metered, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes provide decision points with information about the PCN-marks of PCN-packets which allows them to take decisions about whether to admit or block a new flow request, and to terminate some already admitted flows during serious pre- congestion. The PCN Working Group explored a number of approaches for encoding this pre-congestion information into the IP header. This document provides details of all those approaches along with an explanation of the constraints that had to be met by any solution. "PCN Boundary Node Behaviour for the Single Marking (SM) Mode of Operation", Anna Charny, Georgios Karagiannis, Michael Menth, Tom Taylor, 5-Apr-12, Pre-congestion notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary node behaviours for a PCN-domain. The behaviour described here is that for a form of measurement-based load control using two PCN marking states, not- marked, and excess-traffic-marked. This behaviour is known informally as the Single Marking (SM) PCN-boundary-node behaviour. "Requirements for Signaling of (Pre-) Congestion Information in a DiffServ Domain", Georgios Karagiannis, Tom Taylor, Kwok Chan, Michael Menth, Philip Eardley, 8-Feb-12, Precongestion notification (PCN) is a means for protecting quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo describes the requirements for the signaling applied within the PCN domain: (1) PCN-feedback-information is carried from the PCN-egress- node to the decision point;(2) the decision point may ask the PCN- ingress-node to measure, and report back, the rate of sent PCN- traffic between that PCN-ingress-node and PCN-egress-node. The decision point may be either collocated with the PCN-ingress-node or a centralized node (in the first case, (2) is not required). The signaling requirements pertain in particular to two edge behaviors, "controlled load (CL)" and "single marking (SM)". Port Control Protocol (pcp) --------------------------- "Port Control Protocol (PCP)", Dan Wing, Stuart Cheshire, Mohammed Boucadair, Reinaldo Penno, Paul Selkirk, 21-May-12, The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a network address translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages. "DHCP Options for the Port Control Protocol (PCP)", Mohamed Boucadair, Reinaldo Penno, Dan Wing, 3-May-12, This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) Server names. The use of DHCPv4 or DHCPv6 depends on the PCP deployment scenario. "Universal Plug and Play (UPnP) Internet Gateway Device (IGD)-Port Control Protocol (PCP) Interworking Function", Mohamed Boucadair, Francis Dupont, Reinaldo Penno, Dan Wing, 12-Mar-12, This document specifies the behavior of the UPnP IGD (Internet Gateway Device)/PCP Interworking Function. An UPnP IGD-PCP Interworking Function (IGD-PCP IWF) is required to be embedded in CP routers to allow for transparent NAT control in environments where UPnP is used in the LAN side and PCP in the external side of the CP router. "Port Control Protocol (PCP) Proxy Function", Mohamed Boucadair, Francis Dupont, Reinaldo Penno, Dan Wing, 21-Apr-12, This document specifies the behavior of a PCP Proxy element, for instance embedded in Customer Premise routers. Protocol Independent Multicast (pim) ------------------------------------ "Population Count Extensions to PIM", Dino Farinacci, Greg Shepherd, Stig Venaas, Yiqun Cai, 10-Apr-12, This specification defines a method for providing multicast distribution-tree accounting data. Simple extensions to the PIM protocol allow a rough approximation of tree-based data in a scalable fashion. "Protocol Independent Multicast ECMP Redirect", Yiqun Cai, Liming Wei, Heidi Ou, Vishal Arya, Sunil Jethwani, 26-Apr-12, A Protocol Independent Multicast (PIM) [RFC4601] router uses the Reverse Path Forwarding (RPF) procedure to select an upstream interface and router to build forwarding state. When there are equal cost multiple paths (ECMP), existing implementations often use hash algorithms to select a path. Such algorithms do not allow the spread of traffic among the ECMPs according to administrative metrics. This usually leads to inefficient or ineffective use of network resources. This document introduces the ECMP Redirect, a mechanism to improve the RPF procedure over ECMPs. It allows ECMP path selection to be based on administratively selected metrics, such as data transmission delays, path preferences and routing metrics. "IGMP/MLD-Based Explicit Membership Tracking Function for Multicast Routers", Hitoshi Asaeda, Nicolai Leymann, 10-Apr-12, This document describes the IGMP/MLD-based explicit membership tracking function for multicast routers. The explicit tracking function is useful for accounting and contributes to saving network resource and fast leaves (i.e. shortened leave latency). "Protocol Independent Multicast DR Load Balancing", Yiqun Cai, Sri Vallepalli, Heidi Ou, Andy Green, 25-Mar-12, On a multi-access network such as an Ethernet, one of the PIM routers is elected as a Designated Router (DR). The PIM DR has two roles in the PIM protocol. On the first hop network, the PIM DR is responsible for registering an active source to the RP if the group is operated in PIM SM. On the last hop network, the PIM DR is responsible for tracking local multicast listeners and forwarding traffic to these listeners if the group is operated in PIM SM/SSM/DM. In this document, we propose a modification to the PIM protocol that allows more than one of these last hop routers to be selected so that the forwarding load can be distributed to and handled among these routers. A router responsible for forwarding for a particular group is called a Group Designated Router (GDR). Public-Key Infrastructure (X.509) (pkix) ---------------------------------------- "Internet X.509 Public Key Infrastructure -- HTTP Transport for CMP", Tomi Kause, Martin Peylo, 15-May-12, This document describes how to layer the Certificate Management Protocol over HTTP. It is the "CMPtrans" document referenced in RFC 4210 and therefore updates the reference given therein. "Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", Dave Cooper, 12-Mar-12, This document updates RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. This document changes the set of acceptable encoding methods for the explicitText field of the user notice policy qualifier and clarifies the rules for converting internationalized domain name labels to ASCII. "S/MIME Capabilities for Public Key Definitions", Jim Schaad, 15-May-12, This document defines a set of Secure/Multipurpose Internet Mail Extensions (S/MIME) Capability types for ASN.1 encoding for the current set of public keys defined by the PKIX working group. This facilitates the ability for a requester to specify information on the public keys and signature algorithms to be used in responses. An example of where this is used is is detailed in Online Certificate Status Protocol Algorithm Agility (RFC 6277). "DNS Certification Authority Authorization (CAA) Resource Record", Phillip Hallam-Baker, Rob Stradling, 25-Apr-12, The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify the certificate signing certificate(s) authorized to issue certificates for that domain. CAA resource records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis- issue. "CMC Extensions: Server Key Generation", Jim Schaad, Paul Timmel, Sean Turner, 2-Jan-12, This document defines a set of extensions to the Certificate Management over CMS (CMC) protocol that addresses the desire to support server-side generation of keys. This service is provided by the definition of additional control statements within the CMC architecture. Additional CMC errors are also defined. "Enrollment over Secure Transport", Max Pritikin, Peter Yee, 12-Mar-12, This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple yet functional certificate management protocol targeting simple Public Key Infrastructure clients that need to acquire client certificate(s) and associated Certification Authority (CA) certificate(s). Peer to Peer Streaming Protocol (ppsp) -------------------------------------- "Problem Statement and Requirements of Peer-to-Peer Streaming Protocol (PPSP)", Yunfei Zhang, Gonzalo Camarillo, Yang Yang, Victor Pascual, 27-Feb-12, Peer-to-Peer (P2P for short) streaming systems show more and more popularity in current Internet with proprietary protocols. This document identifies problems of the proprietary protocols, proposes a Peer to Peer Streaming Protocol (PPSP) including tracker and peer signaling components, and discusses the scope, uses cases and requirements of PPSP. "Peer-to-Peer Streaming Peer Protocol (PPSPP)", A. Bakker, 29-Jan-12, The Peer-to-Peer Streaming Peer Protocol (PPSPP) is a peer-to-peer based transport protocol for content dissemination. It can be used for streaming on-demand and live video content, as well as conventional downloading. In PPSPP, the clients consuming the content participate in the dissemination by forwarding the content to other clients via a mesh-like structure. It is a generic protocol which can run directly on top of UDP, TCP, or as a RTP profile. Features of PPSPP are short time-till-playback and extensibility. Hence, it can use different mechanisms to prevent freeriding, and work with different peer discovery schemes (centralized trackers or Distributed Hash Tables). Depending on the underlying transport protocol, PPSPP can also use different congestion control algorithms, such as LEDBAT, and offer transparent NAT traversal. Finally, PPSPP maintains only a small amount of state per peer and detects malicious modification of content. This documents describes PPSPP and how it satisfies the requirements for the IETF Peer-to-Peer Streaming Protocol (PPSP) Working Group's peer protocol. Preparation and Comparison of Internationalized Strings (precis) ---------------------------------------------------------------- "Stringprep Revision Problem Statement", Marc Blanchet, Andrew Sullivan, 12-Mar-12, Using Unicode codepoints in protocol strings that expect comparison with other strings requires preparation of the string that contains the Unicode codepoints. Internationalizing Domain Names in Applications (IDNA2003) defined and used Stringprep and Nameprep. Other protocols subsequently defined Stringprep profiles. A new approach different from Stringprep and Nameprep is used for a revision of IDNA2003 (called IDNA2008). Other Stringprep profiles need to be similarly updated or a replacement of Stringprep needs to be designed. This document outlines the issues to be faced by those designing a Stringprep replacement. "PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols", Peter Saint-Andre, Marc Blanchet, 10-May-12, Application protocols using Unicode code points in protocol strings need to prepare such strings in order to perform comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to handle various classes of strings in a way that depends on the properties of Unicode code points and that is agile with respect to versions of Unicode; as a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). A specification that reuses this framework can either directly use the base string classes or subclass the base string classes as needed. This framework takes an approach similar to the revised internationalized domain names in applications (IDNA) technology (RFC 5890, RFC 5891, RFC 5892, RFC 5893, RFC 5894) and thus adheres to the high-level design goals described in RFC 4690, albeit for application technologies other than the Domain Name System (DNS). This document obsoletes RFC 3454. Pseudowire Emulation Edge to Edge (pwe3) ---------------------------------------- "Pseudowire Preferential Forwarding Status Bit", Praveen Muley, Mustapha Aissaoui, 1-May-12, This document describes a mechanism for standby status signaling of redundant pseudowires (PWs) between their termination points. A set of redundant PWs is configured between provider edge (PE) nodes in single-segment pseudowire (SS-PW) applications, or between terminating provider edge (T-PE) nodes in multi-segment pseudowire (MS-PW) applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new status bit is needed to indicate a preferential forwarding status of Active or Standby for each PW in a redundant set. In addition, a second status bit is defined to allow peer PE nodes to coordinate a switchover operation of the PW. Finally, this document updates the PW operational status textual convention defined in RFC 5542 [9]. "Pseudowire Redundancy", Praveen Muley, Mustapha Aissaoui, Matthew Bocci, 4-May-12, This document describes a framework comprised of a number of scenarios and associated requirements for pseudowire (PW) redundancy. A set of redundant PWs is configured between provider edge (PE) nodes in single -segment PW applications, or between terminating PE (T-PE) nodes in multi-segment PW applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new PW status is required to indicate the preferential forwarding status of active or standby for each PW in the redundancy set. "MPLS and Ethernet OAM Interworking", Dinesh Mohan, Nabil Bitar, Philippe Niger, Ray Qiu, Simon DeLord, 16-Apr-12, This document specifies the mapping of defect states between Ethernet Attachment Circuits (ACs) and associated Ethernet Pseudowires (PWs) connected in accordance to the PWE3 architecture to realize an end-to-end emulated Ethernet service. It standardizes the behavior of Provider Edges (PEs) with respect to Ethernet PW and AC defects. "Inter-Chassis Communication Protocol for L2VPN PE Redundancy", Ali Sajassi, Luca Martini, Samer Salam, Satoru Matsushima, 7-Feb-12, This document specifies an inter-chassis communication protocol (ICCP) that enables Provider Edge (PE) device redundancy for Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS) applications. The protocol runs within a set of two or more PEs, forming a redundancy group, for the purpose of synchronizing data amongst the systems. It accommodates multi-chassis attachment circuit as well as pseudowire redundancy mechanisms. "Signaling Root-Initiated Point-to-Multipoint Pseudowire using LDP", Siva Sivabalan, Sami Boutros, Luca Martini, 11-Mar-12, This document specifies a mechanism to signal Point-to-Multipoint (P2MP) Pseudowires (PW) tree using LDP. Such a mechanism is suitable for any Layer 2 VPN service requiring P2MP connectivity over an IP or MPLS enabled PSN. A P2MP PW established via the proposed mechanism is root initiated. "Packet Pseudowire Encapsulation over an MPLS PSN", Stewart Bryant, Luca Martini, George Swallow, Andrew Malis, 12-May-12, This document describes a pseudowire mechanism that is used to transport a packet service over an MPLS PSN in the case where the client Label Switching Router (LSR) and the server Provider Edge equipments are co-resident in the same equipment. This pseudowire mechanism may be used to carry all of the required layer 2 and layer 3 protocols between the pair of client LSRs. "Pseudowire Control Word Negotiation Mechanism Update", Lizhong Jin, Raymond Key, Simon DeLord, Thomas Nadeau, Vishwas Manral, Sami Boutros, Reshad Rahman, 13-Apr-12, This document describes the problem of control word negotiation mechanism specified in [RFC4447]. Based on the problem analysis, a message exchanging mechanism is introduced to solve this control word negotiation issue. This document is to update [RFC4447] control word negotiation mechanism. "LDP Typed Wildcard FEC for PWid and Generalized PWid FEC Elements", Kamran Raza, Sami Boutros, Carlos Pignataro, 6-Feb-12, The "Typed Wildcard Forwarding Equivalence Class (FEC) Element" defines an extension to the Label Distribution Protocol (LDP) that can be used when it is desired to request or withdraw or release all label bindings for a given FEC Element type. However, a typed wildcard FEC element must be individually defined for each FEC element type. This specification defines the typed wildcard FEC elements for the PWid (0x80) and Generalized PWid (0x81) FEC element types. "A Unified Control Channel for Pseudowires", Thomas Nadeau, Luca Martini, 8-May-12, This document describes a unified mode of operation for Virtual Circuit Connectivity Verification (VCCV), which provides a control channel that is associated with a pseudowire (PW). VCCV applies to all supported access circuit and transport types currently defined for PWs, as well as those being transported by The MPLS Transport Profile. This new mode is intended to augment those described in RFC5085, but this document describes new rules requiring this mode to be used as the default/mandatory mode of operation for VCCV. The older types will remain optional. "Label Distribution Protocol Extensions for Proactive Operations, Administration and Maintenance Configuration of Dynamic MPLS Transport Profile PseudoWire", Fei Zhang, Wu Bo, Elisa Bellagamba, 28-Jan-12, This document specifies extensions to the Label Distribution Protocol (LDP) to configure and control proactive Operations, Adminstration and Maintenance (OAM) functions, suitable for dynamic Single-Segment PseudoWire (SS-PW) and Multi-Segment PseudoWire (MS-PW). "The Pseudowire (PW) & Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results", Nick Regno, 17-Apr-12, Most Pseudowire Emulation Edge-to-Edge (PWE3) encapsulations mandate the use of the Control Word (CW) in order to better emulate the services for which the encapsulations have been defined. However, some encapulations treat the Control Word as optional. As a result, implementations of the CW, for encapsulations for which it is optional, vary by equipment manufacturer, equipment model and service provider network. Similarly, Virtual Circuit Connectivity Verification (VCCV) supports three Control Channel (CC) types and multiple Connectivity Verification (CV) Types. This flexibility has led to reports of interoperability issues within deployed networks and associated drafts to attempt to remedy the situation. This survey of the PW/VCCV user community was conducted to determine implementation trends. The survey and results is presented herein. "Definition of P2MP PW TLV for LSP-Ping Mechanisms", Parag Jain, Sam Aldrin, 7-May-12, LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. This document describes a mechanism to verify connectivity of Point-to-Multipoint (P2MP) Pseudowires (PW) using LSP Ping. RADIUS EXTensions (radext) -------------------------- "Transport Layer Security (TLS) encryption for RADIUS", Klaas Wierenga, Mike McCauley, Stefan Winter, Stig Venaas, 13-Feb-12, This document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP as the transport protocol. This enables dynamic trust relationships between RADIUS servers. "RADIUS Over TCP", Alan DeKok, 12-Oct-10, The Remote Authentication Dial In User Server (RADIUS) Protocol has until now required the User Datagram Protocol (UDP) as the underlying transport layer. This document defines RADIUS over the Transmission Control Protocol (RADIUS/TCP), in order to address handling issues related to RADIUS over Transport Layer Security (RADIUS/TLS). It permits TCP to be used as a transport protocol for RADIUS only when a transport layer such as TLS or IPsec provides confidentialy and security. "RADIUS attributes for IPv6 Access Networks", Benoit Lourdelet, Wojciech Dec, Behcet Sarikaya, Glen Zorn, David Miles, 7-May-12, This document specifies additional IPv6 RADIUS attributes useful in residential broadband network deployments. The attributes, which are used for authorization and accounting, enable assignment of a host IPv6 address and IPv6 DNS server address via DHCPv6; assignment of an IPv6 route announced via router advertisement; assignment of a named IPv6 delegated prefix pool; and assignment of a named IPv6 pool for host DHCPv6 addressing. "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", Alan DeKok, Avi Lior, 26-Apr-12, The Remote Authentication Dial In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes which can carry more than 253 octets of data. This document defines changes to RADIUS which address all of the above problems. "RADIUS Attributes for IEEE 802 Networks", Bernard Aboba, Jouni Malinen, Paul Congdon, Joseph Salowey, Mark Jones, 4-Apr-12, RFC 3580 provides guidelines for the use of the Remote Authentication Dialin User Service (RADIUS) within IEEE 802 local area networks (LANs). This document proposes additional attributes for use within IEEE 802 networks, as well as providing clarifications on the usage of the EAP-Key-Name attribute, updating RFC 4072. The attributes defined in this document are usable both within RADIUS and Diameter. Reputation Services (repute) ---------------------------- "A Reputation Response Set for Email Identifiers", Nathaniel Borenstein, Murray Kucherawy, 6-Apr-12, This document defines a response set for describing assertions a reputation service provider can make about email identifers, for use in generating reputons. "A Media Type for Reputation Interchange", Nathaniel Borenstein, Murray Kucherawy, 6-Apr-12, This document defines a media type for exchanging reputation information about an arbitrary class of object. "Reputation Data Interchange using HTTP and JSON", Nathaniel Borenstein, Murray Kucherawy, 6-Apr-12, This document defines a mechanism to conduct queries for reputation information using the Hypertext Transfer Protocol. "A Model for Reputation Reporting", Nathaniel Borenstein, Murray Kucherawy, Andrew Sullivan, 5-Mar-12, This document describes a general architecture for a reputation-based service and a model for the exchange of reputation information on the Internet. The document roughly follows the recommendations of RFC4101 for describing a protocol model. Reliable Multicast Transport (rmt) ---------------------------------- "FLUTE - File Delivery over Unidirectional Transport", Toni Paila, Rod Walsh, Michael Luby, Vincent Roca, Rami Lehtonen, 12-Mar-12, This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. This document obsoletes RFC3926. "FCAST: Scalable Object Delivery for the ALC and NORM Protocols", Vincent Roca, Brian Adamson, 19-Oct-11, This document introduces the FCAST object (e.g., file) delivery application on top of the ALC and NORM reliable multicast protocols. FCAST is a highly scalable application that provides a reliable object delivery service. "SDP Descriptors for FLUTE", Igor Curcio, Rod Walsh, Jani Peltotalo, Sami Peltotalo, Harsh Mehta, 12-Mar-12, This document specifies the use of SDP to describe the parameters required to begin, join, receive data from, and/or end FLUTE sessions. It also provides a Composite Session SDP media grouping semantic for grouping media streams into protocol-specific sessions, such as multiple-channel FLUTE sessions. Routing Over Low power and Lossy networks (roll) ------------------------------------------------ "A Security Framework for Routing over Low Power and Lossy Networks", Tzeta Tsao, Roger Alexander, Mischa Dohler, Vanesa Daza, Angel Lozano, 12-Jan-12, This document presents a security framework for routing over low power and lossy networks (LLN). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low power and lossy networks. A systematic approach is used in defining and evaluating the security threats and identifying applicable countermeasures. These assessments provide the basis of the security recommendations for incorporation into low power, lossy network routing protocols. As an illustration, this framework is applied to IPv6 Routing Protocol for Low Power and Lossy Networks (RPL). "Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks", Mukul Goyal, Emmanuel Baccelli, Matthias Philipp, Anders Brandt, Jerry Martocci, 8-May-12, This document specifies a point-to-point route discovery mechanism, complementary to the RPL core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in the LLN such that the discovered routes meet specified metrics constraints. "The Minimum Rank with Hysteresis Objective Function", Omprakash Gnawali, P Levis, 26-Apr-12, The Routing Protocol for Low Power and Lossy Networks (RPL) uses objective functions to construct routes that optimize or constrain the routes it selects and uses. This specification describes the Minimum Rank with Hysteresis Objective Function (MRHOF), an objective function that selects routes that minimize a metric, while using hysteresis to reduce churn in response to small metric changes. MRHOF works with metrics that are additive along a route, and the metric it uses is determined by the metrics RPL Destination Information Object (DIO) messages advertise. "A Mechanism to Measure the Quality of a Point-to-point Route in a Low Power and Lossy Network", Mukul Goyal, Emmanuel Baccelli, Anders Brandt, Jerry Martocci, 9-May-12, This document specifies a mechanism that enables an RPL router to measure the quality of an existing route towards another RPL router in a low power and lossy network, thereby allowing the router to decide if it wants to initiate the discovery of a better route. "Applicability Statement for the Routing Protocol for Low Power and Lossy Networks (RPL) in AMI Networks", Daniel Popa, Jorjeta Jetcheva, Nicolas Dejean, Ruben Salazar, Jonathan Hui, Kazuya Monden, 30-Apr-12, This document discusses the applicability of RPL in Advanced Metering Infrastructure (AMI) networks. Real-Time Communication in WEB-browsers (rtcweb) ------------------------------------------------ "Web Real-Time Communication Use-cases and Requirements", Christer Holmberg, Stefan Hakansson, Goran Eriksson, 2-Apr-12, This document describes web based real-time communication use-cases. Based on the use-cases, the document also derives requirements related to the browser, and the API used by web applications to request and control media stream services provided by the browser. "Overview: Real Time Protocols for Brower-based Applications", Harald Alvestrand, 12-Mar-12, This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This work is an attempt to synthesize the input of many people, but makes no claims to fully represent the views of any of them. All parts of the document should be regarded as open for discussion, unless the RTCWEB chairs have declared consensus on an item. This document is a work item of the RTCWEB working group. "Web Real-Time Communication (WebRTC): Media Transport and Use of RTP", Colin Perkins, Magnus Westerlund, Joerg Ott, 12-Mar-12, The Web Real-Time Communication (WebRTC) framework provides support for direct interactive rich communication using audio, video, text, collaboration, games, etc. between two peers' web-browsers. This memo describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context, and gives requirements for which RTP features, profiles, and extensions need to be supported. "Security Considerations for RTC-Web", Eric Rescorla, 12-Mar-12, The Real-Time Communications on the Web (RTC-Web) working group is tasked with standardizing protocols for real-time communications between Web browsers. The major use cases for RTC-Web technology are real-time audio and/or video calls, Web conferencing, and direct data transfer. Unlike most conventional real-time systems (e.g., SIP- based soft phones) RTC-Web communications are directly controlled by some Web server, which poses new security challenges. For instance, a Web browser might expose a JavaScript API which allows a server to place a video call. Unrestricted access to such an API would allow any site which a user visited to "bug" a user's computer, capturing any activity which passed in front of their camera. This document defines the RTC-Web threat model and defines an architecture which provides security within that threat model. "RTCWEB Security Architecture", Eric Rescorla, 12-Mar-12, The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for real-time communications between Web browsers. The major use cases for RTCWEB technology are real-time audio and/or video calls, Web conferencing, and direct data transfer. Unlike most conventional real-time systems (e.g., SIP- based soft phones) RTCWEB communications are directly controlled by some Web server, which poses new security challenges. For instance, a Web browser might expose a JavaScript API which allows a server to place a video call. Unrestricted access to such an API would allow any site which a user visited to "bug" a user's computer, capturing any activity which passed in front of their camera. [I-D.ietf- rtcweb-security] defines the RTCWEB threat model. This document defines an architecture which provides security within that threat model. "Javascript Session Establishment Protocol", Justin Uberti, Cullen Jennings, 3-Mar-12, This document proposes a mechanism for allowing a Javascript application to fully control the signaling plane of a multimedia session, and discusses how this would work with existing signaling protocols. This document is an input document for discussion. It should be discussed in the RTCWEB WG list, rtcweb@ietf.org. "RTCWeb Datagram Connection", Randell Jesup, Salvatore Loreto, Michael Tuexen, 5-Mar-12, The Web Real-Time Communication (WebRTC) working group is charged to provide protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. This document describes the non-media data transport aspects of the WebRTC framework. It provides an architectural overview of how the Stream Control Transmission Protocol (SCTP) is used in the WebRTC context as a generic transport service allowing Web Browser to exchange generic data from peer to peer. Routing Area Working Group (rtgwg) ---------------------------------- "IP MIB for IP Fast-Reroute", Alia Atlas, Kiran Koushik, John Flick, 26-Mar-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 relevant for IP routes using IP Fast-Reroute [RFC5714]. "IP Fast Reroute Using Not-via Addresses", Stewart Bryant, Stefano Previdi, Mike Shand, 21-Dec-11, This draft describes a mechanism that provides fast reroute in an IP network through encapsulation to "not-via" addresses. A single level of encapsulation is used. The mechanism protects unicast, multicast and LDP traffic against link, router and shared risk group failure, regardless of network topology and metrics. "Requirements for MPLS Over a Composite Link", Andrew Malis, Curtis Villamizar, Dave McDysan, Lucy Yong, Ning So, 30-Jan-12, There is often a need to provide large aggregates of bandwidth that are best provided using parallel links between routers or MPLS LSR. In core networks there is often no alternative since the aggregate capacities of core networks today far exceed the capacity of a single physical link or single packet processing element. The presence of parallel links, with each link potentially comprised of multiple layers has resulted in additional requirements. Certain services may benefit from being restricted to a subset of the component links or a specific component link, where component link characteristics, such as latency, differ. Certain services require that an LSP be treated as atomic and avoid reordering. Other services will continue to require only that reordering not occur within a microflow as is current practice. Current practice related to multipath is described briefly in an appendix. "LFA applicability in SP networks", Clarence Filsfils, Pierre Francois, 18-Jan-12, In this document, we analyze the applicability of the Loop-Free Alternates method of providing IP fast re-route in both the core and the access parts of Service Provider networks. We consider both the link and node failure cases, and provide guidance on the applicability of LFA to different network topologies, with special emphasis on the access parts of the network. "An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees", Alia Atlas, Robert Kebler, Gabor Envedi, Andras Csaszar, Maciek Konstantynowicz, Russ White, Mike Shand, 12-Mar-12, As IP and LDP Fast-Reroute are increasingly deployed, the coverage limitations of Loop-Free Alternates are seen as a problem that requires a straightforward and consistent solution for IP and LDP, for unicast and multicast. This draft describes an architecture based on redundant backup trees where a single failure can cut a point-of-local-repair from the destination only on one of the pair of redundant trees. One innovative algorithm to compute such topologies is maximally disjoint backup trees. Each router can compute its next-hops for each pair of maximally disjoint trees rooted at each node in the IGP area with computational complexity similar to that required by Dijkstra. The additional state, address and computation requirements are believed to be significantly less than the Not-Via architecture requires. Sip ALerting for User Devices (salud) ------------------------------------- "Alert-Info URNs for the Session Initiation Protocol (SIP)", Laura Liess, Roland Jesske, Alan Johnston, Dale Worley, Paul Kyzivat, 5-Apr-12, The Session Initiation Protocol (SIP) supports the capability to provide a reference to a specific rendering to be used by the UA when the user is alerted. This is done using the Alert-Info header field. However, the reference addresses only network resources with specific rendering properties. There is currently no support for predefined standard identifiers for describing the semantics of the alerting situation or the characteristics of the alerting signal, without being tied to a particular rendering. To overcome this limitation and support new applications, a new family of URNs for use in SIP Alert-Info header fields is defined in this specification. This document normatively updates [RFC3261], the Session Initiation Protocol (SIP). It changes the usage of the SIP Alert-Info header field defined in the [RFC3261] by additionally allowing its use in all provisional responses to INVITE (except the 100 response). Source Address Validation Improvements (savi) --------------------------------------------- "SEND-based Source-Address Validation Implementation", Marcelo Bagnulo, Alberto Garcia-Martinez, 28-Mar-12, This memo describes SEND SAVI, a mechanism to provide source address validation using the SEND protocol. The proposed mechanism is intended to complement ingress filtering techniques to provide a finer granularity on the control of the source addresses used. "SAVI Threat Scope", Danny McPherson, Fred Baker, Joel Halpern, 11-Apr-11, Source Address Validation Improvement (SAVI) effort aims to complement ingress filtering with finer-grained, standardized IP source address validation. This document describes threats enabled by IP source address spoofing both in the global and finer-grained context, describes currently available solutions and challenges, and provides a starting point analysis for finer-grained (host granularity) anti-spoofing work. "SAVI Solution for DHCP", Jun Bi, Jianping Wu, Guang Yao, Fred Baker, 10-Feb-12, This document specifies the procedure for creating bindings between a DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and a binding anchor [I-D.ietf-savi-framework] on SAVI (Source Address Validation Improvements) device. The bindings can be used to filter packets generated on the local link with forged source IP address. "Source Address Validation Improvement Framework", Jianping Wu, Jun Bi, Marcelo Bagnulo, Fred Baker, Christian Vogt, 8-Jan-12, Source Address Validation Improvement methods were developed to prevent nodes attached to the same IP link from spoofing each other's IP addresses, so as to complement ingress filtering with finer- grained, standardized IP source address validation. This document is a framework document, which describes and motivates the design of the SAVI methods. Particular SAVI methods are described in other documents. "SAVI for Mixed Address Assignment Methods Scenario", Jun Bi, Guang Yao, Joel Halpern, Eric Levy-Abegnoli, 28-Apr-12, This document reviews how multiple address discovery methods can coexist in a single SAVI device and collisions are resolved when the same binding entry is discovered by two or more methods. Secure Inter-Domain Routing (sidr) ---------------------------------- "Securing RPSL Objects with RPKI Signatures", Robert Kisteleki, Brian Haberman, 10-May-12, This document describes a method to allow parties to electronically sign RPSL-like objects and validate such electronic signatures. This allows relying parties to detect accidental or malicious modifications on such objects. It also allows parties who run Internet Routing Registries or similar databases, but do not yet have RPSS-like authentication of the maintainers of certain objects, to verify that the additions or modifications of such database objects are done by the legitimate holder(s) of the Internet resources mentioned in those objects. "Use Cases and Interpretation of RPKI Objects for Issuers and Relying Parties", Terry Manderson, Kotikalapudi Sriram, Russ White, 26-Jan-12, This document provides use cases, directions, and interpretations for organizations and relying parties when creating or encountering RPKI object scenarios in the public RPKI. All of the above are discussed here in relation to the Internet routing system. "BGP Prefix Origin Validation", Pradosh Mohapatra, John Scudder, David Ward, Randy Bush, Rob Austein, 21-May-12, To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination AS of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. "The RPKI/Router Protocol", Randy Bush, Rob Austein, 2-Feb-12, In order to verifiably validate the origin ASs of BGP announcements, routers need a simple but reliable mechanism to receive RPKI [I-D.ietf-sidr-arch] prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. "A Publication Protocol for the Resource Public Key Infrastructure (RPKI)", Samuel Weiler, Anuja Sonalker, Rob Austein, 12-Mar-12, This document defines a protocol for publishing Resource Public Key Infrastructure (RPKI) objects. Even though the RPKI will have many participants issuing certificates and creating other objects, it is operationally useful to consolidate the publication of those objects. This document provides the protocol for doing so. "Local Trust Anchor Management for the Resource Public Key Infrastructure", Mark Reynolds, Stephen Kent, 4-Dec-11, This document describes a facility to enable a relying party (RP) to manage trust anchors (TAs) in the context of the Resource Public Key Infrastructure (RPKI). It is common to allow an RP to import TA material in the form of self-signed certificates. The facility described in this document allows an RP to impose constraints on such TAs. Because this mechanism is designed to operate in the RPKI context, the relevant constraints are the RFC 3779 extensions that bind address spaces and/or autonomous system (AS) numbers to entities. The primary motivation for this facility is to enable an RP to ensure that resource allocation information that it has acquired via some trusted channel is not overridden by the information acquired from the RPKI repository system or by the putative TAs that the RP imports. Specifically, the mechanism allows an RP to specify a set of bindings between public key identifiers and RFC 3779 extension data and will override any conflicting bindings expressed via the putative TAs and the certificates downloaded from the RPKI repository system. Although this mechanism is designed for local use by an RP, an entity that is accorded administrative control over a set of RPs may use this mechanism to convey its view of the RPKI to a set of RPs within its jurisdiction. The means by which this latter use case is effected is outside the scope of this document. "RPKI-Based Origin Validation Operation", Randy Bush, 23-May-12, Deployment of RPKI-based BGP origin validation has many operational considerations. This document attempts to collect and present them. It is expected to evolve as RPKI-based origin validation is deployed and the dynamics are better understood. "Algorithm Agility Procedure for RPKI.", Roque Gagliano, Stephen Kent, Sean Turner, 18-Jan-12, This document specifies the process that Certification Authorities (CAs) and Relying Parties (RP) participating in the Resource Public Key Infrastructure (RPKI) will need to follow to transition to a new (and probably cryptographically stronger) algorithm set. The process is expected to be completed in a time scale of months or years. Consequently, no emergency transition is specified. The transition procedure defined in this document supports only a top-down migration (parent migrates before children). "BGPSEC Protocol Specification", Matt Lepinski, 11-May-12, This document describes BGPSEC, an extension to the Border Gateway Protocol (BGP) that provides security for the AS-PATH attribute in BGP update messages. BGPSEC is implemented via a new optional non- transitive BGP path attribute that carries a digital signature produced by each autonomous system on the AS-PATH. "An Overview of BGPSEC", Matt Lepinski, Sean Turner, 8-May-12, This document provides an overview of a security extension to the Border Gateway Protocol (BGP) referred to as BGPSEC. BGPSEC improves security for BGP routing. "Threat Model for BGP Path Security", Stephen Kent, Andrew Chi, 22-Feb-12, This document describes a threat model for BGP path security (BGPSEC). It assumes the context established by the SIDR WG charter, as of April 19, 2011. The charter established two goals for the SIDR work: o Enabling an AS to verify the authorization of an origin AS to originate a specified set of prefixes o Enabling an AS to verify that the AS-PATH represented in a route matches the path travelled by the NLRI for the route The charter further mandates that SIDR build upon the Resource Public Key Infrastructure (RPKI), the first product of the WG. Consistent with the charter, this threat model includes an analysis of the RPKI, and focuses on the ability of an AS to verify the authenticity of the AS path info received in a BGP update. The model assumes that BGP path security is achieved through the application of digital signatures to AS_Path Info. The document characterizes classes of potential adversaries that are considered to be threats, and examines classes of attacks that might be launched against BGPSEC. It concludes with brief discussion of residual vulnerabilities. "Security Requirements for BGP Path Validation", Steven Bellovin, Randy Bush, David Ward, 10-Mar-12, This document describes requirements for a future BGP security protocol design to provide cryptographic assurance that the origin AS had the right to announce the prefix and to provide assurance of the AS Path of the announcement. "BGPsec Operational Considerations", Randy Bush, 23-May-12, Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present them. It is expected to evolve as BGPsec is formalized and initially deployed. "BGP Algorithms, Key Formats, & Signature Formats", Sean Turner, 28-Mar-12, This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size and signature format used in BGPSEC (Border Gateway Protocol Security). This document updates the Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure (RFC 6485). "A Profile for BGPSEC Router Certificates, Certificate Revocation Lists, and Certification Requests", Mark Reynolds, Sean Turner, Stephen Kent, 13-Apr-12, This document defines a standard profile for X.509 certificates for the purposes of supporting validation of Autonomous System (AS) paths in the Border Gateway Protocol (BGP), as part of an extension to that protocol known as BGPSEC. BGP is a critical component for the proper operation of the Internet as a whole. The BGPSEC protocol is under development as a component to address the requirement to provide security for the BGP protocol. The goal of BGPSEC is to design a protocol for full AS path validation based on the use of strong cryptographic primitives. The end-entity (EE) certificates specified by this profile are issued under Resource Public Key Infrastructure (RPKI) Certification Authority (CA) certificates, containing the AS Identifier Delegation extension, to routers within the Autonomous System (AS). The certificate asserts that the router(s) holding the private key are authorized to send out secure route advertisements on behalf of the specified AS. This document also profiles the Certificate Revocation List (CRL), profiles the format of certification requests, and specifies Relying Party certificate path validation procedures. The document extends the RPKI; therefore, this documents updates the RPKI Resource Certificates Profile (RFC 6487). "RPKI Router Implementation Report", Randy Bush, Rob Austein, Keyur Patel, Hannes Gredler, Matthias Waehlisch, 8-Jan-12, This document provides an implementation report for RPKI Router protocol as defined in [I-D.ietf-sidr-rpki-rtr]. The editor did not verify the accuracy of the information provided by respondents or by any alternative means. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. Respondents were asked to only use the YES answer if the feature had at least been tested in the lab. "Router Keying for BGPsec", Sean Turner, Keyur Patel, Randy Bush, 5-Mar-12, BGPsec-speaking routers must be provisioned with private keys and the corresponding public key must be published in the global Resource PKI. This document describes two ways of doing so, router-driven and operator-driven. "Definitions of Managed Objects for the RPKI-Router Protocol", Randy Bush, Bert Wijnen, Keyur Patel, Michael Baer, 26-Mar-12, This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for monitoring the RPKI Router protocol. "RPKI Router Implementation Report", Randy Bush, Rob Austein, Keyur Patel, Hannes Gredler, Matthias Waehlisch, 27-Mar-12, This document provides an implementation report for RPKI Router protocol as defined in [I-D.ietf-sidr-rpki-rtr]. The editor did not verify the accuracy of the information provided by respondents or by any alternative means. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. Respondents were asked to only use the YES answer if the feature had at least been tested in the lab. "Router Keying for BGPsec", Sean Turner, Keyur Patel, Randy Bush, 14-May-12, BGPsec-speaking routers must be provisioned with private keys and the corresponding public key must be published in the global Resource PKI. This document describes two ways of doing so, router-driven and operator-driven. Sieve Mail Filtering Language (sieve) ------------------------------------- "Support for Internet Message Access Protocol (IMAP) Events in Sieve", Barry Leiba, 6-Mar-12, Sieve defines an email filtering language that can, in principle, plug into any point in the processing of an email message. As defined in the base specification, it plugs into mail delivery. This document defines how Sieve can plug into points in the IMAP protocol where messages are created or changed, adding the option of user- defined or installation-defined filtering (or, with Sieve extensions, features such as notifications). SIP for Instant Messaging and Presence Leveraging Extensions (simple) --------------------------------------------------------------------- "Multi-party Chat Using the Message Session Relay Protocol (MSRP)", Aki Niemi, Miguel Garcia, Geir Sandbakken, 1-Mar-12, The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP). This document defines the necessary tools for establishing multi-party chat sessions, or chat rooms, using MSRP. "SIMPLE made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence using the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 18-Apr-12, The IETF has produced many specifications related to Presence and Instant Messaging with the Session Initiation Protocol (SIP). Collectively, these specifications are known as SIMPLE - SIP for Instant Messaging and Presence Leveraging Extensions. This document serves as a guide to the SIMPLE suite of specifications. It breaks them up into categories and explains what each is for and how they relate to each other. "Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP)", Christer Holmberg, Staffan Blau, Eric Burger, 3-May-12, This document defines a Message Session Relay Protocol (MSRP) extension, Connection Establishment for Media Anchoring (CEMA). Support of the extension is optional. The extension allows middleboxes to anchor the MSRP connection, without the need for middleboxes to modify the MSRP messages, and thus also enables a secure end-to-end MSRP communication in networks where such middleboxes are deployed. The document also defines a Session Description Protocol (SDP) attribute, 'msrp-cema', that MSRP endpoints use to indicate support of the CEMA extension. Session Initiation Protocol (sip) --------------------------------- "A Framework for Session Initiation Protocol (SIP) Session Policies", Gonzalo Camarillo, Jonathan Rosenberg, Volker Hilt, 18-Feb-11, Proxy servers play a central role as an intermediary in the Session Initiation Protocol (SIP) as they define and impact policies on call routing, rendezvous, and other call features. This document specifies a framework for SIP session policies that provides a standard mechanism by which a proxy can define or influence policies on sessions, such as the codecs or media types to be used. It defines a model, an overall architecture and new protocol mechanisms for session policies. SIP Common Log Format (sipclf) ------------------------------ "The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Data Model", Vijay Gurbani, Eric Burger, Tricha Anjali, Humberto Abdelnur, Olivier Festor, 9-Mar-12, Well-known web servers such as Apache and web proxies like Squid support event logging using a common log format. The logs produced using these de-facto standard formats are invaluable to system administrators for trouble-shooting a server and tool writers to craft tools that mine the log files and produce reports and trends. Furthermore, these log files can also be used to train anomaly detection systems and feed events into a security event management system. The Session Initiation Protocol (SIP) does not have a common log format, and as a result, each server supports a distinct log format that makes it unnecessarily complex to produce tools to do trend analysis and security detection. We propose a common log file format for SIP servers that can be used uniformly by user agents, proxies, registrars, redirect servers as well as back-to-back user agents. "Format for the Session Initiation Protocol (SIP) Common Log Format (CLF)", Gonzalo Salgueiro, Vijay Gurbani, Adam Roach, 12-Mar-12, The SIPCLF Workgroup has defined a common log format framework for Session Initiation Protocol (SIP) servers. This common log format mimics the successful event logging format found in well-known web servers like Apache and web proxies like Squid. This document proposes an indexed text encoding format for the SIP Common Log Format (CLF) that retains the key advantages of a text-based format, while significantly increasing processing performance over a purely text-based implementation. This file format adheres to the SIP CLF data model and provides an effective encoding scheme for all mandatory and optional fields that appear in a SIP CLF record. Session Initiation Protocol Core (sipcore) ------------------------------------------ "SIP-Specific Event Notification", Adam Roach, 30-Apr-12, This document describes an extension to the Session Initiation Protocol (SIP) defined by RFC 3261. The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. This document represents a backwards-compatible improvement on the original mechanism described by RFC 3265, taking into account several years of implementation experience. Accordingly, this document obsoletes RFC 3265. This document also updates RFC 4660 slightly to accommodate some small changes to the mechanism that were discussed in that document. "An Extension to the Session Initiation Protocol (SIP) for Request History Information", Mary Barnes, Francois Audet, Shida Schubert, Hans van Elburg, Christer Holmberg, 30-Apr-12, This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a SIP request arrives at a specific application or user. This document defines an optional SIP header field, History-Info, for capturing the history information in requests. The document also defines SIP header field parameters for the History-Info and Contact header fields to tag the method by which the target of a request is determined. In addition, this specification defines a value for the Privacy header field that directs the anonymization of values in the History-Info header field This document obsoletes RFC 4244. "Requirements for indication of features supported by a SIP proxy", Christer Holmberg, Ivo Sedlacek, 5-Dec-11, The Session Initiation Protocol (SIP) "Caller Preferences" extension defined in RFC 3840 provides a mechanism that allows a SIP message to convey information relating to the originator's supported features/ capabilities. This document defines requirements for a mechanism that would allow SIP proxies to convey information relating to the proxy's supported features/capabilities. "Indication of features supported by proxy", Christer Holmberg, Ivo Sedlacek, Hadriel Kaplan, 9-May-12, This specification creates a new IANA registry, "SIP Feature Cap Registry", which is used to register indicators, "SIP feature caps", used by SIP entities to indicate support of features and capabilities, in cases where the Contact header field contains a URI that does not represent the SIP entity that wants to indicate support of its features and capabilities. This specification also defines a new SIP header field, Feature-Caps, that can be used by SIP entities to convey information about supported features and capabilities, using SIP feature caps. "The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)", Inaki Castillo, Jose Millan, Victor Pascual, 5-May-12, 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 SIP (Session Initiation Protocol) entities and enables usage of the SIP protocol in new scenarios. Session Initiation Proposal Investigation (sipping) --------------------------------------------------- "A Session Initiation Protocol (SIP) Event Package for Session-Specific Session Policies.", Gonzalo Camarillo, Volker Hilt, 23-Mar-10, This specification defines a Session Initiation Protocol (SIP) event package for session-specific policies. This event package enables user agents to subscribe to session policies for a SIP session and to receive notifications if these policies change. SIP Recording (siprec) ---------------------- "An Architecture for Media Recording using the Session Initiation Protocol", Andrew Hutton, Leon Portman, Rajnish Jain, Ken Rehor, 12-Mar-12, Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes architectures for deploying session recording solutions in an environment which is based on the Session Initiation Protocol (SIP). "Session Initiation Protocol (SIP) Recording Metadata", Ram R, Parthasarathi Ravindran, Paul Kyzivat, 12-Mar-12, Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes the metadata model as viewed by Session Recording Server(SRS) and the Recording metadata format. "Session Recording Protocol", Leon Portman, Henry Lum, Charles Eckel, Alan Johnston, Andrew Hutton, 9-May-12, This document specifies the use of the Session Initiation Protocol (SIP), the Session Description Protocol (SDP), and the Real Time Protocol (RTP) for delivering real-time media and metadata from a Communication Session (CS) to a recording device. The Session Recording Protocol specifies the use of SIP, SDP, and RTP to establish a Recording Session (RS) between the Session Recording Client (SRC), which is on the path of the CS, and a Session Recording Server (SRS) at the recording device. SIP Overload Control (soc) -------------------------- "Session Initiation Protocol (SIP) Overload Control", Vijay Gurbani, Volker Hilt, Henning Schulzrinne, 12-Mar-12, Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document defines the behaviour of SIP servers involved in overload control, and in addition, it specifies a loss-based overload scheme for SIP. "A Session Initiation Protocol (SIP) Load Control Event Package", Charles Shen, Henning Schulzrinne, Arata Koike, 2-Mar-12, We define a load control event package for the Session Initiation Protocol (SIP). It allows SIP servers to distribute load filters to other SIP servers in the network. The load filters contain rules to throttle calls based on their source or destination domain, telephone number prefix or for a specific user. The mechanism helps to prevent signaling overload and complements feedback-based SIP overload control efforts. "Session Initiation Protocol (SIP) Rate Control", Eric Noel, Philip Williams, 8-Mar-12, The prevalent use of Session Initiation Protocol (SIP) [RFC3261] in Next Generation Networks necessitates that SIP networks provide adequate control mechanisms to maintain transaction throughput by preventing congestion collapse during traffic overloads. Already [draft-ietf-soc-overload-control-07] proposes a loss-based solution to remedy known vulnerabilities of the [RFC3261] SIP 503 (service unavailable) overload control mechanism. This document proposes a rate-based control solution to complement the loss-based control defined in [draft-ietf-soc-overload-control-07]. Softwires (softwire) -------------------- "Gateway Initiated Dual-Stack Lite Deployment", Frank Brockners, Sri Gundavelli, Sebastian Speicher, David Ward, 28-Apr-12, Gateway-Initiated Dual-Stack lite (GI-DS-lite) is a variant of Dual- Stack lite (DS-lite) applicable to certain tunnel-based access architectures. GI-DS-lite extends existing access tunnels beyond the access gateway to an IPv4-IPv4 NAT using softwires with an embedded context identifier that uniquely identifies the end-system the tunneled packets belong to. The access gateway determines which portion of the traffic requires NAT using local policies and sends/ receives this portion to/from this softwire. "RADIUS Attribute for 6rd", Dayong Guo, Sheng Jiang, Remi Despres, Roberta Maglione, 18-Apr-12, IPv6 Rapid Deployment (6rd) is one of the most popular methods to provide both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in Authentication Authorization and Accounting (AAA) servers while user configuration is mainly from Broadband Network Gateway (BNG) through DHC protocol. This document defines a Remote Authentication Dial In User Service (RADIUS) attribute that carries 6rd configuration information from AAA server to BNG. "Public IPv4 over IPv6 Access Network", Yong Cui, Jianping Wu, Peng Wu, Chris Metz, Olivier Vautrin, Yiu Lee, 12-Mar-12, When the service provider networks are upgraded to IPv6, IPv4 connectivity will still be demanded by network users, at least in the recent future. This draft proposes a mechanism for end hosts or networks in IPv6 access networks to build bidirectional IPv4 communication with the IPv4 Internet. The mechanism follows the softwire hub and spoke model, and uses IPv4-over-IPv6 tunnel as basic method to traverse IPv6 network. The bi-directionality of end-to-end communication is achieved by allocating public IPv4 addresses to end hosts/networks. This mechanism is an IPv4 access method for network users in IPv6. "Motivations for Stateless IPv4 over IPv6 Migration Solutions", Gang Chen, Isabel Borges, Mohamed Boucadair, Olaf Bonness, Satoru Matsushima, Yiu Lee, 10-Feb-12, IPv4 service continuity is one of the most pressing problems that must be resolved by Service Providers during the IPv6 transition period - especially after the exhaustion of the public IPv4 address space. Current standardization effort that addresses IPv4 service continuity focuses on stateful mechanisms. This document elaborates on the motivations for the need to undertake a companion effort to specify stateless IPv4 over IPv6 approaches. "Multicast Extensions to DS-Lite Technique in Broadband Deployments", Jacni Qin, Mohamed Boucadair, Christian Jacquenet, Yiu Lee, Qian Wang, 3-May-12, This document specifies a solution for the delivery of multicast service offerings to DS-Lite serviced customers. The proposed solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme and uses the IPv6 multicast distribution tree to deliver IPv4 multicast traffic over an IPv6 multicast-enabled network. "Softwire Mesh Multicast", Mingwei Xu, Yong Cui, Shu Yang, Jianping Wu, Chris Metz, Greg Shepherd, 18-Apr-12, The Internet needs to support IPv4 and IPv6 packets. Both address families and their attendant protocol suites support multicast of the single-source and any-source varieties. As part of the transition to IPv6, there will be scenarios where a backbone network running one IP address family internally (referred to as internal IP or I-IP) will provide transit services to attached client networks running another IP address family (referred to as external IP or E-IP). It is expected that the I-IP backbone will offer unicast and multicast transit services to the client E-IP networks. Softwires Mesh is a solution to E-IP unicast and multicast support across an I-IP backbone. This document describes the mechanisms for supporting Internet-style multicast across a set of E-IP and I-IP networks supporting softwires mesh. "Deployment Considerations for Dual-Stack Lite", Yiu Lee, Roberta Maglione, Carl Williams, Christian Jacquenet, Mohamed Boucadair, 12-Mar-12, This document discusses the deployment issues and describes requirements for the deployment and operation of Dual-Stack Lite. This document describes the various deployment considerations and applicability of the Dual-Stack Lite architecture. "DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes", Mohamed Boucadair, Jacni Qin, Tina Tsou, Xiaohong Deng, 28-Mar-12, This document defines Dynamic Host Configuration Protocol version 6 (DHCPv6) Option for multicast transition solutions, aiming to convey the IPv6 prefixes to be used to build unicast and multicast IPv4- embedded IPv6 addresses. "IPv4 Residual Deployment via IPv6 - a unified Stateless Solution (4rd)", Remi Despres, Reinaldo Penno, Yiu Lee, Gang Chen, Sheng Jiang, 21-May-12, The 4rd automatic tunneling mechanism makes IPv4 Residual Deployment possible via IPv6 networks without maintaining for this per-customer states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment of 6rd). To cope with the IPv4 address shortage, customers can be assigned IPv4 addresses with restricted port sets. In some scenarios, 4rd-capable customer nodes can exchange packets of their IPv4-only applications via stateful NAT64s that are upgraded to support 4rd tunnels (in addition to their IP/ICMP translation of [RFC6145]). Speech Services Control (speechsc) ---------------------------------- "Media Resource Control Protocol Version 2 (MRCPv2)", Daniel Burnett, Saravanan Shanmugham, 15-Nov-11, The MRCPv2 protocol allows client hosts to control media service resources such as speech synthesizers, recognizers, verifiers and identifiers residing in servers on the network. MRCPv2 is not a "stand-alone" protocol - it relies on other protocols, such as Session Initiation Protocol (SIP) to rendezvous MRCPv2 clients and servers and manage sessions between them, and the Session Description Protocol (SDP) to describe, discover and exchange capabilities. It also depends on SIP and SDP to establish the media sessions and associated parameters between the media source or sink and the media server. Once this is done, the MRCPv2 protocol exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server. SPF Update (spfbis) ------------------- "Resolution of The SPF and Sender ID Experiments", Murray Kucherawy, 11-May-12, In 2006 the IETF published a suite of protocol documents comprising SPF and Sender ID, two proposed email authentication protocols. Both of these protocols enable one to publish via the Domain Name System a policy declaring which mail servers were authorized to send email on behalf of the domain name being queried. There was concern that the two would conflict in some significant operational situations, interfering with message delivery. The IESG required the publication of all of these documents (RFC4405, RFC4406, RFC4407, and RFC4408) with Experimental status, and requested that the community observe deployment and operation of the protocols over a period of two years from the date of publication to determine a reasonable path forward. After six years, sufficient experience and evidence have been collected that the experiments thus created can be considered concluded. This document presents those findings. STORage Maintenance (storm) --------------------------- "iSCSI Extensions for RDMA Specification", Mike Ko, Alexander Nezhinsky, 20-May-12, iSCSI Extensions for RDMA provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA- Capable Protocol. This document obsoletes RFC 5046. "Internet Small Computer Systems Interface (iSCSI) SCSI Features Update", Frederick Knight, Mallikarjun Chadalapaka, 13-Dec-11, Internet Small Computer Systems Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. The iSCSI protocol as specified in [draft-ietf-storm- iscsi-cons-xx] (and as previously specified by the combination of RFC 3720 and RFC 5048) is based on the SAM-2 (SCSI Architecture Model - 2) version of the SCSI family of protocols. This document defines enhancements to the iSCSI protocol to support certain additional features of the SCSI protocol that were defined in SAM-3, SAM-4, and SAM-5. This document is a companion document to [draft-ietf-storm- iscsi-cons-xx]. -------------------------------------------------------- RFC EDITORS NOTE: The above references to [draft-ietf-storm- iscsi-cons-xx] should reference the RFC number assigned to that document, and this note should be removed. -------------------------------------------------------- "iSCSI Protocol (Consolidated)", Kalman Meth, Mallikarjun Chadalapaka, Julian Satran, 10-Jan-12, This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI Architecture Model (SAM-2). RFC 3720 defined the original iSCSI protocol. RFC 3721 discusses iSCSI Naming examples and discovery techniques. Subsequently, RFC 3980 added an additional naming format to iSCSI protocol. RFC 4850 followed up by adding a new public extension key to iSCSI. RFC 5048 offered a number of clarifications and a few improvements and corrections to the original iSCSI protocol. This document obsoletes RFCs 3720, 3980, 4850 and 5048 by consolidating them into a single document and making additional updates to the consolidated specification. This document also updates RFC 3721 and RFC 3723. The text in this document thus supersedes the text in all the noted RFCs wherever there is a difference in semantics. "RDMA Protocol Extensions", Hemal Shah, Felix Marti, Wael Noureddine, Asgeir Eiriksson, Robert Sharp, 9-Jan-12, This document specifies extensions to the IETF Remote Direct Memory Access Protocol (RDMAP [RFC5040]). RDMAP provides read and write services directly to applications and enables data to be transferred directly into Upper Layer Protocol (ULP) Buffers without intermediate data copies. The extensions specified in this document provide the following capabilities and/or improvements: Atomic Operations and Immediate Data. "Definitions of Managed Objects for Internet Small Computer System Interface (iSCSI)", Prakash Venkatesen, Mark Bakke, 25-Oct-11, This document defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing a client using the Internet Small Computer System Interface (iSCSI) protocol (SCSI over TCP). This document obsoletes RFC4544. TCP Maintenance and Minor Extensions (tcpm) ------------------------------------------- "TCP Extensions for High Performance", David Borman, Robert Braden, Van Jacobson, Richard Scheffenegger, 18-May-12, This memo presents a set of TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths. It defines TCP options for scaled windows and timestamps, which are designed to provide compatible interworking with TCP's that do not implement the extensions. The timestamps are used for two distinct mechanisms: RTTM (Round Trip Time Measurement) and PAWS (Protection Against Wrapped Sequences). Selective acknowledgments are not included in this memo. This memo updates and obsoletes RFC 1323. "TCP Options and MSS", David Borman, 29-Mar-12, This memo discusses what value to use with the TCP MSS option, and updates RFC 879 and RFC 2385. "Survey of Security Hardening Methods for Transmission Control Protocol (TCP) Implementations", Fernando Gont, 12-Mar-12, This document surveys methods to harden Transmission Control Protocol (TCP) implementations. It provides an overview of known attacks and refers to the corresponding solutions in the TCP standards. "Increasing TCP's Initial Window", Jerry Chu, Nandita Dukkipati, Yuchung Cheng, Matt Mathis, 26-Feb-12, This document proposes an increase in the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large scale experiments showing that the higher initial window improves the overall performance of many web services without risking congestion collapse. The document closes with a discussion of usage and deployment recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group. Terminology "Proportional Rate Reduction for TCP", Matt Mathis, Nandita Dukkipati, Yuchung Cheng, 24-Feb-12, This document describes an experimental algorithm, Proportional Rate Reduction (PPR) to improve the accuracy of the amount of data sent by TCP during loss recovery. Standard Congestion Control requires that TCP and other protocols reduce their congestion window in response to losses. This window reduction naturally occurs in the same round trip as the data retransmissions to repair the losses, and is implemented by choosing not to transmit any data in response to some ACKs arriving from the receiver. Two widely deployed algorithms are used to implement this window reduction: Fast Recovery and Rate Halving. Both algorithms are needlessly fragile under a number of conditions, particularly when there is a burst of losses that such that the number of ACKs returning to the sender is small. Proportional Rate Reduction minimizes these excess window reductions such that at the end of recovery the actual window size will be as close as possible to ssthresh, the window size determined by the congestion control algorithm. It is patterned after Rate Halving, but using the fraction that is appropriate for target window chosen by the congestion control algorithm. "A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP", Ethan Blanton, Mark Allman, Lili Wang, Ilpo Jarvinen, Markku Kojo, Yoshifumi Nishida, 26-Mar-12, This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option. The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 5681), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data. "Shared Use of Experimental TCP Options", Joseph Touch, 17-Jan-12, This document describes how TCP option codepoints can support concurrent experiments. The suggested mechanism avoids the need for a coordinated registry, and is backward-compatible with currently known uses. "TCP Fast Open", Yuchung Cheng, Jerry Chu, Sivasankar Radhakrishnan, Arvind Jain, 17-Feb-12, TCP Fast Open (TFO) allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, thus providing a saving of up to one full round trip time (RTT) compared to standard TCP requiring a three-way handshake (3WHS) to complete before data can be exchanged. Terminology Timing over IP Connection and Transfer of Clock (tictoc) -------------------------------------------------------- "Precision Time Protocol Version 2 (PTPv2) Management Information Base", Greg Dowd, Laurent Montini, Tim Frost, Vinay Shankarkumar, 6-Feb-12, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing networks using Precision Time Protocol. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. "TICTOC Security Requirements", Tal Mizrahi, Karen O'Donoghue, 12-Mar-12, As time synchronization protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing. This document defines a set of requirements for security solutions for time synchronization protocols, focusing on the IEEE 1588 and NTP. This document also discusses the security impacts of time synchronization protocol practices, the time synchronization performance implications of external security practices, the dependencies between other security services and time synchronization. Transport Layer Security (tls) ------------------------------ "Transport Layer Security (TLS) Cached Information Extension", Stefan Santesson, Hannes Tschofenig, 26-Dec-11, Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted Certification Authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate path (including all intermediary certificates up to the trust anchor public key). This document defines an extension that omits the exchange of already available information. The TLS client informs a server of cached information, for example from a previous TLS handshake, allowing the server to omit the already available information. "TLS Out-of-Band Public Key Validation", Paul Wouters, John Gilmore, Samuel Weiler, Tero Kivinen, Hannes Tschofenig, 25-Apr-12, This document specifies a new TLS certificate type for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) for use with out-of-band public key validation. Currently, TLS authentication can only occur via X.509-based Public Key Infrastructure (PKI) or OpenPGP certificates. By specifying a minimum resource for raw public key exchange, implementations can use alternative public key validation methods. One such alternative public key valiation method is offered by the DNS-Based Authentication of Named Entities (DANE) together with DNS Security. Another alternative is to utilize pre-configured keys, as is the case with sensors and other embedded devices. The usage of raw public keys, instead of X.509-based certificates, leads to a smaller code footprint. The support for raw public keys is introduced into TLS via a new non- PKIX certificate type. "The TLS Multiple Certificate Status Request Extension", Yngve Pettersen, 9-May-12, This document defines the Transport Layer Security (TLS) Certificate Status Version 2 Extension to allow clients to specify and support multiple certificate status methods. Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status information not just about the server's own certificate, but also the status of intermediate certificates in the chain. Transparent Interconnection of Lots of Links (trill) ---------------------------------------------------- "RBridges: Campus VLAN and Priority Regions", Radia Perlman, Ayan Banerjee, Anil Rijhsinghani, Donald Eastlake, Dinesh Dutt, 27-Apr-12, Within an RBridge campus, the VLAN and priority of TRILL encapsulated frames is preserved. However, in some cases it may be desired that data VLAN and/or priority be mapped at the boundary between regions of such a campus. This document describes an optional RBridge feature to provide this function. "RBridges: Further TRILL Header Extensions", Donald Eastlake, Anoop Ghanwani, Vishwas Manral, Caitlin Bestler, 2-Dec-11, The TRILL base protocol standard specifies minimal hooks to safely support TRILL Header extensions. Initial extensions have been specified in RFC [ExtendHeader]. This document specifies the format for further such extensions and specifies some further specific extensions. "Definitions of Managed Objects for RBridges (Routing Bridges)", Anil Rijhsinghani, Kate Zebrose, 5-Apr-12, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing an RBridge (Routing Bridge), also known as a TRILL Switch, based on the IETF TRILL (Transparent Interconnection of Lots of Links) protocol. "TRILL: RBridge Channel Support", Donald Eastlake, Vishwas Manral, Li Yizhou, Sam Aldrin, David Ward, 15-May-12, This document specifies a general channel mechanism for sending messages, such as BFD (Bidirectional Forwarding Detection) messages, between RBridges (Routing Bridges) and between RBridges and end stations in an RBridge campus through extensions to the TRILL (TRansparent Interconnection of Lots of Links) protocol. "TRILL: Bidirectional Forwarding Detection (BFD) Support", Vishwas Manral, Donald Eastlake, David Ward, Ayan Banerjee, 10-Apr-12, This document specifies use of the BFD (Bidirectional Forwarding Detection) protocol in RBridge campuses based on the Rbridge Channel extension to the the TRILL (TRansparent Interconnection of Lots of Links) protocol. BFD is a widely deployed OAM (Operations, Administration, and Maintenance) mechanism in IP and MPLS networks, using UDP and ACH encapsulation respectively. This document specifies the BFD encapsulation over TRILL. "Routing Bridges (RBridges): Operations, Administration, and Maintenance (OAM) Support", David Bond, Vishwas Manral, 12-Mar-12, Routing Bridges (RBridges) implement the TRansparent Interconnection of Lots of Links (TRILL) protocol which provide a transparent least- cost frame routing in multi-hop networks with arbitrary topologies, while also inherently providing loop mitigation. As RBridges are deployed in real-world situations, operators will need tools for debugging problems that arise. This document specifies a set of RBridge features for operations, administration, and maintenance (OAM) purposes in RBridge campuses. The features specified in this document include tools for traceroute, ping, and error reporting. "TRILL: Header Extension", Donald Eastlake, Anoop Ghanwani, Vishwas Manral, Li Yizhou, Caitlin Bestler, 2-May-12, The IETF TRILL (Transparent Interconnection of Lots of Links) base protocol specifies minimal hooks to safely support TRILL Header extensions. This document specifies an initial extension providing additional flag bits and specifies two of those bits. "TRILL: Fine-Grained Labeling", Dinesh Dutt, Donald Eastlake, Mingui Zhang, Puneet Agarwal, Radia Perlman, 8-Dec-11, The IETF has standardized TRILL (TRansparent Interconnection of Lots of Links), a protocol for least cost transparent frame routing in multi-hop networks with arbitrary topologies and link technologies, using link-state routing and encapsulation with a hop count. The TRILL base protocol standard supports labeling of TRILL data with up to 4K IDs. However, there are applications that require more fine- grained labeling of data. This document updates RFC 6325 by specifying extensions to the TRILL base protocol to accomplish this. "TRILL: Clarifications, Corrections, and Updates", Donald Eastlake, Mingui Zhang, Anoop Ghanwani, Ayan Banerjee, Vishwas Manral, 8-May-12, The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides least cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to Intermediate System) link state routing and by encapsulating traffic using a header that includes a hop count. Since the TRILL base protocol was approved in March 2010, active development of TRILL has revealed a few errata in the original RFC 6325 and some cases that could use clarifications or updates. RFC 6327 and RFC 6439 provide clarifications and updates with respect to Adjacency and Appointed Forwarders. This document provide other known clarifications, corrections, and updates to RFC 6325, RFC 6327, and RFC 6439. "Coordinated Multicast Trees (CMT)for TRILL", Tissa Senevirathne, Janardhanan Pathangi, Jon Hudson, 17-Apr-12, TRILL facilitates loop free connectivity to non TRILL legacy networks via choice of an Appointed Forwarder for set of VLANs. Appointed Forwarder provides VLAN level load sharing with active- standby model. Mission critical operations such as High Performance Data Centers require active-active load sharing model. Active-Active load sharing model can be accomplished by representing any given non TRILL legacy network with a single virtual RBridge. Virtual representation of the non-TRILL legacy network with a single RBridge poses serious challenges in multi-destination RPF calculations. This document presents the required enhancements to build Coordinated Multicast Trees (CMT) within the TRILL campus to solve related RPF issues. CMT provides flexibility to RBridges to select desired path of association to a given distribution tree. Transport Area Working Group (tsvwg) ------------------------------------ "Byte and Packet Congestion Notification", Bob Briscoe, Jukka Manner, 20-Feb-12, This memo concerns dropping or marking packets using active queue management (AQM) such as random early detection (RED) or pre- congestion notification (PCN). We give three strong recommendations: (1) packet size should be taken into account when transports read and respond to congestion indications, (2) packet size should not be taken into account when network equipment creates congestion signals (marking, dropping), and therefore (3) the byte-mode packet drop variant of the RED AQM algorithm that drops fewer small packets should not be used. "Stream Control Transmission Protocol (SCTP) Network Address Translation Support", Randall Stewart, Michael Tuexen, Irene Ruengeler, 12-Mar-12, 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 (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 the protocol extensions required for the SCTP endpoints to help NAT's provide similar features of NAPT in the single-point and multi-point traversal scenario. "Deprecation of ICMP Source Quench messages", Fernando Gont, 24-Feb-12, This document formally deprecates the use of ICMP Source Quench messages by transport protocols, formally updating RFC 792, RFC 1122, and RFC 1812. "Integrated Services (IntServ) Extension to Allow Signaling of Multiple Traffic Specifications and Multiple Flow Specifications in RSVPv1", James Polk, Subha Dhesikan, 12-Mar-12, This document defines extensions to Integrated Services (IntServ) allowing multiple traffic specifications and multiple flow specifications to be conveyed in the same Resource Reservation Protocol (RSVPv1) reservation message exchange. This ability helps optimize an agreeable bandwidth through a network between endpoints in a single round trip. "UDP Encapsulation of SCTP Packets", Michael Tuexen, Randall Stewart, 11-Mar-12, This document describes a simple method of encapsulating SCTP Packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacy NAT not supporting SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP-layer, for example implementing it as part of the application without requiring special privileges. "Generic Aggregation of Resource ReSerVation Protocol (RSVP) for IPv4 And IPv6 Reservations over PCN domains", Georgios Karagiannis, Anurag Bhargava, 10-Mar-12, This document specifies the extensions to the Generic Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using Pre- Congestion Notification. Uniform Resource Names, Revised (urnbis) ---------------------------------------- "Uniform Resource Name (URN) Syntax", Alfred Hoenes, 11-Mar-12, Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers. This document serves as the foundation of the 'urn' URI Scheme according to RFC 3986 and sets forward the canonical syntax for URNs, which subdivides URNs into "namespaces". A discussion of both existing legacy and new namespaces and requirements for URN presentation and transmission are presented. Finally, there is a discussion of URN equivalence and how to determine it. This document supersedes RFC 2141. The requirements and procedures for URN Namespace registration documents are set forth in BCP 66, for which RFC 3406bis is the companion revised specification document replacing RFC 3406. "Uniform Resource Name (URN) Namespace Definition Mechanisms", Alfred Hoenes, 12-Mar-12, Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers. To structure and organize their usage, the URN syntax (RFC 2141bis) specifies a hierarchy that divides the set of possible URNs into "URN Namespaces" that can be individually defined and managed. URN Namespaces in particular serve to map existing identifier systems into the URN system and thereby make available generic, network-based resolution services for the identified documents, artifacts, and other objects (and metadata related to them). To achive these goals, URN Namespaces need to be specified in a comparable manner, and their Namespace Identifiers (NIDs) need to be registered with IANA, so that naming conflicts are avoided and implementers of services can follow a structured approach in support of various namespaces, guided by the registry to the related documents and the particularities of specific namespaces, as described in these Namespace registration documents. This RFC serves as a guideline for authors of URN Namespace definition and registration documents and the process to be followed to register a URN Namespace with IANA. It describes the essential content of such documents and how they shall be structured to allow readers familar with the scheme to quickly assess the properties of a specific URN Namespace. This document is a companion document to the revised URN Syntax specification, RFC 2141bis; it supersedes and replaces RFC 3406. "Using International Standard Book Numbers as Uniform Resource Names", Maarit Huttunen, Alfred Hoenes, 16-Feb-12, The International Standard Book Number, ISBN, is a widely used identifier for monographic publications. Since 2001, the URN (Uniform Resource Name) namespace "ISBN" has been reserved for ISBNs. The namespace registration was performed in RFC 3187 and applied only to the ISBN as specified in the ISO Standard 2108-1992, now known as "ISBN-10". To allow for further growth in use, the successor ISO Standard, ISO 2108:2005, has defined an expanded format for the ISBN, known as "ISBN-13". This document defines how both of these ISBN standard versions can be supported within the URN framework. Moreover, additional syntax related information required by RFC 2141[bis] has been included. An updated namespace registration is provided. It describes how both the old and the new ISBN format can share the same namespace. This document replaces RFC 3187; it also obsoletes and moves to Historic status the predecessor thereof, RFC 2288. "Using National Bibliography Numbers as Uniform Resource Names", Juna Hakala, Alfred Hoenes, 16-Feb-12, National Bibliography Numbers, NBNs, are widely used by the national libraries and other organizations in order to identify various resources such as digitized monographs. Generally, NBNs may be applied to all kinds of resources that do not have an established (standard) identifier system of their own. A URN (Uniform Resource Names) namespace for NBNs was established in 2001 in RFC 3188. Since then, several European national libraries have implemented URN:NBN-based systems. This document replaces RFC 3188 and defines how NBNs can be supported within the updated URN framework. A revised namespace registration (version 4) is included. "Using International Standard Serial Numbers as Uniform Resource Names", Pierre Godefroy, 5-Mar-12, The International Standard Serial Number, ISSN, has been the authoritative identifier for continuing resources (which include serials) for more than three decades. Since 2001, the URN (Uniform Resource Name) namespace "ISSN" has been reserved for ISSNs. The namespace registration was performed in RFC 3044. This document redefines how the revised ISSN standard can be supported within the URN framework, taking into account in particular the latest revision of the ISSN standard in the ISO framework (ISO 3297:2007). Moreover, additional syntax related information required by the RFC 2141[bis] has been included. An updated namespace registration is provided. This document replaces RFC 3044. IPv6 Operations (v6ops) ----------------------- "IPv6 Multihoming without Network Address Translation", Satoru Matsushima, Tadahisa Okimoto, Ole Troan, David Miles, Dan Wing, 21-Feb-12, Network Address and Port Translation (NAPT) works well for conserving global addresses and addressing multihoming requirements, because an IPv4 NAPT router implements three functions: source address selection, next-hop resolution and optionally DNS resolution. For IPv6 hosts one approach could be the use of NPTv6. However, NAT should be avoided, if at all possible, to permit transparent end-to- end connectivity. In this document, we analyze the use cases of multihoming. We also describe functional requirements and possible solutions for multihoming without the use of NAT in IPv6 for hosts and small IPv6 networks that would otherwise be unable to meet minimum IPv6 allocation criteria. We conclude that DHCPv6 based solutions are suitable to solve the multihoming issues, described in this document, while NPTv6 may be required as an intermediate solution. "Basic Requirements for IPv6 Customer Edge Routers", Hemant Singh, Wes Beebee, Chris Donley, Barbara Stark, 16-May-12, This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers IP transition technologies. Two transition technologies in RFC 5969's 6rd and RFC 6333's DS-Lite are covered in the document. The document obsoletes RFC 6204, if approved. "A Discard Prefix for IPv6", Nick Hilliard, David Freedman, 22-May-12, Remote triggered black hole filtering describes a method of mitigating the effects of denial-of-service attacks by selectively discarding traffic based on source or destination address. Remote triggered black hole routing describes a method of selectively re- routing traffic into a sinkhole router (for further analysis) based on destination address. This document updates RFC5156 by explaining why a unique IPv6 prefix should be formally assigned by IANA for the purpose of facilitating IPv6 remote triggered black hole filtering and routing. "Stateless Source Address Mapping for ICMPv6 Packets", Xing Li, Congxiao Bao, Dan Wing, Ramji Vaithianathan, Geoff Huston, 24-Feb-12, A stateless IPv4/IPv6 translator may receive ICMPv6 packets containing non IPv4-translatable addresses as the source that should be passed across the translator as an ICMP packet directed to the the IPv4-translatable destination. This document discusses the considerations and presents a stateless address mapping algorithm for source address translation in ICMPv6 headers for such cases. "Wireline Incremental IPv6", Victor Kuarsingh, Lee Howard, 22-May-12, Operators worldwide are in various stages of preparing for, or deploying IPv6 into their networks. The operators often face difficult challenges related to both IPv6 introduction along with those related to IPv4 run out. Operators will need to meet the simultaneous needs of IPv6 connectivity and continue support for IPv4 connectivity for legacy devices with a stagnant supply of IPv4 addresses. The IPv6 transition will take most networks from an IPv4- only environment to an IPv6 dominant environment with long transition period varying by operator. This document helps provide a framework for wireline providers who are faced with the challenges of introducing IPv6 along with meeting the legacy needs of IPv4 connectivity utilizing well defined and commercially available IPv6 transition technologies. "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", Fernando Gont, 22-May-12, The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly employed to mitigate attack vectors based on forged ICMPv6 Router Advertisement messages. Many existing IPv6 deployments rely on RA- Guard as the first line of defense against the aforementioned attack vectors. However, some implementations of RA-Guard have been found to be prone to circumvention by employing IPv6 Extension Headers. This document describes the evasion techniques that affect the aforementioned implementations, and formally updates RFC 6105, such that the aforementioned RA-Guard evasion vectors are eliminated. "464XLAT: Combination of Stateful and Stateless Translation", Masataka Mawatari, Masanobu Kawashima, Cameron Byrne, 7-May-12, This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation RFC 6146 in the core and stateless protocol translation RFC 6145 at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to mobile and wireline IPv6-only edge networks without encapsulation. "IPv6 Guidance for Internet Content and Application Service Providers", Brian Carpenter, 18-Apr-12, This document provides guidance and suggestions for Internet Content Providers and Application Service Providers who wish to offer their service to both IPv6 and IPv4 customers. Many of the points will also apply to any enterprise network preparing for IPv6 users. vCard and CardDAV (vcarddav) ---------------------------- "vCard Format extension : represent vCard extensions defined by the Open Mobile Alliance (OMA) Converged Address Book (CAB) group", Dany Cauchie, Barry Leiba, Kepeng Li, 11-May-12, This document defines extensions to the vCard data format for representing and exchanging certain contact information. The properties covered here have been defined by the Open Mobile Alliance Converged Address Book group, in order to synchronize, using OMA Data Synchronization, contact fields that were not already defined in the base vCard 4.0 specification. Web Security (websec) --------------------- "HTTP Strict Transport Security (HSTS)", Jeff Hodges, Collin Jackson, Adam Barth, 17-May-12, This specification defines a mechanism enabling Web sites to declare themselves accessible only via secure connections, and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by Web sites via the Strict-Transport-Security HTTP response header field, and/or by other means, such as user agent configuration, for example. "HTTP Header Frame Options", David Ross, Tobias Gondrom, 5-Mar-12, To improve the protection of web applications against Cross Site Request Forgery (CSRF) and Clickjacking this standards defines a http response header that declares a policy communicated from a host to the client browser whether the transmitted content MUST NOT be displayed in frames of other pages from different origins or a list of trusted origins which are allowed to frame the content. "Public Key Pinning Extension for HTTP", Chris Evans, Chris Palmer, 9-Dec-11, This memo describes an extension to the HTTP protocol allowing web host operators to instruct user agents (UAs) to remember ("pin") the hosts' cryptographic identities for a given period of time. During that time, UAs will require that the host present a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one or more of the pinned fingerprints for that host. By effectively reducing the scope of authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities and other authentication errors and attacks. "HTTP Header X-Frame-Options", David Ross, Tobias Gondrom, 5-Mar-12, To improve the protection of web applications against Cross Site Request Forgery (CSRF) and Clickjacking this standards defines a http response header that declares a policy communicated from a host to the client browser whether the transmitted content MUST NOT be displayed in frames of other pages from different origins or a list of trusted origins which are allowed to frame the content. This drafts serves to document the existing use and specification of X-Frame-Options. Web Extensible Internet Registration Data Service (weirds) ---------------------------------------------------------- "A RESTful Web Service for Domain Name Registration Data (RWS-DNRD)", Steve Sheng, Francisco Arias, Francisco Obispo, Ning Kong, 12-Mar-12, This document specifies a RESTful Web Service for querying Domain Name Registration Data (WHOIS data). The purpose of this document is to facilitate discussion and serve as input into a standards process in this area, currently being discussed on the Worthwhile Extensible Internet Registry Data Service (WEIRDS) mailing list (https://www.ietf.org/mailman/listinfo/weirds). "Requirements For Internet Registry Services", Murray Kucherawy, 2-Apr-12, This document enumerates a base set of requirements to be included in any system that provides registration information for Internet registration entities, i.e., network and/or domain name assignments. Some of these, in turn, will define requirements for registrars; this, however, is an issue outside of the scope of this document. It is hoped that this work will also influence the development of requirements and specifications for domain name registries at some point in the future. "A Uniform RESTful URL Query Pattern for RIRs", Andrew Newton, Kaveh Ranjbar, Arturo Servin, Byron Ellacott, 11-Mar-12, This document describes uniform patterns for which to construct HTTP URLs that may be used to retreive information from Regional Internet Registries (RIRs) using "RESTful" web access patterns. "JSON Responses to RESTful URL Queries for RIRs", Andrew Newton, Kaveh Ranjbar, Arturo Servin, Byron Ellacott, 11-Mar-12, This document describes responses in the JSON format to the RESTful queries described in draft-newton-et-al-weirds-rir-query. "Domain Name Registration Data Access Protocol Query Format", Scott Hollenbeck, Steve Sheng, Francisco Arias, 7-May-12, This document describes a RESTful query format proposal for the Domain Name Registration Data Access Protocol. "Using HTTP for RESTful Whois Services by Internet Registries", Andrew Newton, Kaveh Ranjbar, Arturo Servin, Byron Ellacott, Scott Hollenbeck, Steve Sheng, Francisco Arias, Ning Kong, Francisco Obispo, 10-May-12, This document describes the use of HTTP in Whois services using RESTful web methodologies. Extensible Messaging and Presence Protocol (xmpp) ------------------------------------------------- "Extensible Messaging and Presence Protocol (XMPP): Address Format", Peter Saint-Andre, 14-Apr-12, This document defines the address format for the Extensible Messaging and Presence Protocol (XMPP), including support for code points outside the US-ASCII range. This document obsoletes RFC 6122. Metric Blocks for use with RTCP's Extended Report Framework (xrblock) --------------------------------------------------------------------- "Measurement Identity and information Reporting using SDES item and XR Block", Geoff Hunt, Alan Clark, Wenson Wu, 19-Apr-12, This document defines an RTP Control Protocol (RTCP) Source Description (SDES) item and an RTCP Extended Report (XR) Block carrying parameters that identify and describe a measurement period, to which one or more other RTCP XR Report Blocks may refer. "RTCP XR Report Block for Packet Delay Variation Metric Reporting", Geoff Hunt, Alan Clark, 7-Dec-11, This document defines an RTCP XR Report Block that allows the reporting of Packet Delay Variation metrics for a range of RTP applications. "RTCP XR Report Block for Burst/Gap Discard metric Reporting", Geoff Hunt, Alan Clark, Rachel Huang, Wenson Wu, 18-Apr-12, This document defines an RTCP XR Report Block that allows the reporting of Burst and Gap Discard metrics for use in a range of RTP applications. "RTCP XR Report Block for Burst/Gap Loss metric Reporting", Alan Clark, Geoff Hunt, Jing Zhao, Wenson Wu, Sunshine Zhang, 18-Jan-12, This document defines an RTCP XR Report Block that allows the reporting of Burst and Gap Loss metrics for use in a range of RTP applications. "RTCP XR Report Block for Delay metric Reporting", Geoff Hunt, Alan Clark, Kevin Gross, Wenson Wu, 13-May-12, This document defines an RTCP XR Report Block that allows the reporting of Delay metrics for use in a range of RTP applications. "RTCP XR Report Block for Discard metric Reporting", Geoff Hunt, Alan Clark, Glen Zorn, Wenson Wu, 17-Apr-12, This document defines an RTCP XR Report Block that allows the reporting of a simple discard count metric for use in a range of RTP applications. "Real-time Transport Control Protocol (RTCP) Extension Report (XR) for Run Length Encoding of Discarded Packets", Joerg Ott, Varun Singh, Igor Curcio, 2-Feb-12, The Real-time Transport Control Protocol (RTCP) is used in conjunction with the Real-time Transport Protocol (RTP) in to provide a variety of short-term and long-term reception statistics. The available reporting may include aggregate information across longer periods of time as well as individual packet reporting. This document specifies a per-packet report metric capturing individual packets discarded from the jitter buffer after successful reception. "RTCP XR Blocks for QoE Metric Reporting", Geoff Hunt, Alan Clark, Wenson Wu, Roland Schott, Glen Zorn, 13-May-12, This document defines an RTCP XR Report Block including two new segment types and associated SDP parameters that allow the reporting of QoE metrics for use in a range of RTP applications. "RTCP XR Report Block for Jitter Buffer Metric Reporting", Geoff Hunt, Alan Clark, Varun Singh, Wenson Wu, 9-May-12, This document defines an RTCP XR Report Block that allows the reporting of Jitter Buffer metrics for a range of RTP applications.