"Cisco Systems' Simple Certificate Enrollment Protocol", Andy Nourse, J Vilhuber, 13-Jul-09. ( bytes): This document specifies the Simple Certificate Enrollment Protocol, a PKI communication protocol which leverages existing technology by using PKCS#7 and PKCS#10 over HTTP. SCEP is the evolution of the enrollment protocol developed by VeriSign, Inc. for Cisco Systems, Inc. It now enjoys wide support in both client and CA implementations.
"LDAP Transactions", Kurt Zeilenga, 19-Dec-08. ( bytes): Lightweight Directory Access Protocol (LDAP) update operations, such as Add, Delete, and Modify operations, have atomic, consistency, isolation, durability (ACID) properties. Each of these update operations act upon an entry. It is often desirable to update two or more entries in a single unit of interaction, a transaction. Transactions are necessary to support a number of applications including resource provisioning. This document extends LDAP to support transactions.
"Diversion Indication in SIP", Stuart Levy, Bryan Byerly, John Yang, 28-Jul-09. ( bytes): This document proposes an extension to the Session Initiation Protocol (SIP). This extension provides the ability for the called SIP user agent to identify from whom the call was diverted and why the call was diverted. The extension defines a general header, Diversion, which conveys the diversion information from other SIP user agents and proxies to the called user agent. This extension allows enhanced support for various features, including Unified Messaging, Third-Party Voicemail, and Automatic Call Distribution (ACD). SIP user agents and SIP proxies which receive diversion information may use this as supplemental information for feature invocation decisions.
"Multicast in MPLS/BGP IP VPNs", Yiqun Cai, Eric Rosen, IJsbrand Wijnands, 29-Jun-09. ( bytes): This draft describes the deployed MVPN (Multicast in BGP/MPLS IP VPNs) solution of Cisco Systems.
"Multicast DNS", Stuart Cheshire, Marc Krochmal, 11-Sep-08. ( bytes): As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server, is becoming essential. Multicast DNS (mDNS) provides the ability to do DNS-like operations on the local link in the absence of any conventional unicast DNS server. In addition, mDNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. The primary benefits of mDNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures.
"The "tdb" URI scheme: denoting described resources", Larry Masinter, 12-Jul-09. ( bytes): This document defines a URI scheme, "tdb" ( standing for "Thing Described By"). It provides a semantic hook for allowing anyone at any time to mint a URI for anything that they can describe. Such URIs may include a timestamp to fix the description at a given date or time. This URI scheme may reduce the need to define define new URN namespaces merely for the purpose of creating stable identifiers. In addition, they provide a ready means for identifying "non-information resources" by semantic indirection -- a way of creating a URI for anything. Note This document is not a product of any working group. Many of the ideas here have been discussed since 2001. This document has been discussed on the mailing list . Previous versions have couched "tdb" as a URN namespace, and included a "duri" scheme for fixing date without indirection, which seems unnecessary. It was originally written as a thought experiment as a way of resolving the use/mention problem in semantic web applications, but may have other uses. (This Internet-Draft is also available in PDF format [ bytes].)
"Requirements for Replacing AppleTalk", Stuart Cheshire, Marc Krochmal, 17-Nov-08. ( bytes): One of the goals of the authors of Multicast DNS (mDNS) and DNS-Based Service Discovery (DNS-SD) was the desire to retire AppleTalk and the AppleTalk Name Binding Protocol, and to replace them with an IP-based solution. This document presents a brief overview of the capabilities of AppleTalk NBP, and outlines the properties required of an IP-based replacement.
"Compressed Data within an Internet EDI Message", Terry Harding, 27-Aug-08. ( bytes): This document explains the rules and procedures for utilizing compression (RFC 3274) within an Internet EDI (Electronic Data Interchange) 'AS' message, as defined in RFCs 3335, 4130, and 4823.
"URI Scheme for GSM Short Message Service", Erik Wilde, Antti Vaha-Sipila, 6-Aug-09. ( bytes): This memo specifies the Uniform Resource Identifier (URI) scheme "sms" for specifying one or more recipients for an SMS message. SMS messages are two-way paging messages that can be sent from and received by a mobile phone or a suitably equipped networked device.
"Analysis of Inter-Domain Routing Requirements and History", Elwyn Davies, Avri Doria, 16-Feb-09. ( bytes): This document analyses the state of the Internet domain-based routing system, concentrating on Inter-Domain Routing (IDR) and also considering the relationship between inter-domain and intra-domain routing. The analysis is carried out with respect to RFC 1126 and other IDR requirements and design efforts looking at the routing system as it appeared to be in 2001 with editorial additions reflecting developments up to 2006. It is the companion document to "A Set of Possible Requirements for a Future Routing Architecture" [I-D.irtf-routing-reqs], which is a discussion of requirements for the future routing architecture, addressing systems developments and future routing protocols. This document summarizes discussions held several years ago by members of the IRTF Routing Research Group (IRTF RRG) and other interested parties. The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical concensus of the research group at the date of publication. [Note to RFC Editor: Please replace the reference in the abstract with a non-reference quoting the RFC number of the companion document when it is allocated, i.e., '(RFC xxxx)' and remove this note.]
"An IPv4 Flowlabel Option", Thomas Dreibholz, 5-Jul-09. ( bytes): 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.
"IMAP4 Keyword Registry", Alexey Melnikov, Dave Cridland, 13-Jul-09. ( bytes): The aim of this document is to establishe a new IANA registry for IMAP keywords and to define a procedure for keyword registration, in order to improve interoperability between different IMAP clients.Note A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to morg@ietf.org.
"Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)", Geoffrey Clemm, Jason Crawford, Julian Reschke, Jim Whitehead, 10-Jun-09. ( bytes): This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource. Servers are required to ensure the integrity of any bindings that they allow to be created.
"EAP-Support in Smartcard", Guy Pujolle, Pascal Urien, 6-Aug-09. ( bytes): 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, 5-Jul-09. ( bytes): This document describes the applicability of the Reliable Server Pooling architecture to the IP Flow Information Exchange using the Aggregate Server Access Protocol (ASAP) functionality of RSerPool only. Data exchange in IPFIX between the router and the data collector can be provided by a limited retransmission protocol.
"Prepaid Extensions to Remote Authentication Dial-In User Service (RADIUS)", Avi Lior, Parviz Yegani, Kuntal Chowdhury, Hannes Tschofenig, Andreas Pashalidis, 13-Jul-09. ( bytes): This document specifies an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol that enables service providers to charge for prepaid services. The supported charging models supported are volume-based, duration-based, and based on one-time events.
"Lumas - Language for Universal Message Abstraction and Specification", Peter Cordell, 2-Feb-07. ( bytes): 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.
"Sieve Email Filtering: Include Extension", Cyrus Daboo, Aaron Stone, 9-Mar-09. ( bytes): The Sieve Email Filtering "include" extension permits users to include one Sieve script inside another. This can make managing large scripts or multiple sets of scripts much easier, as well as supporting common 'libraries' of scripts. Users are able to include their own personal scripts or site-wide scripts provided by the local Sieve implementation. Change History (to be removed prior to publication as an RFC) Changes from -05 to -06: a. Aaron Stone joins as author. b. Removed | characters from the script examples. c. Updated draft references to published RFCs. Changes from -04 to -05: a. Fixed examples. b. Relaxed requirement that imported/exported variables be set before being used. Changes from -03 to -04: a. Fixed missing 2119 definitions. b. Defined interaction with variables through use of import and export commands. Changes from -02 to -03: a. Refreshing expired draft (updated for nits). b. Syntax -> Usage. c. Updated to 3028bis reference. Changes from -01 to -02: a. Minor formatting changes only - refreshing expired draft. Changes from -00 to -01: a. Added IPR boiler plate. b. Re-ordered sections at start to conform to RFC style. c. Moved recursion comment into General Considerations section. d. Switched to using optional parameter to indicate personal vs global. e. Explicitly state that an error occurs when a missing script is included.Open Issues (to be resolved prior to publication as an RFC) a. Interaction with variables (scoping). Should variables be carried over between scripts that are included? Or should variables defined in an included script be local to that script only?
"A Set of Possible Requirements for a Future Routing Architecture", Avri Doria, Elwyn Davies, Frank Kastenholz, 16-Feb-09. ( bytes): The requirements for routing architectures described in this document were produced by two sub-groups under the IRTF Routing Research Group in 2001, with some editorial updates up to 2006. The two sub-groups worked independently, and the resulting requirements represent two separate views of the problem and of what is required to fix the problem. This document may usefully serve as part of the recommended reading for anyone who works on routing architecture designs for the Internet in the future. The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical consensus of the research group at the date of publication.
"TTL-Based Security Option for the LDP Hello Message", Enke Chen, Albert Tian, 9-Mar-09. ( bytes): To facilitate the deployment of the TTL-based security mechanism for LDP, in this document we propose a new optional parameter for the LDP Hello Message that can be used by a LSR to indicate its support of the TTL-based mechanism.
"Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment", Sanjib HomChaudhuri, Marco Foschiano, 19-Aug-08. ( bytes): This document describes a mechanism to achieve device isolation through the application of special Layer 2 forwarding constraints. Such mechanism allows end devices to share the same IP subnet while being Layer 2 isolated, which in turn allows network designers to employ larger subnets and so reduce the address management overhead. Some of the numerous deployment scenarios of the aforementioned mechanism (which range from data center designs to Ethernet-to-the- home basement networks) are mentioned in the following to exemplify its possible usages; however, this document is not intended to cover all such deployment scenarios nor delve into their details.
"PATCH Method for HTTP", Lisa Dusseault, James Snell, 13-Apr-09. ( bytes): Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existing HTTP PUT method only allows a complete replacement of a document. This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource.
"Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling", Kireeti Kompella, Bhupesh Kothari, Rao Cherukuri, 13-Jul-09. ( bytes): Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM circuits have been around a long time; more recently, Ethernet VPNs, including Virtual Private LAN Service, have become popular. Traditional L2VPNs often required a separate Service Provider infrastructure for each type, and yet another for the Internet and IP VPNs. In addition, L2VPN provisioning was cumbersome. This document presents a new approach to the problem of offering L2VPN services where the L2VPN customer's experience is virtually identical to that offered by traditional Layer 2 VPNs, but such that a Service Provider can maintain a single network for L2VPNs, IP VPNs and the Internet, as well as a common provisioning methodology for all services.
"IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)", Marc Blanchet, Florent Parent, 6-May-08. ( bytes): A tunnel broker with the Tunnel Setup Protocol (TSP) enables the establishment of tunnels of various inner protocols, such as IPv6 or IPv4, inside various outer protocols packets, such as IPv4, IPv6 or UDP over IPv4 for IPv4 NAT traversal. The control protocol (TSP) is used by the tunnel client to negotiate the tunnel with the broker. A mobile node implementing TSP can be connected to both IPv4 and IPv6 networks whether it is on IPv4 only, IPv4 behind a NAT or on IPv6 only. A tunnel broker may terminate the tunnels on remote tunnel servers or on itself. This document describes the TSP protocol within the model of the tunnel broker model.
"An Extension for EAP-Only Authentication in IKEv2", Pasi Eronen, Hannes Tschofenig, Yaron Sheffer, 6-Apr-09. ( bytes): IKEv2 specifies that EAP authentication must be used together with public key signature based responder authentication. This is necessary with old EAP methods that provide only unilateral authentication using, e.g., one-time passwords or token cards. This document specifies how EAP methods that provide mutual authentication and key agreement can be used to provide extensible responder authentication for IKEv2 based on methods other than public key signatures.
"A QoS Model for Signaling IntServ Controlled-Load Service with NSIS", Cornelia Kappler, Xiaoming Fu, Bernd Schloer, 20-Apr-09. ( bytes): This document describes a QoS Model to signal IntServ controlled load service with QoS NSLP. QoS NSLP is QoS Model agnostic. All QoS Model specific information is carried in an opaque object, the QSPEC. This document hence specifies the QSPEC for controlled load service, how the QSPEC must be processed in QoS NSLP nodes, and how QoS NSLP messages must be used.
"Iowa Internet Annoyance Logging Protocol (IIALP) pronounced E'-alp", Paula Davey, Dan Arthur, George Davey, 17-May-09. ( bytes): This draft describes a system by which Internet Annoyances can be logged quickly and automatically using IIALP (Iowa Internet Annoyance Logging Protocol). The annoyance logs on a particular IIALP Server are condensed and forwarded up the IIALP hierarchy to central Root IIALP Servers for central annoyance queries. Serial numbers and TTL values keep the individual reports organized and dated. One unique complaint per IP per epoch period prevents flooding. Differences in detail and propagation parameters exist between Root and Subordinate IIALP Servers to allow for more detail to be kept at the originating IIALP Server. Standard XML and TCP security techniques, and Hierarchy Structure eliminate erroneous reporting. Routers and software running IIALP can use IIALP to create dynamic QOS lists for abusing Internet assets exceeding a set limits. IIALP allows for an infinite number of different types of annoyances to exist but has concise templates for common annoyances such as SPAM. IIALP is a centralized logging system for Internet annoyance event reporting.
"DNS Blacklists and Whitelists", John Levine, 17-Nov-08. ( bytes): The rise of spam and other anti-social behavior on the Internet has led to the creation of shared blacklists and whitelists of IP addresses or domains. The DNS has become the de-facto standard method of distributing these blacklists and whitelists. This memo documents the structure and usage of DNS based blacklists and whitelists, and the protocol used to query them. IRTF Notice This document is a product of the Anti-Spam Research Group (ASRG) of the Internet Research Task Force. It represents the consensus of the ASRG with respect to practices to improve interoperability of DNS based blacklists and whitelists, but does not constitute an IETF or Internet standard. [NOTE TO RFC EDITOR: Please remove this paragraph in publication.] Comments and discussion may be directed to the ASRG mailing list, asrg@irtf.org.
"Light Weight Access Point Protocol", Pat Calhoun, 2-Mar-07. ( bytes): In the recent years, there has been a shift in wireless LAN product architectures from autonomous access points to centralized control of light weight access points. The general goal has been to move most of the traditional wireless functionality such as access control (user authentication and authorization), mobility and radio management out of the access point into a centralized controller. The IETF's CAPWAP WG has identified that a standards based protocol is necessary between a wireless Access Controller and Wireless Termination Points (the latter are also commonly referred to as Light Weight Access Points). This specification defines the Light Weight Access Point Protocol (LWAPP), which addresses the CAPWAP's protocol requirements. Although the LWAPP protocol is designed to be flexible enough to be used for a variety of wireless technologies, this specific document describes the base protocol, and an extension that allows it to be used with the IEEE's 802.11 wireless LAN protocol.
"Nested Nemo Tree Discovery", Pascal Thubert, 29-Jun-09. ( bytes): This paper describes a simple distance vector protocol that exposes only a default route towards the infrastructure in a nested NEMO configuration. The draft extends the Neighbor Discovery Protocol [RFC4861] in order to carry information and metrics which will help a Mobile Router select its Attachment Router(s) in an autonomous fashion and provides generic rules which guarantee that the interaction of different selection processes will not create loops.
"IP Fast Reroute using tunnels", Stewart Bryant, Clarence Filsfils, Stefano Previdi, Mike Shand, 16-Nov-07. ( bytes): This draft describes an IP fast re-route mechanism that provides backup connectivity in the event of a link or router failure. In the absence of single points of failure and asymmetric costs, the mechanism provides complete protection against any single failure. If perfect repair is not possible, the identity of all the unprotected links and routers is known in advance. This IP Fast Reroute advanced method was invented in 2002 and draft (draft-bryant-ipfrr-tunnels-00.txt) describing it was submitted to the IETF in May 2004. It was one of the first methods of achieving full repair coverage in an IP Network, and as such the draft has been widely referenced in the academic literature. The authors DO NOT propose that this IPFRR method be implemented since better IPFRR advanced method capable of achieving full repair coverage have subsequently been invented.
"DISCOVER: Supporting Multicast DNS Queries", Bill Manning, Paul Vixie, 17-Nov-05. ( bytes): This document describes the DISCOVER opcode, an experimental extension to the Domain Name System (DNS) to use multicast queries for resource discovery. A client multicasts a DNS query using the DISCOVER opcode and processes the multiple responses that may result.
"The case against Hop-by-Hop options", Suresh Krishnan, 14-Jul-09. ( bytes): The Hop-by-Hop option header is a type of IPv6 extension header that has been defined in the IPv6 protocol specification. The contents of this header need to be processed by every node along the path of an IPv6 datagram.This draft highlights the characteristics of this extension header which make it prone to Denial of Service attacks and proposes solutions to minimize such attacks.
"Vendor Specific RADIUS Attributes for the Delivery of Keying Material", Glen Zorn, Tiebing Zhang, Jesse Walker, Joseph Salowey, 6-Mar-09. ( bytes): This document defines a set of RADIUS Attributes designed to allow both the secure transmission of cryptographic keying material and strong authentication of any RADIUS message.
"SDP Descriptors for FLUTE", Harsh Mehta, 30-Jan-06. ( bytes): 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.
"XML Media Types", Murata Makoto, Dan Kohn, Chris Lilley, 31-Jul-09. ( bytes): This document standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while deprecating text/xml and text/ xml-external-parsed-entity. This document also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME entities. XML MIME entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains. Major differences from [RFC3023] are deprecation of text/xml and text/xml-external-parsed-entity, the addition of XPointer and XML Base as fragment identifiers and base URIs, respectively, mention of the XPointer Registry, and updating of many references.
"HIP Experiment Report", Tom Henderson, Andrei Gurtov, 8-Mar-09. ( bytes): This document is a report from the IRTF HIP research group documenting the collective experiences and lessons learned from studies, related experimentation, and designs completed by the research group. The documents summarizes implications of adding HIP to host protocol stacks, Internet infrastructure, and applications. The perspective of a network operator, as well as a list of HIP experiments, are presented as well.
"Robust Header Compression (ROHC) over 802 networks", Carsten Bormann, 13-Jul-09. ( bytes): Various proposals have been submitted to the ROHC working group for enabling the use of ROHC [RFC3095] header compression over Ethernet, 802.11 and other 802-based links. Previous proposals generally suffered from a lack of systems perspective on 802 networks. The present document attempts to supply some systems perspective and provides a rough outline for a solution. This is a submission to the IETF ROHC WG. Please direct discussion to its mailing list, rohc@ietf.org $Revision: 1.9 $
"Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs", Joseph Touch, 8-Jul-08. ( bytes): This document describes the properties and use of a revised Microsoft Word template (.dot) for writing Internet Drafts and RFCs. It updates the initial template described in RFC 3285 to more fully support Word's outline modes and to be easier to use. This template can be direct-printed and direct-viewed, where either is line-for-line identical with RFC Editor-compliant ASCII output. This version is intended as an update to RFC3285. The most recent version of this template and post-processing scripts are available at http://www.isi.edu/touch/tools
"Certificate Exchange Messaging for EDIINT", Kyle Meadors, Dale Moberg, 14-Apr-09. ( bytes): 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).
"VoIP Configuration Server Address Option", Richard Johnson, 6-Jan-09. ( bytes): This memo documents existing usage for the "VoIP Configuration Server Address Option" (previously known as the "TFTP Server IP Address Option"). The option number currently in use is 150. This memo documents the current usage of the option in agreement with RFC 3942 [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.
"Session Initiation Protocol (SIP) Session Mobility", Ron Shacham, Henning Schulzrinne, Srisakul Thakolsri, Wolfgang Kellerer, 18-Nov-07. ( bytes): Session mobility is the transfer of media of an ongoing communication session from one device to another. This document describes the basic approaches and shows the signaling and media flow examples for providing this service using the Session Initiation Protocol (SIP). Service discovery is essential to locate targets for session transfer and is discussed using the Service Location Protocol (SLP) as an example. This document is intended as an informational document.
"The 'mailto' URI Scheme", Martin Duerst, Larry Masinter, Jamie Zawinski, 9-Mar-09. ( bytes): This document defines the format of Uniform Resource Identifiers (URI) to identify resources that are reached using Internet mail. It adds better internationalization and compatibility with IRIs (RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368).
"SDP and RTSP extensions defined for 3GPP Packet-switched Streaming Service and Multimedia Broadcast/Multicast Service", Magnus Westerlund, Per Frojdh, 8-May-09. ( bytes): The Packet-switched Streaming Service (PSS) and the Multimedia Broadcast/Multicast Service (MBMS) defined by 3GPP use SDP and RTSP with some extensions. This document provides information about these extensions and registers the RTSP and SDP extensions with IANA.
"Unintended Consequence of two NAT deployments with Overlapping Address Space", Pyda Srisuresh, Bryan Ford, 23-Mar-09. ( bytes): This document identifies two deployment scenarios that have arisen from the unconventional network topologies formed using Network Address Translator devices (NATs). First, the simplicity of administering networks through the combination of NAT and DHCP has increasingly lead to the deployment of multi-level inter-connected private networks involving overlapping private IP address spaces. Second, the proliferation of private networks in enterprises, hotels and conferences, and the wide spread use of Virtual Private Networks (VPNs) to access enterprise intranet from remote locations has increasingly lead to overlapping private IP address space between remote and corporate networks. The document does not dismiss these unconventional scenarios as invalid, but recognizes them as real and offers recommendations to help ensure these deployments can function without a meltdown.
"Wireless LAN Control Protocol (WiCoP)", Satoshi Iino, 7-Feb-07. ( bytes): The popularity of wireless local area networks (WLANs) has led to wide spread deployments across different establishments. It has also translated in to increasing scale of the WLANs. Large-scale deployments made of large numbers of wireless termination points (WTPs) and covering substantial areas are increasingly common. The Wireless LAN Control Protocol (WiCoP) described in this document allows for the control and provisioning of large-scale WLANs. It enables central management of these networks and realizes the objectives set forth for the control and provisioning of wireless access points (CAPWAP).
"SLAPP : Secure Light Access Point Protocol", Partha Narasimhan, 27-Mar-06. ( bytes): The CAPWAP problem statement [3] describes a problem that needs to be addressed before a wireless LAN (WLAN) network designer can construct a solution composed of Wireless Termination Points (WTP) and Access Controllers (AC) from multiple, different vendors. One of the primary goals is to find a solution that solves the interoperability between the two classes of devices (WTPs and ACs) which then enables an AC from one vendor to control and manage a WTP from another.
"An Extensible Format for Email Feedback Reports", Yakov Shafranovich, John Levine, Murray Kucherawy, 17-Apr-09. ( bytes): This document defines an extensible format and MIME type that may be used by network operators to report feedback about received email to other parties. This format is intended as a machine-readable replacement for various existing report formats currently used in Internet email.
"The 'news' and 'nntp' URI Schemes", Frank Ellermann, 2-Apr-08. ( bytes): This memo specifies the 'news' and 'nntp' Uniform Resource Identifier (URI) schemes that were originally defined in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about these schemes on standards track.
"CalDAV Scheduling Extensions to WebDAV", Cyrus Daboo, Bernard Desruisseaux, 19-Jun-09. ( bytes): This document defines extensions to the CalDAV "calendar-access" feature to specify a standard way of performing scheduling transactions with iCalendar-based calendar components. This document defines the "calendar-auto-schedule" feature of CalDAV. (This Internet-Draft is also available in PDF format [ bytes].)
"Bundle Security Protocol Specification", Susan Symington, Stephen Farrell, Howard Weiss, Peter Lovell, 23-Mar-09. ( bytes): This document defines the bundle security protocol, which provides data integrity and confidentiality services. We also describe various bundle security considerations including policy options.
"Distributing Address Selection Policy using DHCPv6", Tomohiro Fujisaki, Arifumi Matsumoto, Shirou Niinobe, Ruri Hiromi, Ken-ichi Kanayama, 9-Mar-09. ( bytes): This document describes a new DHCPv6 option for distributing address selection policy information defined in RFC3484 to a client. With this option, site administrators can distribute address selection policy to control the node's address selection behavior.
"Using non-ASCII Characters in RFCs", Xiaodong Faltstrom, Paul Hoffman, Tim Bray, 14-Apr-09. ( bytes): This document specifies a change to the IETF process in which Internet Drafts and RFCs are allowed to contain non-ASCII characters. The proposed change is to change the encoding of Internet Drafts and RFCs to UTF-8 when non-ASCII characters are needed.
"Applicability of Reliable Server Pooling for Real-Time Distributed Computing", Thomas Dreibholz, 5-Jul-09. ( bytes): This document describes the applicability of the Reliable Server Pooling architecture to manage real-time distributed computing pools and access the resources of such pools.
"RADIUS Attributes for IEEE 802 Networks", Bernard Aboba, Jouni Malinen, Paul Congdon, Joseph Salowey, 29-Apr-09. ( bytes): 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. The attributes defined in this document are usable both within RADIUS and Diameter.
"Secure SCTP", Carsten Hohendorf, Esbold Unurkhaan, Thomas Dreibholz, 7-Jul-09. ( bytes): 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. ( bytes): 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, 24-Apr-09. ( bytes): 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.
"EDI-INT Features Header", Kyle Meadors, 1-Oct-08. ( bytes): With the maturity of the EDI-INT standard of AS1, AS2 and AS3, applications and additional features are being built upon the basic secure transport functionality. These features are not necessarily supported by all EDI-INT applications and could cause potential problems with implementations.
"Extended Optional Parameters Length for BGP OPEN Message", Enke Chen, John Scudder, 25-Jun-09. ( bytes): The Optional Parameters in the BGP OPEN message as defined in the base BGP specification are limited to 255 octets due to a one-octet length field. BGP Capabilities are carried in this field and may foreseeably exceed 255 octets in the future, leading to concern about this limitation. In this document we extend the BGP OPEN length field in a backward- compatible manner. The Parameter Length field of individual Optional Parameters is similarly extended.
"HIP DHT Interface", Jeff Ahrenholz, 9-Mar-09. ( bytes): This document specifies a common interface for using HIP with a Distributed Hash Table service to provide a HIT-to-address lookup service and an unmanaged name-to-HIT lookup service.
"Enhanced Fast Handover for Mobile IPv6 based on IEEE 802.11 Network", Youngsong Mun, 20-Feb-09. ( bytes): In MIPv6 [1], whenever a mobile node changes its attached point, handover process should be followed to inform its home agent and correspondent of a MN's current location. The handover process is decomposed into layer 2 and layer 3 handovers again, and these two handovers are accomplished sequentially, which causes long latency problem. This problem is a critical issue in MIPv6. To make up for this, we propose an enhanced Fast Handover scheme to reduce the overall latency on handover, revising the Fast Handover [2]. Especially, several messages in layer 3 are sent in one frame during layer 2 handover.
"Delay-Tolerant Networking Security Overview", Stephen Farrell, Susan Symington, Howard Weiss, Peter Lovell, 8-Mar-09. ( bytes): This document provides an overview of the security requirements and mechanisms considered for delay tolerant networking security. It discusses the options for protecting such networks and describes reasons why specific security mechanisms were (or were not) chosen for the relevant protocols. The entire document is informative, given its purpose is mainly to document design decisions.
"GRE Key Extension for Mobile IPv4", Parviz Yegani, Gopal Dommety, Avi Lior, Kuntal Chowdhury, Jay Navali, 28-Jul-09. ( bytes): The GRE specification contains a Key field, which MAY contain a value that is used to identify a particular GRE data stream. This specification defines a new Mobile IP extension that is used to exchange the value to be used in the GRE Key field. This extension further allows the Mobility Agents to setup the necessary protocol interfaces prior to receiving the mobile's traffic. The new extension option allows a foreign agent to request GRE tunneling without disturbing the Home Agent behavior specified for Mobile Ipv4. GRE tunneling provides an advantage that allows operator's private home networks to be overlaid and allows the HA to provide overlapping home addresses to different subscribers. When the tuple < Care of Address, Home Address and Home Agent Address > is the same across multiple subscriber sessions, GRE tunneling will provide a means for the FA and HA to identify data streams for the individual sessions based on the GRE key. In the absence of this key identifier, the data streams cannot be distinguished from each other, a significant drawback when using IP-in-IP tunneling.
"MTLS: (D)TLS Multiplexing", Mohamad Badra, Ibrahim Hajjeh, 21-Apr-09. ( bytes): The (Datagram) Transport Layer Security ((D)TLS) standard provides connection security with mutual authentication, data confidentiality and integrity, key generation and distribution, and security parameters negotiation. However, missing from the protocol is a way to multiplex several application data over a single (D)TLS. This document defines MTLS, an application-level protocol running over (D)TLS Record protocol. The MTLS design provides application multiplexing over a single (D)TLS session. Therefore, instead of associating a (D)TLS session with each application, MTLS allows several applications to protect their exchanges over a single (D)TLS session.
"Password-Authenticated Diffie-Hellman Exchange (PAK)", Igor Faynberg, Sarvar Patel, Zachary Zeltsan, Alec Brusilovsky, 10-Apr-09. ( bytes): This document proposes to add mutual authentication, based on human-memorizable password, to the basic unauthenticated Diffie-Hellman key exchange. The proposed algorithm is called Password-authenticated Key exchange (PAK). PAK allows two parties to authenticate themselves while performing the Diffie-Hellman exchange. The protocol is secure against all passive and active attacks. In particular, it does not allow either type of attackers to obtain any information that would enable an off-line dictionary attack on the password. PAK provides Forward Secrecy.
"Re-ECN: Adding Accountability for Causing Congestion to TCP/IP", Bob Briscoe, Arnaud Jacquet, T Moncaster, Alan Smith, 3-Mar-09. ( bytes): This document introduces a new protocol for explicit congestion notification (ECN), termed re-ECN, which can be deployed incrementally around unmodified routers. 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. 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 correctly to congestion,and these are described more fully in a companion document [re-ecn-motive]. Authors' Statement: Status (to be removed by the RFC Editor) Although the re-ECN protocol is intended to make a simple but far- reaching change to the Internet architecture, the most immediate priority for the authors is to delay any move of the ECN nonce to Proposed Standard status. The argument for this position is developed in Appendix E. Changes from previous drafts (to be removed by the RFC Editor) Full diffs created using the rfcdiff tool are available at From -06 to -07 (current version): Major changes made following splitting this protocol document from the related motivations document [re-ecn-motive]. Significant re-ordering of remaining text. New terminology introduced for clarity. Minor editorial changes throughout.
"IAX: Inter-Asterisk eXchange Version 2", Mark Spencer, Brian Capouch, Ed Guy, Frank Miller, Kenneth Shumard, 5-Oct-08. ( bytes): This document describes IAX, the Inter-Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for the Asterisk PBX and is targeted primarily at Voice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia. IAX is an "all in one" protocol for handling multimedia in IP networks. It combines both control and media services in the same protocol. In addition, IAX uses a single UDP data stream on a static port greatly simplifying Network Address Translation (NAT) gateway traversal, eliminating the need for other protocols to work around NAT, and simplifying network and firewall management. IAX employs a compact encoding which decreases bandwidth usage and is well suited for Internet telephony service. In addition, its open nature permits new payload types additions needed to support additional services.
"IPv6 over Low Power WPAN Security Analysis", Soohong Daniel Park, Ki-Hyung Kim, Wassim Haddad, Samita Chakrabarti, Julien Laganier, 13-Jul-09. ( bytes): This document discusses possible threats and security options for IPv6-over-IEEE802.15.4 networks. Its goal is to raise awareness about security issues in IPv6 lowPan networks.
"The Atom "deleted-entry" Element", James Snell, 8-Jun-09. ( bytes): This specification adds mechanisms to the Atom Syndication Format which Atom Feed publishers can use to explicitly identify Atom entries that have been removed from an Atom feed.
"Extending ICMP for Interface and Next-hop Identification", Ronald Bonica, Carlos Pignataro, Cisco Systems, Naiming Shen, 3-Aug-09. ( bytes): This memo defines a data structure that can be appended to selected ICMP messages. The ICMP extension defined herein can be used identify any combination of the following: the IP interface upon which a datagram arrived, the sub-IP component of an IP interface upon which a datagram arrived, the IP interface through which the datagram would have been for forwarded had it been forwardable, the IP next hop to which the datagram would have been forwarded. Devices can use this ICMP extension to identify interfaces and their components by any combination of the following: ifIndex, IPv4 address, IPv6 address, name and MTU. ICMP-aware devices can use these extensions to identify both numbered and unnumbered interfaces.
"OCRA: OATH Challenge-Response Algorithms", David M'Raihi, Salah Machani, Johan Rydell, David Naccache, Siddharth Bajaj, 9-Jul-09. ( bytes): This document describes the OATH algorithm for challenge-response authentication and signatures. This algorithm is based on the HOTP algorithm [RFC4226] that was introduced by OATH (initiative for Open AuTHentication) [OATH] and submitted as an individual draft to the IETF in 2006.
"Private Extensions to the Session Initiation Protocol (SIP) for Service Interaction Indicator", Yuzhong Shen, 6-Apr-09. ( bytes): In SIP-based networks, a SIP session MAY involve several application servers on the originating and terminating side. In a certain case, an application server needs to set some indications in SIP message to indicate service information (what are invoked, what can be allowed and what should blocked). This kind of information will be also required for composition of SIP applications. There is a need to provide indicators for service interaction between SIP application servers or other SIP endpoints. This document describes a mechanism of service interaction indicator for the Session Initiation Protocol (SIP) that enhances service interaction between SIP application servers in a trusted network.
"The "pack" URI Scheme", Andrey Shur, Jerry Dunietz, 17-Feb-09. ( bytes): 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.
"Transport Layer Security (TLS) Authorization Extensions", Mark Brown, Russ Housley, 10-Sep-07. ( bytes): This document specifies authorization extensions to the Transport Layer Security (TLS) Handshake Protocol. Extensions carried in the client and server hello messages to confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, authorization information is exchanged in the supplemental data handshake message.
"Accounting on Softwires", Bruno Stevant, Laurent Toutain, Francis Dupont, David Binet, 20-Apr-09. ( bytes): For access network operators, accounting information are crucial: they provide information for billing and give an overview of the traffic usage. This document defines the requirements for accounting information needed on Softwires.1. Motivation The Softwires WG is working on a solution to bring IPvX connectivity over an IPvY network [RFC4925]. This solution may be deployed and managed by access network operators to provide for example IPvX continuity of service. Operators should then consider the Softwires solution as an extension of their access network service. For operators, AAA [RFC2865] is the key feature for access network deployment: Authentication verifies user credentials, Authorization ensures access network integrity and Accounting provides information for billing and network management. Information from accounting usually includes measurements of in and out octets and packets [RFC2867]. As an alternative access network, the Softwires solution should provide similar AAA features. For instance accounting on the softwire should gives to the operator measurements of the traffic generated by the user using this access network. In a dual stack (IPvX and IPvY) network, the operator may want to manage information about the comparative usage of both protocols, for example for billing purpose. When the softwire is used to access IPvX over IPvY, accounting information will be specific to IPvX. Operators should be able to differentiate for which version of IP such information are relevant. This differentiation may become important if such operators offer a softwire solution for both IPvX over IPvY and IPvY over IPvX access networks.2. Study case In this section is given an example of IPv6 access over IPv4 network which is similar to the Hub-and-Spokes problem stated in the Softwires WG ([RFC4925]). The Point6box architecture uses L2TP [RFC2661] and PPP for IPv6 tunneling over IPv4 (see Figure 1). Radius manages AAA parameters for the access network created by the tunnel. On the server side, PPP sends to RADIUS accounting information measuring the traffic generated by the customer. /---------------------------\ CPEv6 | +--------------+ | DHCPv6 +-----+ | /....>| DHCPv6 relay |<........................>| P | | . +--------------+ | CPEv4 | o | | | . | L2TP IPv6 | | L2TP +-----+ | i | |-- X | . | server |=======================b=== n B | | | v +--------------+ | @@ @@ | r| | t o | | | +--------+ ^ | @ @@ @ | N i|-| 6 x | |-- Y | | DHCPv6 | | |--@ IPv4 @------| A d| +-----+ | | | server | | | @ @@ @ | T g| | | +--------+ | | @@ @@ PEv4 | e|----------| \-------------|-------------/ +-----+ RA-> |-- Z | PEv6 | +--------+ | clients | RADIUS | | RADIUS | server |<-/ +--------+ IPv4/v6 ISP Customer Figure 1: Point6Box Service Architecture3. Problem statement The accounting information defined for tunnels [RFC2867] includes attributes Acct-{Input,Output}-Octets and Acct-{Input,Output}-Packets for traffic measurements. These attributes do not depend of the version of IP used by the monitored traffic. Operators may not be able to differenciate IPv4 from IPv6 traffic in their accounting statistics. This non-differentiation even leads to mis-usages: In the current PPP implementation from BSD, the values of these attributes are only based on IPv4 statistics collected from IPCP protocol. No statistics are collected for IPv6 from IPV6CP. This proposal should decide which attributes may be candidate for IP- version differentiation. In operating system MIBs, values for in/out octets on a network interface are independent of the IP version. Having such values for each version may be usefull for monitoring and billing purpose. However the differentiation is done for in/out IPv4 and IPv6 packets on a network interface. Operators can extract from these values some hints about the usage of each version of the IP protocol but can not give quantitative report of bandwidth usage.
"Encrypted Key Transport for Secure RTP", David McGrew, Flemming Andreasen, Dan Wing, Lakshminath Dondeti, 12-Jul-09. ( bytes): SRTP Encrypted Key Transport (EKT) is an extension to SRTP that provides for the secure transport of SRTP master keys, Rollover Counters, and other information, within SRTCP. This facility enables SRTP to work for decentralized conferences with minimal control, and to handle situations caused by SIP forking and early media.
"4over6 Transit Solution using IP Encapsulation and MP-BGP Extensions", Jianping Wu, Yong Cui, Xing Li, Mingwei Xu, Chris Metz, 14-Apr-09. ( bytes): The emerging and growing deployment of IPv6 networks, in particular IPv6 backbone networks, will introduce cases where connectivity with IPv4 networks is desired. In one such case, an Internet Service Provider (ISP) operating an IPv6 backbone network will accomodate connectivity and offer transit services for attached legacy IPv4 networks and applications. This is accomplished through the use of IPv4-over-IPv6 (4over6) tunnels established between dual-stack IPv4/ IPv6 edge routers. Along with the growth of IPv6 backbones networks and the corresponding increase in the number of attached IPv4 networks, the complexity of the interconnection tunnel topology will severely increase to support the IPv4 transit service across the backbone. The manual configuration mechanism for a potentially large number of IPv4-over-IPv6 tunnels will cause an insufferable operational burden. This document addresses this problem and presents a mechanism for the automatic discovery and creation of 4over6 tunnels employing multi-protocol BGP extensions. The mechanisms described in this document have been implemented, tested and deployed on the CNGI-CERNET2 IPv6 testbed.
"WiMAX Forum/3GPP2 Proxy Mobile IPv4", Kent Leung, 1-Dec-08. ( bytes): Mobile IPv4 is a standard mobility protocol that enables IPv4 device to move among networks while maintaining its IP address. The mobile device has the Mobile IPv4 client function to signal its location to the routing anchor, known as the Home Agent. However, there are many IPv4 devices without such capability due to various reasons. This document describes Proxy Mobile IPv4 (PMIPv4), a scheme based on having the Mobile IPv4 client function in a network entity to provide mobility support for an unaltered and mobility-unaware IPv4 device. This document also describes a particular application of PMIPv4 as specified in the WiMAX Forum and another application that is to be adopted in 3GPP2
"Media Server Markup Language (MSML)", Adnan Saleem, Garland Sharratt, 28-Jul-09. ( bytes): The Media Server Markup Language (MSML) is used to control and invoke many different types of services on IP Media Servers. The MSML control interface was initially driven by Radisys with subsequent significant contributions from Intel, Dialogic, and others in the industry. Clients can use it to define how multimedia sessions interact on a Media Server and to apply services to individuals or groups of users. MSML can be used, for example, to control Media Server conferencing features such as video layout and audio mixing, create sidebar conferences or personal mixes, and set the properties of media streams. As well, clients can use MSML to define media processing dialogs, which may be used as parts of application interactions with users or conferences. Transformation of media streams to and from users or conferences as well as IVR dialogs are examples of such interactions, which are specified using MSML. MSML clients may also invoke dialogs with individual users or with groups of conference participants using VoiceXML.
"Mobile IPv6 Location Privacy Solutions", QIU Ying, Fan Zhao, Rajeev Koodli, 8-Jul-09. ( bytes): Mobile IPv6 (RFC 3775) enables a mobile node to remain reachable while it roams on the Internet. However, the location and movement of the mobile node can be revealed by the IP addresses used in signaling or data packets. In this document, we consider the Mobile IPv6 location privacy problem described in RFC 4882, and propose efficient and secure techniques to protect location privacy of the mobile node. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group.
"Enhanced validation of domains for HTTP State Management Cookies using DNS", Yngve Pettersen, 21-Jun-09. ( bytes): HTTP State Management Cookies are used for a wide variety of tasks on the Internet, from preference handling to user identification. An important privacy and security feature of cookies is that their information can only be sent to a servers in a limited namespace, the domain. The variation of domain structures that are in use by domain name registries, especially the country code Top Level Domains (ccTLD) namespaces, makes it difficult to determine what is a valid domain, e.g. example.co.uk and example.no, which cookies should be permitted for, and a registry-like domain (subTLDs) like co.uk where cookies should not be permitted. This document specifies an imperfect method using DNS name lookups for cookie domains to determine if cookies can be permitted for that domain, based on the assumption that most subTLD domains will not have an IP address assigned to them, while most legitimate services that share cookies among multiple servers will have an IP address for their domain name to make the user's navigation easier by omitting the customary "www" prefix.
"The TLD Subdomain Structure Protocol and its use for Cookie domain validation", Yngve Pettersen, 21-Jun-09. ( bytes): This document defines a protocol and specification format that can be used by a client to discover how a Top Level Domain (TLD) is organized in terms of what subdomains are used to place closely related but independent domains, e.g. commercial domains in country code TLDs (ccTLD) like .uk are placed in the .co.uk subTLD domain. This information is then used to limit which domains an Internet service can set cookies for, strengthening the rules already defined by the cookie specifications.
"ZRTP: Media Path Key Agreement for Secure RTP", Philip Zimmermann, Alan Johnston, Jon Callas, 4-Mar-09. ( bytes): This document defines ZRTP, a protocol for media path Diffie-Hellman exchange to agree on a session key and parameters for establishing Secure Real-time Transport Protocol (SRTP) sessions. The ZRTP protocol is media path keying because it is multiplexed on the same port as RTP and does not require support in the signaling protocol. ZRTP does not assume a Public Key Infrastructure (PKI) or require the complexity of certificates in end devices. For the media session, ZRTP provides confidentiality, protection against man-in-the-middle (MiTM) attacks, and, in cases where the signaling protocol provides end-to-end integrity protection, authentication. ZRTP can utilize a Session Description Protocol (SDP) attribute to provide discovery and authentication through the signaling channel. To provide best effort SRTP, ZRTP utilizes normal RTP/AVP profiles.
"A New Forking Mechanism for Session Initiation Protocol (SIP)", Dale Worley, 3-Mar-09. ( bytes): The rules for SIP proxies are organized so that when a UAC sends an out-of-dialog request, even if the request is forked to a number of UASs, (usually) only one UAS will accept the request, and only the final response from that UAS will be returned to the UAC. This forking mechanism is optimal for an INVITE intended to connect one human user with another human uses, but is poor for requests that have a "one to many" nature, especially PUBLISH and SUBSCRIBE requests, but also including some INVITEs. This document proposes an alternative forking mechanism that better supports "one to many" requests, and that mechanism be the standardized meaning of the (existing but weakly specified) "Request-Disposition: no-cancel, parallel" header.
"Applicability of Reliable Server Pooling for SCTP-Based Endpoint Mobility", Thomas Dreibholz, Jobin Pulinthanath, 5-Jul-09. ( bytes): This document describes a novel mobility concept based on a combination of SCTP with Dynamic Address Reconfiguration extension and Reliable Server Pooling (RSerPool).
"Access Right Distribution Protocol (ARDP)", Alexandre Cassen, 2-Jun-09. ( bytes): This document describes a protocol using multicast to securely distribute IPTV management elements such as IPTV customer's access rights. The protocol typically runs on any piece of equipments to locally store owned customers IPTV service access right. This design provides access control at aggregation level.
"Reliable Server Pooling (RSerPool) Bakeoff Scoring", Thomas Dreibholz, Michael Tuexen, 5-Jul-09. ( bytes): This memo describes some of the scoring to be used in the testing of Reliable Server Pooling protocols ASAP and ENRP at upcoming bakeoffs.
"Virtual Enterprise Traversal (VET)", Fred Templin, 13-Apr-09. ( bytes): Enterprise networks connect routers over various link types, and may also connect to provider networks and/or the global Internet. Enterprise network nodes require a means to automatically provision IP addresses/prefixes and support internetworking operation in a wide variety of use cases including SOHO networks, Mobile Ad-hoc Networks (MANETs), multi-organizational corporate networks and the interdomain core of the global Internet itself. This document specifies a Virtual Enterprise Traversal (VET) abstraction for autoconfiguration and operation of nodes in enterprise networks.
"Web Linking", Mark Nottingham, 11-Jul-09. ( bytes): This document specifies relation types for Web links, and defines a registry for them. It also defines how to send such links in HTTP headers with the Link header-field.
"Diameter Base Protocol MIB", Glen Zorn, Subash Comerica, 6-Mar-09. ( bytes): Along with providing support for certain basic authentication, authorization and accounting functions, the Diameter protocol is designed to provide a framework for AAA applications. This document defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage an implementation of the Diameter protocol.
"Diameter Credit Control Application MIB", Glen Zorn, Subash Comerica, 6-Mar-09. ( bytes): Along with providing support for certain basic authentication, authorization and accounting functions, the Diameter base protocol is intended to provide a framework for AAA applications. This document defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage an implementation of the Diameter Credit Control application.
"Considerations for Information Services and Operator Services Using SIP", John Haluska, Renee Berkowitz, Paul Roder, Wesley Downum, Richard Ahern, Paul Lung, Nicholas Costantino, Chris Blackwell, 19-Jun-09. ( bytes): Information Services are services whereby information is provided in response to user requests, and may include involvement of a human or automated agent. A popular existing Information Service is Directory Assistance (DA). Moving ahead, Information Services providers envision exciting multimedia services that support simultaneous voice and data interactions with full operator backup at any time during the call. Information Services providers are planning to migrate to SIP based platforms, which will enable such advanced services, while continuing to support traditional DA services. Operator Services are traditional PSTN services which often involve providing human or automated assistance to a caller, and often require the specialized capabilities traditionally provided by an operator services switch. Market and/or regulatory factors in some jurisdictions dictate that some subset of Operator Services continue to be provided going forward. This document aims to identify how Operator and Information Services can be implemented using existing or currently proposed SIP mechanisms, to identity existing protocol gaps, and to provide a set of Best Current Practices to facilitate interoperability. For Operator Services, the intention is to reproduce the current PSTN behaviour.
"Multiple aggregated control URIs for RTSP", Thorsten Lohmar, Torbjorn Einarsson, 14-Jul-09. ( bytes): RTSP defines the setup and control for on demand and live streaming media sessions, which are delivered via an external media transport protocol such as RTP/UDP. RTSP does not define a mechanism to change the content during an on-going streaming session. Such a mechanism improves the streaming experience when a user browses through multiple offerings on a single streaming site. This document describes several methods to improve content switching. The basic principle is to re-use already established transport sessions (e.g. RTP/UDP sessions) and negotiate new content to be delivered on the existing sessions. If additional transport sessions are necessary, those sessions are established separately. This principle of re-using the RTSP control and transport sessions decreases the content switch delay to a large extent and improves the end-user experience. The present document defines a mechanism for switching to new content, both when the client already has the content description available and when it does not. This document additionally considers switching of a single media stream in a session, when several alternative media components are available. For instance, the content may provide several alternate audio tracks in different languages to be played with a single video stream. The principle of Fast Content Switching and Start-up is also defined in 3GPP TS 26.234 [3GPP.26.234] for RTSP 1.0 [RFC2326].
"Reporting Metrics: Different Points of View", Al Morton, Gomathi Ramachandran, Ganga Maguluri, 7-Jul-09. ( bytes): Consumers of IP network performance metrics have many different uses in mind. This memo categorizes the different audience points of view. It describes how the categories affect the selection of metric parameters and options when seeking info that serves their needs. The memo then proceeds to discuss "long-term" reporting considerations (e.g, days, weeks or months, as opposed to 10 seconds).
"Identifying and Reacting to Unsolicited DNS Queries", Peter Koch, 9-Mar-09. ( bytes): This document deals with unsolicited Domain Name System (DNS) queries directed towards authoritative name servers. It identifies reasons for the existence of these queries and lists some observed or proposed reactions.
"LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS", Pranjal Dutta, 8-Mar-09. ( bytes): [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 the MAC addresses in the VPLS that does not require relearning due to such topology change. This document defines an extension to MAC Address Withdrawal procedure with empty MAC List [RFC4762], which enables a Provider Edge(PE) device to remove only the MAC addresses that needs to be relearned. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively.
"Device Capability Negotiation for Device-Based Location Determination and Location Measurements in HELD", Martin Thomson, James Winterbottom, 10-Jul-09. ( bytes): A framework for the exchange of capabilities in HELD is described. Capabilities for enabling Device-based measurements and Device-based location generation are defined based on this framework.
"DTLS transport mapping for SYSLOG", Tom Petch, Rainer Gerhards, 9-Jun-09. ( bytes): This document describes the transport of syslog messages over DTLS (Datagram Transport Level Security). It provides a secure transport for syslog messages in cases where a connection-less transport is desired.
"Delay-Tolerant Networking Previous Hop Insertion Block", Susan Symington, 11-Jun-09. ( bytes): This document defines an extension block that may be used with the Bundle Protocol [refs.DTNBP] within the context of a Delay-Tolerant Network architecture [refs.DTNarch]. This Previous Hop Insertion Block is designed to be inserted by a forwarding node to provide the endpoint identifier (EID) of an endpoint of which the forwarding node is a member so that this EID may be conveyed to the next-hop receiving node. Knowledge of an EID of an endpoint of which a previous-hop node is a member may be required in some circumstances to support certain routing protocols (e.g., flood routing). The Previous Hop Insertion block is always removed from the bundle by the receiving node so that its duration within the bundle lasts for exactly one hop. This document defines the format and processing of this Previous Hop Insertion Block.
"The Hypertext Transfer Protocol (HTTP) Entity Tag ("ETag") Response Header in Write Operations", Julian Reschke, 2-Mar-09. ( bytes): The Hypertext Transfer Protocol (HTTP) specifies a state identifier, called "Entity Tag", to be returned in the "ETag" response header. However, the description of this header for write operations such as PUT is incomplete, and has caused confusion among developers and protocol designers, and potentially interoperability problems. This document explains the problem in detail and suggests both a clarification for a revision to the HTTP/1.1 specification (RFC2616) and a new header for use in responses, making HTTP entity tags more useful for user agents that want to avoid round-trips to the server after modifying a resource.
"Channel Bindings for TLS", Jeffrey Altman, Nicolas Williams, Larry Zhu, 29-Jun-09. ( bytes): This document defines three channel binding types for Transport Layer Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for- telnet, in accordance with RFC 5056 (On Channel Binding).
"Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO)", Henning Schulzrinne, Vishal Singh, Hannes Tschofenig, Martin Thomson, 21-Jun-09. ( bytes): The Geopriv Location Object introduced by the Presence Information Data Format - Location Object (PIDF-LO), RFC 4119, defines a basic XML format for carrying geographical information of a presentity. This document defines PIDF-LO extensions that are intended to convey information about moving objects. Elements are defined that enable expression of spatial orientation, speed, heading, and acceleration of the presentity.
"Presentation of Text Conversation in realtime and en-bloc form", Gunnar Hellstrom, Norman Williams, Arnoud Wijk, Gregg Vanderheiden, 11-Jul-09. ( bytes): This specification defines methods for presentation of a text conversation with focus on the real-time features. The aim is to give the participants in a conversation a good opportunity to perceive the real-time flow of the conversation and also provide a display of the history of the conversation that makes it easy to read. Both two-party and multi-party situations are defined.
"Transporting User to User Call Control Information in SIP for ISDN Interworking", Alan Johnston, Joanne McMillen, 2-Jul-09. ( bytes): Several approaches to transporting the ITU-T Q.931 User to User Information Element (UU IE) data in SIP have been proposed. As networks move to SIP it is important that applications requiring this data can continue to function in SIP networks as well as the ability to interwork with this ISDN service for end-to- end transparency. This document discusses three mechanisms to meet the requirements defined in the Requirements for SIP Call Control UUI document. A new SIP header field which bests meets these requirements is proposed.
"Congestion Control in the RFC Series", Michael Welzl, Wesley Eddy, 30-Oct-08. ( bytes): This document is an informational snapshot produced by the IRTF's Internet Congestion Control Research Group (ICCRG). It provides a survey of congestion control topics described by documents in the RFC series. This does not modify or update the specifications or status of the RFC documents that are discussed. It may be used as a reference or starting point for the future work of the research group, especially in noting gaps or open issues in the current IETF standards.
"Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer", Douglas Stebila, Jon Green, 5-Jun-09. ( bytes): This document describes algorithms based on Elliptic Curve Cryptography (ECC) for use within the Secure Shell (SSH) transport protocol. In particular, it specifies: Elliptic Curve Diffie-Hellman (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement and Elliptic Curve Digital Signature Algorithm (ECDSA) for use in the SSH Transport Layer protocol.
"DAI Parameter for the "tel" URI", James Yu, David Hancock, Flemming Andreasen, 10-Jul-09. ( bytes): This document defines a "dai" parameter for the "tel" Uniform Resource Identifier (URI) to support the Dial Around Indicator (DAI). The "dai" parameter is associated with the "cic" parameter, defined in [RFC4694], and indicates how the carrier identified in the "cic" parameter was selected. This document also expands the use of the "cic" parameter to support pre-subscribed and dialed long-distance carrier requirements.
"Authentication/Confidentiality for OSPFv2", Mukesh Gupta, Nagavenkata Melam, 4-Aug-09. ( bytes): This document describes means and mechanisms to provide authentication/confidentiality to OSPFv2 using IPsec (IP Security).
"Atom Bidirectional Attribute", James Snell, 9-Jun-09. ( bytes): This document adds a new attribute to the Atom Syndication Format used to indicate the base directionality of directionally-neutral characters.
"GSSAPI authentication for HTTP", Leif Johansson, 8-Mar-09. ( bytes): This document specifies a template extension to the HTTP Negotiate authentication mechanism defined in RFC4559 which supports mutual authentication, fast session-based re-authentication and channel bindings. An IANA registry for such GSS-API HTTP authentication mechanisms is defined.
"Extensible Messaging and Presence Protocol (XMPP): Core", Peter Saint-Andre, 8-Mar-09. ( bytes): This document defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a technology for streaming Extensible Markup Language (XML) elements for the purpose of exchanging structured information in close to real time between any two or more network-aware entities. XMPP provides a generalized, extensible framework for incrementally exchanging XML data, upon which a variety of applications can be built. The framework includes methods for stream setup and teardown, channel encryption, authentication of a client to a server and of one server to another server, and primitives for push-style messages, publication of network availability information ("presence"), and request-response interactions. This document also specifies the format for XMPP addresses, which are fully internationalizable. This document obsoletes RFC 3920.
"Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", Peter Saint-Andre, 8-Mar-09. ( bytes): This document defines extensions to core features of the Extensible Messaging and Presence Protocol (XMPP) that provide basic instant messaging (IM) and presence functionality in conformance with RFC 2779. This document obsoletes RFC 3921.
"A Uniform Resource Name Namespace For The GSM Association (GSMA) and the International Mobile station Equipment Identity(IMEI)", Andrew Allen, Paul Gosden, David McDonald, Michael Montemurro, 15-Apr-09. ( bytes): This specification defines a Uniform Resource Name namespace for the GSMA and sub namespaces for the IMEI (International Mobile station Equipment Identity), and for the IMEISV (International Mobile station Equipment Identity and Software Version number). The IMEI is 15 decimal digits long and the IMEISV is 16 decimal digits long and both are encoded using Binary Encoded Decimal (BCD). The IMEI and IMEISV were introduced as part of the specification for Global System for Mobile (GSM) and are also now incorporated by the 3rd Generation Partnership Project (3GPP) as part of the 3GPP specification for GSM, and the Universal Mobile Telecommunications System (UMTS). The IMEI and IMEISV are used to uniquely identify Mobile Equipment within these systems and are managed by the GSMA (GSM Association).
"Sharing Transaction Fraud Data", Siddharth Bajaj, 11-Feb-09. ( bytes): This document describes a document format for exchanging transaction fraud (Thraud) information. It extends the Incident Handling Working Group (INCH WG) Incident Object Description Exchange Format (IODEF) incident reporting document format. M'RAIHI Expires - August 2009 [page 2] Sharing Transaction Fraud Data February 2009
"Simple SIP Usage Scenario for Applications in the Endpoints", Kundan Singh, Henry Sinnreich, Alan Johnston, Eunsoo Shim, 29-Jun-09. ( bytes): For Internet-centric usage, the number of SIP required standards for presence; IM and audio/video communications can be drastically smaller than what has been published, by using only the rendezvous and session initiation capabilities of SIP. The simplification is based on avoiding emulating telephony and its model of the intelligent network. 'Simple SIP' by contrast relies on powerful computing endpoints. Simple SIP desktop applications can be combined with rich Internet applications (RIA). Significant telephony features may also be implemented in the endpoints. This approach for SIP reduces the number of SIP standards to comply with, currently from roughly 100 and still growing, to about 11. References for NAT traversal and for security are also provided.
"Session Initiation Protocol (SIP) Overload Control", Volker Hilt, Indra Widjaja, Henning Schulzrinne, 7-Mar-09. ( bytes): 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 an overload control mechanism for SIP.
"Extensions to the IODEF-Document Class for Reporting Phishing, Fraud, and Other Crimeware", Patrick Cain, David Jevans, 1-Jul-09. ( bytes): This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC5070 to support the reporting of phishing, fraud, other types of electronic crime. The extensions also support the exchange on information about widespread spam incidents. These extensions are flexible enough to support information gleaned from activities throughout the entire electronic fraud or spam cycle. Both simple reporting and complete forensic reporting are possible, as is consolidating multiple incidents . The extensions defined in this document are used to generate two different types of reports: a fraud report and a wide-spread spam report. Although similar in structure, each report has different required objects and intentions.RFC 2129 Keywords
"Use of Target Identity in HTTP-Enabled Location Delivery (HELD)", Martin Thomson, Hannes Tschofenig, Richard Barnes, James Winterbottom, 26-Feb-09. ( bytes): When a Location Information Server receives a request for location information (using the locationRequest message), described in the base HTTP Enabled Location Delivery (HELD) specification, it uses the source IP address of arriving message as a pointer to the location determination process. This is sufficient in environments where a Target's location can be determined based on its IP address. Two additional use cases are addresses by this document. In the first, location configuration requires additional or alternative identifiers from the source IP address provided in the request. In the second, an entity other than the Target requests the Target's location. This document extends the HELD protocol to allow the location request message to carry Target identifiers. Privacy and security considerations describe the conditions where requests containing identifiers are permitted.
"HTTP State Management Mechanism v2", Yngve Pettersen, 5-Jul-09. ( bytes): This document specifies a way to create a stateful session with Hypertext Transfer Protocol (HTTP) requests and responses. It describes three HTTP headers, Cookie, Cookie2, and Set-Cookie2, which carry state information between participating origin servers and user agents. The method described here differs from both Netscape's Cookie proposal [Netscape], and [RFC2965], but it can, provided some requirements are met, interoperate with HTTP/1.1 user agents that use Netscape's method. (See the HISTORICAL section.) This document defines new rules for how cookies can be shared between servers within a domain. These new rules are intended to address security and privacy concerns that are difficult to counter for clients implementing Netscape's proposed rules or the rules specified by RFC 2965. This document reflects implementation experience with RFC 2965 and obsoletes it.
"An uniform format for IPv6 extension headers", Suresh Krishnan, James Woodyatt, Erik Kline, James Hoagland, 13-Jul-09. ( bytes): In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the transport layer header. There are a small number of such extension headers currently defined. This document defines a format for defining a new family of IPv6 extension headers.
"Real-time Inter-network Defense", Kathleen Moriarty, 13-Jul-09. ( bytes): Network security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Network providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms across for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations.
"OSPF Extensions for Dynamic Placement of Multi-Segment Pseudowires", Matthew Bocci, Dimitri Papadimitriou, Alex Zinin, Mustapha Aissaoui, Andrew Dolganow, Yuji Kamite, Luca Martini, Frederic JOUNAY, 15-Apr-09. ( bytes): Multi-segment pseudowires have been defined to enable emulated layer 1 and layer 2 services to be delivered from an IP based packet switched network over a sparse mesh of PSN tunnels and PW control protocol sessions. MS-PWs can be used to scale PW based networks over both a single AS, or between multiple ASs, and there is a particular need to be able to dynamically route MS-PWs through a given AS to reach PEs at or beyond the edge of the AS, where the route of the PW through each AS needs to be automatically determined. This draft proposes extensions to OSPF to enable the automatic advertisement of summarized PW FECs, thus enabling the dynamic routing of MS-PWs across an OSPF domain.
"Fast Macro Mobility Handovers in HMIPv6", Youngsong Mun, 20-Feb-09. ( bytes): In Hierarchical Mobile IPv6 (HMIPv6), a mobile node (MN) moving from one MAP domain to another can experience both long handover latency and packet loss due to the distance between the two MAPs. To solve the problems, this document describes two fast handover schemes that In Hierarchical Mobile IPv6 (HMIPv6), a mobile node (MN) moving from one MAP domain to another can experience both long handover latency and packet loss due to the distance between the two MAPs. To solve the problems, this document describes two fast handover schemes that
"IEEE 802.21 Basic Schema", Kenichi Taniuchi, Yoshihiro Ohba, Subir Das, 2-Nov-08. ( bytes): This document describes an RDF (Resource Description Framework) schema defined in IEEE 802.21 as the basic schema for Media- Independent Information Service. This document serves as the Specification required by the IANA to maintain a global registry for storing the RDF schema.
"Distributed DNS Implementation in IpV6", Lican Huang, 28-Jul-09. ( bytes): This file is a proposal for P2P based Domain Name query stratagy 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. This strategy may use for Domain Name query and reverse Domain Name query in IpV6 for a large number of domain names.
"Locator/ID Separation Protocol (LISP)", Dino Farinacci, Vince Fuller, Dave Meyer, Darrel Lewis, 2-Mar-09. ( bytes): This draft describes a simple, incremental, network-based protocol to implement separation of Internet addresses into Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). This mechanism requires no changes to host stacks and no major changes to existing database infrastructures. The proposed protocol can be implemented in a relatively small number of routers. This proposal was stimulated by the problem statement effort at the Amsterdam IAB Routing and Addressing Workshop (RAWS), which took place in October 2006.
"Anonymous Layers Identifiers (ALIen): Threat Model for Mobile and Multihomed Nodes", Wassim Haddad, Erik Nordmark, Francis Dupont, Marcelo Bagnulo, Basavaraj Patil, Hannes Tschofenig, 9-Mar-09. ( bytes): This memo describes privacy threats related to the MAC and IP layers identifiers in a mobile and multi-homed environment.
"Anonymous Layers Identifiers for Mobile and Multi-homed Nodes: Problem Statement", Wassim Haddad, Erik Nordmark, Francis Dupont, Marcelo Bagnulo, Basavaraj Patil, 14-Feb-09. ( bytes): This memo describes the anonymous layers identifiers in mobility and multi-homing problem statement.
"Requirements for the XCON-DCON Synchronization Protocol", Simon Romano, Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Alfonso Buono, 5-Jun-09. ( bytes): 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.
"Requirements for Distributed Conferencing", Simon Romano, Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Alfonso Buono, 5-Jun-09. ( bytes): 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.
"A Framework for Distributed Conferencing", Simon Romano, Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Alfonso Buono, 5-Jun-09. ( bytes): 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.
"Relay Chaining in DHCPv4", Bharat Joshi, Pavan Kurapati, 7-Jul-09. ( bytes): DHCP Relay Agents eliminate the necessity of having a DHCP server on each physical network. In certain network configurations, a DHCP server may be multiple subnets away from the DHCP client and multiple Relay Agents may be configured to relay DHCP messages to and from DHCP client. Such configuration can be supported only when each Relay Agent adds certain Information to DHCP messages before relaying them. This additional information helps in relaying the DHCP reply back to the DHCP client through the same path. This mechanism is referred as Relay Chaining.
"PSTN scope of PCN Charter", Stuart Goldman, Robert Schafer, Frank Suraci, Bob Schaefer, 7-Jul-09. ( bytes): The IETF PCN Working Group has continued its work investigating pre- congestion and admission control mechanisms. This work has progressed under the current charter, but has not yet considered related legacy PSTN interactions or the need for ubiquitous connectivity between users on dissimilar networks. The PCN charter could be improved by a strong positive statement to the effect committing to future work addressing legacy networks. In that light, please consider the questions below which include differential PCN treatment based on traffic types, security, and PSTN interoperability concerns. It seems helpful to have a touchstone of some concerns relative to the PSTN network and IP network Gateway in order to confirm that they will be addressed in future work. This attempt is motivated by a desire to avoid the accidental omission of a topic that may be hard to "retrofit" in later.
"Prefix Management for Mobile IPv6 Fast Handover on Point-to-Point Links", Frank Xia, Behcet Sarikaya, 5-Aug-09. ( bytes): Mobile IPv6 Fast Handovers specification currently does not explicitly define prefix management over point-to-point links when a mobile node uses a prefix to formulate a new care-of-address. In this document a mechanism is developed for a previous access router to request unique prefixes from a new access router, and in turn, the previous access router advertises the prefixes to the mobile node for a new care-of-address configuration. Extensions to Mobile IPv6 Fast Handovers specification are also specified in this document.
"Supporting Multiple Path Routing in the Session Initiation Protocol (SIP)", Dale Worley, 6-Mar-09. ( bytes): An increasing number of SIP architectures implement multiple path routing (MPR), which is the providing of more than one path for a call to reach a destination user agent (UA). A typical example is a redundant pair of gateways from a SIP system to the PSTN. A call from the SIP system to the PSTN can pass through either gateway to ultimately reach the destination telephone. In order to gain the benefits of redundancy in case one of the gateways fails or reaches capacity, a proxy forks INVITEs serially to both gateways. Unfortunately, if the call passes through one gateway but fails at the destination phone (e.g., ring-no-answer), the proxy will then fork the call to the other gateway, because the proxy has no way to know that the call failed at the destination phone rather than at the first gateway. The second fork will fail in the same way at the same destination phone. This annoys both the caller (because the call takes twice as long as it should before failing) and anyone within earshot of the destination phone. Similar failures plague any other SIP architecture where a request can reach a destination through multiple paths. To gain the benefits of MPR without suffering from this problem, the proxy which forks a request onto the redundant paths needs to be able to determine if a fork that failed reached the destination UA and was rejected by the UA (and so an alternate path should not be tried), or if the fork failed before reaching the UA (and so an alternate path should be attempted). This document is to begin a discussion of strategies for making this determination.
"A BEEP Binding for the HELD Protocol", Martin Thomson, James Winterbottom, 6-Jul-09. ( bytes): A BEEP binding is described for HELD. This binding is more suitable than the basic HTTP binding in scenarios where multiple messages are sent between the same two parties.
"Digital Signature Methods for Location Dependability", Martin Thomson, James Winterbottom, 7-Jul-09. ( bytes): The dependability of location information is closely related to the degree of trust placed in the source of that information. This document describes techniques that can be used to mitigate the impact of falsifying location information. The application of digital signatures is described, relating these methods to the attacks that they address.
"FCAST: Scalable Object Delivery for the ALC and NORM Protocols", Vincent Roca, Brian Adamson, 13-Jul-09. ( bytes): 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.
"Media Gateway Control Protocol Voiceband Data Package and General Purpose Media Descriptor Parameter Package", Sandeep Sharma, Joe Stone, Rajesh Kumar, 9-Jul-09. ( bytes): This document defines Media Gateway Control Protocol (MGCP) packages that enable a Call Agent to authorize and monitor the transition of a connection to and from voiceband data (VBD) with or without redundancy and FEC (forward error correction). Although the focus is on VBD, the General-Purpose Media Descriptor Parameter package can be used to authorize other modes of operation, not relevant to VBD, for a particular codec. In addition to the definition of these new packages, this document describes the use of the Media Format Parameter package and Fax package with VBD, redundancy and FEC.
"IP Tunneling Optimization in a Mobile Environment", Wassim Haddad, Mats Naslund, Pekka Nikander, 9-Mar-09. ( bytes): This memo introduces a simple tunneling optimization mechanism, which removes the need for inserting an additional header in the IP packet. The main goals are to minimize the packet size, provide a simpler protocol design and a better efficiency.
"VPLS Interoperability with Provider Backbone Bridges", Ali Sajassi, San Jose, Florin Balus, 23-Mar-09. ( bytes): The scalability of H-VPLS with Ethernet access network can be improved by incorporating Provider Backbone Bridge (PBB) functionality in VPLS access. PBB has been standardized as IEEE 802.1ah-2008, which is an amendment to 802.1Q to improve the scalability of MAC addresses and service instances in Provider Ethernet networks. This document describes different interoperability scenarios where IEEE 802.1ah functionality is used in H-VPLS with Ethernet or MPLS access network to attain better scalability in terms of number of customer MAC addresses and number of service instances. The document also describes the scenarios and the mechanisms for incorporating PBB functionality within H-VPLS with existing IEEE 802.1ad (aka QinQ) Ethernet access and interoperability among them. Furthermore, the document discusses the migration mechanisms and scenarios by which PBB functionality can be incorporated into H-VPLS with existing MPLS access.
"The Use of Galois/Counter Mode (GCM) Modes of Operation for Camellia and Its Use With IPsec", Akihiro Kato, Satoru Kanno, Masafumi Kanda, 8-Mar-09. ( bytes): This document describes the use of the Camellia block ciper algorithm in Galois/Counter Mode (GCM) as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality and data origin authentication.
"SASL Yet Another Password Mechanism", Kurt Zeilenga, 30-May-09. ( bytes): This document describes a password authentication mechanism, called YAP-SHA-256-TLS-UNIQ, for use in protocols which support Simple Authentication and Security Layer (SASL) framework. The mechanism relies on security services provided by a lower layer, such as Transport Layer Security (TLS), to protect the authentication exchange, and subsequent application data exchange, from common attacks. The YAP-SHA-256-TLS-UNIQ mechanism can be viewed as an alternative to other password-based SASL mechanism, such as PLAIN, CRAM-MD5, and DIGEST-MD5.
"EAP Authentication Extensions for the Dynamic Host Configuration Protocol for Broadband", Richard Pruss, Glen Zorn, 9-Jun-09. ( bytes): This document defines Dynamic Host Configuration Protocol (DHCP) extensions that provide for end-user authentication prior to configuration of the host. The primary applicability is within a Digital Subscriber Line (DSL) Broadband network environment in order to enable a smooth migration from the Point to Point Protocol (PPP).
"Media Description for IKE in the Session Description Protocol (SDP)", Makoto Saito, Dan Wing, Shintaro Mizuno, 8-Jun-09. ( bytes): This document specifies how to establish secure media sessions over VPN using SIP for the purpose of on-demand media/application sharing between peers. It extends the protocol identifier of SDP so that it could negotiate the use of IKE for media session in SDP offer/answer model. And it also specifies the method to boot up IKE and generate IPsec SA using self-signed certificate under the mechanism of comedia-tls. This document extends RFC 4572. In addition, it defines a new attribute "udp-setup", which is similar to "setup" attribute defined in RFC 4145, to enable endpoints to negotiate their roles in the IKE session. Considering the case that pre-shared keys can be used for authentication in IKE, a new attribute "psk- fingerprint" is also defined. The spec in this document would be applicable to the following use- cases: o Media sharing using DLNA or similar protocol over VPN between 2 users' devices o Remote desktop sharing for customer services over VPN initiated by SIP call As an additional function of Click to Call, a customer service agent can access customer's pc remotely to troubleshoot the problem while talking with the customer over the phone. o Accessing and controlling medical equipments(medical robotics) remotely to monitor elders in a rural area (remote care services) o LAN based gaming protocol based on peer to peer rather than via gaming server
"The Camellia-CMAC-96 and Camellia-CMAC-PRF-128 Algorithms and Its Use with IPsec", Akihiro Kato, Satoru Kanno, Masayuki Kanda, Tetsu Iwata, 6-Mar-09. ( bytes): This memo specifies two new algorithms. One is the usage of Cipher- based Message Authentication Code (CMAC) with Camellia block cipher on the authentication mechanism of the IPsec Encapsulating Security Payload and Authentication Header protocols. This algorithm is called Camellia-CMAC-96. Latter is pseudo-random function based on CMAC with Camellia block cipher for Internet Key Exchange. This algorithm is called Camellia-CMAC-PRF-128.
"A context mechanism for controlling caching of HTTP responses", Yngve Pettersen, 5-Jul-09. ( bytes): 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 at some later point in time. 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.
"P2PSIP Security Overview and Risk Analysis", Song Yongchao, Marcin Matuszewski, Dan York, 10-Jul-09. ( bytes): This document provides a security overview and analysis for the Peer- to-Peer Session Initiation Protocol (P2PSIP) overlay network. It discusses security threats for the P2PSIP architecture and its components. It compares security difference between client/server (C/S) and P2P implementations of SIP, and then partitions the P2PSIP architecture into layers and analyzes the security issues in each layer and the security relationship among the layers.
"DTLS as a Transport Layer for RADIUS", Alan DeKok, 9-Jun-09. ( bytes): The RADIUS protocol [RFC2865] has limited support for authentication and encryption of RADIUS packets. The protocol transports data "in the clear", although some parts of the packets can have "hidden" content. Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets. This document specifies how the Datagram Transport Layer Security (DTLS) protocol may be used as a solution to these problems. It also describes how this proposal can co-exist with current RADIUS systems.
"LDP Extensions for Source-initiated Point-to-Multipoint Pseudowire", Philippe Niger, Yuji Kamite, Frederic JOUNAY, 13-Jul-09. ( bytes): This document provides a solution to extend Label Distribution Protocol (LDP) signaling in order to allow set up and maintenance of Point-to-Multipoint Pseudowire (P2MP PW). Such an extension of existing point to point Pseudowire is made necessary by new applications. The document deals with the source-initiated P2MP PW setup and maintenance.
"Implementing Call Park and Retrieve using the Session Initiation Protocol (SIP)", Michael Procter, 8-Jun-09. ( bytes): Call Park and Call Retrieve are useful telephony services that are familiar to many users. Existing implementations using the Session Initiation Protocol (SIP) show that a variety of approaches can be taken, with varying degrees of interoperability. This draft discusses a number of feature variations, and how they may be implemented using existing techniques. An additional URI parameter is also described, which enables further common use-cases to be implemented.
"The Minger Email Address Verification Protocol", Arvel Hathcock, Jonathan Merkel, 3-Aug-09. ( bytes): This document describes the Minger protocol. Minger is a protocol which allows a mail handling entity to query a remote service and ask the question "do you accept mail for this email address?" It includes security in the form of a hashed shared secret but can also be used anonymously if desired.
"The SatLabs Group DVB-RCS MIB", Petter Amundsen, Micheline Lambert, Hans-Peter Lexow, Stephane Combes, 28-Jul-09. ( bytes): This document describes the MIB module for the Digital Video Broadcasting Return Channel via Satellite system (DVB-RCS), as defined by the SatLabs Group. It defines a set of MIB entities to characterize the behavior and performance of network layer entities deploying DVB-RCS.
"Adding Acknowledgement Congestion Control to TCP", Sally Floyd, 4-Jul-09. ( bytes): This document describes a possible congestion control mechanism for acknowledgement traffic (ACKs) in TCP. The document specifies an end-to-end acknowledgement congestion control mechanism for TCP that uses participation from both TCP hosts, the TCP data sender and the TCP data receiver. The TCP data sender detects lost or ECN-marked ACK packets, and tells the TCP data receiver the ACK Ratio R to use to respond to the congestion on the reverse path from the data receiver to the data sender. The TCP data receiver sends roughly one ACK packet for every R data packets received. This mechanism is based on the acknowledgement congestion control in DCCP's CCID 2. This acknowledgement congestion control mechanism is being specified for further evaluation by the network community. (This Internet-Draft is also available in PDF format [ bytes].)
"Campus/Building Relative Location for Civic Location Format", Marc Linsner, Allan Thomson, 6-Mar-09. ( bytes): This document defines additional civic address parameters for use in Location Objects [1], [2], and [4]. The format is based on the civic address definition of PIDF-LO. These additional parameters allow expression of a relative location within a building or campus.
"DNSSEC Trust Anchor History Service", Wouter Wijngaards, 30-Jun-09. ( bytes): When DNS validators have trusted keys, but have been offline for a longer period, key rollover will fail and they are stuck with stale trust anchors. History service allows validators to query for older DNSKEY RRsets and pick up the rollover trail where they left off.
"Diameter Credit Control Interoperability Test Suite", Alan McNamee, Hannes Tschofenig, Victor Fajardo, Julien Bournelle, 13-Jul-09. ( bytes): This document describes a collection of test cases to be used for Diameter Credit Control application interoperability testing.
"Diameter Applications Interoperability Test Suite", Victor Fajardo, Alan McNamee, Hannes Tschofenig, Julien Bournelle, 13-Jul-09. ( bytes): This document describes a collection of test cases to be used for Diameter applications interoperability testing.
"Diameter Base Protocol Interoperability Test Suite", Victor Fajardo, Alan McNamee, Hannes Tschofenig, Julien Bournelle, 13-Jul-09. ( bytes): This document describes a collection of test cases to be used for Diameter base protocol interoperability testing.
"A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Sub-Types", Jonathan Rosenberg, 29-Jul-09. ( bytes): The caller preferences specification for the Session Initiation Protocol (SIP) allows a caller to express preferences that the call be routed to a User Agent (UA) with particular capabilities. Similarly, a specification exists to allow a UA to indicate its capabilities in a registration. Amongst those capabilities are the type of media streams the agent supports, described as top-level MIME types. The 'application' MIME type is used to describe a broad range of stream types, and provides insufficient granularity as a capability. This specification allows a UA to indicate which application sub-types the agent supports.
"A Session Initiation Protocol (SIP) Extension for the Identification of Services", Keith Drage, 24-Mar-09. ( bytes): This document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to assert the service of authenticated users. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport and usage of such information. This document does NOT offer a general service identification model suitable for use between different trust domains, or use in the Internet at large. The document also defines a URN to identify both services and UA applications. This URN can be used within the SIP header fields defined in this document to identify services, and also within the framework defined for caller preferences and callee capabilities to identify usage of both services and applications between end UAs.
"Reclassification of the APEX RFCs to Historic", Marshall T. Rose, 4-Jun-07. ( bytes): This memo reclassifies the APEX RFCs (RFCs 3340-3343) from PROPOSED STANDARD to HISTORIC.
"Delay-Tolerant Networking Retransmission Block", Susan Symington, 3-Apr-09. ( bytes): This document defines an optional extension block, called a Retransmission Block (RB), that may be used with the Bundle Protocol [refs.DTNBP] within the context of a Delay-Tolerant Network architecture [refs.DTNarch]. The Retransmission Block (RB) is designed to be used within a DTN that, as a matter of policy, deletes all replayed bundles from the network. It is designed to be used in a network that permits duplicate bundles to be forwarded if those bundles have been retransmitted by a custodian, that may (if possible) permit duplicate bundles to be forwarded if those bundles are in intentional or unintentional routing loops (contingent on the availability of mechanisms to distinguish looping bundles from other bundles), but that will consider all other duplicate bundles to be maliciously replayed bundles and delete them as such. The Retransmission Block is designed to be inserted into a bundle by a custodian when the custodian is retransmitting that bundle. The purpose of the RB is to mark the bundle as a custody-based retransmission so that it can be distinguished from other types of duplicate bundles and thereby be spared from deletion. This document defines the format and processing of this new Retransmission Block.
"An XCON Client Conference Control Package for the Media Control Channel Framework", Chris Boulton, Mary Barnes, 26-Mar-09. ( bytes): The Centralized Conferencing framework defines a model whereby client initiated interactions are required for creation, deletion, manipulation and querying the state of a of conference. This document defines a Media Control Channel Package for XCON client initiated Conference Control. The Package is based on the Media Control Channel Framework, which is also used for media server control, thus optimizing the implementation for some entities participating in an XCON system.
"Using Saratoga with a Bundle Agent as a Convergence Layer for Delay-Tolerant Networking", Lloyd Wood, Jim McKim, Wesley Eddy, Will Ivancic, Chris Jackson, 12-May-09. ( bytes): 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.
"Multicast Mobility in MIPv6: Problem Statement and Brief Survey", Gorry Fairhurst, 2-Aug-09. ( bytes): This document discusses current mobility extensions to IP layer multicast. It describes problems arising from mobile group communication in general, the case of multicast listener mobility, and for mobile senders using Any Source Multicast and Source Specific Multicast. Characteristic aspects of multicast routing and deployment issues for fixed IPv6 networks are summarized. Specific properties and interplays with the underlying network access are surveyed with respect to the relevant technologies in the wireless domain. It outlines the principal approaches to multicast mobility, together with a comprehensive exploration of the mobile multicast problem and solution space. This document concludes with a conceptual roadmap for initial steps in standardization for use by future mobile multicast protocol designers. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group.
"Timezone Information in HTTP", Stefanos Harhalakis, 27-Jul-09. ( bytes): This document defines a HTTP header for clients to provide timezone information to web servers. An ABNF description of the corresponding header is provided.Discussion Discussion about this document takes place in http-wg mailing list (ietf-http-wg@w3.org). Please CC v13@v13.gr too.
"Handle Resolution Option for ASAP", Thomas Dreibholz, 5-Jul-09. ( bytes): This document describes the Handle Resolution option for the ASAP protocol.
"Media Resource Brokering", Chris Boulton, Lorenzo Miniero, 4-Mar-09. ( bytes): The MediaCtrl work group in the IETF is currently proposing an architecture for controlling media services. The Session Initiation Protocol (SIP) will be 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:M combinations of Application Servers and Media Servers.
"TLS using EAP Authentication", Yoav Nir, Yaron Sheffer, Hannes Tschofenig, Peter Gutmann, 21-Apr-09. ( bytes): This document describes an extension to the TLS protocol to allow TLS clients to authenticate with legacy credentials using the Extensible Authentication Protocol (EAP). This work follows the example of IKEv2, where EAP has been added to the IKEv2 protocol to allow clients to use different credentials such as passwords, token cards, and shared secrets. When TLS is used with EAP, additional records are sent after the ChangeCipherSpec protocol message and before the Finished message, effectively creating an extended handshake before the application layer data can be sent. Each EapMsg handshake record contains exactly one EAP message. Using EAP for client authentication allows TLS to be used with various AAA back-end servers such as RADIUS or Diameter. TLS with EAP may be used for securing a data connection such as HTTP or POP3. We believe it has three main benefits: o The ability of EAP to work with backend servers can remove that burden from the application layer. o Moving the user authentication into the TLS handshake protects the presumably less secure application layer from attacks by unauthenticated parties. o Using mutual authentication methods within EAP can help thwart certain classes of phishing attacks.
"EAP-Based Keying for IP Mobility Protocols", Vidya Narayanan, Gerardo Giaretta, 16-Nov-07. ( bytes): EAP [1] is increasingly used for network access authentication in various networks. Also, key generating EAP methods are being adopted in various systems for the purposes of cryptographic protection between an EAP peer and an enforcement point in the network. Key generating EAP methods produce an MSK and an EMSK in accordance with [1]. The MSK is meant for use by the EAP lower layer at the peer and the authenticator and is used differently by various lower layers. The EMSK hierarchy is defined in [2]. The EMSK hierarchy is meant to be extensible to derive keys for various usages. This document defines the key hierarchy and key derivations for using the EMSK hierarchy for keying in IP mobility protocols.
"Definition of a Delay Measurement Infrastructure and Delay-Sensitive Least-Used Policy for Reliable Server Pooling", Thomas Dreibholz, Xing Zhou, 5-Jul-09. ( bytes): This document contains the definition of a delay measurement infrastructure and a delay-sensitive Least-Used policy for Reliable Server Pooling.
"Guidelines for Using the Privacy Mechanism for SIP", Mayumi Munakata, Shida Schubert, Takumi Ohba, 25-Sep-08. ( bytes): This is an informational document that provides guidelines for using the privacy mechanism for Session Initiation Protocol (SIP), that is specified in RFC 3323 and subsequently extended in RFCs 3325 and 4244. It is intended to clarify the handling of the target SIP headers/parameters and SDP parameters for each of the privacy header values (priv-values).
"ECC Brainpool Standard Curves and Curve Generation", Manfred Lochter, Johannes Merkle, 6-Mar-09. ( bytes): This Memo proposes several elliptic curve domain parameters over finite prime fields for use in cryptographic applications. The domain parameters are consistent with the relevant international standards, and can be used in X.509 certificates and certificate revocation lists (CRLs), for Internet Key Exchange (IKE), Transport Layer Security (TLS), XML signatures, and all applications or protocols based on the cryptographic message syntax (CMS).
"Header Protection for S/MIME", Lijun Liao, Joerg Schwenk, 30-Jun-09. ( bytes): In the current S/MIME Version 3.1 specification, the header protection is achieved by encoding the whole message as a message/rfc822 MIME media. Since this approach poses some practical problems, we propose to use signed attributes to implement a fully backward compatible S/MIME header protection scheme.
"Establishing Location URI Contexts using HTTP-Enabled Location Delivery (HELD)", James Winterbottom, Hannes Tschofenig, Martin Thomson, 14-Apr-09. ( bytes): This document describes a protocol extension for the HTTP-Enabled Location Delivery (HELD) protocol. It allows a Target to manage their location information on a Location Information Server (LIS) through the application of constraints invoked by accessing a location URI. Constraints described in this memo restrict how often location can be accessed through a location URI, how long the URI is valid for, and the type of location information returned when a location URI is accessed. Extension points are also provided.
"Sieve Extension: Externally Stored Lists", Alexey Melnikov, 5-Jul-09. ( bytes): Sieve scripting language can be used for implementing of whitelisting, blacklisting and personal distribution lists. Currently this requires that all members of such lists be hardcoded in the script itself. Whenever a member of such list is added or deleted, the script needs to be updated and possibly uploaded to a mail server. This document defines a Sieve extension for accessing externally stored mailing lists, i.e. list whose members are stored externally to the script, for example in LDAP (RFC 4510), ACAP (RFC 2244) or a relational database. ToDo o Need a way to advertise supported URI schemas in ManageSieve and ihave.
"Internationalized Resource Identifiers (IRIs)", Martin Duerst, Michel Suignard, Larry Masinter, 13-Jul-09. ( bytes): This document defines a new protocol element, the Internationalized Resource Identifier (IRI), as an extension of the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). A mapping from IRIs to URIs is defined, which provides a means for IRIs to be used instead of URIs, where appropriate, to identify resources. To accomodate widespread current practice, additional derivative protocol elements are defined, and current practice for resolving IRI-based hypertext references in HTML are outlined. The approach of defining new protocol elements, rather than updating or extending the definition of URI, was chosen to allow independent orderly transitions as appropriate: other protocols and languages that use URIs and their processing may explicitly choose to allow IRIs or derivative forms. 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. [RFC Editor: Please remove this paragraph before publication.] This is a draft to update RFC 3987 and move towards IETF Draft Standard. For an issues list/change log and additional information (including mailing list information), please see http://www.w3.org/International/iri-edit. For discussion and comments on this draft, please use the public-iri@w3.org mailing list. (This Internet-Draft is also available in PDF format [ bytes].)
"Collection Synchronization for WebDAV", Cyrus Daboo, 8-Mar-09. ( bytes): This specification defines an extension to WebDAV that allows efficient synchronization of the contents of a WebDAV collection.
"RADIUS Support for Proxy Mobile IPv6", Frank Xia, Behcet Sarikaya, Jouni Korhonen, Sri Gundavelli, Damjan Damic, 7-Apr-09. ( bytes): This document defines new attributes to facilitate Proxy Mobile IPv6 operations using RADIUS infrastructure. The RADIUS interactions take place when the Mobile Node attaches, authenticates and authorizes to a Proxy Mobile IPv6 domain. Furthermore, this document also defines a RADIUS based interface between the Local Mobility Anchor and the RADIUS server for authorizing received initial Proxy Binding Update messages for the mobility service session. In addition to the mobility session setup related RADIUS interaction, this document defines the baseline for both the Mobile Access Gateway and the Local Mobility Anchor generated accounting.
"IPv4 Mobility Extension for Multicast and Broadcast Packets", Ahmad Muhanna, Samita Chakrabarti, Gabriel Montenegro, Yingzhe Wu, Basavaraj Patil, 8-Jul-09. ( bytes): This specification defines a new Mobile IPv4 extension which is used to negotiate the Multicast-Broadcast Encapsulation Delivery style in the case of Mobile IPv4 Foreign Agent Care-of Address mode registration. This mechanism allows the mobile node to negotiate which type of traffic to be delivered encapsulated to the foreign agent while delivering other types of IP packets using direct delivery style. In particular, this mechanism gives the flexibility to eliminate tunnel overhead in the (typically) wireless medium between the mobile node and the foreign agent. In addition to the reduced overhead, the new mechanism makes many multicast and broadcast services available to the mobile node in a much more deterministic and efficient way.
"Flow Selection Techniques", Lorenzo Peluso, Tanja Zseby, 2-Mar-09. ( bytes): Flow selection is the process in charge of electing a limited number of flows from all of those observed at an observation point to be considered into the measurement process chain. The flow selection process can be enabled at different stages of the monitoring reference model. It can be performed at metering time once the packet classification has been executed, i.e. flow state dependent packet selection, or at recording/exporting time by limiting the number of flows to be stored and/or exported to the collector applications. This document illustrates the motivations which might lead flow selection to be performed and presents a classification of the related techniques. The document furthermore provides an information model for configuring flow selection techniques and discusses what information about the flow selection process is beneficial to be exported by adopting a suitable information model.
"Requirements, Terminology and Framework for Exigent Communications", Hannes Tschofenig, Henning Schulzrinne, Steve Norreys, 13-Jul-09. ( bytes): Various agencies need to provide information to the restricted group of persons or even to the generic public before, during and after emergency situations. 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 summarizes requirements for protocols to allow alerts to be conveyed to IP-based end points.
"Session Initiation Protocol (SIP) Event Package for the Common Alerting Protocol (CAP)", Brian Rosen, Henning Schulzrinne, Hannes Tschofenig, 13-Jul-09. ( bytes): The Common Alerting Protocol (CAP) is an XML document format for exchanging emergency alerts and public warnings. This document allows CAP documents to be distributed via the event notification mechanism available with the Session Initiation Protocol (SIP).
"Pre-Congestion Notification Encoding Comparison", Kwok Chan, Georgios Karagiannis, T Moncaster, Michael Menth, Philip Eardley, Bob Briscoe, 8-Mar-09. ( bytes): A number of mechanisms have been proposed to support differential Qualiy of Service for packets in the Internet. DiffServ is an example of such a mechanism. However, the level of assurance that can be provided with DiffServ without substantial over-provisioning is limited. Pre-Congestion Notification (PCN) uses path congestion information across a PCN region to enable per-flow admission control to provide the required service guarantees for the admitted traffic. While admission control will protect the QoS under normal operating conditions, an additional flow termination mechanism is necessary to cope with extreme events (e.g. route changes due to link or node failure). In order to allow the PCN mechanisms to work it is necessary for IP packets to be able to carry the pre-congestion information to the PCN egress nodes. This document explores different ways in which this information can be encoded into IP packets. This document does not choose the encoding but provide guidance and recommendation based on different criteria. This document also provides a historical trace of the consideration on different encoding alternatives for Pre- Congestion Notification.
"An Evaluation Framework for Data Modeling Languages in Network Management Domain", Hui Xu, Debao Xiao, 6-May-09. ( bytes): With rapid development of next generation networks, it is expected that a separate effort to study data modeling languages in the interest of network management should be undertaken. Based on a good understanding of the requirements of data modeling in next generation network management domain, evaluation on management data modeling languages becomes an essential way for the purpose of standardization to replace proprietary data models in the near future. Our project aims to establish a framework for evaluation to measure the capabilities of management data modeling languages in meeting those requirements by a set of criteria, which are modeling approaches, interoperability, conformance, extensibility, readability, data representation and security considerations.
"File Transfer Protocol HOST Command", Paul Hethmon, Robert McMurray, 6-Jul-09. ( bytes): The File Transfer Protocol, as defined in RFC 959 and Section 4 of RFC 1123, is one of the oldest and widely used protocols on the Internet. This document addresses the subject of creating multi-homed hostname- based FTP servers on a single IP address. This is achieved by extending the FTP specification to add a HOST command that is used to specify individual FTP hosts.
"Open Research Issues in Internet Congestion Control", Michael Welzl, Michael Scharf, Bob Briscoe, Dimitri Papadimitriou, 18-May-09. ( bytes): This document describes some of the open problems in Internet congestion control that are known today. This includes several new challenges that are becoming important as the network grows, as well as some issues that have been known for many years. These challenges are generally considered to be open research topics that may require more study or application of innovative techniques before Internet- scale solutions can be confidently engineered and deployed.
"Administrative Specific Elements for Civic Location Format", Marc Linsner, Subha Dhesikan, Hannes Tschofenig, 6-Mar-09. ( bytes): This document defines additional civic address parameters for use in Location Objects [1], [2], and [4]. The format is based on the civic address definition of PIDF-LO. These addition parameters allow expression of administrative specific location data elements.
"Link Metrics for OLSRv2", Christopher Dearlove, Thomas Clausen, Philippe Jacquet, 9-Jul-09. ( bytes): This document describes how link metrics may be added, in a relatively straightforward manner, to the specification of OLSRv2, in order to allow routing by other than minimum hop count routes. In addition to metric signaling and use, the most significant change is a separation of the routing and flooding functions of MPRs.
"The Lightweight Global Navigation Satellite System (GNSS) Support Protocol (LGSP)", Mike Tyson, Carlo Kopp, 21-Dec-07. ( bytes): 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.
"Routing and Addressing Problem Statement", Thomas Narten, 9-Mar-09. ( bytes): There has been much discussion over the last years about the overall scalability of the Internet routing system. This document attempts to describe what the actual problem is and the various demands being placed on the routing system that have made finding a straightforward solution difficult. Comments should be sent to rrg@psg.com or to radir@ietf.org.
"RAN Synchronization Requirements", LinLang Zhou, 9-Jul-09. ( bytes): This Internet draft describes RAN synchronization requirements, mainly about synchronization description and requirements, also includes some applications and problem description.
"Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices", Henning Schulzrinne, Stephen McCann, Gabor Bajko, Hannes Tschofenig, 13-Jul-09. ( bytes): 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, the device does not have credentials for network access, does not have a VoIP 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.
"A Framework of Media-Independent Pre-Authentication (MPA) for Inter- domain Handover Optimization", Ashutosh Dutta, Victor Fajardo, Yoshihiro Ohba, Kenichi Taniuchi, Henning Schulzrinne, 14-Feb-09. ( bytes): This document describes a framework of Media-independent Pre- Authentication (MPA), a new handover optimization mechanism that addresses the issues on existing mobility management protocols and mobility optimization mechanisms to support inter-domain handover. MPA is a mobile-assisted, secure handover optimization scheme that works over any link-layer and with any mobility management protocol and is best applicable to support optimization during inter-domain handover. MPA's pre-authentication, pre-configuration, and proactive handover techniques allow many of the handoff related operations to take place before the mobile has moved to the new network. We describe the details of all the associated techniques and its applicability for different scenarios involving various mobility protocols during inter-domain handover. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group.
"Home Agent assisted Route Optimization between Mobile IPv4 Networks", Antti Makela, Jouni Korhonen, 29-Apr-09. ( bytes): This document describes a Home Agent assisted route optimization extension to IPv4 Network Mobility Protocol.
"Reliability-only Ciphersuites for the Bundle Protocol", Wesley Eddy, Lloyd Wood, Will Ivancic, 12-May-09. ( bytes): The Delay-Tolerant Networking Bundle Protocol includes a custody transfer mechanism to provide acknowledgements of receipt for particular bundles. No checksum is included in the basic DTN Bundle Protocol, however, so at intermediate hops, it is not possible to verify that bundles have been either forwarded or passed through convergence layers without error. Without assurance that a bundle has been received without errors, the custody transfer receipt cannot guarantee that a correct copy of the bundle has been transferred, and errored bundles are forwarded when the destination cannot use the errored content, and discarding the errored bundle early would have been better for performance and throughput reasons. This document addresses that situation by defining new ciphersuites for use within the existing Bundle Security Protocol's Payload Integrity Block (formerly called the Payload Security Block [ED: remove old name before RFC]) to provide error-detection functions that do not require support for other, more complex, security-providing ciphersuites that protect integrity against deliberate modifications. This creates the checksum service needed for error-free reliability, and does so by separating security concerns from the few new reliability-only ciphersuite definitions that are introduced here. The reliability- only ciphersuites given here are intended to protect only against errors and accidental modification; not against deliberate integrity violations. This document discusses the advantages and disadvantages of this approach and the existing constraints that combined to drive this design.
"H.248/MEGACO Registration Procedures", Christian Groves, Yangbo Lin, 26-May-09. ( bytes): This document updates the H.248/MEGACO IANA Package Registration procedures in order to better describe the Package registration process and to provide a more formal review and feedback process.
"Cryptographic Message Syntax (CMS) Content Constraints X.509 Certificate Extension", Russ Housley, Sam Ashmore, Carl Wallace, 4-Mar-09. ( bytes): This document specifies the syntax and semantics for the Cryptographic Message Syntax (CMS) content constraints X.509 certificate extension. This extension is used to determine whether the public key in an X.509 public key certificate is appropriate to use in the processing of a protected content. In particular, the CMS content constraints certificate extension is one part of the authorization decision; it is used when validating a digital signature on a CMS SignedData content or validating a message authentication code (MAC) on a CMS AuthenticatedData content or CMS AuthEnvelopedData content. The signed or authenticated content type is identified by an ASN.1 object identifier, and this certificate extension indicates the content types that the certified public key is authorized to validate. If the authorization check is successful, the CMS content constraints certificate extension also provides default values for absent attributes.
"Principles of Internet Host Configuration", Bernard Aboba, Dave Thaler, Loa Andersson, Stuart Cheshire, 23-Feb-09. ( bytes): This document describes principles of Internet host configuration. It covers issues relating to configuration of Internet layer parameters, as well as parameters affecting higher layer protocols.
"Using Device-provided Location-Related Measurements in Location Configuration Protocols", Martin Thomson, James Winterbottom, 4-May-09. ( bytes): A method is described by which a Device is able to provide location- related measurement data to a LIS within a request for location information. Location-related measurement information are observations concerning properties related to the position of a Device, which could be data about network attachment or about the physical environment. When a LIS generates location information for a Device, information from the Device can improve the accuracy of the location estimate. A basic set of location-related measurements are defined, including common modes of network attachment as well as assisted Global Navigation Satellite System (GNSS) parameters.
"URI Scheme for Java(tm) Message Service 1.0", Mark Phillips, Peter Easton, Derek Rokicki, Eric Johnson, 30-Jun-09. ( bytes): This document defines the format of Uniform Resource Identifiers (URI) as defined in [RFC3986], for designating connections and destination addresses used in the Java(tm) Messaging Service (JMS) [REF-JMS]. It was originally designed for particular uses, but should have general applicability wherever a JMS URI is needed to describe the connection to a JMS provider, and access to a JMS destination. The syntax of this 'jms' URI is not compatible with any known current vendor implementation, but the expressivity of the format should permit all vendors to use it.
"Sieve Email Filtering: Sieves and display directives in XML", Ned Freed, Srinivas Vedam, 11-Jun-09. ( bytes): This document describes a way to represent Sieve email filtering language scripts in XML. Representing sieves in XML is intended not as an alternate storage format for Sieve but rather as a means to facilitate manipulation of scripts using XML tools. The XML representation also defines additional elements that have no counterparts in the regular Sieve language. These elements are intended for use by graphical user interfaces and provide facilities for labeling or grouping sections of a script so they can be displayed more conveniently. These elements are represented as specially structured comments in regular Sieve format. Change History (to be removed prior to publication as an RFC Changed representation of comments in XML to use a comment element. Update references. Added an IANA registration of a URN for the Sieve namespace. Updated XML Schema to allow largely unrestricted use of material in other namespaces. Add compact Relax NG schema. Updated example stylesheet to handle material in other namespaces. Corrected stylesheet handling of elements. Added a section defining the structured comment convention. Moved the examples section to an appendix. Added text to clarify that the examples in the various appendices are in fact code components and may therefore be reused. Added a section on validation requirements. Clarified various editor requirements and trust issues, restricted the use of "*/" in non-Sieve XML content. Added XML reference.
"Non-Renegable Selective Acknowledgements (NR-SACKs) for SCTP", Preethi Natarajan, Paul Amer, Ertugrul Yilmaz, Randall Stewart, Janardhan Iyengar, 22-Jun-09. ( bytes): Stream Control Transmission Protocol (SCTP) [RFC4960] specifies Selective Acknowledgements (SACKs) to allow an SCTP receiver to acknowledge DATA chunks which arrive out-of-order. In SCTP, SACK information is advisory -- though SACKs notify a data sender about the reception of specific out-of-order data, the SCTP data receiver is permitted to later discard the data, a.k.a reneging. Since delivery of a SACKed out-of-order DATA chunk is not guaranteed, a copy of this DATA chunk MUST be kept in the data sender's retransmission queue until this DATA chunk is cumulatively acked. By definition, data that has been delivered to the application is non-renegable by the SCTP data receiver. (Recall that, in SCTP, out- of-order data can sometimes be delivered.) Also, SCTP implementations can be configured such that the SCTP data receiver is not allowed to, and therefore, never reneges on out-of-order data. With SCTP's current SACK mechanism, non-renegable out-of-order data is selectively acked, and is (wrongly) deemed renegable by the SCTP data sender. This document specifies an extension to SCTP's acknowledgment mechanism called Non-Renegable Selective Acknowledgements (NR-SACKs.) NR-SACKs enable a data receiver to explicitly inform the data sender of non-renegable out-of-order data. As opposed to renegable data, a data sender can consider non-renegable data as never requiring retransmission, and therefore can remove non-renegable data from the retransmission queue.
"Saratoga: A Scalable File Transfer Protocol", Lloyd Wood, Jim McKim, Wesley Eddy, Will Ivancic, Chris Jackson, 12-May-09. ( bytes): This document specifies the Saratoga transfer protocol. Saratoga was originally developed to efficiently transfer remote-sensing imagery 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 only sporadic or intermittent connectivity, and is capable of transferring very large amounts of data reliably under adverse conditions. The Saratoga protocol is designed to cope with highly asymmetric link or path capacity between peers, and can support fully-unidirectional data transfer if required. In scenarios with dedicated links, Saratoga focuses on high link utilization to make the most of limited connectivity times, while standard congestion control mechanisms can be implemented for operation over shared links. Loss recovery is implemented via a simple negative-ack ARQ mechanism. The protocol specified in this document is considered to be appropriate for experimental use on private IP networks.
"Chatrooms within a Centralized Conferencing (XCON) System", Mary Barnes, Chris Boulton, Salvatore Loreto, 10-Jul-09. ( bytes): The document "A Framework for Centralized Conferencing" defines a centralized conference as both signaling and protocol agnostic. The primary examples within this framework focus on audio and video as the media types for the session. This document provides an overview of the mechanisms defined in the centralized conferencing framework that can be used to support multi-user chat. In addition, the document describes additional functionality and requirements necessary to provide feature rich functionality.
"Signaling Extensions for Wavelength Switched Optical Networks", Greg Bernstein, 8-Jul-09. ( bytes): This memo provides extensions to Generalized Multi-Protocol Label Switching (GMPLS) signaling for control of wavelength switched optical networks (WSON). These extensions build on previous work for the control of G.709 based networks.
"A Feature Set for the Extensible Messaging and Presence Protocol (XMPP)", Peter Saint-Andre, 9-Mar-09. ( bytes): This document defines a protocol feature set for the Extensible Messaging and Presence Protocol (XMPP), in accordance with the concepts and formats proposed by Larry Masinter within the NEWTRK Working Group.
"Distributed Universal Resource Name Resolution based on Distributed DNS", Lican Huang, 28-Jul-09. ( bytes): This file is a proposal for Universal Resource Name resolution based on semantic P2P network-VIRGO.
"PCEP Requirements for WSON Routing and Wavelength Assignment", Greg Bernstein, 29-Jun-09. ( bytes): 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 related to optical impairments will be addressed in a separate document.
"Certificate profile and certificate management for SEND", Suresh Krishnan, Ana Kukec, Khaja Ahmed, 9-Mar-09. ( bytes): Secure Neighbor Discovery (SEND) Utilizes X.509v3 certificates for performing router authorization. This document specifies a certificate profile for SEND based on Resource Certificates along with extended key usage values required for SEND.
"OSPF Transport Instance Extensions", Acee Lindem, Abhay Roy, Sina Mirtorabi, 26-Feb-09. ( bytes): 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.
"Session Initiation Protocol Service Example -- Music on Hold", Dale Worley, 5-Mar-09. ( bytes): 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, but is simpler than the methods previously documented.
"SMTP Service Extension for Indicating Message Authentication Status", Murray Kucherawy, 17-Apr-09. ( bytes): This memo defines an extension to the Simple Mail Transfer protocol (SMTP) service whereby a server can indicate its ability to accept and apply information regarding the efforts of upstream SMTP servers to establish authenticity of the message via various authentication methods.
"GMPLS Signaling Extensions for Optical Impairment Aware Lightpath Setup", Giovanni Martinelli, Andrea Zanardi, 13-Jul-09. ( bytes): The problem of provisioning a lightpath in a transparent dense wavelength division multiplexing (DWDM) optical island requires the evaluation of of the optical impairments along the selected route. In this memo we propose a GMPLS signaling protocol (RSVP/RSVP-TE) extension to collect and provide the egress node the optical impairment parameters needed to validate a lightpath setup request feasibility.
"Flow Aware Transport of MPLS Pseudowires", Stewart Bryant, Clarence Filsfils, Ulrich Drafz, Vach Kompella, Joe Regan, Shane Amante, 2-Mar-09. ( bytes): Where the payload carried over a pseudowire carries a number of identifiable flows it can in some circumstances be desirable to carry those flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Most forwarding engines are able to hash based on label stacks and use this to balance flows over ECMPs. This draft describes a method of identifying the flows, or flow groups, to the label switched routers by including an additional label in the label stack.
"Flow Distribution Rule Language for Multi-Access Nodes", Conny Larsson, Michael Eriksson, Koshiro Mitsuya, Kazuyuki Tasaka, Romain Kuntz, 24-Feb-09. ( bytes): This document defines an OS independent rule language as a mean to define and perform per flow path selection for a multi-homed node. Per flow path selection is typically needed when there exist multiple network interfaces, each with different network characteristics, and an application has specific performance requirements for a data flow that makes one network interface more suitable than another. The flow distribution rule set is used by the node itself but also exchanged with other nodes that needs to know about the multi-homed node's capability of receiving data on multiple network interfaces. This document does not define how the rule set is transferred between nodes.
"MVPN Profiles Using PIM Control Plane", A Boers, Yiqun Cai, Eric Rosen, IJsbrand Wijnands, 29-Jun-09. ( bytes): The MVPN (Multicast Virtual Private Network) architecture is divided into a number of functional "layers". At each layer, multiple options are allowed. It is necessary to allow multiple options at each layer because "one size doesn't fit all." However, it is not expected that any particular implementation will support all the possible combinations of options. To ensure multi-vendor interoperability, it is useful to specify "profiles", where each profile is a particular combination of options. The number of specified profiles will be much less than the total number of possible combination, and a given implementation can be characterized by saying which profiles it supports. This document describes two profiles that use a PIM control plane.
"Teredo Security Updates", Dave Thaler, Suresh Krishnan, James Hoagland, 2-Jul-09. ( bytes): The Teredo protocol defines a set of flags that are embedded in every Teredo IPv6 address. This document specifies a set of security updates that modify the use of this flags field, but are backward compatible.
"Real-time text interworking between PSTN and IP networks", Gunnar Hellstrom, Barry Dingle, Arnoud Wijk, Guido Gybels, 13-Jul-09. ( bytes): IP networks can support real-time text communication. SIP-based real- time text is called Text-over-IP or ToIP. PSTN networks support real-time text using textphones (or TTYs). When real-time text is supported by different networks, gateways are needed to provide interoperability. Real-time text capable gateways may also support real-time voice. This specification describes procedures for interworking between ToIP and PSTN textphones using a real-time text capable gateway (RTT gateway). It also describes ways to route calls to RTT gateways for several call scenarios. Procedures that support the phased introduction of RTT gateways and procedures that support the invocation of text channels at any time during the call are included. Interworking of PSTN textphones that do not support simultaneity of voice and text with IP User Agents that support simultaneous voice and text is also described.
"Registration of the Real-time-text Media Feature Tag", Gunnar Hellstrom, Arnoud Wijk, 12-Jul-09. ( bytes): This memo defines a new Media Feature Tag "real-time-text" for use in SIP registration and session establishment. This is used to indicate if a device capable of text communication has full real-time text capabilities or limitations in its capabilities requiring the users to apply some turn-taking habits. To the RFC editor Please replace y.y with the assigned ASN.1 identifier and XXXX with the RFC number of this specification.
"End-Host Authentication for HIP Middleboxes", Tobias Heer, Klaus Wehrle, Miika Komu, 27-Feb-09. ( bytes): The Host Identity Protocol [RFC5201] is a signaling protocol for secure communication, mobility, and multihoming that introduces a cryptographic namespace. This document specifies an extension for HIP that enables middleboxes to unambiguously verify the identities of hosts that communicate across them. This extension allows middleboxes to verify the liveness and freshness of a HIP association and, thus, to secure access control in middleboxes.
"A Location Dereferencing Protocol Using HELD", James Winterbottom, Hannes Tschofenig, Henning Schulzrinne, Martin Thomson, Martin Dawson, 27-Jul-09. ( bytes): 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 secure HELD URI that can be used in conjunction with the HELD protocol to request the location of the Target.
"Representation of Uncertainty and Confidence in PIDF-LO", Martin Thomson, James Winterbottom, 3-Jun-09. ( bytes): 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.
"DTLS-SRTP Key Transport (KTR)", Dan Wing, 9-Mar-09. ( bytes): The existing DTLS-SRTP specification allows SRTP keys to be established between a pair of SRTP endpoints. However, when there are more than two participants in an SRTP session, DTLS-SRTP is unable to provide a single key for all of the participants. This existing limitation of DTLS-SRTP prevents deploying DTLS-SRTP in certain scenarios. This document describes an extension to DTLS-SRTP called Key Transport (KTR). This extension transports SRTP keying material from one DTLS-SRTP peer to another, so the same SRTP keying material can be used by multiple DTLS-SRTP peers. This extension eliminates the need to key each SRTP session individually, allowing cost-effective deployment of several DTLS-SRTP scenarios.
"Mutual Authentication Protocol for HTTP", Yutaka Oiwa, 13-Feb-09. ( bytes): This document specifies the "Mutual authentication protocol for Hyper-Text Transport Protocol". This protocol provides true mutual authentication between HTTP clients and servers using simple password-based authentication. Unlike Basic and Digest HTTP access authentication protocol, the protocol ensures that server knows the user's entity (encrypted password) upon successful authentication. This prevents common phishing attacks: phishing attackers cannot convince users that the user has been authenticated to the genuine website. Furthermore, even when a user has been authenticated against an illegitimate server, the server cannot gain any bit of information about user's passwords. The protocol is designed as an extension to the HTTP protocol, and the protocol design intends to replace existing authentication mechanism such as Basic/Digest access authentications and form-based authentications.
"LISP Alternative Topology (LISP+ALT)", Dino Farinacci, Vince Fuller, Dave Meyer, Darrel Lewis, 24-Feb-09. ( bytes): This document describes a method of building an alternative, logical topology for managing Endpoint Identifier to Routing Locator mappings using the Locator/ID Separation Protocol. The logical network is built as an overlay on the public Internet using existing technologies and tools, specifically the Border Gateway Protocol and the Generic Routing Encapsulation. An important design goal for LISP+ALT is to allow for the relatively easy deployment of an efficient mapping system while minimizing changes to existing hardware and software.
"BGP based Virtual Private Multicast Service Auto-Discovery and Signaling", Rahul Aggarwal, Yuji Kamite, Frederic JOUNAY, 13-Jul-09. ( bytes): A Point-to-Multipoint (P2MP) Pseudowire (PW) is a mechanism that emulates the essential attributes of a unidirectional P2MP Telecommunications service such as P2MP ATM over a Packet Switched Network (PSN). One of the applicabilities of a P2MP PW is to deliver a Layer 2 multicast service, that carries multicast frames (encoded using Layer 2 or IP mechanisms) from a multicast source to one or more multicast receivers. [RFC4664] describes a number of different ways in which sets of PWs may be combined together into "Provider Provisioned Layer 2 VPNs" (L2 PPVPNs, or L2VPNs), resulting in a number of different kinds of L2VPN. P2MP PWs enable a L2VPN to provide a Virtual Private Multicast Service (VPMS), which may be in addition to the Virtual Private Wire Service (VPWS) offered by the L2VPN. A VPMS is a L2VPN service that provides point-to-multipoint connectivity traffic to customers. VPMS framework and requirements are described in [VPLS-REQ]. One of the VPMS requirements is auto-discovery. This document describes how procedures outlined in [VPLS-MCAST] can be used for auto-discovery (A-D) in VPMS using BGP. This document also describes BGP based procedures for P2MP PW signaling for VPMS that may be used when BGP is used for VPMS auto-discovery.
"BGP protocol extensions for Path Computation Element (PCE) Discovery in a BGP/MPLS IP-VPN", Kenji Kumaki, Tomoki Murai, 13-Jul-09. ( bytes): In order to provide an end-to-end MPLS TE LSP between customer sites within a BGP/MPLS IP-VPN, it is highly desirable for a Path Computation Element (PCE) to be able to dynamically discover a set of Path Computation Elements (PCEs) that know VPN routes. In BGP/MPLS IP-VPNs, it is advantageous to use BGP to distribute PCE information. This document defines a new attribute and describes how PCE information can be carried using BGP.
"RTP Payload Format for MVC Video", Ye-Kui Wang, Thomas Schierl, 18-Feb-09. ( bytes): This memo describes an RTP payload format for the multiview extension of the ITU-T Recommendation H.264 video codec that is technically identical to ISO/IEC International Standard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units, produced by the video encoder, in each RTP payload. The payload format has wide applicability, such as 3D video streaming, free-viewpoint video, and 3DTV.
"Mobile and Wireless Multicast Requirements on IGMP/MLD Protocols", Hui Liu, 13-Jul-09. ( bytes): This document presents the requirements for IGMP/MLD protocols to allow the deployment of mobile multicast service. It is intended to provide useful guideline when adapting current IGMP/MLD protocols to support terminal mobility.
"IGMP and MLD Hold and Release Extensions for Mobility", Hitoshi Asaeda, Thomas Schmidt, 13-Jul-09. ( bytes): This document describes IGMP and MLD Hold and Release protocol extensions for hosts and routers. The interoperability with the standard IGMPv3/MLDv2 protocols and these previous versions is also taken into account.
"A Session Description Protocol (SDP) Control Package Attribute", Chris Boulton, 27-Mar-09. ( bytes): This document defines a new Session Description Protocol (SDP) media- level attribute: "ctrl-package". The "ctrl-package" attribute conveys details of the SIP Control Framework extension packages that are supported by a client participating in an offer/answer exchange.
"Test Cases for the use of Galois/Counter Mode (GCM) and Galois Message Authentication Code (GMAC) in IPsec ESP", David McGrew, 9-Mar-09. ( bytes): This note provides test cases for the use of AES GCM and GMAC in ESP, as defined in RFC4106 and RFC4543, and clarifies some points in the latter specification.
"An overload control package for the Session Initiation Protocol (SIP).", Youssef Chadli, Xavier Marjou, 25-Feb-09. ( bytes): This document specifies an event package for the notification of overload control using the Session Initiation Protocol (SIP) events framework. The overload control package allows an upstream server to retrieve overload control information from a downstream server and to be notified when this information changes. This information is used by the upstream server to adapt its flow toward the downstream server and thus to avoid overloading it.
"Specifying Location Quality Requirements in Location Protocols", Martin Thomson, James Winterbottom, 21-Jun-09. ( bytes): Parameters that define the expected quality of location information are defined for use in location protocols. These parameter can be used by a requester to indicate to a Location Server quality requirements for the location information it requests. If applicable, the Location Server is able to use this information to control how location information is determined. An optional indication of whether the quality requirements were met is defined to be provided by the Location Server alongside location information.
"Text media handling in RTP based real-time conferences", Gunnar Hellstrom, Arnoud Wijk, 12-Jul-09. ( bytes): This memo specifies methods for text media handling in multi-party calls, where the text is carried by the RTP protocol. Real-time text is carried in a time-sampled mode according to RFC 4103. Centralized multi-party handling of real-time text is achieved through a media control unit coordinating multiple RTP text streams into one RTP session, identifying each stream with its own SSRC. Identification for the streams are provided through the RTCP messages. This mechanism enables the receiving application to present the received real-time text medium in different ways according to user preferences. Some presentation related features are also described explaining suitable variations of transmission and presentation of text. Call control features are described for the SIP environment, while the transport mechanisms should be suitable for any IP based call control environment using RTP transport. An alternative method using a single RTP stream and source identification inline in the text stream is also described.
"Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Core", Peter Saint-Andre, Avshalom Houri, Joe Hildebrand, 8-Mar-09. ( bytes): As a foundation for the definition of application-specific, bi- directional protocol mappings between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this document specifies the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions.
"Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence", Peter Saint-Andre, Avshalom Houri, Joe Hildebrand, 8-Mar-09. ( bytes): This document defines a bi-directional protocol mapping for the exchange of presence information between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP).
"Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging", Peter Saint-Andre, Avshalom Houri, Joe Hildebrand, 8-Mar-09. ( bytes): This document defines a bi-directional protocol mapping for the exchange of single instant messages between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP).
"Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat", Peter Saint-Andre, Eddy Gavita, Nazin Hossain, Salvatore Loreto, 8-Mar-09. ( bytes): This document defines a bi-directional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP). Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP).
"Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Media Sessions", Peter Saint-Andre, 8-Mar-09. ( bytes): This document defines a bi-directional protocol mapping for use by gateways that enable the exchange of media signalling messages between systems that implement the Jingle extensions to the Extensible Messaging and Presence Protocol (XMPP) and those that implement the Session Initiation Protocol (SIP).
"Syntax for binding documents with time stamps", Adriano Santoni, 20-Apr-09. ( bytes): This document describes an envelope which can be used to bind a file (not necessarily protected by means of cryptographic techniques) with one or more time-stamp tokens obtained for that file, where "time- stamp token" has the meaning defined in RFC 3161 or its successors. Additional types of temporal evidence are also allowed. The proposed envelope is based on the Cryptographic Message Syntax as defined in RFC 3852.
"The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force", Paul Hoffman, 28-Jun-09. ( bytes): This document describes the inner workings of IETF meetings and Working Groups, discusses organizations related to the IETF, and introduces the standards process. It is not a formal IETF process document but instead an informational overview.
"Using OpenPGP Keys for Transport Layer Security (TLS) Authentication", Nikos Mavrogiannopoulos, 25-Nov-08. ( bytes): This memo proposes extensions to the Transport Layer Security (TLS) protocol to support the OpenPGP key format. The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol. This memo replaces the Experimental [RFC5081].
"Shim6 Implementation Report : LinShim6", Sebastien Barre, 10-Feb-09. ( bytes): LinShim6 is an implementation of the Shim6 and REAP protocols, on the Linux platform. This draft provides a description of the architecture and describes the current state of our implementation. The level of support of each protocol feature is detailed. Protocol conformance is evaluated against the main drafts. (This Internet-Draft is also available in PostScript format [ bytes]. PDF format [ bytes].)
"Special Use IPv4 Addresses", Michelle Cotton, Leo Vegoda, 11-Jun-09. ( bytes): This document obsoletes RFC 3330. It describes the global and other specialized IPv4 address blocks that have been assigned by the Internet Assigned Numbers Authority (IANA). It does not address IPv4 address space assigned to operators and users through the Regional Internet Registries, nor does it address IPv4 address space assigned directly by IANA prior to the creation of the Regional Internet Registries. It also does not address allocations or assignments of IPv6 addresses or autonomous system numbers. Special IPv6 addresses are described in RFC 5156.
"Validation of Route Origination in BGP using the Resource Certificate PKI", Geoff Huston, George Michaelson, 25-May-09. ( bytes): This document defines an application of the Resource Public Key Infrastructure to validate the origination of routes advertised in the Border Gateway Protocol. The proposed application is intended to fit within the requirements for adding security to inter-domain routing, including the ability to support incremental and piecemeal deployment, and does not require any changes to the specification of BGP.
"EAP Authentication Using Only A Password", Dan Harkins, Glen Zorn, 29-Jun-09. ( bytes): This memo describes an Extensible Authentication Protocol (EAP) method, EAP-pwd, which uses a shared password for authentication. The password may be a low-entropy one and may be drawn from some set of possible passwords, like a dictionary, which is available to an attacker.
"Probabilistic Routing Protocol for Intermittently Connected Networks", Anders Lindgren, Avri Doria, Elwyn Davies, Samo Grasic, 9-Mar-09. ( bytes): This document defines PRoPHET, a Probabilistic Routing Protocol using History of Encounters and Transitivity. PRoPHET is a routing protocol for intermittently connected 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.
"The Subnetwork Encapsulation and Adaptation Layer (SEAL)", Fred Templin, 19-Aug-08. ( bytes): For the purpose of this document, subnetworks are defined as virtual topologies that span connected network regions bounded by encapsulated border nodes. These virtual topologies may span multiple IP- and/or sub-IP layer forwarding hops, and can introduce failure modes due to packet duplication and/or links with diverse Maximum Transmission Units (MTUs). This document specifies a Subnetwork Encapsulation and Adaptation Layer (SEAL) that accommodates such virtual topologies over diverse underlying link technologies.
"Specification of 3GPP IM CN Subsystem XML body handling", John-Luc Bakker, 2-Mar-09. ( bytes): This document registers new disposition-types for the Content- Disposition header field that apply to the application/3gpp-ims+xml body used by 3GPP. The applicability of these content-disposition values are limited to 3GPP IMS. The application/3gpp-ims+xml body has the following two distinct uses: (1) for redirecting the emergency session to use a different domain (e.g. using a Circuit Switched call), and (2) for delivering user profile specific information from the SIP registrar to an Application Server.
"Enabling an Enhanced Care-of Address Reachability Test for the Home Agent", Wassim Haddad, Francis Dupont, 9-Mar-09. ( bytes): This memo aims to improve Mobile IPv6 protocol security by enabling an enhanced care-of address rechability test for the home agent. The main goals are to discourage a rogue mobile node from misleading its home agent to flood a targeted foreign network and to empower the latter to thwart this type of attack if launched at a later stage.
"Linguistic Guidelines for the Use of the Arabic Language in Internet Domains", Abdulaziz Al-Zoman, Ayman El-Sherbiny, Mansour Farah, Ibaa Oueichek, 6-Feb-09. ( bytes): This document constitutes technical specifications for the use of Arabic in Internet Domain names and provides linguistic guidelines for Arabic Domain Names. It addresses Arabic-specific linguistic issues pertaining to the use of Arabic language in domain names.
"Change Process for the Session Initiation Protocol (SIP)", Jon Peterson, Cullen Jennings, Robert Sparks, 8-Jul-09. ( bytes): This memo documents a process intended to organize the future development of the Session Initiation Protocol (SIP). As the environments in which SIP is deployed grow more numerous and diverse, modifying or extending SIP in certain ways may threaten the interoperability and security of the protocol; however, the IETF process must also cater to the realities of existing deployments and serve the needs of the implementers working with SIP. This document therefore defines the functions of two long-lived working groups in the RAI Area which are, respectively, responsible for the maintenance of the core SIP specifications and development of new efforts to extend and apply SIP. This document obsoletes RFC3427.
"Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP)", Salvatore Loreto, Gonzalo Camarillo, 13-Jul-09. ( bytes): 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' and 'SCTP/ DTLS' protocol identifiers for SDP.
"A BGP Inter-AS Cost Attribute", Iljitsch van Beijnum, Rolf Winter, 9-Mar-09. ( bytes): Although BGP implementations have extensive path selection algorithms, in practice operators have trouble performing satisfactory traffic engineering of incoming traffic based on BGP attributes that are taken into account in the path selection algorithm alone. For this reason, many ASes deaggregate their address range(s) into smaller blocks and announce these blocks differently to different neighboring ASes in order to arrive at the desired traffic flow. This practice contributes to the growth of the global routing table, which drives up capital expenditures for networks engaging in inter-domain routing. This memo introduces a new inter-domain metric that supports finer-grained traffic engineering than current BGP attributes.
"Indirect Presence Publication with the Session Initiation Protocol(SIP)", Miguel Garcia, Hannes Tschofenig, Henning Schulzrinne, 6-Mar-09. ( bytes): SIP is extended by the SIP-events framework to provide subscriptions and notifications of SIP events. One example of such event notification mechanism is 'presence' and this presence information is carried in Presence Information Data Format (PIDF) documents. The SIP PUBLISH method specified in RFC 3903 carrying a PIDF document is typically used when presentities publish their own presence since these presentities are typically the source of the information. However, there are cases when the presentity is not the direct source of the presence information. One such example is location information where the end host may obtain a reference to location information as opposed to as a value. The endpoint is typically not interested in knowing its own location information, but other users or entities might be. So, if the endpoint gets its own location information with a reference and wants to publish it embedded in its presence information, it first needs to de-reference it for getting a value, and then it can embed that value in its presence information. While this is certainly a correct sequence, it adds a round-trip to the presence publication, in addition to a demand processing power and network bandwidth consumption. There is a need for a mechanism that the presentity can use to publish indirect references, such as indirect location references. This document discusses a few variants that may be used to provide this functionality.
"Using Imprecise Location for Emergency Context Resolution", Richard Barnes, Matt Lepinski, 2-Jun-09. ( bytes): Emergency calling works best when precise location is available for emergency call routing. However, there are situations in which a location provider is unable or unwilling to provide precise location, yet still wishes to enable subscribers to make emergency calls. This document describes the level of location accuracy that providers must provide to enable emergency call routing. In addition, we descibe how emergency services and non-emergency services can be invoked by an endpoint that does not have access to its precise location.
"Specifying a Circular Uncertainty Area Using DHCP", Hannes Tschofenig, James Winterbottom, 7-Mar-09. ( bytes): This document specifies how a circular area representing the location of device can be returned using DHCP. The document also shows how the data returned from DHCP can be encoded into GML for using in a PIDF-LO in an unambiguous or contentious manner. This document is a contribution to the ongoing discussion on RFC 3825; it represents one possible solution to address the discussed issues.
"The Uniform Resource Identifier (URI) DNS Resource Record", Patrik Faltstrom, Olaf Kolkman, 23-May-09. ( bytes): This document defines a new DNS resource record, called the Uniform Resource Identifier (URI) RR, for publishing mappings from hostnames to URIs.
"Hierarchical Host Identity Tag Architecture", Sheng Jiang, 11-May-09. ( bytes): This document analyzes the problems and limitation of the current flat-structured Host Identity Tag architecture. The document specifies a hierarchical HIT architecture which is compatible with the flat-structured HIT architecture. This architecture and the process of HIT generation ensure the global uniqueness of HITs. This architecture also enables the multiple Host Identity Protocol management domains, solves the deployment problem of current flat- structured HIT architecture. It also enhances the scalability and resolution efficiency of the mapping system from HIT to IP or FQDN.
"Diameter Application for Authentication and Authorization in Web Applications", Niklas Neumann, Xiaoming Fu, 13-Jul-09. ( bytes): This document specifies the Diameter Application for Authentication and Authorization in Web Applications (Diameter WebAuth). This Diameter application is intended to be used by Diameter clients to perform authentication and authorization operations with a Diameter server in web-based environments. It provides facilities to allow web sites to authenticate their web user clients using a number of (HTTP) authentication schemes. In addition, it supports user authorization using dedicated service identifiers. Diameter WebAuth may also be used by non web-based Diameter clients and servers that require a lightweight authentication and authorization Diameter application.
"Kerberos Option for DHCPv6", Masahiro Ishiyama, Shoichi Sakane, 12-Mar-09. ( bytes): This document defines a new DHCPv6 option to carry a set of configuration information related to the Kerberos protocol [RFC4120]. This document also defines three sub-options to be used within this new option, which specify a realm name of the Kerberos, a list of IP addresses of the Key Distribution Center of that realm, and a client principal name to distinguish a Kerberos client by the DHCPv6 server.
"Requirements for the graceful shutdown of BGP sessions", Bruno Decraene, Pierre Francois, cristel pelsser, Zubair Ahmad, Antonio Jose Elizond Armengol, 6-Mar-09. ( bytes): The BGP protocol is heavily used in Service Provider networks both for Internet and BGP/MPLS VPN services. For resiliency purposes, redundant routers and BGP sessions can be deployed to reduce the consequences of an AS Border Router or BGP session breakdown on customers' or peers' traffic. However simply taking down or even up a BGP session for maintenance purposes may still induce connectivity losses during the BGP convergence. This is no more satisfactory for new applications (e.g. voice over IP, on line gaming, VPN). Therefore, a solution is required for the graceful shutdown of a (set of) BGP session(s) in order to limit the amount of traffic loss during a planned shutdown. This document expresses requirements for such a solution.
"Rbridges: TRILL Header Options", Donald Eastlake 3rd, 23-Apr-09. ( bytes): The TRILL base protocol specification, draft-ietf-trill-rbridge- protocol-12.txt, specifies minimal hooks for options. This draft fully describes the format for options and specifies an initial set of options.
"EAP Method Support for Transporting AAA Payloads", Charles Clancy, Avi Lior, Glen Zorn, 2-May-09. ( bytes): This document defines bindings for existing EAP methods to transport Diameter AVPs, called "AAA payloads". The primary application is to support EAP channel bindings, but this could be used for other applications as well.
"Using HTTP for delivery in Delay/Disruption-Tolerant Networks", Lloyd Wood, Peter Holliday, 12-May-09. ( bytes): This document describes how to use the Hypertext Transfer Protocol, HTTP, for communication across delay- and disruption-tolerant networks, by making every transit node in the network HTTP-capable, and doing peer HTTP transfers between nodes to move data hop-by-hop or subnet-by-subnet towards its final destination. HTTP is well- known and straightforward to implement in these networks.
"Graceful BGP session shutdown", Pierre Francois, Bruno Decraene, cristel pelsser, Clarence Filsfils, 6-Mar-09. ( bytes): This draft describes operational procedures aimed at reducing the amount of traffic lost during planned maintenances of routers, involving the shutdown of BGP peering sessions.
"LoWPAN simple fragment Recovery", Pascal Thubert, Jonathan Hui, 30-Jun-09. ( bytes): 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 recover individual fragments that might be lost over multiple hops between 6LoWPAN endpoints.
"Global HA to HA protocol", Pascal Thubert, Ryuji Wakikawa, Vijay Devarapalli, 3-Jul-09. ( bytes): This HAHA protocol extends MIPv6 [RFC3775] and NEMO [RFC3963] to remove their link layer dependencies on the Home Link and distribute the HAs at IP layer. Global HAHA considers the distribution at the scale of the Internet, and introduces the MIP proxy for Local Mobility Management and Route Optimization in the Infrastructure.
"Location-to-Service Translation Protocol (LoST) Extensions", Andrea Forte, Henning Schulzrinne, 23-Mar-09. ( bytes): An important class of location-based services answer the question "What instances of this service are closest to me?" Examples include finding restaurants, gas stations, stores, automated teller machines, wireless access points (hot spots) or parking spaces. Currently, the Location-to-Service Translation (LoST) protocol only supports mapping locations to a single service based on service regions. This document describes an extension that allows queries "N nearest" and "within distance X".
"The BagIt File Packaging Format (V0.96) http://www.ietf.org/internet-drafts/draft-kunze-bagit-04.txt", Andy Boyko, John Kunze, Justin Littman, Liz Madden, Brian Vargas, 24-Jun-09. ( bytes): This document specifies BagIt, a hierarchical file packaging format for the exchange of generalized digital content. A "bag" has just enough structure to safely enclose descriptive "tags" and a "payload" but does not require any knowledge of the payload's internal semantics. This BagIt format should be suitable for disk-based or network-based storage and transfer.
"TOTP: Time-based One-time Password Algorithm", David M'Raihi, Salah Machani, Mingliang Pei, Johan Rydell, 11-May-09. ( bytes): This document describes an extension of one-time password algorithm HOTP as defined in [RFC4226] to support time based moving factor.
"Host Identity Protocol-based Mobile Router (HIPMR)", Jan Melen, Jukka Ylitalo, Patrik Salmela, Tom Henderson, 26-May-09. ( bytes): This drafts defines a moving network support for HIP enabled hosts. The protocol uses asymmetric authentication and symmetric authorization. The solution presented in this draft is based on delegation of signalling rights between mobile nodes and mobile routers that results in route optimization between end-hosts.
"X.509 Key and Signature Encoding for the KeyNote Trust Management System", Angelos Keromytis, 30-Mar-09. ( bytes): This memo describes X.509 key identifiers and signature encoding for version 2 of the KeyNote trust-management system [KEYNOTE]. X.509 certificates [RFC3280] can be directly used in the Authorizer or Licensees field (or in both fields) in a KeyNote assertion, allowing for easy integration with protocols that already use X.509 certificates for authentication. In addition, the document defines additional signature types that use other hash functions (beyond the MD5 and SHA1 hash functions that are defined in [RFC2792]).
"A Quick Crash Detection Method for IKE", Yoav Nir, Frederic Detienne, Pratima Sethi, 11-Jul-09. ( bytes): This document describes an extension to the IKEv2 protocol that allows for faster detection of SA desynchronization using a saved token. When an IPsec tunnel between two IKEv2 peers is disconnected due to a restart of one peer, it can take as much as several minutes for the other peer to discover that the reboot has occurred, thus delaying recovery. In this text we propose an extension to the protocol, that allows for recovery immediately following the restart.
"Distributed Internet Archive Protocol (DIAP)", Damian Brasher, 27-Jul-09. ( bytes): A de-centralised, self-contained and managed storage protocol. A system to provide strong storage fail over by using existing resources over networks distributing vital data evenly. Rapid deployment and high redundancy for small to medium organisations as well as individuals. Designed to reduce dependency on tape backup systems. The protocol also has implications for long term archiving. By classifying data vitality values the limitations in physical space due to bandwidth constrictions can be overcome and the usefulness of DIAP maximised.
"Better Approach To Mobile Ad-hoc Networking (B.A.T.M.A.N.)", Axel Neumann, Corinna Aichele, Marek Lindner, Simon Wunderlich, 7-Apr-08. ( bytes): 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, 8-Jul-09. ( bytes): It is highly desirable for VPN customers to be able to dynamically establish their MPLS TE LSPs in the context of a BGP/MPLS IP-VPN. In such a scenario, it is advantageous to use PCE to calculate customer MPLS TE LSPs. This document defines PCEP extensions for BGP/MPLS IP- VPNs.
"Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications", Juergen Schoenwaelder, Alex Clemm, Anirban Karmakar, 9-Feb-09. ( bytes): 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 a mapping of SYSLOG messages to Simple Network Management Protocol (SNMP) notifications.
"PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics", Bo Berry, Stan Ratliff, Ed Paradise, Tim Kaiser, Mike Adams, 24-Apr-08. ( bytes): This document extends the Point-to-Point over Ethernet (PPPoE) Protocol with an optional credit-based flow control mechanism and an optional Link Quality Metric report. These optional extensions improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile point-to-point radio links.
"Extended Random Values for TLS", Eric Rescorla, Margaret Salter, 2-Mar-09. ( bytes): This document describes an extension for using larger client and server Random values with Transport Layer Security (TLS) and Datagram TLS (DTLS).
"ECC in OpenPGP", Andrey Jivsov, 29-Jun-09. ( bytes): This document proposes an Elliptic Curve Cryptography extension to the OpenPGP public key format and specifies three Elliptic Curves that enjoy broad support by other standards, including NIST standards. The document aims to standardize an optimal but narrow set of parameters for best interoperability and it does so within the framework it defines that can be expanded in the future to allow more choices. (This Internet-Draft is also available in PDF format [ bytes].)
"Definition of Managed Objects for the Neighborhood Discovery Protocol", Robert Cole, Ian Chakeres, 21-Feb-09. ( bytes): 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 Neighborhood Discovery Protocol (NHDP) process on a router. The NHDP MIB also reports state information, performance information and notifications. This additional state and performance information is useful to management stations troubleshooting neighbor discovery problems.
"A Uniform Resource Identifier for Geographic Locations ('geo' URI)", Alexander Mayrhofer, Christian Spanring, 12-Feb-09. ( bytes): This document specifies an Uniform Resource Identifier (URI) for geographic locations using the 'geo' scheme name. A 'geo' URI identifies a physical location by latitude, longitude and optionally altitude in a compact, simple, human-readable, and protocol independent way.
"IP Flow Information Accounting and Export Benchmarking Methodology", Jan Novak, Benoit Claise, 13-Jul-09. ( bytes): This document provides methodology and framework for quantifying performance of selective monitoring of IP flows on a network device and export of this information to a collector. It is based on the Architecture for IP Flow Information Export [RFC5470]. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 1, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Novak Expires January 1, 2010
"Location Measurements for IEEE 802.16e Devices", Martin Thomson, James Winterbottom, 15-Jun-09. ( bytes): IEEE 802.16e defines means for true mobility within an 802.16 wireless network. Determining an accurate location for 802.16e devices requires information on radio parameters. A format is defined for location-related measurement data that can be provided by an 802.16e device. This measurement data can be used by a Location Information Server (LIS) to more accurately determine the location of the device. A separate measurement used for identifying WiMAX session-related parameters is also provided.
"Location-to-Service Translation Protocol (LoST) Extension: ServiceListBoundary", Karl Wolf, 3-Mar-09. ( bytes): LoST maps service identifiers and location information to service contact URIs. If a LoST client wants to discover available services for a particular location, it will perform a query to the LoST server. However, the response from the LoST server does not provide information about the geographical region for which the returned service list is valid. Therefore, this document proposes a ServiceListBoundary.
"Labels for Common Location-Based Services", Andrea Forte, Henning Schulzrinne, 23-Mar-09. ( bytes): This document creates a registry for describing the types of services available at a specific location. The registry is then 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. ( bytes): This document describe an data encryption specification which is based on random bytes selection of data and random key generation. This encryption process accepts variable input and the key size is dependent on the input data. This encryption process does not depend upon any 128 or 256 fixed block encryption. The mechanism for encryption is simpler to implement, but gives key complexity of more than 256 bit encryption.
"BGP Extended Community for QoS Marking", Thomas Martin Knoll, 9-Jul-09. ( bytes): 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", Yasuhiro Shirasaki, Shin Miyakawa, Akira Nakagawa, Jiro Yamaguchi, Hiroyuki Ashida, 9-Mar-09. ( bytes): 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.
"Attention Request (POKE) for Instant Messaging", Gustavo Garcia, Jose-Luis Martin, 12-Feb-09. ( bytes): This document specifies a message content type and XML format to request attention from a targeted user. This feature is usually known as poke, nudge or buzz in existing messaging platforms. Its primary use is as an additional instant messaging capability that can be sent in the middle of a instant messaging session or in a standalone message at any time.
"Requirements for Dialog Correlation in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, Salvatore Loreto, 5-Mar-09. ( bytes): This document justifies the need and lists the requirements for correlating SIP (Session Initiation Protocol) dialogs. The correlated dialogs may or may not be related to the same multimedia session. Being able to logically correlate multiple SIP dialogs is useful for applications that, for different reasons, need to establish several SIP dialogs to provide a given service. The logical correlation of two SIP dialogs is also useful, for instance, to correlate an incoming with an outgoing dialog at a B2BUA.
"Conversion parameters for IMAP CONVERT", Alexey Melnikov, 7-Mar-09. ( bytes): This is a companion document to the IMAP CONVERT (RFC 5259) extension defined by the Lemonade Working Group. It defines additional conversion parameters for conversions of images, audio, video and textual body parts. It also demonstrates additional CONVERT usage scenarios.
"HIP support for RFID", Pascal Urien, 8-Jun-09. ( bytes): This document describes an architecture based on the Host Identity Protocol (HIP), for active tags, i.e. RFIDs that include tamper resistant computing resources, as specified for example in the ISO 14443 or 15693 standards. HIP-Tags never expose their identity in clear text, but hide this value (typically an EPC-Code) by a particular equation (f) that can be only solved by a dedicated entity, referred as the portal. HIP exchanges occurred between HIP- Tags and portals; they are shuttled by IP packets, through the Internet cloud.
"TLS Key Generation", Pascal Urien, 8-Jun-09. ( bytes): The TLS protocol is widely deployed and used over the Internet. Client and server nodes compute a set of keys called the keys-block, according to a pseudo random function (PRF). This draft proposes a keying infrastructure based on the TLS protocol. It suggests defining an additional Key Distribution Function (KDF) in order to deliver a set of cryptographic keys. In a peer to peer mode keys are directly produced as inputs of the KDF functions. For centralized architectures they are delivered through containers, secured with keys derived from the KDF function.
"Things To Be Considered for RFC 3484 Revision", Arifumi Matsumoto, Tomohiro Fujisaki, Ruri Hiromi, Ken-ichi Kanayama, 16-Mar-09. ( bytes): RFC 3484 has several known issues to be fixed mainly because of the deprecation of IPv6 site-local unicast address and the coming of ULA. Additionally, the rule 9 of the destination address selection rules, namely the longest matching rule, is known for its adverse effect on the round robin DNS technique. This document covers these essential points to be modified and proposes possible useful changes to be included in the revision of RFC 3484.
"Stream Control Transmission Protocol (SCTP) Stream Reconfiguration", Randall Stewart, Peter Lei, Michael Tuexen, 16-Feb-09. ( bytes): Many applications that desire to use SCTP have requested the ability to "reset" a stream. The intention of resetting a stream is to start the numbering sequence of the stream back at 'zero' with a corresponding notification to the upper layer that this act as been performed. The applications that have requested this feature normally desire it so that they can "re-use" streams for different purposes but still utilize the stream sequence number for the application to track the message flows. Thus, without this feature, a new use on an old stream would result in message numbers larger than expected without a protocol mechanism to "start the streams back at zero". This documents presents also a method for resetting the transport sequence numbers and all stream sequence numbers.
"Safe IKE Recovery", Frederic Detienne, Pratima Sethi, Yoav Nir, 29-Jul-09. ( bytes): The Internet Key Exchange protocol version 2 (IKEv2) suffers from the limitation of not having a means to quickly recover from a stale state known as dangling Security Associations (SA's) where one side has SA's that the corresponding party does not have anymore. This Draft proposes to address the limitation by offering an immediate, DoS-free recovery mechanism for IKE that can be used in all failover or post-crash situations.
"Signaling Cryptographic Algorithm Understanding in DNSSEC", Steve Crocker, Scott Rose, 7-Jul-09. ( bytes): The DNS Security Extensions (DNSSEC) was developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. Each digital signature added to a response increases the size of the response, which could result in the response message being truncated. This draft sets out to specify a way for validating end-system resolvers to signal to a server which cryptographic algorithms they prefer in a DNSSEC response by defining an EDNS option to list a client's preferred algorithms.
"A three state extended PCN encoding scheme", T Moncaster, Bob Briscoe, Michael Menth, 9-Mar-09. ( bytes): Pre-congestion notification (PCN) is a mechanism designed to protect the Quality of Service of inelastic flows. 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 baseline encoding specified how two encoding states could be encoded into the IP header. This document specified an extension to the baseline encoding that enables three encoding states to be carried in the IP header as well as enabling limited support for end-to-end ECN. Status (to be removed by RFC Editor) This memo is posted as an Internet-Draft with an intent to eventually be published as an experimental RFC. The PCN Working Group will be asked to adopt this memo as a Working Group document describing one of several possible experimental PCN encoding schemes. The intention is that the title of this document will change to avoid confusion with the three state marking scheme. Changes from previous drafts From 00 to 01: o Checked terminology for consistency with [I-D.ietf-pcn-baseline-encoding] o Minor editorial changes.
"Optimized MAC Address Operations in VPLS with Redundancy", Yuanlong Jiang, Yang Yang, 7-Jul-09. ( bytes): The Virtual Private LAN Service (VPLS) using Label Distribution Protocol (LDP) signaling is described in RFC 4762. That document describes a mechanism called MAC Address Withdrawal to remove or unlearn MAC addresses which have been dynamically learned in a VPLS instance. Further work in progress defines an extension to MAC Address Withdrawal procedure which can greatly restrict the scope of MAC flushing. This document provides a flushing-free mechanism which removes the need for MAC address flushing in a VPLS instance. This mechanism is called MAC Address Switching.
"On RFC Streams, Headers, and Boilerplates", Leslie Daigle, Olaf Kolkman, 22-Apr-09. ( bytes): RFC documents contain a number of fixed elements such as the title page header, standard boilerplates and copyright/IPR statements. This document describes them and introduces some updates to reflect current usage and requirements of RFC publication. In particular, this updated structure is intended to communicate clearly the source of RFC creation and review.
"IPv6 Rapid Deployment on IPv4 infrastructures (6rd)", Remi Despres, 7-Apr-09. ( bytes): IPv6 rapid deployment (6rd) builds upon mechanisms of 6to4 (RFC3056) to enable a service provider to rapidly deploy IPv6 unicast service to IPv4 sites to which it provides customer premise equipment. Like 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to transit IPv4-only network infrastructure. Unlike 6to4, a 6rd service provider uses an IPv6 prefix of its own in place of the fixed 6to4 prefix. A service provider has used this mechanism for its own IPv6 "rapid deployment": five weeks from first exposure to 6rd principles to more than 1,500,000 residential sites being provided native IPv6, under the only condition that they activate it.
"Inter-Chassis Communication Protocol for L2VPN PE Redundancy", Luca Martini, Samer Salam, Ali Sajassi, Satoru Matsushima, Thomas Nadeau, 17-Feb-09. ( bytes): This document specifies an inter-chassis communication protocol (ICCP) that enables PE 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.
"Clarification of sender behaviour in persist condition.", Murali Bashyam, Mahesh Jethanandani, Anantha Ramaiah, 13-Jul-09. ( bytes): This document attempts to clarify the notion of the Zero Window Probes (ZWP) described in RFC 1122 [RFC1122]. In particular, it clarifies the actions that can be taken on connections which are experiencing the ZWP condition. The motivation for this document stems from the belief that TCP implementations strictly adhering to the current RFC language have the potential to become vulnerable to Denial of Service (DoS) scenarios.
"AES Galois Counter Mode for the Secure Shell Transport Layer Protocol", Kevin Igoe, Jerome Solinas, 20-Jul-09. ( bytes): Secure Shell (SSH, RFC 4251) is a secure remote-login protocol. SSH provides for algorithms that provide authentication, key agreement, confidentiality and data integrity services. The purpose of this document is to show how the AES Galois/Counter Mode can be used to provide both confidentiality and data integrity to the SSH Transport Layer
"Certified Electronic Mail", Francesco Gennai, Alba Shahin, Claudio Petrucci, Alessandro Vinciarelli, 24-Jun-09. ( bytes): Since 1997, the Italian Laws have recognized electronic delivery systems as legally usable. In 2005 after two years of technical tests, the characteristics of an official electronic delivery service, named certified electronic mail (in Italian "Posta Elettronica Certificata") were defined, giving the system legal standing. Design of the entire system was carried out by the National Center for Informatics in the Public Administration of Italy (CNIPA), followed by efforts for the implementation and testing of the service. The CNIPA has given the Italian National Research Council (CNR), and in particular The Institute of Information Science and Technologies at the CNR (ISTI), the task of running tests on providers of the service to guarantee the correct implementation and interoperability. This document describes the certified email system adopted in Italy. It represents the system as it is at the moment of writing, following the technical regulations that were written based upon the Italian Law DPR. November 2, 2005.
"Common Functions of Large Scale NAT (LSN)", Tomohiro Nishitani, Shin Miyakawa, Akira Nakagawa, Hiroyuki Ashida, 1-Jun-09. ( bytes): This document defines common functions of multiple types of Large Scale Network Address Translation (NAT) that handles Unicast UDP, TCP and ICMP.
"DHCP Based Configuration of Mobile Node from Home Network", Hui Deng, Peng Yang, 22-Feb-09. ( bytes): This document describes the mechanism for providing the host configuration parameters needed for network service from home network based on DHCPINFORM. DHCPINFORM message has been widely used by client to obtain other configuration information and could be sent to local broadcast address or server unicast address. Mobile IP specification could support DHCPINFORM broadcast or unicast message straightfully without any revision.
"Providing Satellite Navigation Assistance Data using HELD", Martin Thomson, James Winterbottom, 6-Jul-09. ( bytes): This document describes a method for providing Global Navigation Satellite System (GNSS) assistance data using the HTTP-Enabled Location Delivery (HELD) protocol. An assistance data request is included with the HELD location request and the Location Information Server (LIS) provides assistance data along with location information.
"Pointers for Peer-to-Peer Overlay Networks, Nodes, or Resources", Ted Hardie, Vidya Narayanan, 9-Mar-09. ( bytes): Identifying overlay networks and the resources found within in them presents a number of bootstrapping problems. While those hard problems are under discussion, this draft proposes a small set of URI-based mechanisms which are intended to be generically useful for providing pointers to peer-to-peer overlay networks in web pages, email messages, and other textual media.
"Shelter Service And Classification", Qian Sun, Robins George, Henning Schulzrinne, 10-Jul-09. ( bytes): This document defines and registers a new service 'shelter', for the service URN to find, what instances of shelter service are closest to the user's location. The Location-to-Service Translation (LoST) protocol can provide these information for a geographical region.
"MVPN: Optimized use of PIM, Wild Card Selectors, S-PMSI Join Extensions, Bidirectional Tunnels, Extranets, Hub and Spoke", A Boers, Yiqun Cai, Eric Rosen, IJsbrand Wijnands, 6-Jul-09. ( bytes): Specifications for a number of important topics were arbitrarily omitted from the initial MVPN specifications, so that those specifications could be "frozen" and advanced. The current document provides some of the missing specifications. The topics covered are: (a) using Wild Card selectors to bind multicast data streams to tunnels, (b) using Multipoint-to-Multipoint Label Switched Paths as tunnels, (c) binding bidirectional customer multicast data streams to specific tunnels, (d) running PIM (i.e., sending and receiving multicast control traffic) over a set of tunnels that are created only if needed to carry multicast data traffic, (e) extranets, (f) support for anycast sources, and (g) support for "hub and spoke" VPNs.
"MPLS TP Network Management Requirements", Scott Mansfield, Kam Lam, Eric Gray, 6-Feb-09. ( bytes): This document specifies the requirements necessary to manage the elements and networks that support an MPLS Transport Profile (MPLS-TP). This document is a product of a joint International Telecommunications Union - Telecommunications Standardization Sector (ITU-T) and Internet Engineering Task Force (IETF) effort to include a MPLS Transport Profile within the IETF MPLS architecture. The requirements are driven by the management functionality needs defined by ITU-T for packet transport networks. Gray, et al Expires August, 2009 [page 1] Internet-Draft MPLS-TP NM Requirements February, 2009
"Routing Metrics used for Path Calculation in Low Power and Lossy Networks", JP Vasseur, Dust Networks, 7-Mar-09. ( bytes): This document specifies routing metrics to be used in path calculation for Routing Over Low power and Lossy networks (ROLL). Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired networks or even with similar ones such as mobile ad-hoc networks. By contrast with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link attributes, this document specifies a set of routing metrics suitable to LLNs.
"Updates to Referred-By in the Session Initiation Protocol (SIP).", Nadia Bishai, Salvatore Loreto, Adamu Haruna, 1-Mar-09. ( bytes): SIP has a mechanism for conveying the identity of the referrer of a request by means of the Referred-By header field. This header field may be used when exploding a SIP MESSAGE request to a pre-defined group URI and when exploding a SIP INVITE request to an ad-hoc group or to a pre-defined group URI. The Referred-By header is only included if the P-Asserted-Identity header field or From header field in the exploded SIP requests needs to carry another value, e.g. the URI of a pre-defined group, or a conference focus URI. In those cases, the Referred-By header field in the resulting exploded requests is set to the P-Asserted-Identity header field or to the From header field of the original SIP request received before exploding to convey to the receiver the identity of the original inviting sender. RFC 3892 restricts the value of the header to only one SIP URI. However the P-Asserted-Identity header field currently allows two URI values and may be expanded in the future to carry more than two values as described in draft-ietf-sipping-update-pai-09. This document extends the Referred-By definition to support more than one value as well.
"Secure DHCPv6 Using CGAs", Sheng Jiang, Sean Shen, 13-Jul-09. ( bytes): The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCP servers to pass configuration parameters. It offers configuration flexibility. If not secured, DHCPv6 is vulnerable to various attacks, particularly fake attack. This document analyzes the security issues of DHCPv6 and specifies security mechanisms, mainly using CGAs.
"SACK-IMMEDIATELY extension for the Stream Control Transmission Protocol", Michael Tuexen, Irene Ruengeler, Randall Stewart, 10-Jul-09. ( bytes): This document defines a method for a sender of a DATA chunk to indicate that the corresponding SACK chunk should be sent back immediately.
"The CERNET IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition", Xing Li, Congxiao Bao, Maoke Chen, Hong Zhang, Jianping Wu, 13-Jun-09. ( bytes): This document presents the CERNET IVI translation design and deployment for the IPv4/IPv6 coexistence and transition. The IV stands for 4 and VI stands for 6, so IVI stands for the IPv4/IPv6 translation. The IVI is a prefix-specific and stateless address mapping mechanism for "an IPv6 network connected to the IPv4 Internet" scenario. In the IVI design, subsets of the ISP's IPv4 addresses are embedded in ISP's IPv6 addresses and these IPv6 addresses can therefore communicate with the global IPv6 networks directly and can communicate with the global IPv4 networks via stateless translators, which can either be IPv6 initiated or IPv4 initiated. The IVI mechanism supports the end-to-end address transparency and incremental deployment. This document is a comprehensive report on the CERNET IVI design and its deployment in large scale public networks.
"The Model for Net and App Interaction", Ray Aatarashi, Megumi Ninomiya, 25-Mar-09. ( bytes): This document describes the model for application and network interaction in reaction to Application Area Architecture Workshop held on February 11 and 12, 2008. There is not completed mechanism for collaboration between application and network yet even though a solution is required. The model proposed in this document is designed without a layer violation.
"The VLAN Model for Applications", Megumi Ninomiya, Ray Aatarashi, 25-Mar-09. ( bytes): This document describes the model for application and network interaction in reaction to Application Area Architecture Workshop held on February 11 and 12, 2008. There is not completed mechanism for collaboration between application and network yet even though a solution is required. The model proposed in this document is designed without a layer violation. This document propose the VLAN model for the application users.
"The References Header for SIP", Dale Worley, 12-Jun-09. ( bytes): 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.
"Common TCP Evaluation Suite", Lachlan Andrew, Sally Floyd, Gang Wang, 8-Jul-09. ( bytes): This document presents an evaluation test suite for the initial evaluation of proposed TCP modifications. The goal of the test suite is to allow researchers to quickly and easily evaluate their proposed TCP extensions in simulators and testbeds using a common set of well- defined, standard test cases, in order to compare and contrast proposals against standard TCP as well as other proposed modifications. This test suite is not intended to result in an exhaustive evaluation of a proposed TCP modification or new congestion control mechanism. Instead, the focus is on quickly and easily generating an initial evaluation report that allows the networking community to understand and discuss the behavioral aspects of a new proposal, in order to guide further experimentation that will be needed to fully investigate the specific aspects of a new proposal.
"DNS SRV Records for HTTP", Cullen Jennings, 8-Mar-09. ( bytes): This document specifies a new URI scheme called http+srv which uses a DNS SRV lookup to locate a HTTP server. The http+srv scheme operates in the same way as an http scheme but instead of the normal DNS lookup that a http scheme would use, it first tries an DNS SRV lookup. This memo also defines a https+srv scheme that operates in the same was as an https URI but uses DNS SRV lookups. The draft is being discussed on the apps-discuss@ietf.org list.
"HTTP API for Updating DNS Records", Cullen Jennings, Tom Daly, Jeremy Hitchcock, 8-Mar-09. ( bytes): This specification defines a simple HTTP based scheme for clients to update DNS records. The draft is being discussed on the apps-discuss@ietf.org list.
"GMPLS RSVP-TE recovery extension for data plane initiated reversion", Attila Takacs, Benoit Tremblay, 9-Mar-09. ( bytes): GMPLS RSVP-TE recovery extensions are specified in [RFC4872] and [RFC4873]. Currently these extensions cannot signal request for revertive protection neither values for the associated timers to the remote endpoint. This document extends the PROTECTION Object allowing sub-TLVs, and defines two sub-TLVs to carry wait-to-restore and hold-off intervals.
"Signaling RSVP-TE P2MP LSPs in an Inter-domain Environment", Zafar Ali, Nic Neate, 9-Mar-09. ( bytes): 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 issues that arise when a P2MP-TE LSP is signaled in multi-domain networks. Specifically, it does not provide a mechanism to avoid re-merges in inter-domain P2MP TE LSPs. This document provides a framework and protocol extensions for establishing and controlling P2MP MPLS and GMPLS TE LSPs in multi-domain networks. This document borrows inter-domain TE terminology from [RFC4726], 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).
"Proxy Mobile IPv6 Management Information Base", Glenn Mansfield, Kazuhide Koide, Sri Gundavelli, Aramoto Masafumi, 12-Jul-09. ( bytes): This memo defines a portion of the Management Information Base (MIB), the Proxy Mobile-IPv6 MIB, for use with network management protocols in the Internet community. In particular, the Proxy Mobile-IPv6 MIB will be used to monitor and control the mobile access gateway (MAG) node and the local mobility anchor (LMA) functions of a Proxy Mobile IPv6 (PMIPv6) entity.
"Camellia Cipher Suites for TLS", Akihiro Kato, Masayuki Kanda, Satoru Kanno, 5-Apr-09. ( bytes): This document specifies a set of cipher suites for the Transport Security Layer (TLS) protocol to support the Camellia encryption algorithm as a block cipher. It amends the ciphersuites originally specifed in RFC 4132 by counterparts using the newer cryptographic hash algorithms from the SHA-2 familiy. This document obsoletes RFC 4132.
"Problem Statement and Requirement of Simple IP Multi-homing of the Host", Min Hui, Hui Deng, 9-Mar-09. ( bytes): This document discusses current issues with simple IP multi-homing. In order to have deep understanding of the issue, the document also analyzes related works in IETF. In the end gives the requirements of the simple IP multi-homing in concern of technical implements. Simple IP multi-homing focuses on simultaneous multiple IP connections of the host.
"Best Current Practice for IP-based In-Vehicle Emergency Calls", Brian Rosen, Hannes Tschofenig, Ulrich Dietz, 7-Mar-09. ( bytes): 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.
"Trustworthy Location Information", Hannes Tschofenig, Henning Schulzrinne, Bernard Aboba, 13-Jul-09. ( bytes): For some location-based applications, such as emergency calling or roadside assistance, it appears that the identity of the requestor is less important than accurate and trustworthy location information. To ensure adequate help location has to be left untouched by the end point or by entities in transit. This document lists different threats, an adversary model, outlines three frequentlly discussed solutions and discusses operational considerations. Finally, the document concludes with a suggestion on how to move forward.
"MPLS-TP OAM Analysis", Nurit Sprecher, Thomas Nadeau, Huub Helvoort, Yaacov Weingarten, 7-May-09. ( bytes): The intention of this document is to analyze the set of requirements for Operations, Administration, and Maintenance (OAM) for the Transport Profile of MPLS(MPLS-TP) as defined in [MPLS-TP OAM Reqs], to evaluate whether existing OAM tools (either from the current MPLS toolset or from the ITU-T documents) can be applied to these requirements. Eventually, the purpose of the document is to recommend which of the existing tools should be extended and what new tools should be defined to support the set of OAM requirements for MPLS-TP.
"A Uniform Resource Name (URN) Namespace for CableLabs", Eduardo Cardona, Sumanth Channabasappa, Jean-Francois Mule, 9-Jul-09. ( bytes): This document describes the Namespace Identifier (NID) for Uniform Resource Namespace (URN) resources published by Cable Television Laboratories, Inc. (CableLabs). CableLabs defines and manages resources that utilize this URN identification model. Management activities for these and other resource types are handled by the manager of the CableLabs' Assigned Names and Numbers registry.
"SRTP Store-and-Forward Use Cases and Requirements", Rolf Blom, Yi Cheng, Fredrik Lindholm, John Mattsson, Mats Naslund, Karl Norrman, 6-Jul-09. ( bytes): The Secure Real-time Transport Protocol (SRTP) was designed to allow simple and efficient protection of RTP. To provide this, encryption and authentication of media and control signaling are tightly coupled to the RTP session, and the information in the RTP header. Hence, in general, it is not possible to perform store-and-forward of protected media using SRTP. This document gives, based on a use case analysis, requirements that SRTP and new SRTP transforms need to satisfy in order to allow secure store-and-forward operation. A first outline on how to introduce the needed new functionality and transforms in SRTP is also presented.
"Inter-Domain Handover and Data Forwarding between Proxy Mobile IPv6 Domains", Niklas Neumann, Xiaoming Fu, Jun Lei, Gong Zhang, 9-Mar-09. ( bytes): This document specifies mechanisms to setup and maintain handover and data forwarding procedures that allow a mobile node to move between different domains that provide (localized) network-based mobility support based on Proxy Mobile IPv6 for that node.
"A Session Initiation Protocol (SIP) Load Control Event Package", Charles Shen, Henning Schulzrinne, Arata Koike, 23-Jun-09. ( bytes): This document defines a load control event package for the Session Initiation Protocol (SIP). It allows SIP servers to distribute user load control information to SIP servers. The load control information can throttle outbound calls based on their 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.
"End-to-End Identity Important in the Session Initiation Protocol (SIP)", John Elwell, 25-Feb-09. ( bytes): This document surveys existing mechanisms in the Session Initiation Protocol (SIP) for identifying and authenticating the source of a SIP request (or caller identification). It describes how identification and authentication are not always end-to-end and the problems that this can lead to, particularly since media security based on techniques such as DTLS-SRTP is dependent on end-to-end authenticated identification of parties. This work is being discussed on the sip@ietf.org mailing list.
"A way for a host to indicate support for 240.0.0.0/4 addresses", Teemu Savolainen, 20-Feb-09. ( bytes): This document describes how in certain deployment scenarios the 240.0.0.0/4 address space can be taken into use in incremental and backwards compatible manner.
"Bulk Re-registration for Proxy Mobile IPv6", Domagoj Premec, Basavaraj Patil, Suresh Krishnan, 9-Mar-09. ( bytes): The Proxy Mobile IPv6 specification requires the Mobile Access Gateway (MAG) to send a separate Proxy Binding Update (PBU) message to the Local Mobility Agent (LMA) for each mobile node (MN) to renew the MN's mobility binding. This document defines a mechanism by which a MAG can update the mobility bindings of multiple MNs attached to it with a single PBU message to the serving LMA. This mechanism is also intended to be used by a MAG to re-establish bindings at a new LMA when its old LMA fails.
"Teredo Extensions", Dave Thaler, 8-Mar-09. ( bytes): This document specifies a set of extensions to the Teredo protocol. These extensions provide additional capabilities to Teredo, including support for more types of Network Address Translations (NATs), and support for more efficient communication.
"BGP Class of Service Interconnection", Thomas Martin Knoll, 11-May-09. ( bytes): 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.
"TICTOC Requirement", Silvana Rodrigues, Kurt Lindqvist, 2-Mar-09. ( bytes): Distribution of high precision time and frequency over the Internet and special purpose IP networks is becoming more and more needed as IP networks replace legacy networks and as new applications with need for frequency and time are developed on the Internet. The IETF formed the TICTOC working group to address the problem and perform an analysis on existing solutions and the needs. This document summarizes application needs, as described and agreed on at an TICTOC interim meeting held in Paris from June 16 to 18, 2008.
"Private Extensions to the Session Initiation Protocol (SIP) for Asserter Identification within Trusted Networks", Hadriel Kaplan, 8-Mar-09. ( bytes): This document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to identify the asserter of private user identity defined in RFC 3325. The use of these extensions is only applicable inside a set of administrative domains with previously agreed-upon policies for generation, transport and usage of such information. This document does NOT offer a general identity model suitable for use between different trust domains, or use in the Internet at large.
"Opaque MSRP Path Uri", Derek MacDonald, 9-Mar-09. ( bytes): The Message Session Relay Protocol(MSRP) does not allow privacy and topology hiding, such that MSRP users can hide the IP Address of their systems. This limitation is due to the fact that MSRP Path headers contain physical IP addresses. This document describes a mechanism which adds a level of indirection to allow privacy and topology hiding, to prevent remote parties and a man-in-the-middle from learning the IP Address and port information of the MSRP client. It also defines the option tag msrp-opaque, to indicate such support.
"Transport Layer Security Transport Model for SNMP", Wesley Hardaker, 24-Jun-09. ( bytes): This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of a SNMP Transport Subsystem to make this protection possible in an interoperable way. This transport model is designed to meet the security and operational needs of network administrators. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g. UDP or SCTP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures. This document also defines a portion of the Management Information Base (MIB) for monitoring and managing the TLS Transport Model for SNMP.
"IP Flow Anonymisation Support", Elisa Boschi, Brian Trammell, 10-Jul-09. ( bytes): This document describes anonymisation techniques for IP flow data and the export of anonymised data using the IPFIX protocol. It provides a categorization of common anonymisation schemes and defines the parameters needed to describe them. It provides guidelines for the implementation of anonymised data export and storage over IPFIX, and describes an Options-based method for anonymization metadata export within the IPFIX protocol, providing the basis for the definition of information models for configuring anonymisation techniques within an IPFIX Metering or Exporting Process, and for reporting the technique in use to an IPFIX Collecting Process.
"Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples", Mary Barnes, Chris Boulton, Lorenzo Miniero, Simon Romano, 9-Mar-09. ( bytes): This document provides detailed call flows for the scenarios documented in the Centralized Conferencing (XCON) Framework and the XCON Scenarios. The call flows document the use of the interface between a conference control client and a conference control server using the Centralized Conferencing Manipulation Protocol (CCMP). The objective is to provide a base reference for both protocol researchers and developers.
"Path MTU Discovery Using Session Traversal Utilities for NAT (STUN)", Marc Petit-Huguenin, 9-Mar-09. ( bytes): This document describes a Session Traversal Utilities for NAT (STUN) usage for discovering the path MTU between a client and a server.
"Signaled PID When Multiplexing Multiple PIDs over RSVP-TE LSPs", Zafar Ali, 9-Mar-09. ( bytes): There are many deployment scenarios where an RSVP-TE LSP carries multiple payloads. In these cases, it gets ambiguous on what should value should be carried as L3PID in the Label Request Object [RFC3209] or G-PID in the Generalized Label Request Object [RFC3471], [RFC3473]. The document proposes use of some dedicated PID values to cover some typical cases of multiple payloads carried by the LSP. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively.
"Updated Specification of the IPv4 ID Field", Joseph Touch, Matt Mathis, 13-Jul-09. ( bytes): The IPv4 Identification (ID) field enables fragmentation and reassembly, and as currently specified is required to be unique within the maximum lifetime on all IP packets. If enforced, this uniqueness requirement would limit all connections to 6.4 Mbps. Because this is obviously not the case, it is clear that existing systems violate the current specification. This document updates the specification of the IP ID field to more closely reflect current practice and to more closely match IPv6, so that the field is defined only when a packet is actually fragmented and that fragmentation occurs only at originating hosts or their equivalent. When fragmentation occurs, this document recommends that the ID field be unique within the reordering context, rather than an arbitrary, unenforced upper bound on packet lifetime.
"Definition of Managed Objects for the Manet Simplified Multicast Framework Relay Set Process", Robert Cole, Joseph Macker, Brian Adamson, Sean Harnedy, 28-Feb-09. ( bytes): This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring aspects of the Simplified Multicast Forwarding (SMF) process. The SMF MIB also reports state information, performance metrics, and notifications. In addition to configuration, this additional state and performance information is useful to management stations troubleshooting multicast forwarding problems.
"HIP Extensions for Object to Object Communications", Gyu Myoung Lee, Jun Kyun Choi, Taesoo Chung, 12-Mar-09. ( bytes): This document explains the concept of object to object communications and specifies naming and addressing issues for object identification. In order to use Host Identity Protocol (HIP) for object to object communications, this document provides the extended architecture of HIP according to mapping relationships between host and object(s). In addition, packet formats and considerations for HIP extensions concerning object are specified.
"Applicability of Access Node Control Mechanism to PON based Broadband Networks", Nabil Bitar, Sanjay Wadhwa, 9-Mar-09. ( bytes): The purpose of this document is to provide applicability of Access Node Control Mechanism, as described in [ANCP-FRAMEWORK], 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 the information does not need to go through distinct element managers but rather uses a direct device- device communication. This allows for performing access link related operations within those network elements to meet performance objectives.
"Mapping and interworking of Diversion information Between Diversion and History-Info Headers in the Session Initiation Protocol (SIP)", Marianne Mohali, 24-Jun-09. ( bytes): The Diversion header is not standardized but widely used to convey diverting information in Session Initiation Protocol (SIP) signaling. This informational document proposes a way to interwork call diversion information contained in Diversion header with a History- Info header. In addition, an interworking policy is proposed to manage the headers coexistence. The History-Info header is described in [RFC4244] and the Diversion header is described in [draft-levy-sip-diversion-09]. Note to the RFC-Editor: The reference to this draft should be replaced by the Historic RFC reference (work in progress). Since the Diversion header is used in many existing networks implementations for transport of diversion information and its interworking with standardized solutions is not obvious, an interworking recommendation is needed.
"RTP Payload Format for the iSAC Codec", Pascal Huart, Tina le Grand, Paul Jones, 6-Jul-09. ( bytes): 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).
"Border Router Discovery Protocol (BRDP) based Address Autoconfiguration", Teco Boot, Arjen Holtzer, 13-Jul-09. ( bytes): Mobile Ad hoc Networks (MANET) may be attached to a fixed infrastructure network, like the Internet. This document specifies a mechanism for Border Router discovery and utilization in such a subordinate, possibly multi-homed, MANET. It provides facilities for choosing preferred Border Router(s) and configuring IP address(es) needed for communication between MANET nodes and nodes on the Internet via the selected Border Router. Autonomous MANETs do not have Border Routers; a self-sufficient Address Autoconfiguration mechanism for Autonomous MANETs is defined as well.
"Advertisement of the best external route in BGP", Pedro Roque Marques, Rex Fernando, Enke Chen, Pradosh Mohapatra, 25-Mar-09. ( bytes): The base BGP specifications prevent a BGP speaker from advertising any route that is not the best route for a BGP destination. This document specifies a modification of this rule. Routes are divided into two categories, "external" and "internal". A specification is provided for choosing a "best external route" (for a particular value of the Network Layer Reachability Information). A BGP speaker is then allowed to advertise its "best external route" to its internal BGP peers, even if that is not the best route for the destination. The document explains why advertising the best external route can improve convergence time without causing routing loops. Additional benefits include reduction of inter-domain churn and avoidance of permanent route oscillation. The document also generalizes the notions of "internal" and "external" so that they can be applied to Route Reflector Clusters and Autonomous System Confederations.
"HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper- layer Protocol Signaling (HICCUPS)", Pekka Nikander, Gonzalo Camarillo, Jan Melen, 28-Jul-09. ( bytes): This document defines a new HIP (Host Identity Protocol) packet type called DATA. HIP DATA packets are used to securely and reliably convey arbitrary protocol messages over the Internet and various overlay networks.
"IESG Procedures for Handling of Independent and IRTF Stream Submissions", Harald Alvestrand, Russ Housley, 12-May-09. ( bytes): This document describes the procedures used by the IESG for handling documents submitted for RFC publication on the Independent and IRTF streams. This document updates procedures described in RFC 2026 and RFC 3710.
"Dynamic Host Configuration Protocol Option for Dual-Stack Lite", David Hankins, 23-Mar-09. ( bytes): This document describes how Dual-Stack Lite configuration (the Softwire Concentrator (SC)'s address) can be obtained by a Softwire Initiator (SI) via DHCPv6.
"Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard", Lisa Dusseault, Robert Sparks, 2-Jul-09. ( bytes): Advancing a protocol to Draft Standard requires documentation of the interoperation and implementation of the protocol. Historic reports have varied widely in form and level of content and there is little guidance available to new report preparers. This document updates the existing processes and provides more detail on what is appropriate in an interoperability and implementation report.
"SASL Mechanism Family for External Authentication: EXTERNAL-*", Simon Josefsson, 25-May-09. ( bytes): This document describes a way to perform client authentication in the Simple Authentication and Security Layer (SASL) framework by referring to the client authentication provided by an external security layer. We specify a SASL mechanism family EXTERNAL-* and one instance EXTERNAL-TLS that rely on the Transport Layer Security (TLS) protocol. This mechanism differs to the existing EXTERNAL mechanism by alleviating the a priori assumptions that servers and clients needs somehow negotiate out of band which secure channel that is intended. This document also discuss the implementation of authorization decisions. See for more information.
"Auto Issued X.509 Certificate Mechanism (AIXCM)", Thierry Moreau, 6-Aug-08. ( bytes): 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.
"Problems observed with RSVP recovery signaling", Andrew Rhodes, Nic Neate, David McWalter, 4-Mar-09. ( bytes): Implementation experience with RSVP-TE recovery signaling has uncovered some problems. Associations between LSPs in different sessions are forbidden. Protecting LSPs cannot themselves be protected. Overlapping repairs cause loss of traffic. This draft provides details of these problems for the community to consider.
"GSS-API: Delegate if approved by policy", Love Astrand, Sam Hartman, 15-Jan-09. ( bytes): Several GSS-API applications work in a multi-tiered architecture, where the server takes advantage of delegated user credentials to act on behalf of the user and contact additional servers. In effect, the server acts as an agent on behalf of the user. Examples include web applications that need to access e-mail or file servers as well as CIFS file servers. However, delegating the user credentials to a party who is not sufficiently trusted is problematic from a security standpoint. Kerberos provides a flag called OK-AS-DELEGATE that allows the administrator of a Kerberos realm to communicate that a particular service is trusted for delegation. This specification adds support for this flag and similar facilities in other authentication mechanisms to GSS-API (RFC 2743).
"Application of RFC 2231 Encoding to Hypertext Transfer Protocol (HTTP) Headers", Julian Reschke, 19-May-09. ( bytes): By default, message header parameters in Hypertext Transfer Protocol (HTTP) messages can not carry characters outside the ISO-8859-1 character set. RFC 2231 defines an escaping mechanism for use in Multipurpose Internet Mail Extensions (MIME) headers. This document specifies a profile of that encoding suitable for use in HTTP.
"EDNS Option for performing a data PING", Bert Hubert, David Ulevitch, 20-Apr-09. ( bytes): For various reasons, it may be desirable to ask a remote nameserver to add certain data to the response to a query. This document describes an EDNS option that implements such behavioiur.
"Alert-Info URNs for the Session Initiation Protocol (SIP)", Denis Alexeitsev, Laura Liess, Roland Jesske, Martin Huelsemann, Alan Johnston, 13-Jul-09. ( bytes): The Session Initiation Protocol (SIP) supports the capability to provide a reference to the alternative ringback tone (RBT) for caller, or ring tone (RT) for callee using the Alert-Info header. However, the reference addresses only the network resources with specific rendering properties. There is currently no support for predefined standard identifiers for ringback tones or semantic indications without tied rendering. To overcome this limitations and support new applications a family of the URNs is defined in this specification.
"Inter-Technology Handoff support in Mobile Node for Proxy Mobile IPv6", Hidetoshi Yokota, Sri Gundavelli, Kent Leung, 9-Apr-09. ( bytes): Proxy Mobile IPv6 supports a handoff between different access technologies, by which the assigned IP address is preserved regardless of the access technology type. From the perspective of the mobile node, this involves the change of the network interfaces, through which the IP address is assigned and the IP session is established. Some implementations, however, do not assume this interface switching in the middle of the session and it could cause a disconnection by the event of unavailability of the current interface; hence it is not guaranteed to be able to maintain the IP session simply by assigning the same IP address to the new interface. This document analyzes the handling of the network interfaces on the mobile node and presents several measures to avoid a disconnection due to the interface switching.
"The Metalink Download Description Format", Anthony Bryan, Metalinker Project, Metalinker Project, 8-Aug-09. ( bytes): This document specifies Metalink Documents, an XML-based download description format.
"Resolver side mitigations", Wouter Wijngaards, 24-Feb-09. ( bytes): This document describes a set of mitigations that stop the known variations of the Kaminsky cache poisoning attacks against the DNS system, for which only resolver side deployment is necessary.
"Transport Layer Security (TLS) Authorization Using KeyNote", Angelos Keromytis, 30-Mar-09. ( bytes): This document specifies the use of the KeyNote trust-management system as an authorization extension in the Transport Layer Security (TLS) Handshake Protocol, according to [AUTHZ]. Extensions carried in the client and server hello messages confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, KeyNote credentials are exchanged during the supplemental data handshake message.
"Encapsulation Methods for Transport of InfiniBand over MPLS Networks", Suresh Shelvapille, Vikas Puri, 6-Mar-09. ( bytes): An InfiniBand(IB) pseudowire (PW) is used to carry InfiniBand frames over an MPLS network. This enables service providers to offer "emulated" InfiniBand services over existing MPLS networks. This document specifies the encapsulation of InfiniBand PDUs within a pseudowire. It also specifies how islands of IB fabrics can be connected via PWs to form a single IB subnet.
"SOS Uniform Resource Identifier (URI) Parameter for Marking of Session Initiation Protocol (SIP) Requests related to Emergency Services", Milan Patel, 26-May-09. ( bytes): This document defines a new Session Initiation Protocol (SIP) Uniform Resource Identifier (URI) parameter intended for marking SIP registration requests related to emergency services. The usage of this new URI parameter complements the usage of the Service Uniform Resource Name (URN) and is not intended to replace it.
"Delay-Tolerant Networking Metadata Extension Block", Susan Symington, 3-Apr-09. ( bytes): This document defines an extension block that may be used with the Bundle Protocol [refs.DTNBP] within the context of a Delay-Tolerant Network architecture [refs.DTNarch]. This Metadata Extension Block is designed to be used to carry application-level information that DTN nodes can use to make DTN-level processing decisions regarding bundles, such as deciding whether to store a bundle or determining to which nodes to forward a bundle. The actual metadata that is carried in a metadata block must be formatted according to the metadata type that is identified in the block's metadata type field. One specific metadata type, for encoding metadata as URIs, is defined in this document. Other metadata types may be defined in separate documents.
"BU/BA Based Prefix Delegation Support for Mobile Networks", Behcet Sarikaya, Frank Xia, 13-Jul-09. ( bytes): This document defines prefix delegation support for mobile networks. Mobile Router dynamically requests its Mobile Network Prefixes from its Home Agents using Binding Update both at the home link and at the visited links. Home agents get the prefixes delegated using DHCPv6 Prefix Delegation or by other means and reply to the Mobile Router with Binding Acknowledgement.
"Multicast Support Requirements for Proxy Mobile IPv6", Hui Deng, Gang Chen, Thomas Schmidt, Pierrick Seite, Peng Yang, 13-Jul-09. ( bytes): This document summarizes requirements for multicast listener support in Proxy Mobile IPv6 (PMIPv6) scenarios. In correspondance to PMIPv6, multicast mobility management requirements do not request any active participation of the mobile node.
"IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios", Jari Arkko, Mark Townsley, 13-Jul-09. ( bytes): When IPv6 was designed, it was expected that the transition from IPv4 to IPv6 would occur more smoothly and expeditiously than experience has revealed. The growth of the IPv4 Internet and predicted depletion of the free pool of IPv4 address blocks on a foreseeable horizon has highlighted an urgent need to revisit IPv6 deployment models. This document provides an overview of deployment scenarios with the goal of helping to understand what types of additional tools the industry needs to assist in IPv4 and IPv6 co-existence and transition. This document was originally created as input to the Montreal co- existence interim meeting in October 2008, which led to the rechartering of the Behave and Softwire working groups to take on new IPv4 and IPv6 coexistence work. This document is published as a historical record of the thinking at the time.
"RTP Payload Format for MPEG-4 Audio/Visual Streams", Malte Schmidt, Frans Bont, Stefan Doehla, Jaehwan Kim, 3-Jul-09. ( bytes): This document describes Real-Time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for Media Type registration and the use of Session Description Protocol (SDP). Comments are solicited and should be addressed to the working group's mailing list at avt@ietf.org and/or the author(s).
"Using POST to add Members to Web Distributed Authoring and Versioning (WebDAV) Collections", Julian Reschke, 13-Jan-09. ( bytes): The Hypertext Transfer Protocol (HTTP) Extensions for the Web Distributed Authoring and Versioning (WebDAV) do not define the behavior for the "POST" method when applied to collections, as the base specification (HTTP) leaves implementers lots of freedom for the semantics of "POST". This has led to a situation where many WebDAV servers do not implement POST for collections at all, although it is well suited to be used for the purpose of adding new members to a collection, where the server remains in control of the newly assigned URL. As a matter of fact, the Atom Publishing Protocol (AtomPub) uses POST exactly for that purpose. On the other hand, WebDAV-based protocols such as the Calendar Extensions to WebDAV (CalDAV) frequently require clients to pick a unique URL, although the server could easily perform that task. This specification defines a discovery mechanism through which servers can advertise support for POST requests with the aforementioned "add collection member" semantics.
"Comparison of OSPF-MDR and OSPF-OR", Richard Ogier, 8-Mar-09. ( bytes): This document presents a comparison of two proposed MANET extensions of OSPF: OSPF-MDR and OSPF-OR. It includes a simulation comparison and a qualitative comparison, which discusses the different design choices and how they can affect performance and scalability.
"Comparison of OSPF-MDR and OSPF-MPR", Richard Ogier, 8-Mar-09. ( bytes): This document presents a comparison of two proposed MANET extensions of OSPF: OSPF-MDR and OSPF-MPR. It includes a qualitative comparison, which discusses the different design choices and how they can affect performance and scalability, and a simulation comparison.
"Alternative Approaches to Traffic Engineering Database Creation and Maintenance for Path Computation Elements", Greg Bernstein, 5-May-09. ( bytes): In order to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). Traditionally this TED has been obtained from a link state routing protocol supporting traffic engineering extensions. This document discusses possible alternatives and enhancements to the existing approach to TED creation. This document gives architectural alternatives for these enhancements and their potential impacts on network nodes, routing protocols, and PCEs.
"The OAuth Core Protocol", Eran Hammer-Lahav, Blaine Cook, 23-Mar-09. ( bytes): This document specifies the OAuth core protocol. OAuth provides a method for clients to access server resources on behalf of another party (such a different client or an end user). It also provides a redirection-based user agent process for end users to authorize access to clients by substituting their credentials (typically, a username and password pair) with a different set of delegation- specific credentials.
"A Profile for AS Adjacency Attestation Objects", Geoff Huston, George Michaelson, 28-May-09. ( bytes): This document defines a standard profile for AS Adjacency Attestation Objects (AAOs). An AAO is a digitally signed object that provides a means of verifying that an AS has made an attestation that it has a inter-domain routing adjacency with one or more other AS's, with the associated inference that this AS may announce or receive routes with these adjacent AS's in the inter-domain domain environment.
"Scalable Multihoming across IPv6 Local-Address Routing Zones Global-Prefix/Local-Address Stateless Address Mapping (SAM)", Remi Despres, 13-Jul-09. ( bytes): The continuous growth of routing tables in the core of Internet is a challenge. It would become overwhelming if each multihomed customer site would need a provider independent prefix to take full advantage of its multihoming. IPv6 has the potential to solve this problem, but a complete specification is still missing. This draft proposes an approach for a solution. The Stateless Address Mapping (SAM) model, introduced for this, is applicable to a hierarchy of routing zones with multihoming permitted at each level, and with each zone using local addresses for its internal routing plan. End-to-end transparency of the Internet is maintains across these local-address zones, thanks to a systematic encapsulation of global-address packets into local-address packets. Local addresses are statelessly derived from prefixes found in global addresses, and from static parameters of traversed zones. Global prefixes delegated by a zone to its child interfaces can be obtained by autoconfiguration, thanks to to a bidirectional correspondence between SAM local addresses and SAM global prefixes. Deployment can be incremental.
"RFC Editor Model (Version 1)", Olaf Kolkman, 8-Jun-09. ( bytes): The RFC Editor performs a number of functions that may be carried out by various persons or entities. The RFC Editor model presented in this document divides the responsibilities for the RFC Series into four functions: The RFC Series Editor, the Independent Submission Editor, the RFC Production Center, and the RFC Publisher. It also introduces the RFC Series Advisory Group and an (optional) Independent Submission Stream Editorial Board. The model outlined here is intended to increase flexibility and operational support options, provide for the orderly succession of the RFC Editor, and ensure the continuity of the RFC series, while maintaining RFC quality, maintaining timely processing, ensuring document accessibility, reducing costs, and increasing cost transparency.
"Clearance Sponsor Attribute", Sean Turner, 4-Mar-09. ( bytes): This document defines the clearance sponsor attribute. This attribute may be carried in a public key certificate in the Subject Directory Attributes extension, in an attribute certificate in the attribute field, in a directory as an attribute, or in protocols that support attributes.
"Device Owner Attribute", Sean Turner, 4-Mar-09. ( bytes): This document defines the deviceOwner attribute. This attribute may be carried in a public key certificate in the Subject Directory Attributes extension, in an attribute certificate in the attribute field, in a directory as an attribute, or in protocols that support attributes.
"Threat Model for Networks Employing AAA Proxies", Stefan Winter, Katrin Hoeper, 9-Mar-09. ( bytes): This memo defines a threat model for access networks with AAA proxies. Use cases of current and future applications in which AAA proxies are employed are described and it is discussed how proxies could launch attacks in the defined use cases. The risk associated with these attacks in each use case is analyzed. In addition, mitigation techniques used in current AAA deployments are discussed and best practices for mitigating the identified attacks are identified. As a result, this draft can serve as a guideline for risk assessments and problem mitigation by providers, implementers and protocol designers of systems with proxies.
"IANA Considerations for IAX: Inter-Asterisk eXchange Version 2", Ed Guy, 5-Oct-08. ( bytes): This document establishes the IANA registries for IAX, the Inter- Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for the Asterisk PBX and is targeted primarily at Voice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia.
"LMA Discovery for Proxy Mobile IPv6", Jouni Korhonen, Vijay Devarapalli, 24-Feb-09. ( bytes): Large Proxy Mobile IPv6 deployments would benefit from a functionality, where a Mobile Access Gateway could dynamically discover a Local Mobility Anchor for a Mobile Node attaching to a Proxy Mobile IPv6 domain. The purpose of the dynamic discovery functionality is to reduce the amount of static configuration in the Mobile Access Gateway. This specification describes a number of possible dynamic Local Mobility Anchor discovery solutions.
"IMAP Annotation for Indicating Message Authentication Status", Murray Kucherawy, 17-Apr-09. ( bytes): This memo defines an application of the IMAP (Internet Message Access Protocol) Annotations facility whereby a server can store and retrieve meta-data about a message relating to message authentication tests performed on the message and the corresponding results.
"Operating MPLS Transport Profile LSP in Loopback Mode", Sami Boutros, Siva Sivabalan, George Swallow, David Ward, Stewart Bryant, Carlos Pignataro, Rahul Aggarwal, Nabil Bitar, Martin Vigoureux, Italo Busi, Lieven Levrau, Laurent Ciavaglia, 9-Mar-09. ( bytes): This document specifies an extension to MPLS Operation, Administration, and Maintenance (OAM) to operate an MPLS Transport Profile(MPLS-TP) Label Switched Path (LSP) in loopback mode for management purpose. This extension can be used to loop either all traffic (i.e, data and control traffic) or only specific OAM traffic at a specified LSR on the path of the MPLS-TP LSP back to the source.Contents
"PREFIX64 Comparison", Hiroshi Miyata, Marcelo Bagnulo, 9-Mar-09. ( bytes): This draft compares different IPv6 prefix formats that can be used by IPv6-IPv4 translator to represent IPv4 addresses in the IPv6 Internet. The goal of the draft is asses the benefits and problems of each proposed format and make a recommendation about which prefix to use in the different scenarios considered.
"Routing and Addressing in Next-Generation EnteRprises (RANGER)", Fred Templin, 6-Feb-09. ( bytes): RANGER is an architectural framework for scalable routing and addressing in next generation enterprise networks. The term "enterprise network" within this context extends to a wide variety of use cases and deployment scenarios, where an "enterprise" can be as small as a SOHO network, as dynamic as a Mobile Ad-hoc Network, as complex as a multi-organizational corporation, or as large as the global Internet itself. Such networks will require an architected solution for the coordination of routing and addressing plans with accommodations for scalability, provider-independence, mobility, multi-homing and security. These considerations are particularly true for existing deployments, but the same principles apply even for clean-slate approaches. The RANGER architecture addresses these requirements, and provides a comprehensive framework for IPv6/IPv4 coexistence.
"Defining Well-Known URIs", Mark Nottingham, Eran Hammer-Lahav, 11-Jul-09. ( bytes): This memo defines a path prefix for "well-known locations" in URIs.
"RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1) Protocol Support", Glen Zorn, 28-Jul-09. ( bytes): This document defines a set of RADIUS Attributes which are designed to provide RADIUS support for IEEE 802.16 Privacy Key Management Version 1.
"IPv6 destination header option for IPv4 translator mapping notification", Remi Denis-Courmont, 9-Mar-09. ( bytes): This memo defines a new IPv6 Destination header option to convey the transport mapping information from an IPv4-IPv4 protocol translator to the IPv6 end of a protocol-translated packet flow.
"IPv6 Ephemeral Addresses", Hiroshi Kitamura, Shingo Ata, Masayuki Murata, 28-Jul-09. ( bytes): This document describes a new address type that is called "Ephemeral Addresses". Ephemeral Addresses are designed to be used as clients' source addresses of TCP / UDP sessions. An idea Ephemeral Addresses is simple enough. They are achieved by deriving existing "ephemeral ports" specifications. In other words, they are achieved by naturally upgrading their concept from the port space to the address space. Since Ephemeral Addresses functions are implemented only in the kernel side of the OS, we can use the Ephemeral Addresses functions in current exiting enormous client applications without modifying them. Ephemeral Addresses functions can contribute to various types of security enhancements that include privacy protections etc.
"Guidelines for Internationalized Email Deployment", Jiankang Yao, XiaoDong Lee, 12-Jul-09. ( bytes): Key RFCs for internationalized email address have been published, specifying the basic protocols for using it. This document provides some guidelines for implementing the email systems that support Email Address Internationalization (EAI). Its aim is to give some suggestions and help the engineers to implement these protocols.
"RADIUS Support for Prefix Authorization", Behcet Sarikaya, Frank Xia, 9-Mar-09. ( bytes): This document specifies a new attribute for supporting prefix authorization. Using RADIUS protocol, a client requests prefixes from a server; the client gives back the prefixes to the server; the client is responsible for renewing the prefixes when the lifetime expires. The RADIUS server can also renumber prefixes. RADIUS clients can be home agents in MIPv6 and NEMO scenario, local mobile anchors in Proxy MIPv6 scenario, or common access routers.
"Using mLDP through a Backbone where there is no Route to the Root", IJsbrand Wijnands, Eric Rosen, Maria Napierala, 7-Apr-09. ( bytes): The control protocol used for constructing Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths ("MP LSPs") contains a field that identifies the address of a "root node". Intermediate nodes are expected to be able to look up that address in their routing tables. However, if the route to the root node is a BGP route, and the intermediate nodes are part of a BGP-free core, this is not possible. This document specifies procedures which enable a MP LSP to be constructed through a BGP-free core. In these procedures, the root node address is temporarily replaced by an address which is known to the intermediate nodes.
"RTP Payload Format for Bluetooth's SBC audio codec", Christian Hoene, Frans Bont, 16-Jun-09. ( bytes): 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.
"Requirements for the Support of Continuously Varying Values in Presence", Martin Thomson, 2-Jul-09. ( bytes): The attributes of continuous-valued data are examined in respect to presence systems. The limitations of the existing presence system with respect to continuous-valued data is examined. Requirements are formulated that would enable the use of the presence system for this data, with an emphasis on providing the watcher with a means of control over the measurement process.
"IPv4 Connectivity Access in the Context of IPv4 Address Exhaustion: Port Range based IP Architecture", Mohammed Boucadair, Pierre Levis, Gabor Bajko, Teemu Savolainen, 3-Jul-09. ( bytes): This memo proposes a solution, based on fractional addresses, to face the IPv4 public address exhaustion. It details the solution and presents a mock-up implementation, with the results of tests that validate the concept. It also describes architectures and how fractional addresses are used to overcome the IPv4 address shortage. A comparison with the alternative Carrier-Grade NAT (CG-NAT) solutions is also elaborated in the document. The IPv6 variant of this solution is described in a companion draft.
"IPv6 Inverse Neighbor Discovery Update", Pascal Thubert, Eric Levy-Abegnoli, 27-Feb-09. ( bytes): This draft updates the Inverse Discovery Specification [RFC3122] to provide Secure Neighbor Discovery. The behaviour of the protocol is slightly amended to enable an easier management of the addresses on a link and enable Secure ND.
"Renumbering still needs work", Brian Carpenter, Randall Atkinson, Hannu Flinck, 6-May-09. ( bytes): This document reviews the existing mechanisms for site renumbering for both IPv4 and IPv6, and identifies operational issues with those mechanisms. It also summarises current technical proposals for additional mechanisms. Finally there is a gap analysis identifying possible areas for future work.
"Local Mobile Anchor Discovery Using DHCP", Frank Xia, Behcet Sarikaya, 29-Apr-09. ( bytes): This draft defines a DHCP-based scheme to enable dynamic discovery of a Local Mobility Anchor (LMA) in Proxy Mobile IPv6. Existing Dynamic Host Configuration Protocol (DHCP) options are used allowing a Mobile Access Gateway (MAG) to request the LMA's IP address, Fully Qualified Domain Name (FQDN), or home network prefix via the DHCP response.
"Service Differentiation Using Virtualization of Mobile Network", Chulhyun Park, Eun Paik, 11-Mar-09. ( bytes): A mobile network can be multihomed as described in [RFC4980]. This document describes the experimental result of service differentiation using multihoming of multiple prefixes. The multiple prefixes in IPv6 NEMO implements multiple virtual mobile network on a single physical NEMO. Then, service differentiation can be achieved using several virtual mobile networks that exist on a single mobile network. As a result, this configuration can be used for service differentiation for each mobile network node inside the mobile network by prioritizing among the virutal mobile networks or forwarding traffic from each virtual mobile network to different access networks. In this experiment, a mobile router with multiple interfaces can make connection to several access networks simultaneoulsly.
"CGA Extension Header of IPv6", Dong Zhang, Padmanabha Nallur, 26-Jun-09. ( bytes): This document specifies a method to carry Cryptographically Generated Addresses (CGA) information in an IPv6 extension header to protect the IPv6 network from address spoofing.
"Framework and Requirements for MPLS Over Composite Link", So Ning, Andrew Malis, Dave McDysan, Lucy Yong, Frederic JOUNAY, Yuji Kamite, 9-Jul-09. ( bytes): This document states a traffic distribution problem in today's IP/MPLS network when multiple links are configured between two routers. The document presents motivation, a framework and requirements. It defines a composite link as a group of parallel links that can be considered as a single traffic engineering link or as an IP link, and used for MPLS. The document primarily focuses on MPLS traffic controlled through control plane protocols, the advertisement of composite link parameter in routing protocols, and the use of composite links in the RSVP-TE and LDP signaling protocols. Interactions with the data and management plane are also addressed. Applicability can be between a single pair of MPLS- capable nodes, a sequence of MPLS-capable nodes, or a multi-layer network connecting MPLS-capable nodes.
"Learning the IPv6 Prefixes of an IPv6/IPv4 Translator", Dan Wing, Xuewei Wang, Xiaohu Xu, 13-Jul-09. ( bytes): Some IPv6 applications obtain IPv4 address literals and want to communicate with those IPv4 hosts through an IPv6/IPv4 translator. The IPv6 application can send an IPv6 packet through the translator if it knows the IPv6 prefix of the IPv6/IPv4 translator. In many IPv6/IPv4 translation deployments, that IPv6 prefix is not fixed; rather, the prefix is chosen by the network operator. This specification provides three methods for a host to learn the IPv6 prefix of its IPv6/IPv4 translator. Unicast, any-source multicast (ASM), and source-specific multicast (SSM) are supported.
"An extension to RELOAD to support Direct Response and Relay Peer routing", XingFeng Jiang, Roni Even, David Bryan, 29-May-09. ( bytes): This document proposes an extension to RELOAD to support direct response and relay peer routing modes. RELOAD recommends symmetric recursive routing for routing messages. The new extensions provide a shorter route for responses and describes the potential cases where these extensions can be used.
"LDAP schema for storing SCRAM secrets", Alexey Melnikov, 30-Jul-09. ( bytes): This memo describes how authPassword LDAP attribute can be used for storing secrets used by Salted Challenge Response (SCRAM) Simple Authentication and Security Layer (SASL) Mechanism.Note A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to ietf-sasl@imc.org.
"DTN Bundle Metadata Confidentiality Specification", Peter Lovell, 8-Mar-09. ( bytes): This document described a confidentiality ciphersuite for metadata in Delay-Tolerant Networking (DTN) Bundle Protocol (BP) bundles. The content has been incorporated into the Bundle Security Protocol specification [refs.DTNBSP] and this separate document is now withdrawn.
"DTN EID References Specification", Peter Lovell, 8-Mar-09. ( bytes): This document described a convention for storing references to Delay- Tolerant Networking (DTN) Bundle Protocol (BP) endpoint identifiers [EIDs] within extension blocks of bundles. The content has been incorporated into RFC 5050 [refs.DTNBP] and this separate document is now withdrawn.
"A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments", Greg Bernstein, 5-May-09. ( bytes): The operation of optical networks requires information on the physical characterization of optical network elements, subsystems, devices, and cabling. These physical characteristics may be important to consider when using a GMPLS control plane to support path setup and maintenance. This document discusses how the definition and characterization of optical fiber, devices, subsystems, and network elements contained in various ITU-T recommendations can be combined with GMPLS control plane protocols and mechanisms to support Impairment Aware Routing and Wavelength Assignment (IA-RWA) in optical networks.
"Information Model for Impaired Optical Path Validation", Greg Bernstein, Cisco Systems, 8-Jul-09. ( bytes): This document provides an information model for the optical impairment characteristics of optical network elements for use in GMPLS/PCE control plane protocols and mechanisms. This information model supports Impairment Aware Routing and Wavelength Assignment (IA-RWA) in optical networks in which path computation and optical path validation are essential components. This is not a general network management information model. This model is based on ITU-T defined optical network element characteristics as given in ITU-T recommendation G.680 and related specifications. This model is intentionally compatible with a previous impairment free optical information model used in optical path computations and wavelength assignment.
"Time synchronization method in packet-switched transport network for mobile backhaul", Li He, Fei Su, 8-Apr-09. ( bytes): This document introduces a phase/time transfer application mode employing popular packet-based method IEEE Std 1588-2008 i.e. PTP with support of common physical layer method Synchronous Ethernet in a packet-switched transport network for mobile backhaul and phase/ time transfer protection switching.
"A Uniform Resource Name (URN) for Early Warning Emergency Services and Location-to-Service Translation (LoST) Protocol Usage", Brian Rosen, Henning Schulzrinne, Hannes Tschofenig, 13-Jul-09. ( bytes): The Common Alerting Protocol (CAP) is an XML document format for exchanging emergency alerts and public warnings. Different organizations issue alerts for specific geographic regions. The Location-to-Service Translation (LoST) protocol provides a way to discover servers that distribute these alerts for a geographical region. This document defines the Service Uniform Resource Names (URN)s for warnings in the same way as they have been defined with RFC 5031 for citizen-to-authority emergency services. Additionally, this document suggests to use LoST for the discovery of servers distributing alerts.
"Additional Multicast Control Extensions for ANCP", Francois Le Faucheur, Roberta Maglione, Tom Taylor, 9-Mar-09. ( bytes): This memorandum aims at defining additional ANCP protocol extensions (beyond those already defined) to support some of the Multicast use cases defined in the ANCP Framework document that are not yet supported.
"NAT444 with ISP Shared Address", Yasuhiro Shirasaki, Shin Miyakawa, Akira Nakagawa, Jiro Yamaguchi, Hiroyuki Ashida, 9-Mar-09. ( bytes): This document describes one of the network models that is designed for smooth transition to IPv6. It is called NAT444 model. NAT444 model is composed of IPv6, and IPv4 with Large Scale NAT (LSN). 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.
"On Secure Neighbor Discovery Proxying Using 'Symbiotic' Relationship", Wassim Haddad, Mats Naslund, 29-Jul-09. ( bytes): This document introduces a simple mechanism which enables a host using a cryptographically generated IPv6 address to delegate the task of secure neighbor discovery to another node, i.e., proxying, by means of establishing a 'symbiotic' relationship with that node.
"Multiprotocol Label Switching Transport Profile Ring Protection Analysis", Jian Yang, Hui Su, 30-Apr-09. ( bytes): The three potential solutions to the MPLS-TP ring protection were addressed in the report of the IETF-ITU-T Joint Working Team(JWT). Each solution has different attributes and advantages. This document provides an analysis for MPLS-TP based on the ring protection.
"Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP)", Miguel Garcia, Simo Veikkolainen, Robert Gilman, 8-Jul-09. ( bytes): 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 a number of miscellaneous SDP capabilities. In particular, this memo provides a mechanism to negotiate media titles ("i=" line for each media), connection data ("c=" line), and media bandwidth ("b=" line).
"BFD Extensions in Support of Performance Measurement", Xinchun Guo, Mach Chen, 9-Mar-09. ( bytes): This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol to support Performance Measurement for IP/MPLS network. Specifically, it defines BFD extensions for measuring packet loss, delay and delay variation for arbitrary paths between systems.
"PMIPv6 Extensions for Multicast", Hitoshi Asaeda, Pierrick Seite, Jinwei Xia, 13-Jul-09. ( bytes): This document describes Proxy Mobile IPv6 (PMIPv6) extensions to support IP multicast. The Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA) are the mobility entities defined in the PMIPv6 protocol. The proposed protocol extension provides; 1) a dedicated multicast tunnel (M-Tunnel) between LMA and MAG, and 2) local routing to deliver IP multicast packets for mobile nodes. This document defines the roles of LMA and MAG to support IP multicast for the mobile nodes.
"IPv4 Support for DSMIPv6 IPv6 Home Link", Domagoj Premec, Jouni Korhonen, 13-Jul-09. ( bytes): Mobile IPv6 Support for Dual Stack Hosts and Routers allows the mobile node to maintain connectivity for its IPv6 home address while attached to the IPv4-only links. This document specifies how a mobile node can maintain connectivity for its IPv4 home address while attached to an IPv6 home link.
"The A+P Approach to the IPv4 Address Shortage", Randy Bush, 13-Jul-09. ( bytes): We are facing the exhaustion of the IANA IPv4 free IP address pool. Unfortunately, IPv6 is not yet deployed widely enough to fully replace IPv4, and it is unrealistic to expect that this is going to change before we run out of IPv4 addresses. Letting hosts seamlessly communicate in an IPv4-world without assigning a unique globally routable IPv4 address to each of them is a challenging problem. This draft discusses the possibility of address sharing by treating some of the port number bits as part of an extended IPv4 address (Address plus Port, or A+P). Instead of assigning a single IPv4 address to a customer device, we propose to extended the address by "stealing" bits from the port number in the TCP/UDP header, leaving the applications a reduced range of ports. This means assigning the same IPv4 address to multiple clients (e.g., CPE's, mobile phones), each with its assigned port-range. In the face of IPv4 address exhaustion, the need for addresses is stronger than the need to be able to address thousands of applications on a single host. If address translation is needed, the end-user should be in control of the translation process - not some smart boxes in the core.
"Diameter MIP6 Feature Vector Additional Bit Allocations", Jouni Korhonen, 10-Jun-09. ( bytes): During the Mobile IPv6 Split Scenario bootstrapping the Mobile IPv6 Home Agent and the Authentication, Authorization, and Accounting server may exchange a set of authorized mobility capabilities. This document defines new mobility capability flags that are used to authorize per Mobile Node route optimization, Multiple Care-of Address and user plane traffic encryption support. Furthermore, this document also defines a capability flag of indicating whether the Home Agent is authorized to act as a stand alone Virtual Private Network gateway.
"Problems with the use of IPsec as the security protocol for Mobile IPv6", Basavaraj Patil, Domagoj Premec, Charles Perkins, Hannes Tschofenig, 13-Jul-09. ( bytes): Mobile IPv6 as specified in RFC3775 relies on IPsec for security. An IPsec SA between the mobile node and the home agent provides security for the mobility signaling. Use of IPsec for securing the data traffic between the mobile node and home agent is optional. This document analyses the implications of the design decision to mandate IPsec as the default security protocol for Mobile IPv6 and consequently Dual-stack Mobile IPv6 and recommends revisiting this decision in view of the experience gained from implementation and adoption in other standards bodies.
"Definition of Managed Objects for the MANET Optimized Link State Routing Protocol version 2", Robert Cole, Thomas Clausen, 21-Feb-09. ( bytes): 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 and managing aspects of the Optimized Link State Routing protocol version 2. The Optimized Link State Routing MIB also reports state information, performance metrics, and notifications. In addition to configuration, this additional state and performance information is useful to management stations troubleshooting Mobile Ad-Hoc Networks routing problems.
"Harmless IPv6 Address State Extension (Uncertain State)", Hiroshi Kitamura, Shingo Ata, Masayuki Murata, 28-Jul-09. ( bytes): This document describes a new IPv6 address state called "Uncertain" address state as an extension of IPv6 address state specification. "Uncertain" address state is designed to introduce two functionalities. One is to achieve "Temporary Address Reservation" function. The other is to avoid a DAD (Duplicate Address Detection) time consuming problem for dynamically created addresses. New "Uncertain" Address State is inserted between "Tentative" address state and "Valid" address state. After "Tentative" address state (DAD operation has finished) for a newly created address, its state will enter to "Uncertain" address state. While an address stay at "Uncertain" address state, the address is behaved as if it is temporary reserved by the node exclusively. (The other nodes can not obtain such a reserved address.) When it becomes really necessary for the node to utilize the temporary reserved address, its address state is changed into "Valid" address state without accompanying time consuming DAD operation. By these procedures, we can avoid the DAD problem.
"DHCPv6 and CGA Interaction: Problem Statement", Tim Chown, Sheng Jiang, Sean Shen, 17-Jun-09. ( bytes): This document describes potential issues in the interaction between DHCPv6 and Cryptographically Generated Addresses (CGAs). Firstly, the scenario of using CGAs in DHCPv6 environments is discussed. Some operations are clarified for the interaction of DHCPv6 servers and CGA-associated hosts. We then also discuss how CGAs and DHCPv6 may have mutual benefits for each other, including using CGAs in DHCPv6 operations to enhance its security features and using DHCPv6 to provide the CGA generation function.
"IPv6-to-IPv6 Network Address Translation (NAT66)", Margaret Wasserman, Fred Baker, 9-Mar-09. ( bytes): This document describes a stateless, transport-agnostic IPv6-to-IPv6 Network Address Translation (NAT66) function that provides the address independence benefit associated with IPv4-to-IPv4 NAT (NAT44) while minimizing, but not completely eliminating, the problems associated with NAT44.
"Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Multi-Party Text Chat", Peter Saint-Andre, Salvatore Loreto, Fabio Forno, 8-Mar-09. ( bytes): This document defines a bi-directional protocol mapping for the exchange of instant messages in the context of a many-to-many chat session among users of the Session Initiation Protocol (SIP) and users of the Extensible Messaging and Presence Protocol (XMPP). Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP).
"Real-time Transport Control Protocol (RTCP) in Overlay Multicast", Jegadish Devadoss, Joerg Ott, Igor Curcio, 9-Mar-09. ( bytes): 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 needs 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.
"Session Initiation Protocol (SIP) Event Package for Content Push Delivery", Martin Dolly, Salvatore Loreto, Kent Bogestam, 6-Mar-09. ( bytes): This document specifies an event package for content push delivery protocol over SIP. The purpose is to allow an application on a UA to subscribe to updates to its own application events containing either content or references to the content. This document describes how content can be pushed out to an application by the use of push events. A new SIP event package is defined for notification of push events for content delivery.
"Virtual IPv6 Connectivity for IPv4-Only Networks", Christian Vogt, Alain Durand, 27-Jul-09. ( bytes): Although the impetus to invest in interworking between IP versions 4 and 6 is initially on the side of early IPv6 adopters, more substantial IPv6 deployment in the future will shift this impetus towards the side of the legacy IPv4 Internet. However, interworking techniques for IPv4-only networks are as yet largely unexplored. This document proposes Virtual IPv6 Connectivity, a technique for IPv4-only networks to communicate with the IPv6 Internet.
"Threshold Secret Sharing", David McGrew, Praveen Patnala, Alfred Hoenes, 9-Mar-09. ( bytes): Threshold secret sharing (TSS) provides a way to generate N shares from a value, so that any M of those shares can be used to reconstruct the original value, but any M-1 shares provide no information about that value. This method can provide shared access control on key material and other secrets that must be strongly protected. This note defines a threshold secret sharing method based on polynomial interpolation in GF(256) and a format for the storage and transmission of shares. It also provides usage guidance, describes how to test an implementation, and supplies test cases.
"Considerations for IPv6 Address Selection Policy Changes", Tim Chown, 13-Jul-09. ( bytes): Where the source and/or destination node of an IPv6 communication is multi-addressed, a mechanism is required for the initiating node to select the most appropriate address pair for the communication. RFC 3484 (IPv6 Default Address Selection) [RFC3484] defines such a mechanism for nodes to perform source and destination address selection. While RFC3484 recognised the need for implementations to be able to change the policy table, it did not define how this could be achieved. Requirements have now emerged for administrators to be able to dynamically change the RFC 3484 policy tables from a central control point, and for nomadic hosts to be able to obtain the policy for the network that they are currently attached to without manual user intervention. This text discusses considerations for such policy changes, including examples of cases where a change of policy is required, and the likely frequency of such policy changes. This text also includes some discussion on the need to also update RFC 3484, where default policies are currently defined.
"Comcast's ISP Experiences In a P4P Technical Trial", Chris Griffiths, Jason Livingood, Laird Popkin, Richard Woundy, Yang Yang, 12-Jun-09. ( bytes): This document describes the experiences of Comcast, a large cable broadband Internet Service Provider (ISP) in the U.S., in a Proactive Network Provider Participation for P2P (P4P) technical trial in July 2008. This trial used P4P iTracker technology being considered by the IETF, as part of the Application Layer Transport Optimization (ALTO) working group.
"Authenticated Encryption with AES-CBC and HMAC-SHA1 (and other generic combinations of ciphers and MACs)", David McGrew, 9-Mar-09. ( bytes): This document specifies algorithms for authenticated encryption with additional authenticated data (AEAD) that are based on the composition of the Advanced Encryption Standard (AES) in the Cipher Block Chaining (CBC) mode of operation for encryption, and the HMAC- SHA1 message authentication code (MAC). It also separately defines a generic composition method that can be used with other MACs and randomized ciphers (that is, ciphers that use random initialization vectors). These algorithms are randomized, and thus are suitable for use with applications that cannot provide distinct nonces to each invocation of the AEAD encrypt operation.
"BGP Prefix Origin Validation", Pradosh Mohapatra, John Scudder, Geoff Huston, 27-Jul-09. ( bytes): A BGP route associates an address prefix with a set of autonomous systems (AS) that identify the interdomain path the prefix has traversed in the form of BGP announcements. This set is represented as the AS_PATH attribute in BGP and starts with the AS that originated the prefix. To help reduce well-known threats against BGP including prefix hijacking 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.
"IPv4/v6 NAT With Explicit Control (NAT-XC)", Keith Moore, 8-Mar-09. ( bytes): This document describes a mechanism called NAT-XC (for NAT with Explicit Control) for translating between IPv4 and IPv6. NAT-XC is distinguished from other IPv4/IPv6 translations schemes in that it separates the translation between IPv4 and IPv6 from the management of address bindings for such a translation; and is designed to allow applications to be explicitly aware of, and control, their address bindings. NAT-XC can be used by both IPv4 clients wishing to communicate via IPv6, and IPv6 clients wishing to communicate via IPv4. NAT-XC appears to be usable in a wide variety of scenarios requiring communication across IPv4/IPv6 boundaries.
"Healthy Food and Special Dietary Requirements for IETF meetings", Mary Barnes, 8-Mar-09. ( bytes): 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.
"DHCP options for Access Point Name and attach type indication", Basavaraj Patil, Kuntal Chowdhury, Domagoj Premec, 8-Mar-09. ( bytes): Access Point Names are used in wireless networks which are based on 3GPP standards to identify a specific gateway element. A mobile node which attaches via a 3GPP access network indicates the gateway to which connectivity is desired by providing the gateways access point name, in the network attach signaling messages. This document specifies a new DHCP option which enables the mobile node to request connectivity to a gateway, identified by the access point name, in DHCP messages. A mobile node whose mobility is managed by the network using Proxy Mobile IPv6 protocol may perform a handover from one access technology to another. This document defines a DHCP option which enables the host to indicate to Proxy Mobile IPv6 elements in the access network if the attachment via the new interface is a handover or a new connection.
"Diameter Routing Problem Statement", Tina Tsou (Ting ZOU), 13-Jul-09. ( bytes): This document describes use cases that suggest a requirement to be able to add constraints to the existing Diameter routing mechanisms so that subsequent messages in a session pass through specific proxies that were on the initial path that set up the session. Routing between these proxies may use the present Diameter rules.
"Creation of a registry for DNS SRV record protocol names", Olafur Gudmundsson, Alfred Hoenes, 13-Jul-09. ( bytes): The DNS SRV record was been specified in RFC 2052 and RFC 2782. These two RFCs did not specify an IANA registry for names of the protocols using SRV records. This document creates such a registry and populates it.
"OAuth Access Tokens using credentials", Bill hOra, Stephen Farrell, 9-Mar-09. ( bytes): OAuth Access Tokens using credentials is a technique for allowing user agents to obtain an OAuth access token on behalf of a user without requiring user intervention or HTTP redirection to a browser. OAuth itself is documented in the OAuth Core 1.0 Specification.Editorial Note To provide feedback on this Internet-Draft, email the authors.
"The Solution for Pmipv6 Multicast Service", YuanKui ZHAO, Pierrick Seite, 13-Jul-09. ( bytes): To mobility scenario, multicast service is a valuable feature to those mobile customers. We need to consider how to integrate current multicast service in PMIPv6 domain. This draft will introduce this kind of solution about proxy mobile multicast. It explains the system solution and framework about how to provide the proxy mobile multicast system.
"Line identification in IPv6 Router Solicitation messages", Suresh Krishnan, Alan Kavanagh, Sven Ooghe, Balazs Varga, 14-Jul-09. ( bytes): In ethernet and PON based aggregation networks, several subscriber premises may be 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.
"Load Balancing based on IPv6 Anycast and pseudo-Mobility", Wanming Luo, XiaoDong Lee, Wei Mao, Mei Wang, 23-Mar-09. ( bytes): Load balancing is a key factor for both IPv4 to IPv6 transition mechnisms, e.g.NAT-PT or Tunnel broker, and Multihoming to improve their scalability and Robustness. In fact, that is a method, by which IP packet can be distributed across a pool of servers, instead of directing to a single server.Load balancing has been widely used by NAT, Web service and FTP service. However, current load balancing software and implementations have problems such as poor scalability, inability to balance session flow, long latency time and topological constraint on server pool. This document describes a method using pseudo-anycast and pseudo- mobility based on Mobile IPv6 to implement load balancing in session level in IPv6 network, by which those problems above can be solved. Futhermore, this method only need little modification to Mobile IPv6 in the servers' and agent's side; as for the general users, it need not any modification.
"Multicast VPN fast upstream failover", Thomas Morin, Yakhov Rekhter, Rahul Aggarwal, Wim Henderickx, Praveen Muley, 8-Jul-09. ( bytes): This document defines multicast VPN extensions and procedures that allow fast failover for upstream failures, by allowing downstream PEs to take into account the status of Provider-Tunnels (P-tunnels) when selecting the upstream PE for a VPN multicast flow, and extending BGP mVPN routing so that a C-multicast route can be advertised toward a standby upstream PE.
"Interworking between MPLS-TP and IP/MPLS", Riccardo Martinotti, Diego Caviglia, Nurit Sprecher, 6-Mar-09. ( bytes): Purpose of this ID is to illustrate interworking scenarios between network(s) supporting MPLS-TP and network(s) supporting IP/MPLS. Main interworking issues and open points are highlighted.
"IP Router Alert Considerations and Usage", Francois Le Faucheur, 3-Jul-09. ( bytes): The IP Router Alert Option is an IP option that alerts transit routers to more closely examine the contents of an IP packet. RSVP, PGM, IGMP/MLD and MRD are some of the protocols which make use of the IP Router Alert option. This document discusses security aspects, common practices and usage guidelines around the use of the current IP Router Alert option. Specifically, it provides recommendations on the use of Router Alert by new protocols, discusses controlled environments where existing protocols depending on Router Alert can be used effectively and discusses protection approaches for Service Providers. Finally it provides brief guidelines for Router Alert implementation on routers.
"Mobile IPv6 IPsec Route Optimization (IRO)", Arnaud Ebalard, 21-May-09. ( bytes): This memo specifies an improved alternate route optimization procedure for Mobile IPv6 designed specifically for environments where IPsec is used between peers (most probably with IKE). The replacement of the complex Return Routability procedure for a simple mechanism and the removal of HAO and RH2 extensions from exchanged packets result in performance and security improvements.
"Hierarchical OLSR", Yannick Lacharite, Maoyu Wang, Pascale Minet, Thomas Clausen, 13-Jul-09. ( bytes): This document describes the Hierarchical Optimized Link State Routing (HOLSR) mechanism for heterogeneous mobile ad hoc networks. In this specification a heterogeneous mobile ad hoc network is defined as a network of mobile routers that are characterized by different communication capabilities, such as communication channels, processing powers or energy levels. The HOLSR mechanism is an extension to the OLSRv2 protocol. HOLSR takes advantage of the router's distinct communications capabilities to reduce the routing control overhead in large heterogeneous ad hoc networks, thus improving the performance of the routing mechanism. More precisely, HOLSR defines a hierarchy in the network and presents a routing scheme for this hierarchical structure with a better scalability.
"The Remote Framebuffer Protocol", Tristan Richardson, John Levine, 30-Jul-09. ( bytes): RFB ("remote framebuffer") is a simple protocol for remote access to graphical user interfaces which allows a client to view and control a window system on another computer. Because it works at the framebuffer level RFB is applicable to all windowing systems and applications. This document describes the protocol used to communicate between an RFB client and RFB server. RFB is the protocol used in VNC, Virtual Network Computing.
"Using SCTP as a Transport Layer Protocol for HTTP", Preethi Natarajan, Paul Amer, Jonathan Leighton, Fred Baker, 9-Jul-09. ( bytes): Hyper-Text Transfer Protocol (HTTP) [RFC2616] requires a reliable transport for end-to-end communication. While historically TCP has been used for this purpose, this document proposes an alternative -- the Stream Control Transmission Protocol (SCTP) [RFC4960]. Similar to TCP, SCTP offers a reliable end-to-end transport connection to applications. Additionally, SCTP offers innovative services unavailable in TCP. This draft (i) specifies HTTP over SCTP's multistreaming service, (ii) lists open issues warranting more discussion and/or investigation, and (iii) shares some lessons learned from implementing HTTP over SCTP. Finally, this document highlights SCTP services that better match HTTP's needs than TCP.
"vCard XML Schema", Simon Perreault, 13-Jul-09. ( bytes): This document defines the XML schema of the vCard data format.
"A Session Identifier for the Session Initiation Protocol (SIP)", Hadriel Kaplan, 8-Mar-09. ( bytes): There are several reasons for having a globally unique session identifier for the same SIP session, which can be maintained across B2BUA's and other SIP middle-boxes. This draft proposes a new SIP header to carry such a value: Session-ID.
"Single PCN Threshold Marking by using PCN baseline encoding for both admission and termination controls", Daisuke Satoh, Yukari Maeda, Oratai Phanachet, Harutaka Ueno, 9-Mar-09. ( bytes): [I-D.ietf.pcn.architecture] defines two rates, admissible and supportable, per link that divide PCN traffic load into three states. PCN admission control and flow termination mechanisms operate in accordance with these three states. [I-D.ietf.pcn.baseline.encoding] defines one bit for packet marking. This document proposes an algorithm for marking and metering by using pre-congestion notification (PCN) baseline encoding for both flow admission and flow termination. The ratio of marked packets determines the three link states: no packets marked, some packets marked, and all packets marked. To achieve this marking behaviour, we use two token buckets. One is not used for marking but for a marking switch; the other is used for marking. The token bucket for marking has two thresholds. One is TBthreshold.threshold, already defined in [I-D.ietf-pcn- marking-behaviour], and the other is a new threshold, which is set to be the number of bits of a metered-packet smaller than the token bucket size. Therefore, the new threshold is larger than TBthreshold.threshold. If the amount of tokens is less than TBthreshold.threshold, all the packets are marked as defined in [I-D.ietf-pcn-marking-behaviour]. If the amount of tokens is less than the new threshold and greater than TBthreshold.threshold, one- Nth packets are marked. We evaluated the performance of admission control and flow termination using a simulation. For admission control, the results show that the performance of the algorithm was almost the same as, but slightly inferior to, that of CL [draft-briscoe-tsvwg-cl-phb-03]. For flow termination, the performance of the algorithm was almost the same as CL when the load was 1.2 times the supportable rate, but it was superior to CL when the load was high (two times the supportable rate). Furthermore, in the algorithm, over termination percentages of all the bottleneck links are almost the same in the case of multi-bottleneck. In CL, the over termination percentages of all the bottleneck links are different and those at upstream bottleneck links are higher than those at downstream bottleneck links because of accumulation of marked packets.
"A SIP Event Package for Subscribing to Changes to an HTTP Resource", Adam Roach, 7-Jul-09. ( bytes): The Session Initiation Protocol (SIP) is increasingly being used in systems that are tightly coupled with Hypertext Transport Protocol (HTTP) servers for a variety of reasons. In many of these cases, applications can benefit from being able to discover, in near-real- time, when a specific HTTP resource is created, changed, or deleted. This document proposes a mechanism, based on the SIP events framework, for doing so. This document further proposes that the HTTP work necessary to make such a mechanism work be extensible to support protocols other than SIP for monitoring HTTP resources.
"Alternative Proposal for Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations", Marc Petit-Huguenin, 9-Mar-09. ( bytes): This document proposes to use a shared TCP connection between a Traversal Using Relays around NAT (TURN) client and a TURN server instead of the multiple TCP connections proposed by [I-D.ietf-behave-turn-tcp]
"HTTP Cache-Control Extensions for Stale Content", Mark Nottingham, 28-Nov-08. ( bytes): This document defines two independent HTTP Cache-Control extensions that allow control over the use of stale responses by caches.
"Suite B Certificate and Certificate Revocation List (CRL) Profile", Jerome Solinas, L Zieglar, 1-Jul-09. ( bytes): This document specifies a base profile for X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) for use with the United States National Security Agency's Suite B Cryptography. The reader is assumed to have familiarity with RFC 5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile."
"Compressed Bundle Header Encoding (CBHE)", Scott Burleigh, 9-Apr-09. ( bytes): This document describes a convention by which Delay-Tolerant Networking (DTN) Bundle Protocol (BP) "convergence-layer" adapters may represent endpoint identifiers in a compressed manner within the primary blocks of bundles, provided those endpoint identifiers conform to the structure prescribed by this convention. CBHE compression is a convergence-layer adaptation. It is opaque to bundle processing. It therefore has no impact on the interoperability of different Bundle Protocol implementations, but instead affects only the interoperability of different convergence layer adaptation implementations.
"Multiple Tunnel Support for Mobile IPv4", Sri Gundavelli, Kent Leung, 3-Jul-09. ( bytes): This document defines extensions to Mobile IPv4 protocol for allowing a mobile node or a mobile router with multiple interfaces to register a care-of address for each of the available interfaces and to simultaneously establish multiple Mobile IP tunnels to the home agent, each through a different interface path. This capability is required for enabling a mobile node to utilize all the available wireless access links and build an higher aggregated data pipe to the home agent by setting the home address reachability over all of those tunnel paths.
"Indicating Message Authentication System Parameters", Murray Kucherawy, 17-Apr-09. ( bytes): This memo defines simple extensions to IMAP, POP3 and SMTP to permit a user's message reading software (Mail User Agent, or MUA) to determine the properties of its environment with respect to available message authentication services.
"Multiple Interfaces Problem Statement", Marc Blanchet, Pierrick Seite, 5-Jun-09. ( bytes): A multihomed host receives node configuration information from each of its access networks. Some configuration objects are global to the node, some are local to the interface. Various issues arise when multiple conflicting node-scoped configuration objects are received on multiple interfaces. Similar situations also happen with single interface host connected to multiple networks. This document describes these issues.
"Transmission of IPv4 Packets over ISATAP Interfaces", Fred Templin, 24-Mar-09. ( bytes): The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) specifies a Non-Broadcast, Multiple Access (NBMA) interface type for the transmission of IPv6 packets over IPv4 networks using automatic IPv6-in-IPv4 encapsulation. The original specifications make no provisions for the encapsulation and transmission of IPv4 packets, however. This document specifies a method for transmitting IPv4 packets over ISATAP interfaces.
"IPv6 Deployment in Internet Exchange Points (IXPs)", Roque Gagliano, 17-Feb-09. ( bytes): This document provides a guide for IPv6 deployment in Internet Exchange Points (IXP). It includes information about the switching fabric configuration, the addressing plan options and general organizational tasks to be performed. IXP are mainly a layer 2 device (the switching fabric) and in many case the best recommendations state that IPv6 traffic and management should not be handled differently than in IPv4.
"An IPv4 - IPv6 multicast translator", Stig Venaas, Hitoshi Asaeda, Shinsuke SUZUKI, Tomohiro Fujisaki, 9-Jul-09. ( bytes): This document describes an IPv4 - IPv6 translator device that embeds all IPv4 multicast group addresses into IPv6, and allows IPv6 hosts to receive from and send to any IPv4 multicast group. This mechanism can be also used to allow IPv4 hosts to receive from and send to a subset of the IPv6 multicast groups.
"Takeover Suggestion Flag for the ENRP Handle Update Message", Thomas Dreibholz, Xing Zhou, 5-Jul-09. ( bytes): This document describes the Takeover Suggestion Flag for the ENRP_HANDLE_UPDATE message of the ENRP protocol.
"Enterprise Number for Documentation Use", Pasi Eronen, David Harrington, 2-Mar-09. ( bytes): This document describes an Enterprise Number (also known as SMI Network Management Private Enterprise Code) for use in documentation.
"Specifying transport mechanisms in Uniform Resource Identifiers", Lloyd Wood, 12-May-09. ( bytes): This document describes a simple extension of the Uniform Resource Identifier (URI) format that allows preferred transport mechanisms, including protocols, ports and interfaces, to be specified as parseable additions to the scheme name. This explicit configuration is beneficial for separation of the HyperText Transfer Protocol (HTTP) from underlying transports, which has been increasingly recognised as useful when a variety of ways of transporting or configuring use of HTTP are available and a choice of mechanism to use must be indicated.
"BFD with Graceful Restart", Palanivelan A, 10-Jul-09. ( bytes): This document proposes an extension for Bidirectional Forwarding Detection (BFD) to support Graceful restart, in complementing Graceful restart support of the underlying protocol.This shall work consistently irespective of the bfd mode or protocol or the type of restart.This document describes the challenges to bfd in surviving a graceful restart and a generic solution to succeed.
"Expressing Confidence in a Location Object", Martin Thomson, 21-Jun-09. ( bytes): A confidence element is described that expresses the estimated probability that the associated location information is correct. This element conveys information that might otherwise be lost about the probability distribution represented by a region of uncertainty.
"Multi-hop Ad Hoc Wireless Communication", Emmanuel Baccelli, Charles Perkins, 5-Mar-09. ( bytes): This document describes some important 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.
"Explicit Notification Extension (ECN) Support for RTP Sessions", Ken Carlberg, Piers O'Hanlon, 13-Jul-09. ( bytes): This document describes a design to support Explicit Congestion Notification (ECN) for the RTP layer. The design defines a means of end-to-end negotiated support of ECN using the Session Description Protocol (SDP) and a new RTCP Extended Report.
"RTCP Extended Report for ECN Marked Packets", Piers O'Hanlon, Ken Carlberg, 29-Jun-09. ( bytes): This document describes a Real-Time Control Protocol (RTCP) Extended Report (XR) containing information derived from the reception of Explicit Congestion Notification (ECN) marked packets. This document is symbiotic with the approach described in [rtp-ecn], which presents one approach in establishing end-to-end ECN support for real-time sessions.
"draft-kumar-mpls-fec-to-nhlfe-mib-01", Subodh Kumar, Ronald Bonica, 13-Jul-09. ( bytes): This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for FEC-to-NHLFE for use in Multiprotocol Label Switching (MPLS)network. The MIB module defined in this document is used for configuring, and monitoring Forwarding Equivalence Class (FEC) to Next Hop Label Forwarding Entry (NHLFE) mappings and corresponding actions for use with Multiprotocol Label Switching (MPLS).
"Adaptive Routing Protocol", Xingwei Wang, ZhanKao Wen, WeiXin Wu, WeiDong Wang, Yao Fu, 5-May-09. ( bytes): This document describes an Adaptive Routing Protocol. It provides a routing protocol of Swarm Intelligence based network model, to a certain extent, this protocol can solve problems accompanied by network expansion and Dynamic network Increasing. This paper presents a routing protocol to adapt the self-organizing network, defines a set of terms and describes the message format and appropriate action sequences.
"Self-organizing network model", Xingwei Wang, XiuShuang Yi, Yu Wang, Ming Dong, Qiang Chen, 6-May-09. ( bytes): In this paper, a swarm intelligence based self-organizing network model was introduced to network providers. The problems of the existing network as well as the characteristics of the NGI (Next Generation Internet) were described to illustrate the motivation of the proposed self-organizing network model. A network architecture model based on swarm intelligence was introduced, the used technical terms was defined. The network parameters, network behaviors and node stability under the proposed model were described. Especially, some important QoS routing elements under the proposed model, such as the user QoS routing requirements, link satisfaction degree, utility computation, unicast path and multicast tree evaluation, mathematical model of QoS route optimization and small-world behaviors, were introduced.
"Definition of ACH TLV Structure", Sami Boutros, Stewart Bryant, Siva Sivabalan, George Swallow, David Ward, 29-May-09. ( bytes): In some application of the associated channel header (ACH), it is necessary to have the ability to include a set of TLVs to provide additional context information for the ACH payload. This document defines a number of TLV types. NOTE the family of Address Types is known to be incomplete. The authors request that members of the MPLS-TP community provide details of their required address formats in the form of text for the creation of an additional sections similar to Section 3.1. NOTE other TLV types will be added in further revisions of this document. The authors request that members if the MPLS-TP community requiring new TLVs to complete there MPLS-TP specifications provide details of their required TLV in the form of text for the creation of additional sections similar to Section 2.2.
"Security Context Addendum to IPsec", Joy Latten, George Wilson, Serge Hallyn, Trent Jaeger, 10-Jul-09. ( bytes): This document describes the high-level requirements needed within IPsec to support Mandatory Access Control (MAC) on network communications. It describes the extensions to the Security Architecture for the Internet Protocol [RFC4301] and the Internet Key Exchange Protocol Version 2 [RFC4306]. It also describes the negotiation of the security context for a particular Authentication Header (AH) [RFC4302] and/or Encapsulating Security Payload (ESP) [RFC4303] security association.
"draft-jml-ipsec-ikev1-security-context-01", Joy Latten, George Wilson, Serge Hallyn, Trent Jaeger, 10-Jul-09. ( bytes): This document describes the need for and use of a security context within IPsec. It describes the extension to the Internet IP Security Domain of Interpretation (IPsec DOI) [RFC2407] for the Internet Security Association and Key Management Protocol (ISAKMP) [RFC2408]. This extension supports the negotiation of the security context for a particular IP Authentication Header (AH) [RFC4302] or IP Encapsulating Security Payload (ESP) [RFC4303] security association.
"Including text under former copyright conditions", Brian Carpenter, Harald Alvestrand, 11-May-09. ( bytes): This document specifies a procedure for including text in an IETF document for which the current copyright conditions defined in RFC 5378 cannot readily be met.
"The Web Socket protocol", Ian Hickson, 7-Aug-09. ( bytes): This protocol enables two-way communication between a user agent running untrusted code running in a controlled environment to a remote host that understands the protocol. It is intended to fail to communicate with servers of pre-existing protocols like SMTP or HTTP, while allowing HTTP servers to opt-in to supporting this protocol if desired. It is designed to be easy to implement on the server side.Author's note This document is automatically generated from the same source document as the HTML5 specification. [HTML5] Please send feedback to either the hybi@ietf.org list or the whatwg@whatwg.org list.
"The Criterion of Session State", Gao yang, 6-Mar-09. ( bytes): There is debate on the topic of "Commit/Rollback of Offer/Answer on Unsuccessful re-INVITE". The reason of the confusion is some application/session usages of offer/answer imply the nest transaction(mean transaction theory, not mean sip transaction) concept, but whitout unambiguous definition. This paper reveal the concept of nest transactions in current RFC and other well known application/session usages. And then clarify that there is no ambiguous state of session modification using current RFC definition.
"Content-Type Processing Model", Adam Barth, Ian Hickson, 31-May-09. ( bytes): Many web servers supply incorrect Content-Type headers with their HTTP responses. In order to be compatible with these servers, user agents must consider the content of HTTP responses as well as the Content-Type header when determining the effective media type of the response. This document describes an algorithm for determining the effective media type of HTTP responses that balances security and compatibility considerations.
"Connection verification for MPLS Transport Profile LSP", Sami Boutros, Siva Sivabalan, George Swallow, David Ward, Stewart Bryant, 9-Mar-09. ( bytes): This document specifies method for verifying the connection of an MPLS Transport Profile(MPLS-TP) Label Switched Path (LSP) for management purpose. The proposed extension is based on MPLS Operation, Administration, and Maintenance (OAM). The goal is to verify that an MPLS-TP is properly setup in both control and data planes, as well as to record the identities of all the LSRs along the path of MPLS-TP LSP.
"Private Extension to the Session Initiation Protocol (SIP) for Debugging", Peter Dawes, 13-Jul-09. ( bytes): 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.
"Link-based Resource Descriptor Discovery", Eran Hammer-Lahav, 23-Mar-09. ( bytes): This memo describes LRDD (pronounced 'lard'), a process for obtaining information about a resource identified by a URI. The 'information about a resource', a resource descriptor, provides machine-readable information that aims to increase interoperability and enhance the interaction with the resource. This memo only defines the process for locating and obtaining the descriptor, but leaves the descriptor format and its interpretation out of scope.
"Performance Monitoring of MPLS Transport Profile LSP", Sami Boutros, Siva Sivabalan, George Swallow, David Ward, Stewart Bryant, 9-Mar-09. ( bytes): This document specifies an extension to MPLS Operation, Administration, and Maintenance (OAM) for monitoring the performance of an MPLS Transport Profile(MPLS-TP) Label Switched Path (LSP) with respect to packet loss and unidirectional delay/jitter.
"MPLS-TP Fault OAM", Sami Boutros, Siva Sivabalan, George Swallow, David Ward, Stewart Bryant, 13-Jul-09. ( bytes): This draft specifies a fault management indications for MPLS Transport Profile(MPLS-TP) Label Switched Paths (LSPs). The notification mechanism employs a generic method for a Maintenance End Point (MEP) or Maintenance Intermediate Point (MIP) to indicate a fault on an MPLS-TP LSP. A new MPLS Operation, Administration, and Maintenance (OAM) message is defined.
"Internationalizing Domain Names in Applications (IDNA) version 2", Paul Hoffman, 4-Mar-09. ( bytes): IDNA has been a world-wide success since it was introduced over five years ago. However, it has some notable deficiencies, including being tied to an old version of the Unicode standard and needless restrictions that prevented some languages from being used. This document describes IDNA version 2, which rectifies those problems while making the fewest changes necessary to the original protocol.
"Source Address Finding (SAF) for IPv6 Translation Mechanisms", Dave Thaler, 7-Jul-09. ( bytes): There are various recent proposals that would result in IPv6 translation becoming permanent. RFC 3424 discusses UNilateral Self- Address Fixing (UNSAF) mechanisms which are required for applications to work with most translation schemes, points out a number of problems with them, and requires an exit strategy for any UNSAF mechanism. This document discusses an alternative to UNSAF mechanisms should IPv6 translation become permanent.
"Embedding Host Identity Tags Data in DNS", Oleg Ponomarev, Andrei Gurtov, 13-Jul-09. ( bytes): This document proposes conventions to access and manage Host Identity Tag (HIT) mappings using the Domain Name System (DNS) interface.
"The HTTP Sec-From Header", Adam Barth, Collin Jackson, Ian Hickson, 31-Jul-09. ( bytes): This document defines the HTTP Sec-From header. The Sec-From header is added by the user agent to describe the security contexts that caused the user agent to initiate an HTTP request. HTTP servers can use the Sec-From header to mitigate against Cross-Site Request Forgery (CSRF) vulnerabilities.
"Multihoming Problem Statement in NetLMM", Mohana Jeyatharan, Chan-Wah Ng, 9-Mar-09. ( bytes): The Proxy Mobile Internet Protocol version 6 (PMIPv6) supports multihoming whereby a mobile node (1) gets assigned prefixes by the local mobility anchor which are associated with an interface of a mobile node and are managed by the PMIPv6 elements as a single IP mobility session, and (2) can connect to a Proxy Mobile IPv6 domain through multiple interfaces for simultaneous access and get assigned a different set of prefix(es) per interface, since being each interface managed via an independent mobility session. However, PMIPv6 needs multihoming enhancements such that it needs the ability to instantiate additional IP mobility sessions associated with an already active interface or a secondary interface of the mobile node which has an established IP mobility session at a local mobility anchor (LMA), the ability to selectively share home network prefix(es) across access technology types and extended support for multiple IP mobility sessions in a scenario where multiple interfaces of the mobile node are connected to a single mobile access gateway (MAG). This memo highlights such required enhancements to PMIPv6 multihoming with respect to improved operations and extended applicability to different deployment scenarios.
"Roadmap for Cryptographic Authentication of Routing Protocol Packets on the Wire", Gregory Lebovitz, 13-Mar-09. ( bytes): In the March of 2006 the IAB held a workshop on the topic of "Unwanted Internet Traffic". The report from that workshop is documented in RFC 4948 [RFC4948]. Section 8.2 of RFC 4948 calls for "[t]ightening the security of the core routing infrastructure." Four main steps were identified for improving the security of the routing infrastructure. One of those steps was "securing the routing protocols' packets on the wire." One mechanism for securing routing protocol packets on the wire is the use of per-packet cryptographic message authentication, providing both peer authentication and message integrity. Many different routing protocols exist and they employ a range of different transport subsystems. Therefore there must necessarily be various methods defined for applying cryptographic authentication to these varying protocols. Many routing protocols already have some method for accomplishing cryptographic message authentication. However, in many cases the existing methods are dated, vulnerable to attack, and/or employ cryptographic algorithms that have been deprecated. This document creates a roadmap of protocol specification work for the use of modern cryptogrpahic mechanisms and algorithms for message authentication in routing protocols. It also defines the framework for a key management protocol that may be used to create and manage session keys for message authentication and integrity. This roadmap reflects the input of both the security area and routing area in order to form a jointly agreed upon and prioritized work list for the effort.
"BGP Support for Four-octet AS Number Space", Quaizar Vohra, Enke Chen, 17-Apr-09. ( bytes): Currently the Autonomous System (AS) number is encoded as a two-octet entity in BGP. This document describes extensions to BGP to carry the Autonomous System number as a four-octet entity.
"The 'about' URI scheme", Joseph Holsten, Lachlan Hunt, 11-May-09. ( bytes): This document specifies the URI (Uniform Resource Identifier) scheme "about". About URIs are designed to be an internal, application- level identifier. Unlike many other URI schemes, the resolution of, and resources represented by, about URIs are left entirely to each individual application.
"Make TCP more Robust to Long Connectivity Disruptions", Alexander Zimmermann, Arnd Hannemann, 13-Jul-09. ( bytes): Disruptions in end-to-end path connectivity which last longer than one retransmission timeout cause suboptimal TCP performance. The reason for the performance degradation is that TCP interprets segment loss induced by connectivity disruptions as a sign of congestion, resulting in repeated backoffs of the retransmission timer. This leads in turn to a deferred detection of the re-establishment of the connection since TCP waits until the next retransmission timeout occurs before attempting the retransmission. This document describes how standard ICMP messages can be exploited to disambiguate true congestion loss from non-congestion loss caused by long connectivity disruptions. Moreover, a revert strategy of the retransmission timer is specified that enables a more prompt detection of whether the connectivity to a previously disconnected peer node has been restored or not. The specified algorithm is a TCP sender-only modification that effectively improves TCP performance in presence of connectivity disruptions.
"IPv4 Address Shortage: Needs and Open Issues", Pierre Levis, Mohammed Boucadair, Jean-Luc Grimault, Alain Villefranque, 22-Jun-09. ( bytes): This document analyses the main issues related to IPv4 Internet access in the context of public IPv4 address exhaustion.
"An EAP Authentication Method Based on the EKE Protocol", Yaron Sheffer, Glen Zorn, Hannes Tschofenig, Scott Fluhrer, 5-Jul-09. ( bytes): The Extensible Authentication Protocol (EAP) describes a framework that allows the use of multiple authentication mechanisms. This document defines an authentication mechanism for EAP called EAP-EKE, based on the Encrypted Key Exchange (EKE) protocol. This method provides mutual authentication through the use of a short, easy to remember password.
"Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm", Russ Housley, Morris Dworkin, 27-Jul-09. ( bytes): This document specifies a padding convention for use with the AES Key Wrap algorithm specified in RFC 3394. This convention eliminates the requirement that the length of the key to be wrapped is a multiple of 64 bits, allowing a key of any practical length to be wrapped.
"The Common Log File (CLF) format for the Session Initiation Protocol (SIP)", Vijay Gurbani, Eric Burger, Tricha Anjali, Humberto Abdelnur, Olivier Festor, 9-Mar-09. ( bytes): 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 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 for proxies, registrars, redirect servers as well as back-to-back user agents.
"Port Restricted IP Address Assignment", Gabor Bajko, Teemu Savolainen, Mohammed Boucadair, Pierre Levis, 9-Mar-09. ( bytes): When IPv6 was designed, the assumption was that the transition from IPv4 to IPv6 will occur way before the exhaustion of the available IPv4 address pool. The unexpected growth of the IPv4 Internet and the hesitation and technical difficulties to deploy IPv6 indicates that the transition may take much longer than originally anticipated. It is expected that communication using IPv6 addresses will increase during the next few years to come at the expense of communication using IPv4 addresses. The Internet should reach a safety point in the future, where the number of IPv4 public addresses in use at a given time begins decreasing. It is very likely that the IPv4 public address pool currently available at IANA will be exhausted before the internet reaches this safety point. This creates a need to prolong the lifetime of the available IPv4 addresses. This document defines methods to allocate the same IPv4 address to multiple hosts, with the aim to prolong the availability of public IPv4 addresses, possibly for as long as it takes for IPv6 to take over the demand for IPv4.
"PMIPv6 Localized Routing Problem Statement", Marco Liebsch, Sangjin Jeong, Wenson Wu, 13-Jul-09. ( bytes): Proxy Mobile IPv6 is the IETF standard for network-based localized mobility management. In Proxy Mobile IPv6, mobile nodes are topologically anchored at a Local Mobility Anchor, which forwards all data for registered mobile nodes. The set up and maintenance of localized routing, which allows forwarding of data packets between mobile nodes and correspondent nodes directly without involvement of the Local Mobility Anchor in forwarding, is not considered. This document describes the problem space of localized routing in Proxy Mobile IPv6.
"Port Range Configuration Options for PPP IPCP", Mohammed Boucadair, Pierre Levis, Jean-Luc Grimault, Alain Villefranque, 2-Jul-09. ( bytes): This memo defines two IPCP (IP Configuration Protocol, [RFC1332]) Options to be used in the context of Port Range solutions. IPCP is the configuration protocol used when PPP (Point-to-Point Protocol, [RFC1661]) is deployed.
"Session State Analysis", Gao yang, 9-Feb-09. ( bytes): Session state on unsuccessful re-INVITE is an open issue[1]. Many people interested in this topics and there has been a lot of discussion in the mail list publicly or among participants privately. This text tried to analyse incorrectness or drawback of some of the methods to reveal the imortance of precise definition of session state.
"Proxy Mobile IPv6 Mobility Session Redirection Problem Statement", Jouni Korhonen, 9-Feb-09. ( bytes): This document discusses a Proxy Mobile IPv6 mobility session redirection functionality at the Proxy Mobile IPv6 base protocol level. The redirection functionality would allow a Local Mobility Anchor to redirect the Mobile Access Gateway during the Proxy Binding Update and Acknowledgement exchange to an alternative Local Mobility Anchor. The benefit of redirection at the protocol level is that it removes the dependence on having such functionality provided by the Authentication, Authorization and, Accounting elements or the Domain Name System in a Proxy Mobile IPv6 Domain. Furthermore, doing the redirection at the base protocol level reduces the amount of signaling, unnecessary costly setup of mobility sessions and unnecessary costly interactions with backend systems.
"The Accumulated IGP Metric Attribute for BGP", Rex Fernando, Pradosh Mohapatra, Eric Rosen, James Uttaro, 9-Feb-09. ( bytes): 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.
"Issues with network based inter-technology handovers", Suresh Krishnan, Hidetoshi Yokota, Telemaco Melia, Carlos Bernardos, 13-Jul-09. ( bytes): 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. While the PMIPv6 protocol itself supports handover across interfaces and between access types, there are several issues with effectively performing inter-technology handovers with network based mobility protocols. This document aims to enumerate some known issues with such handovers.
"MPLS-TP Proactive Continuity and Connectivity Verification", Italo Busi, Annamaria Fulignoli, Huub Helvoort, Nurit Sprecher, 9-Feb-09. ( bytes): The aim of this draft is to define an MPLS-TP OAM mechanism to meet the requirements for proactive Continuity Check and Connectivity Verification functionality as defined in [3]. Note: this version of the draft is focused on analyzing possible solutions and evaluating their pros&cons as well as issues. In the next version of the draft the solution to be standardized will be proposed using the analysis done in this version to motivate the selection.
"Setup of Asymmetric Media with SDP", Ingemar Johansson, 10-Feb-09. ( bytes): This draft proposes an extension to the SDP Capability Negotiation framework for the setup of asymmetric sessions. One example of an asymmetric session is a conversational video session between a handset with a small screen (high-resolution camera) and a home- entertainment set-top box connected to a wide-screen TV. Another example is tightly coupled conferences with different number of in and outgoing streams for each client.
"Location Information Server (LIS) Discovery From Behind Residential Gateways", Martin Thomson, Ray Bellis, 27-Jul-09. ( bytes): 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.
"GRE and IP-in-IP Tunnels for Virtual Aggregation", Xiaohu Xu, Paul Francis, 11-Feb-09. ( bytes): The document "FIB Suppression with Virtual Aggregation" [I-D.francis-intra-va] describes how FIB size may be reduced. The latest revision of that draft refers generically to tunnels, and leaves it to other documents to define the usage and signaling methods for specific tunnel types. This document provides those definitions for GRE and IP-in-IP tunnels.
"MPLS Tunnels for Virtual Aggregation", Paul Francis, Xiaohu Xu, 11-Feb-09. ( bytes): The document "FIB Suppression with Virtual Aggregation" [I-D.francis-intra-va] describes how FIB size may be reduced. The latest revision of that draft refers generically to tunnels, and leaves it to other documents to define the usage and signaling methods for specific tunnel types. This document provides those definitions for MPLS Label Switched Paths (LSP), without tag stacking.
"Simple Tunnel Endpoint Signaling in BGP", Xiaohu Xu, Paul Francis, 11-Feb-09. ( bytes): Virtual Aggregation (VA) is a mechanism for shrinking the size of the DFZ FIB in routers [I-D.francis-intra-va]. VA can result in longer paths and increased load on routers within the ISP that deploys VA. This document describes a mechanism that allows an AS that originates a route to associate a tunnel endpoint terminating at itself with the route. This allows routers in a remote AS to tunnel packets to the originating AS. If transit ASes between the remote AS and the originating AS install the prefixes associated with tunnel endpoints in their FIBs, then tunneled packets that transit through them will take the shortest path. This results in reduced load for the transit AS, and better performance for the customers at the source and destination.
"DKIM Reputation Hint Extension", Jim Fenton, 12-Feb-09. ( bytes): This document defines an extension to the DomainKeys Identified Mail (DKIM) specification to provide an identifier that may be used as a "hint" by reputation services using DKIM wanting to maintain reputation information at a finer level of granularity than that of the signing domain itself.
"DHCPv6 MRC Clarification", Evan Hunt, 13-Feb-09. ( bytes): The definition of the Maximum Retransmission Count (MRC) variable described in RFC 3315 is clarified to resolve an ambiguity.
"Preliminary Recommendation for a Routing Architecture", Tony Li, 29-Mar-09. ( bytes): It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, multi-homing, and inter-domain traffic engineering. This document reports the Routing Research Group's prelimnary findings from its efforts towards developing a recommendation for a scalable routing architecture. This document is a work in progress.
"Authentication-Results Header Field Appeal", Douglas Otis, David Rand, 16-Feb-09. ( bytes): The proposed [I-D.kucherawy-sender-auth-header] defines a header field used to capture email verification results obtained at border receptions has been approved for publication. However, serious deficiencies remain in its secure use and has prompted an appeal of the publication decision. This new header field is to convey to Mail User Agents (MUA) and downstream processes the verification results that are intended to augment handling decisions and message annotations that might be made visible to recipients. For such use, it is crucial to include within an "authenticated-results" header, a truly authenticated identity. The draft acknowledges that it confuses authorization with authentication in section 1.5.2. This confusion has lead the draft to incorrectly elevate the authorization of an SMTP client into the authentication of an email-address domain. Elevating the *authorization* of the SMTP client into the *authentication* of an email-address domain incorrectly assumes current email practices adequately restrict the use of an email-address domain based upon the originating IP address of the SMTP client. In an era of carrier grade NATs, virtual servers, aggregated services, and other techniques that overload the IP address, this assumption is neither safe nor practical. Although the draft explicitly declares Sender-ID and SPF as the authorization of the transmitting SMTP client, it fails to offer the authenticated identity being trusted. A truly authenticated identity is essential for reputation assessments which section 4.1 indicates should be made prior to results being revealed. A reputation check of a truly authenticated identifier is often a necessary step needed to mitigate fraud and abuse. In addition, it is unfair to attribute fraud or abuse to the unauthenticated identifiers. Even so, the header offers no assurance that any reputation check has been made, nor does it ensure that an authenticated identity, the IP address of the SMTP client, can be determined by the MUA or downstream process. The goal of the appeal is to ensure adequate information is available when annotating email.
"A Self-tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD)", Jouni Maenpaa, Gonzalo Camarillo, Jani Hautakorpi, 16-Feb-09. ( bytes): 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. RELOAD provides an abstract interface to the overlay layer that allows implementing different structured and unstructured overlay algorithms by using different topology plugins. This document defines a new topology plugin for RELOAD. This topology plugin implements a self- tuning DHT (Distributed Hash Table), which adapts to changing operating conditions (e.g., churn and network size).
"ECN Nonces for Stream Control Transmission Protocol (SCTP)", Randall Stewart, Neil Spring, 16-Feb-09. ( bytes): This document describes the addition of the ECN-nonce RFC 3540 [RFC3540] to the Stream Control Transmission Protocol (SCTP) RFC 2960 [RFC2960]. The ECN-nonce reduces the vulnerability of ECN senders to misbehaving receivers that conceal congestion signals like ECN marks and packet losses. The ECN-nonce approach is different in SCTP because SCTP uses chunks for extensible protocol features and is selective acknowlegement (SACK)-based; this document describes those differences. In particular this document describes (1) protocol extensions in the form of a single new parameter for the INIT/ INIT-ACK chunks, and a single bit flag in the SACK chunk, and (2) rules governing the sender and receiver side implementation. This document outlines a minimum response that an SCTP sender should apply after detecting a misbehaving receiver.
"DHCPv6 Route Option", Wojciech Dec, Richard Johnson, 3-Mar-09. ( bytes): This document describes the DHCPv6 Route Option for provisioning static IPv6 routes on a DHCPv6 client..This improves the ability of an operator to configure and influence the client to pick an appropriate route to a destination when the client is multi-homed to routers and where other means of route configuration may be impractical. It is primarily envisaged for implementation on a DHCP client stack of a broadband Residential Gateway (RG) node.
"A Security Framework for Routing over Low Power and Lossy Networks", Tzeta Tsao, Roger Alexander, Mischa Dohler, Vanesa Daza, Angel Lozano, 17-Feb-09. ( bytes): This document presents a security framework for routing over low power and lossy networks. The development of the framework builds upon previous work on routing security and adapts the security assessments to the issues and constraints specific to low power and lossy networks. A systematic approach is used in defining and assessing 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.
"DNSSEC Key Timing Considerations", Stephen Morris, Johan Ihren, John Dickinson, 17-Feb-09. ( bytes): RFC 4641 gives a detailed overview of the operational considerations involved in running a DNSSEC-secured zone, including key rollovers. This document expands on the previous work, and discusses timing considerations in greater depth. It explicitly identifies the relationships between the various time parameters, and gives a suggested algorithm for key rollover in a DNSSEC-secured zone.
"BGP routing information in XML format", Peichun Cheng, He Yan, Kevin Burnett, Dan Massey, Lixia Zhang, 17-Feb-09. ( bytes): This document describes the XML format for BGP routing information (XFB). It can be used to describe both BGP messages and BGP control information. Compared with MRT, XFB is more extensible, human and machine-readable and can serve as a common interface for a variety of tools.
"Reverse Binding for Proxy Mobile IPv6", Youn-Hee Han, Pyung-Soo Kim, Byung-Jun Ahn, 8-Jul-09. ( bytes): This memo proposes a scheme that utilizes only pre-established bi- directional tunnels between LMA and MAGs to support a fast handover effectively in Proxy Mobile IPv6. To expedite the handover procedure, we define new signaling messages, Fast PBU/PBA and Reverse PBU/PBA, exchanged by LMA and MAGs. Because any signaling messages exchanged by two MAGs are neither created nor utilized and thus bi- directional tunnel between MAGs is not created, the proposed scheme puts less overload upon network than the existing fast handover scheme for PMIPv6. It can also tackle effectively with the so-called ping-pong movement of mobile nodes.
"DHCP options for MANET prefix in connected MANET", Jaehwoon Lee, Sanghyun Ahn, Younghan Kim, Yuseon Kim, 18-Feb-09. ( bytes): The mobile ad hoc network (MANET) is a wireless network composed of mobile nodes which can communicate with each other via multiple wireless links. The modified MANET architecture is now standardizing that can resolve the multi-link subnet issue. In this draft, we define two DHCP options in order that a MANET Router (MR) gets the network prefix assigned to the connected MANET. The one is the MANET prefix request option used by a MR when it wants to know the network presix allocated to the MANET. The other is the MANET prefix option that DHCP server provides the MANET prefix to the requesting MR.
"The atypes media feature tag for Session Initiation Protocol (SIP)", Mohammed Boucadair, Yoann Noisette, Andrew Allen, 13-Jul-09. ( bytes): This specification defines a new media feature tag called atypes. This new media feature tag indicates the IP address type capabilities of the UA (User Agent) and can aid the routing process and ease the invocation of required functions when heterogeneous (i.e. IPv4 and IPv6) parties are involved in a given SIP session.
"Problems with IPv6 source address selection and IPv4 NATs", Remi Denis-Courmont, 18-Feb-09. ( bytes): This memo details a problem and potential solution, when using the IPv6 source address selection algorithm with private IPv4 address space.
"Flow Binding in Proxy Mobile IPv6", Frank Xia, 18-Feb-09. ( bytes): This document introduces extensions to Proxy Mobile IPv6 that allows networks dynamically binding IP flows to different interfaces of a mobile node.
"DNS Server Selection on Multi-Homed Hosts", Teemu Savolainen, 19-Feb-09. ( bytes): A multi-homed host may receive DNS server configuration information from multiple physical and/or virtual network interfaces. In split DNS scenarios not all DNS servers are able to provide the same information. When the multi-homed host needs to utilize DNS, it has to select which of the servers to contact to. This document describes problems of split DNS for multi-homed hosts and also a method for selecting the DNS server with help of DNS suffix information received dynamically for each network interface. The method is useful in split DNS scenarios where private names are used and where correct DNS server selection is mandatory for successful DNS resolution.
"Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Servers", Theo Zourzouvillys, 2-Mar-09. ( bytes): This document addresses a vulnerability in publicly accessible SIP servers (servers includes both UASes and proxies) that enables them to be used as an amplifier in an untracable reflected denial of service attack. The amplification ratio is between 1:10 to over 1:350 in both packets and bytes. As a proposed solution, a mechanism for stateless cookie exchange between a SIP server and client to ensure that a public SIP server that wishes to accept SIP requests from hosts over datagram can not be used as an amplifier for a denial of service attack. This brings SIP over datagram transports (such as UDP) in line with TCP in terms of routability to the source IP address.
"Reclassification of Sender ID and SPF to Historic Status", S Moonesamy, 20-Feb-09. ( bytes): This memo reclassifies RFC 4405, SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message, RFC 4406, Sender ID: Authenticating E-Mail, RFC 4407, Purported Responsible Address in E-Mail Messages and RFC 4408, Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 to Historic status. This memo also obsoletes RFC 4405, RFC 4406, RFC 4407, and RFC 4408.
"A Packet Distribution Scheme for Bandwidth Aggregation on Network Mobility", Pyung-Soo Kim, Youn-Hee Han, 20-Feb-09. ( bytes): This draft considers a packet distribution scheme for bandwidth aggregation on the mobile network with a multi-interfaced mobile router (MMR). In the proposed scheme, the MMR with multiple heterogeneous wireless network interfaces effectively and fairly distributes packets over end-to-end multi-path through multiple network interfaces. Each network interface is considered to have a distribution counter associated with corresponding end-to-end path. This distribution counter varied by both weighted capacity and distributed packets is used to determine if a network interface has enough credits to distribute incoming packets on multiple paths. The capacity unit is shown to be a useful design parameter to make the performance of the proposed scheme as good as possible.
"Xcast6 Treemap: An extension of Xcast6", Khoa Phan, Nam Thoai, Eiichi Muramoto, Ettikan Kandasamy, 20-Feb-09. ( bytes): Xcast6 (Explicit Multi-unicast for IPv6) is a new multicast scheme that supports very large number of small multicast sessions. Xcast6 sends data via optimal route without traffic redundancy when Xcast- aware routers exist; otherwise, data will be sent in daisy-chain form. In this document, we propose Xcast6 Treemap - an extension of Xcast6. Using Xcast6 Treemap, data can be branched not only at source but also at remote hosts, solving the limitation of daisy-chain connection. Xcast6 Treemap utilizes existing multicast infrastructure (Xcast-aware routers) to improve application performance and reduce traffic redundancy on network; also, it automatically switches to end-host multicast operation mode in the absence of Xcast-aware router. For widely deployment of Xcast6, routers must be upgraded gradually. This requires a long term strategy and Xcast6 Treemap is a good choice for incremental deployment.
"Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers", Spencer Dawkins, 6-Jul-09. ( bytes): This document updates RFC 3777, Section 4, Bullet 13 to allow announcement of open positions and solicitation of volunteers to be issued before a Nominating and Recall Committee Chair has been named by the Internet Society President.
"Nominating Committee Process: Open Disclosure of Willing Nominees", Spencer Dawkins, 28-Jul-09. ( bytes): This document updates RFC 3777, Section 3, Bullet 6 to allow a Nominating and Recall Commitee to disclose the list of nominees who are willing to be considered to serve in positions the committee is responsible for filling.
"Translating IPv4 to IPv6 based on source IPv4 address", Charles Perkins, 20-Feb-09. ( bytes): A method is proposed to enable communications between an IPv4-only node in today's Internet and an IPv6-only node, initiated by the IPv4-only node. The communication depends on allocation of a flow record and address triggered by a DNS query received for the target v6-only node. DNS query conventions can be agreed upon to provide a natural model for resolving IPv4 queries for IPv6-only nodes. The NAT mechanism proposed demultiplexes multiple sessions through the same dynamically allocated IP address, using flow records matching the source address of incoming packets. This is in contrast to the use of ports in NAT-PT boxes, which inhibits the support of incoming traffic towards a node behind the NAT-PT.
"Security Assessment of the Transmission Control Protocol (TCP)", Fernando Gont, 20-Feb-09. ( bytes): This document contains a security assessment of the IETF specifications of the Transmission Control Protocol (TCP), and of a number of mechanisms and policies in use by popular TCP implementations. It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI).
"Constrained Shortest Path First", Manayya KB, 17-Apr-09. ( bytes): Constrained Shortest Path First (CSPF) is an advanced version of shortest path algorithms used in OSPF and IS-IS route computations. It is used in computing shortest path for label-switched paths (LSPs) based upon multiple constraints. While computing path for LSPs it considers topology of network, attributes of LSP and links. The path is computed using traffic engineering database which takes the extensions of OSPF(open shortest path first) and IS-IS (Intermediate system to Intermediate system) as input. Manayya KB Expires October 16, 2009 [page 1]
"Peer-to-peer (P2P) Architectures", Gonzalo Camarillo, 6-Jul-09. ( bytes): In this document we provide a survey of P2P (Peer-to-Peer) systems. The survey includes a definition and a taxonomy of P2P systems. This survey also includes a description of which types of applications can be built with P2P technologies and examples of P2P applications that are currently in use on the Internet. Finally, we discuss architectural tradeoffs and provide guidelines for deciding whether or not a P2P architecture would be suitable to meet the requirements of a given application.
"Support for Multiple Signature Algorithms in Cryptographically Generated Addresses (CGAs)", Tony Cheneau, Maryline Laurent-Maknavicius, Sean Shen, Michaela Vanderveen, 5-Jun-09. ( bytes): This document defines an extension field for the CGA Parameters data structure specified in RFC 3972. This extension field carries a Public Key that is used in Cryptographically Generated Address (CGA) generation. This extension enables protocols using CGAs, such as SEND, to use multiple Public Key signing algorithms and/or multiple Public Keys.
"Signature Algorithm Agility in the Secure Neighbor Discovery (SEND) Protocol", Tony Cheneau, Maryline Laurent-Maknavicius, Sean Shen, Michaela Vanderveen, 5-Jun-09. ( bytes): This draft describes a mechanism to enable the Secure Neighbor Discovery (SEND) protocol to select between different signature algorithms to use with Cryptographically Generated Addresses (CGA). It also provides optional support for interoperability between nodes that do not share any common signature algorithms.
"An IPTV Usage for RELOAD", Seyung Oh, Seok-Kap Ko, Victor Avila, Young-Han Kim, Byoung-Tak Lee, 13-Jul-09. ( bytes): This document defines a P2P IPTV Usage for Resource Location And Discovery (RELOAD). The IPTV Usage provides the functionality of IPTV servers in a fully-distributed system using P2PSIP RELOAD. The IPTV Usage provides the metadata storage, channel peer list storage, and channel peer group storage using the P2PSIP overlay.
"MPLS-TP Control Plane Framework", Loa Andersson, Lou Berger, Luyuan Fang, Nabil Bitar, Attila Takacs, Martin Vigoureux, 13-Jul-09. ( bytes): The MPLS Transport Profile (MPLS-TP) supports both static provisioning of transport paths via an NMS/OSS, and dynamic provisioning of transport paths via a control plane. This document provides the framework for MPLS-TP dynamic provisioning, and covers control plane signaling, routing, addressing, traffic engineering, path computation, and recovery in the event of network failures. The document focuses on the control of Label Switched Paths (LSPs) as the Pseudowire (PW) control plane is not modified by MPLS-TP. MPLS-TP uses GMPLS as the control plane for MPLS-TP LSPs. Backwards compatibility to MPLS is required. Management plane functions such as manual configuration, the initiation of LSP setup are out of scope of this document.
"UDP Checksums for Tunneled Packets", Marshall Eubanks, 23-Feb-09. ( bytes): We address the problem of computing the UDP checksum on tunneling IPv6 packets when using lightweight tunneling protocols.
"Civic Location Format Extension for Utility and Lamp Post Numbers", Robins George, Qian Sun, Henning Schulzrinne, 23-Feb-09. ( bytes): This document describes an extension to civic location format and adds new element PN (pole number). PN carries pole number information which can identify a civic location.
"DHCP option to transport Protocol Configuration Options", Telemaco Melia, Yacine Mghazli, 23-Feb-09. ( bytes): This document specifies how to convey Protocol Configuration Options (PCO) [24008] from/to the access network to/from the Mobile Node (MN). There are scenarios defined in 3GPP (TS 23.402) and WiMax forum NWG where the mobile node accessing the non-3GPP trusted system needs to convey such information to the Mobility Access Gateway (MAG) functionality implemented in the serving gateway (S-GW). The MAG requires the PCO field to send such information to the Local Mobility Agent (LMA) (implemented in the PDN gateway, P-GW) in a Proxy Binding Update (PBU) message. PCO options are exchanged between the MN and the LMA to transport information such as P-CSCF address, DNS server address.
"Problem Statement of P2P Streaming Protocol (PPSP)", Yunfei Zhang, Ning Zong, Gonzalo Camarillo, James Seng, Yang Yang, 12-Jul-09. ( bytes): We propose to develop an open peer-to-peer (P2P) streaming protocol named PPSP. This document describes problems related to PPSP and outlines considerations that have to be taken in account when arriving at equitable solutions.
"IPv6 Services for UPnP Residential Networks", Mark Baugher, Erwan Nedellec, Mika Saaranen, Barbara Stark, 8-Mar-09. ( bytes): This paper considers some IPv6 issues for residential networks, including address scoping and firewalls. The paper describes IPv6 usage in the UPnP Forums's Device Architecture standard; some clarifications and changes are considered. The paper seeks comments on IPv6 address usage, address selection, and the need to develop best practices for IPv6 firewall traversal.
"Mobile Multicasting Support in Proxy Mobile IPv6", Seil Jeon, Younghan Kim, 7-Mar-09. ( bytes): To support IP-based group mobile communication, such as mobile IPTV, IP multicasting is required. Two major constraints in mobile multicasting are the tunnel convergence problem and high handover latency. To reduce the constraints, several mobile multicasting schemes based on Mobile IP have been proposed. To meet requirements, we present a multicasting architecture and fast handover scheme for Proxy Mobile IPv6 (PMIPv6).
"Authentication Between Mobile Node and Home Agent", Ying Qiu, Jianying Zhou, 10-Mar-09. ( bytes): Mobile IPv6 relies on IPsec for securing the signaling between the MN and HA. However, the tight coupling of the mobility protocol with IPsec is detrimental to broader implementation and deployment. This document proposes a scheme based on Identity-Based Cryptography mechanism to authenticate the mobile node and signaling of home biding update to home agent. Hence, the use of IPsec could be avoided.
"IANA IPv4 Special Purpose Address Registry", Geoff Huston, Michelle Cotton, Leo Vegoda, 27-Feb-09. ( bytes): This is a direction to IANA concerning the creation and management of the IANA IPv4 Special Purpose Address Registry.
"Using EAP-GTC for Simple User Authentication in IKEv2", Yaron Sheffer, 2-Aug-09. ( bytes): Despite many years of effort, simple username-password authentication is still prevalent. In many cases a password is the only credential available to the end user. IKEv2 uses EAP as a sub-protocol for user authentication. This provides a well-specified and extensible architecture. To this day EAP does not provide a simple password- based authentication method. The only existing password authentication methods either require the peer to know the password in advance (EAP-MD5), or are needlessly complex when used within IKEv2 (e.g. PEAP). This document codifies the common practice of using EAP-GTC for this type of authentication, with the goal of achieving maximum interoperability. The various security issues are extensively analyzed.
"P2PSIP Security Requirements", Judy Zhu, Minpeng Qi, 24-Feb-09. ( bytes): This draft discusses the security requirements in Peer-to-Peer (P2P) SIP system. As the P2P SIP is distributed and each peer is equal in it, it should face the extra security threat from traditional system. This draft introduces these security threats at first. After that, the security requirements of P2P SIP system were brought up.
"Hierarchical IPv4 Framework", Patrick Frejborg, 28-May-09. ( bytes): This draft describes a framework how the current IPv4 address structure can be extended towards a similar hierarchical numbering structure as used in the Public Switched Telephone Network and bring a new level of hierarchy to the routing architecture of Internet. The hierarchical IPv4 framework is backwards compatible with the current IPv4 framework; it will also discuss a method to decouple the location and identifier functions, future applications can make use of the separation. The framework requires extensions to the existing Domain Name System architecture, the existing IPv4 stack of the end systems (hosts) and to routers in the Internet. The framework can be implemented incrementally to the hosts, databases, and routers.
"MPLS-TP Linear Protection", Stewart Bryant, Nurit Sprecher, Huub Helvoort, Annamaria Fulignoli, Yaacov Weingarten, 27-Jul-09. ( bytes): This document describes mechanisms for linear protection of Multi- Protocol Label Switching Transport Profile (MPLS-TP) Label Switched Paths (LSP) and Pseudowires (PW) on multiple layers. Linear protection provides a fast and simple protection switching mechanism that is especially optimized for a mesh topology. It provides a clear indication of the protection status. The mechanisms are described both at the architectural level as well as providing a protocol that is used to control and coordinate the protection switching.
"Advice on When It is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE", Kohei Shiomoto, Adrian Farrel, 24-Feb-09. ( bytes): The Resource Reservation Protocol (RSVP) has been extended to support Traffic Engineering (TE) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The protocol enables signaling exchanges to establish Label Switched Paths (LSPs) that traverse nodes and links to provide end-to-end data paths. Each node is programmed with "cross-connect" information as the signaling messages are processed. The cross-connection information instructs the node how to forward data that it receives. End points of the LSP need to know when it is safe to start sending data so that it is not misdelivered and so that safety issues specific to the data plane technology are satisfied. Likewise, all label switching routers along the path of the LSP need to know when to programme their data planes relative to sending control plane messages. This document clarifies and summarises the RSVP-TE protocol exchanges with relation to the programming of cross-connects along an LSP for both unidireciotnal and bidirecitonal LSPs. This document does not define any new procedures or protocol extensions, and defers completely to the documents that normative references. The clarifications set out in this document may also be used to help interpret LSP establishment performance figures for MPLS-TE and GMPLS devices.
"MANET Router Configuration Recommendations", Thomas Clausen, Ulrich Herberg, 25-Feb-09. ( bytes): This document describes a pragmatic set of configuration recommendations for MANETs, as well as provides a rationale for why these recommendations are sound. While there may be other equally valid ways of configuring a MANET, the recommendations in this document have the merit of being supported by an existence proof (there're running networks in existence, configured according to these recommendations), and they require neither modifications to the IP stack nor to upper-layer protocols or applications.
"Transmission of SYSLOG message over DTLS", Hongyan Feng, 10-Apr-09. ( bytes): This document describes a Transport for the Syslog Protocol, that uses the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides authentication and privacy services for SYSLOG applications. This document describes how using DTLS to transport SYSLOG messages makes this protection possible in an interoperable way. This transport is designed to meet the security and operational needs of network administrators, operate in environments where a datagram transport is preferred, and integrates well into existing public keying infrastructures.
"Using HTTP GET with HTTP-Enabled Location Delivery (HELD)", Martin Thomson, 25-Feb-09. ( bytes): This document describes how an HTTP GET request to an HTTP-Enabled Location Delivery (HELD) resource is handled by the server responsible for that resource. This ensures that requests generated by user agents that are unaware of the special status of a URI do not result in unhelpful responses and enables the use of HTTP GET for location configuration and dereference.
"Multiprotocol Label Switching Transport Profile Bidirectional Notify Message Packet", Guoman Liu, Jian Yang, Lili Jiang, 1-Jun-09. ( bytes): This document specifies an extension to MPLS BDI packet to form a new type of OAM packet BNM(Bidirectional Notify Message) , this BNM packet will not only have the function of informing another peer MEP about existing fault of this path like MPLS BDI packet, but also it may use for performance measure and testing communication between two equipments. in addtion, when Client network has a fault or defect. it notify another peer client network about remote peer fault. And these performance measure and fault notification information will be encapsulated in BNM packet by the way of TLV packet. So it may decrease the number of OAM type and keep compatibility with MPLS network. on the other hand, this encapsulating these information by the way of TLV packet will be easy to extend OAM function to operate an MPLS Transport profile(MPLS-TP) label switched path (LSP).
"Link Bundle in Wavelength Switched Optical Networks", Xihua Fu, 2-Mar-09. ( bytes): [RFC4201] provides a link bundle mechanism to improve routing scalability by reducing the amount of information that has to be handled by IGP (OSPF and/or IS-IS). This reduction is accomplished by performing information aggregation/abstraction. As with any other information aggregation/abstraction, this results in losing some of important information. In WSON and MRN, this lost information is very important for the path computation entity to calculate an accurate path. This document discusses some requirements of link bundle for the new GMPLS networks (e.g., WSON and MRN). The draft gives some routing and signaling analysis for this issue.
"Mythbustering Peer-to-peer Traffic Localization", Enrico Marocco, Antonio Fusco, Ivica Rimac, Vijay Gurbani, 11-Jul-09. ( bytes): Peer-to-peer traffic optimization techniques that aim at improving locality in the peer selection process have attracted great interest in the research community and have been subject of much discussion. Some of this discussion has produced controversial myths, some rooted in reality while others remain unfounded. This document evaluates the most prominent myths attributed to P2P optimization techniques by referencing the most relevant study (or studies) that have addressed facts pertaining to the myth. Using these studies, we hope to either confirm or refute each specific myth.
"Robust Configuration Management within NETCONF", Robert Cole, Dan Romascanu, Andy Bierman, 24-Jun-09. ( bytes): This document extends the capabilities of the NETCONF configuration management protocol to validate the configuration on servers and to perform a set of active tests (i.e., verification) against the server's running configuration over a period of time to afford the client and server a more robust and resilient configuration management capability. This is of value to commercial enterprise and public networks as well as wireless emergency and military networks. We propose an initial new NETCONF capability. We also explore the future alternatives for developing these capabilities within the context of the existing NETCONF protocol, the YANG modeling language and existing related IETF, IEEE and ITU-T standards.
"Joint IETF and ITU-T Multi-Protocol Label Switching (MPLS) Transport Profile process", Loa Andersson, David Ward, Malcolm Betts, 30-Jun-09. ( bytes): The decision to develop a Multiprotocol Label Switching (MPLS) Transport Profile in cooperation between IETF and ITU-T does not fully define and document processes for development of the required RFCs. This document complements the processes documented in the JWT decision with a few separate elements; it: o provides an adaptation of the IETF working group process, o identifies the expected participation in the process by the ITU-T, o clarifies the decision rules regarding MPLS-TP documents. This document is not intended to specify any ITU-T process; to the extent necessary ITU-T activities will be done according to ITU-T process/rules. Nor is this document is intended to specify the IETF working group process, it is limited to the temporary adaptations of that process that is the result of that IETF and ITU-T accepted the proposal in the JWT report to jointly develop the MPLS Transport Profile. In general it may be said that these adaptations are introduced to ensure a good and consistent document review across the two organizations.
"Syslog Sending Policy Messages", Washam Fan, 26-Feb-09. ( bytes): This document defines special syslog messages called Sending Policy messages for indicating how syslog senders process syslog messages before sending them. The information Sending Policy messages convey is of interest to syslog receivers and helpful for audit.
"Flexible IPv6 Migration Scenarios in the Context of IPv4 Address Shortage", Mohammed Boucadair, Pierre Levis, Jean-Luc Grimault, Alain Villefranque, Mohamed Kassi-Lahlou, 13-Jul-09. ( bytes): This memo presents a solution to solve IPv4 address shortage and ease IPv4-IPv6 interworking. The document presents a set of incremental steps for the deployment of IPv6 as a means to solve IPv4 address exhaustion. Stateless IPv4/IPv6 address mapping functions are introduced and IPv4-IPv6 interconnection scenarios presented. This memo advocates for a more proactive approach for the deployment of IPv6 into operational networks. This document provides the specification of the solution and deployment scenarios together with IPv6 migrations paths.
"NAI-based Dynamic Peer Discovery for RADIUS over TLS and DTLS", Stefan Winter, Mike McCauley, 26-Feb-09. ( bytes): This document specifies a means to find authoritative AAA servers for a given NAI realm. It can be used in conjunction with RADIUS over TLS and RADIUS over DTLS.
"Definitions of Managed Objects for lock via network management protocols", Tony Meng, Washam Fan, 1-Apr-09. ( bytes): This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. It describes managed objects used for monitoring locks on a device, in paticularly, acquired or released by NETCONF and COPS-PR entities.
"Packet Pseudowire Encapsulation over an MPLS PSN", Stewart Bryant, Sami Boutros, Luca Martini, Siva Sivabalan, George Swallow, David Ward, Andrew Malis, 8-Jul-09. ( bytes): This document describes a pseudowire that is used to transport a packet service over an MPLS PSN is the case where the client LSR and the server PE are co-resident in the same equipment. For correct operation these clients require a multi-protocol interface with fate sharing between the client protocol suite. The packet pseudowire may be used to carry all of the required layer 2 and layer 3 protocols between the pair of client LSRs.
"Service Identifiers for HIP", Tobias Heer, Hanno Wirtz, Samu Varjonen, 27-Feb-09. ( bytes): The Host Identity Protocol [RFC5201] is a signaling protocol for secure communication, mobility, and multihoming that introduces a cryptographic namespace. This document specifies an extension for HIP that enables HIP end-hosts and HIP-aware middleboxes to announce services to HIP hosts during a HIP Base EXchange (BEX) or HIP update. Service providers are able to specify the type and requirements of a service; clients can then decide to agree on the terms of service. This allows the service provider to verify the accordance of the client with the service conditions while the client is able to verify the authenticity of the used service.
"Negotiating IPv6 Encapsulating Security Payload (ESP) Security Association (SA) with Cryptographically Generated Addresses (CGA)", Dong Zhang, 27-Feb-09. ( bytes): This memo specifies a new approach of Encapsulating Security Payload (ESP) Security Association (SA) negotiation. Because of the existing of the Cryptographically Generated Addresses (CGA) extension header and the key pair in CGA, it is convenient and feasible to negotiate ESP SA under the protection of key pair.
"Multi-interface Network Connection Manager in Arena Platform", Yan Zhang, Tao Sun, Hua Chen, 27-Feb-09. ( bytes): This document presents a "Connection Manager" model implemented in the platform Arena, a mobile OS based on Linux. The introduction of Connection Manager brings two major benefits in Arena. First, it logically decouples the underlining connection approach with the connection management. Second, it plays a central role which executes the policy of OS, especially for multiple interfaces.
"Extension of DHCPv4 for policy routing of multiple interfaces terminal", Min Hui, Hui Deng, 27-Feb-09. ( bytes): Current multiple interfaces terminal causes the problem of selecting a proper interface for a specific application, and this is a new question which will change the previous internet model. This document proposes a solution which uses policy routing to map the IP flows to multiple interfaces.
"An Analysis of Scaling Issues for Point-to-Multipoint Label Switched Paths in MPLS-TE Core Networks", Olufemi Komolafe, Adrian Farrel, Daniel King, 28-Feb-09. ( bytes): Traffic engineered Multiprotocol Label Switching (MPLS-TE) is deployed in providers' core networks, and the scaling properties have been analyzed to show how much control state must be maintained to support a full mesh of edge-to-edge point-to-point (P2P) Label Switched Paths (LSPs) in various network topologies and with several different scaling techniques. Point-to-multipoint (P2MP) MPLS-TE LSPs are very interesting to service providers as a means to provide multicast services (such as TV distribution, or multicast VPN connectivity) across core MPLS networks. P2MP LSPs have different scaling properties than P2P LSPs, and service providers need to understand whether existing protocols and implementations can support the network sizes and service levels that they are planning in their P2MP MPLS-TE networks. This document presents an analysis of the scaling properties MPLS-TE core networks that support P2MP LSPs.
"OCSP Algorithm Agility", Phillip Hallam-Baker, 27-Feb-09. ( bytes): The OSCP specification defined in RFC 2560 requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used leading to possible interoperability failures in contexts where multiple signature algorithms are in use. This document specifies an algorithm for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported.
"XTLS: End-to-End Encryption for the Extensible Messaging and Presence Protocol (XMPP) Using Transport Layer Security (TLS)", Dirk Meyer, Peter Saint-Andre, 29-Jun-09. ( bytes): This document specifies "XTLS", a protocol for end-to-end encryption of Extensible Messaging and Presence Protocol (XMPP) traffic. XTLS is an application-level usage of Transport Layer Security (TLS) that is set up using the XMPP Jingle extension for session negotiation and transported using any streaming transport as the data delivery mechanism. Thus XTLS treats the end-to-end exchange of XML stanzas as a virtual transport and uses TLS to secure that transport, enabling XMPP entities to communicate in a way that is designed to ensure the confidentiality and integrity XML stanzas. The protocol can be used for secure end-to-end messaging as well as other XMPP applications, such as file transfer.
"Management and Use of Client Certificates for the Extensible Messaging and Presence Protocol (XMPP)", Dirk Meyer, Peter Saint-Andre, 8-Mar-09. ( bytes): This document defines methods for managing and using client certificates in the Extensible Messaging and Presence Protocol (XMPP). These methods, which make use of the EXTERNAL mechanism of the Simple Authentication and Security Layer (SASL) protocol, enable an XMPP client to log in to an XMPP server without providing a password.
"HIP and Strong Password Authentication of Users", Samu Varjonen, 28-Feb-09. ( bytes): This document specifies how to use Secure Remote Password (SRP) protocol in conjunction with Host Identity Protocol (HIP). In order to conceive this conjunction this document specifies three new parameters to be used with HIP control packets. These parameters are used to transport values related to the SRP protocol. This document also specifies how peers should act when these SRP parameters are found from HIP control packets and how this affects middleboxes.
"Tunnel Negotiation for Proxy Mobile IPv6", Frank Xia, Hidetoshi Yokota, Suresh Krishnan, 4-Mar-09. ( bytes): Proxy Mobile IPv6 allows a mobile node's IPv4 and IPv6 traffic between a Local Mobility Anchor(LMA) and a Mobile Access Gateway (MAG) to be tunneled using IPv6, IPv4 ,IPv4-UDP, or GRE encapsulation headers. In this document, a new mobility option is specified for tunnel negotiation between the LMA and MAG.
"Access Node Control Protocol for Source Adress Validation", John Kaippallimalil, Frank Xia, 28-Feb-09. ( bytes): This document specifies an extension of Access Node Control Protocol to provide source address validation for IPv4 and IPv6 networks. An access router uses the proposed mechanism to provision source address validation states on a layer 2 device which a host may directly connects to. The solution proposed here can be used in either public access networks or enterprise networks.
"Verified-Hello SMTP extension", Alessandro Vesely, 21-Jun-09. ( bytes): This memo defines an extension to the SMTP service that provides protocol support for weak authentication of SMTP clients. Weakly authenticated clients enjoy an intermediate level of trust: they have no relying privileges, but can attempt to deliver mail to local users, are whitelisted from some filters, and may receive DSNs as needed. Note that this treatment is what SMTP recommends for all clients. However, most servers operate filters to limit spam, thereby affecting the reliability of the mail forwarding system. Verified- Hello recovers that reliability by providing for uncensored mail transmission in a framework where authenticated domains are responsible for the messages they send. In addition, support is provided for an extensible set of authentication mechanisms, so that they can be managed and branded.
"The Extension of Subtree Filtering of NETCONF", Bin Zhang, Zhichao Yang, Yan Li, 28-Feb-09. ( bytes): The NETCONF protocol defines a subtree filtering mechanism to allow an client to select particular XML subtrees to be included in the for a or operation. In some aspects, subtree filtering has some disadvantages. This document defines an extended subtree filtering to solve these disadvantages.
"Requirements on multiple Interface (MIF) of simple IP", Peng Yang, Pierrick Seite, Carl Williams, Jacni Qin, 1-Mar-09. ( bytes): This draft makes a summary on the requirements of supporting multiple interfaces (MIF) in hosts with simple IP. These requirements result from examining scenarios for multiple interface host usages. The differentiation between MIF and other related IETF works are interpreted as well.
"An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", Sheng Jiang, Dayong Guo, 1-Mar-09. ( bytes): Global IPv6 deployment was slower than originally expected in the last ten years. As IPv4 address exhaustion gets closer, the IPv4/IPv6 transition issues become more critical and complicated. Host-based transition mechanisms are not able to meet the requirements while most end users are not sufficiently expert to configure or maintain these transition mechanisms. Carrier Grade NAT with integrated transition mechanisms can simplify the operation of end users during the IPv4/IPv6 migration or coexistence period. This document proposes an incremental Carrier-Grade NAT (CGN) solution for IPv6 transition. It can provide IPv6 access services for IPv6-enabled end hosts and IPv4 access services for IPv4 end hosts while remaining most of legacy IPv4 ISP networks unchanged. It is suitable for the initial stage of IPv4/IPv6 migration. Unlike CGN alone, it also supports and encourages transition towards dual-stack or IPv6-only ISP networks.
"PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation", Anna Charny, Fortune Huang, Michael Menth, Tom Taylor, 1-Mar-09. ( bytes): 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 ID.PCNArch. This memo is one of a series describing possible boundary node behaviours for a PCN domain. The behaviour described here is that for three-state measurement-based load control, known informally as CL. The requirement for three encoding states means that CL is for experimental use only pending further standards action.
"Analysis and scenarios of multiple interfaces in a host", Yong-Geun Hong, Tran Trung, Joo-Sang Youn, 13-Jul-09. ( bytes): This document includes an analysis of multiple interfaces in a host and a description of scenarios of multiple interfaces with the respect of the relationship between layer 2 connection and layer 3 connection. The current TCP/IP mechanism and networking methods are suitable for single network interface. When a host has multiple interfaces, the current TCP/IP mechanism and networking methods cannot directly be used for them. A network interface establishes layer 2 connection to layer 2 entity (e.g., WLAN Access Point) and it does not mean providing proper layer 3 connection. So every active network interfaces do not guarantee successful IP layer operations. In this document, we describe some problems for a host which has multiple interfaces as an aspect of host's operations and usage scenarios of multiple interfaces in a host.
"Virtual network interface model for multiple network interfaces in a host", Yong-Geun Hong, Joo-Sang Youn, 1-Mar-09. ( bytes): The use of multiple interfaces in a host with existing TCP/IP stack may have some problems. This document discusses how to solve the problems of multiple interfaces in a host and proposes a virtual network interface model which describes the use of original TCP/IP stack to support multiple network interfaces in a host.
"OSPF Extensions in Support of Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSONs)", Fatai Zhang, Young Lee, Jianrui Han, Greg Bernstein, Yunbin Xu, Guoying Zhang, Dan Li, Ming Chen, 12-Jul-09. ( bytes): This document describes OSPF routing protocols extensions to support Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSON) under the control of Generalized MPLS (GMPLS).
"ALTO H1/H2 Protocol", Martin Stiemerling, Sebastian Kiesel, 2-Mar-09. ( bytes): Many Internet applications are used to access resources, such as pieces of information or server processes, which are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications, which have to select one or several hosts from a set of candidates, that are able to provide a desired resource. This memo proposes one possible way of implementing the ALTO protocol, called H1H2. The H1H2 protocol is a client/server protocols between end hosts and ALTO servers that allows two different ways of exchanging data between the server and the client.
"SAVAH: Source address validation architecture with Host Identity Protocol", Dmitriy Kuptsov, Andrei Gurtov, 6-Mar-09. ( bytes): This document describes an architecture for the source address validation with help of Host Identity Protocol (HIP), SAVAH. The architecture utilizes the properties of cryptographically strong protocol to authenticate an originator of a network communication. In addition this architecture offers network access control, data protection, host mobilty and multihoming features and is suitable for the wireless networks. The proposed, architecture is the first-hop router solution, meaning that it should be deployed on the router placed on the edge of a local network topology.
"RTSP 2.0 Bitrate Notification", Hiroyuki Hatano, Kunihiro Taniguchi, Akira Kobayashi, Martin Stiemerling, 13-Jul-09. ( bytes): Typically, there is no use for providing bandwidth information from an RTSP 2.0 server to RTSP 2.0 clients. The bandwidth of the medias played out by the server is different from the available bandwidth in the network (which is also changing) and there is anyhow the need to perform congestion control during media playout. This is true for Internet deployments, or similar, but conveying information about bandwidth of the medias can be required in other deployments of RTSP 2.0. It might necessarily for RTSP 2.0 clients to obtain information about the by medias used bandwidth in networks that rely on bandwidth reservation initiated by the end host. An example is the Next Generation Network (NGN) standardized by ETSI TISPAN, where RTSP 2.0 clients must indicate the required bandwidth to the network. This memo discusses how to provide bandwidth information from RTSP 2.0 servers to clients and how to introduce it in RTSP 2.0.
"RSVP-TE extensions to GMPLS Calls", Fatai Zhang, Dan Li, Jianhua Gao, 7-Jul-09. ( bytes): Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extensions are used to support Calls. Although it is stated that these mechanisms are applicable to any environment (including multi-area), the "Call Path" is determined hop-by-hop by each "Call Manager" in sequence along the path of the Call. However, it is desirable to allow the Call-initiator to identify the Call Path explicitly in some cases (especially in the multi-domain case). This document describes RSVP-TE signaling extensions to allow the Call-initiator to identify the Call Path explicitly when transit nodes (besides the Call-initiator and Call-terminator) are involved in these Calls.
"Requirements for PCE applied in Time-Division Multiplexing (TDM) Networks", Fatai Zhang, Dan Li, Jianhua Gao, 2-Mar-09. ( bytes): This document describes the special requirements for applying the Path Computation Element (PCE) in Time-Division Multiplexing (TDM) networks, including Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), and Digital Wrapper (G.709 ODUk). The material presented in this document is collected here for analysis. The intention is to separate this material into separate documents on generic GMPLS requirements, generic GMPLS extensions, and TDM-specific requirements and extensions.
"A Session Initiation Protocol (SIP) Reason Header extension for dynamic Incoming Communication Barring", Ranjit Avasarala, Subir Saha, Victor Pascual, 2-Mar-09. ( bytes): The 3GPP, as part of the MITE work item, is defining the Multimedia Telephony service and other Supplementary services using the IP Multimedia Core Network framework. Supplementary services include Incoming and Outgoing Communication Barring. This document describes a new set of procedures for Incoming Communication Barring to allow terminating users to dynamically block unwanted incoming communications. A new extension to SIP reason header is also described.
"Re-ECN: The Motivation for Adding Congestion Accountability to TCP/IP", Bob Briscoe, Arnaud Jacquet, T Moncaster, Alan Smith, 2-Mar-09. ( bytes): This document describes the motivation for a new protocol for explicit congestion notification (ECN), termed re-ECN, 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. Authors' Statement: Status (to be removed by the RFC Editor) Although the re-ECN protocol is intended to make a simple but far- reaching change to the Internet architecture, the most immediate priority for the authors is to delay any move of the ECN nonce to Proposed Standard status. The argument for this position is developed in Appendix E.
"P2PSIP Event Notification Extension", Jun Wang, Zhifeng Chen, Yu Meng, Jiong Shen, 1-Jul-09. ( bytes): The p2p technology is data centric. Data objects are distributed in the p2p overlay according to routing algorithm.Applications access the data objects via peer/client protocol or gateways, some of which need data replicas to be synchronized in real time. This can be achieved by introducing a Subscribe/Notify mechanism to p2psip. This document describes the Subscribe/Notify mechanism extension for p2psip, and also defines several new methods as needed.
"Requirement of Impairment Compensation Control in WSON", Shoichiro Seno, Yoshimasa Baba, Eiichi Horiuchi, Kazuo Kubo, 2-Mar-09. ( bytes): This memo describes requirements of compensation control of optical impairments such as chromatic dispersion for dynamic optical paths, as well as automatic discovery of fiber-related impairments over links by collaboration of a pair of adjacent nodes upon installation. It is intended as a supplement to the wavelength switched optical networks (WSON) framework with impairments, because GMPLS-based automatic adjustment of impairment compensation and automatic discovery of link impairments will improve usability of WSON.
"Deriving Keys From TLS for Kerberos V5", Simon Josefsson, 6-Mar-09. ( bytes): This document describes how clients can use the Kerberos V5 over TLS protocol together with its long term key to 1) avoid having to validate the server certificate, 2) securely learn a KDC's server certificate, and 3) learn the trust anchors used by the KDC. We also describe how the Kerberos V5 over TLS protocol can be used to 4) avoid the need for a long term shared key between the client and the KDC by instead using TLS client authentication. These goals are achieved by introducing a new Kerberos V5 pre- authentication type that modify how the Kerberos V5 reply key is derived.
"Status of Normative References in RFC3261", Robert Sparks, 2-Mar-09. ( bytes): This document captures the current status of the normative references in RFC3261. It is intended to inform continuing discussions on how to maintain the SIP protocol.
"RFC3261 Interop Statement", Robert Sparks, 2-Mar-09. ( bytes): This document captures an outline of the interoperability statements that will be collected to construct an interoperability report for RFC 3261. The outline is stil under review and should not be treated as complete, but will drive data collection at upcoming interoperability events.
"MPLS TP Network Management Framework", Scott Mansfield, Kam Lam, Eric Gray, 23-Apr-09. ( bytes): This document provides the network management framework the Transport Profile for Multi-Protocol Label Switching (MPLS-TP). Mansfield, et al Expires October 23, 2009 [page 2] Internet-Draft MPLS-TP NM Framework April 23, 2009
"The RPKI/Router Protocol", Randy Bush, Rob Austein, 1-Jul-09. ( bytes): In order to formally validate the origin ASes of BGP announcements, routers need a simple but reliable mechanism to receive RPKI [I-D.ietf-sidr-arch] or analogous prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers over ssh.
"Rethinking TCP Friendly", Matt Mathis, 2-Mar-09. ( bytes): The current Internet fairness paradigm mandates that all protocols have equivalent response to packet loss, such that relatively simple network devices can attain a weak form of fairness by sending uniform signals to all flows. This "TCP-friendly" paradigm has been the policy of the IETF for nearly two decades. Although it was only an informal policy in the beginning, it progressively became more formal following the publication of RFC 2001 in 1997. However we observe two trends that differ from this policy: an increasing number of environments where applications and other circumstances create situations that are "unfair", and ISPs that are responding to these situation by imposing traffic control in the network itself. This note explores the question of whether TCP-friendly paradigm is still appropriate for the huge breadth of technology and scale encompassed by today's global Internet. It considers the merits and difficulties of changing IETF policy to embrace these changes by progressively moving the responsibility for capacity allocation from the end-system to the network. Ultimately this policy change might eliminate or redefine the requirement that all protocols be "TCP- Friendly". This note is intended foster discussion in the community and eventually become input to the IESG and IAB, where it might evolve into a future architecture statement.
"Information Encoding for Impaired Optical Path Validation", Greg Bernstein, Cisco Systems, 8-Jul-09. ( bytes): This document provides an information encoding for the optical impairment characteristics of optical network elements for use in path computation and optical path impairment validation. This encoding is based on ITU-T defined optical network element characteristics as given in ITU-T recommendation G.680 and related specifications. This encoding is intentionally compatible with a previous impairment free optical information encoding used in optical path computations and wavelength assignment.
"The PROXIDOR Service", Obi Akonjang, Anja Feldmann, Stefano Previdi, Bruce Davie, Damien Saucez, 2-Mar-09. ( bytes): Several applications, such as peer-to-peer (P2P), content distribution and realtime services rely on selection mechanisms in order to select the peer or server from which to request the service. Examples of such services are: file sharing, media streaming and voice gateways. Application-layer selection algorithms do not typically take into account network-layer topology information; either that information is unavailable to them, or when such information is available (e.g., from BGP Looking Glass servers), it does not include sufficient information about the local topology in the neighbourhood of the application client(s). Therefore, most applications today make their selection decisions based on performance measurements (combined with some amount of random selection) and largely ignore network layer routing. It has been demonstrated that by keeping the traffic local (e.g., within the same Autonomous System) both infrastructure utilization and application performance may be improved. By enhancing selection algorithms through the use of accurate network-layer topology, applications may improve performance while network operators are also able to reduce the utilization of infrastructure resources by application traffic. At the same time, exchange of information between the application and the network should not be allowed to compromise confidentiality for either party. Detailed routing information owned by the service provider should not be made publicly available, while detailed information about the application should also not be made known to the service provider. This draft introduces a signaling protocol which we call "PROXIDOR". The PROXIDOR protocol is a request-response protocol in which a PROXIDOR Client (PxC) issues requests to and receives responses from a PROXIDOR Server (PxS). The questions of how a PxC discovers a PxS and how a PxS acquires network-layer topology information are beyond the scope of this document.
"Multicast only Fast Re-Route", Apoorva Karan, Clarence Filsfils, Dino Farinacci, 2-Mar-09. ( bytes): 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.
"IUA Extension for Rate Control Message", Nick Stewart, Geoff Hunt, Dal Chohan, 2-Mar-09. ( bytes): This document describes a new message, its associated acknowledgement message, and a new parameter to extend the ISDN Q.921-User Adaptation (IUA) protocol (RFC4233). The protocol extension is to support the use of an Overload Control Agent in a Signaling Gateway (SG). The Overload Control Agent is able to restrict the admission of new originating ISDN calls (sessions) messages from the ISDN End Point to each Application Server Process (ASP). Both messages defined here contain a single mandatory parameter, the Call (Session) Admission Rate. An ASP is able to use this protocol extension to control the rate of new calls admitted towards that ASP by the Overload Control Agent. The new message and its acknowledgement message are added to the Application Server Process Traffic Maintenance (ASPTM) message class. As the DPNSS1/DASS2 Extension to IUA (DUA, RFC4129) also uses the ASPTM message class, the IUA protocol extension described in this document also applies to DUA. For backward compatibility, a Signaling Gateway which does not support the new message is expected to follow standard IUA behaviour by discarding the message, and returning an error code of "Unsupported Message Type" to the sender.
"Local Forwarding in Proxy Mobile IPv6", Rajeev Koodli, Kuntal Chowdhury, 2-Mar-09. ( bytes): With bidirectional tunneling in Proxy Mobile IPv6, the communication between any two Mobile Nodes is required to traverse the Local Mobility Anchor (LMA). This is the case even when the communicating Mobile Nodes are attached to the same Mobility Anchor Gateway (MAG). This document introduces two messages between the LMA and the MAG enabling local forwarding by the MAG. Such forwarding avoids the delay due to bidirectional forwarding, and reduces the traffic load on the LMA.
"Modular RELAX NG Schema of NETCONF RPC and Protocol Operations", Ladislav Lhotka, 2-Mar-09. ( bytes): This memo presents a schema for NETCONF RPC and protocol operations expressed in RELAX NG (compact syntax). The schema is modular and cleanly separates the server and client part of the NETCONF vocabulary and also the schema extensions provided by optional capabilities. The modular structure improves readability but also enables selecting certain modules and assembling them into a grammar that can be used for validation of NETCONF protocol data units.
"A Batch Notification Extension for the Session Initiation Protocol (SIP)", Alan Johnston, Bill Mertka, 2-Mar-09. ( bytes): This memo specifies the requirements and mechanism for a SIP events extension where bulk SIP event information can be shared between two peers both with the ability and authority to act as notifiers for this information. An example application use case is the transition of event state information during a backup/recovery sequence between event state servers. This document is targeted at addressing server overflow conditions that include the possibilities of the size of individual notification messages getting excessive and the processing of state information by both the subscriber and notifier also becoming excessive.
"Default Router and Prefix Advertisement Options for DHCPv6", Ralph Droms, Thomas Narten, 2-Mar-09. ( bytes): In some IPv6 deployments, there is a requirement to communicate a list of default routers and advertised prefixes to a host through DHCP. This document defines DHCP options to carry that information.
"Recommendations for Processing Mechanism for Checksum Error LSP in interoperable Networks using Intermediate System to Intermediate System (IS-IS)", Xiaodong Duan, Lianyuan Li, Zhenqiang Li, 13-Jul-09. ( bytes): RFC3719 discusses a number of differences between the IS-IS protocol as described in ISO 10589 and the protocol as it is deployed today. This document discusses some other differences found in the China Mobile's backbone network which is constructed with routers from several manufacturers. The differences include corrupt LSP processing, zero checksum LSP processing, zero remaining lifetime LSP processing, and LSP checksum calculation.
"CJK local mapping in IDNA2008", Yoshiro Yoneya, Yungjin Suh, Erin Chen, XiaoDong Lee, 9-Mar-09. ( bytes): Development of IDNA2008 is now in final stage. It will cause incompatibilities for Chinese, Japanese and Korean (CJK) scripts and languages. To avoid incompatibilities with IDNA2008 and current IDNA (IDNA2003), definition of specific local mapping (pre process of IDNA to be performed to IDN candidate string) for CJK is recommended.
"SIP digest authentication relay attack", R State, O Festor, Humberto Abdelnur, Victor Pascual, J Kuthan, 2-Mar-09. ( bytes): The Session Initiation Protocol (SIP [RFC3261]) provides a mechanism for creating, modifying, and terminating sessions with one or more participants. This document describes a vulnerability of SIP combined with HTTP Digest Access Authentication [RFC2617] through which an attacker can leverage the victim's credentials to send authenticated requests on his behalf. This attack is different from the man-in-the-middle (MITM) attack and does not require any eavesdropping, DNS or IP spoofing.
"Live Entity State Stream (LESS) protocol description", Jon Watte, 4-Mar-09. ( bytes): Virtual worlds, typically implemented as multi-user shared simulations, are becoming increasingly used for serious work in addition to the traditional uses of research and entertainment. Whereas previous distributed simulation protocols have been designed with narrow, time-definite scope, the LESS (Live Entity State Stream) protocol is designed to allow open-ended join and leave for a multitude of simulation peers. The LESS protocol specifies how peers of a simulation collaborate and share state to achieve a mutually agreed "collective hallucination," leading to a user-perceivable shared state of a simulated worlds.
"LISP Map Server", Dino Farinacci, Vince Fuller, 2-Mar-09. ( bytes): This draft describes the LISP Map-Server (LISP-MS), a computing system which provides a simple LISP protocol interface as a "front end" to the Endpoint-ID (EID) to Routing Locator (RLOC) mapping database and associated virtual network of LISP protocol elements. The purpose of the Map-Server is to simplify the implementation and operation of LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs), the devices that implement the "edge" of the LISP infrastructure and which connect directly to LISP-capable Internet end sites.
"Dual Homed Access in Virtual Private Multicast Service", Wu Bo, Zhang Xinquan, Luo Jian, Chen Ran, 2-Mar-09. ( bytes): Virtual Private Multicast Service (VPMS) is defined as a Layer 2 VPN service. It provides point-to-multipoint connectivity for a variety of Layer 2 technologies, including Frame Relay, ATM, Ethernet, PPP, etc, across an IP or MPLS-enabled IP Packet Switch Network (PSN). It is often required for redundant access between two VPMS PEs to which a CE is attached, called "dual-homed". This document describes how dual-homed access can be achieved in the context of BGP-based VPMS.
"Problem Statement for Route Optimization in dual stack environments", Desire Oulai, Suresh Krishnan, Hesham Soliman, 2-Mar-09. ( bytes): Dual Stack MIPv6 (DSMIP) is a MIPv6 extension to support IPv4 mobility for mobile hosts. While route optimization is well defined for IPv6 traffic, this features is not defined for IPv4. This document looks at the different scenarios where IPv4 route optimization is desirable and highlights some problems.
"DSMIPv6 Route Optimization", Desire Oulai, Suresh Krishnan, Hesham Soliman, 2-Mar-09. ( bytes): Dual Stack MIPv6 (DSMIP) is a MIPv6 extension to support IPv4 mobility for mobile hosts. While route optimization is well defined for IPv6 traffic, this feature is not defined for IPv4. However, Route Optimization has many advantages as reduced delays and lower load for the Home Agent. This document proposes solutions for the different scenarios where IPv4 route optimization is performed.
"A Survey of Lower-than-Best Effort Transport Protocols", Michael Welzl, 2-Mar-09. ( bytes): This document provides a survey of transport protocols which are designed to have a smaller bandwidth and/or delay impact on standard TCP than standard TCP itself when they share a bottleneck with it. Such protocols could be used for low-priority "background" traffic, as they provide what is sometimes called a "less than" (or "lower than") best effort service.
"Multiple Passwords per User in XMPP", Kurt Zeilenga, 2-Mar-09. ( bytes): This document discusses use of multiple passwords (per user) in XMPP.
"SIP-Specific Event Notification", Adam Roach, 3-Mar-09. ( bytes): This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification.
"Multicast Acquisition Report Block Type for RTCP XR", Ali Begen, Eric Friedrich, 13-May-09. ( bytes): In most RTP-based multicast applications, the RTP source sends inter- related data. Due to this interdependency, randomly joining RTP receivers usually cannot start consuming the multicast data right after they join the session. Thus, they often experience a random acquisition delay. One approach to reduce this delay is to use an auxiliary unicast RTP session with a retransmission server to receive a burst stream that facilitates rapid acquisition of the multicast stream. An RTP receiver may use this approach (or any other approach) to achieve rapid acquisition. Yet, due to various factors, performance of the rapid acquisition methods usually varies. Furthermore, in some cases the RTP receiver may (or may have to) do a simple multicast join. For quality reporting, monitoring and diagnostics purposes, it is important to collect detailed information from the RTP receivers about their acquisition experiences. This document addresses this issue by defining a new report block type, called Multicast Acquisition (MA) Report Block, within the framework of RTP Control Protocol (RTCP) Extended Reports (XR). This document also defines the necessary signaling of the new MA report block type in the Session Description Protocol (SDP).
"ALTO H12", Sebastian Kiesel, Martin Stiemerling, 3-Mar-09. ( bytes): Many Internet applications are used to access resources, such as pieces of information or server processes, which are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications, which have to select one or several hosts from a set of candidates, that are able to provide a desired resource. This memo proposes one possible way of implementing the ALTO protocol, called H12.
"IPSEC_API requirements", Daniel Migault, 2-Mar-09. ( bytes): IPsec suite has been designed to secure communication between two nodes. Security is performed at the network layer, and there are almost no interactions between applications and the IPsec layer. The main motivation of this API is to enable any applications to interact with the IPsec layer and to take advantage of the security deployed in IPsec suite. This draft lists applications requirements with regard to the IPsec suite, and we tried not to limit the requirements to today's application requirements, but also to consider future applications' requirements. Applications are associated to different privileges, and IPsec layer MUST be protected from nasty IPsec manipulations. This draft is not considering applications privileges management. This draft lists any possible requirements on the IPsec layer an application might require.
"MIP Extension for Ethernet Service transport Support", Wenson Wu, Shah Rahman, Hui Deng, 11-May-09. ( bytes): The IP Mobility Protocol [RFC3344] enables a mobile node maintain IP connectivity when it changes its location. However, it is not enough to enable the node to maintain L2 connectivity between mobile node and Ethernet service provider in order to support Ethernet service transport. This document describes "Ethernet Service Transport" mobility option for mobile IPv4 that is intended to assist home agent tunnel Ethernet packets from the home link to the FA on the foreign link during the datagram delivery process.
"6to4 Qualification", Nathan Ward, 3-Mar-09. ( bytes): A deployment problem exists with existing self-configuring 6to4 implementations making often incorrect assumptions about the state of their IPv4 network connectivity. This document describes the problem, and proposes a qualification mechanism by which nodes can validate that their connectivity to the global IPv6 network is suitable for use with the 6to4 protocol.
"Issues with ISP Responses to IPv4 Address Exhaustion", Alain Durand, Mat Ford, Phil Roberts, 3-Mar-09. ( bytes): The looming completion of IPv4 address allocations from IANA and the RIRs is already causing ISPs around the world to start to question how they will continue providing IPv4 service to IPv4-speaking customers when there are no longer sufficient IPv4 addresses to allocate them one per customer. Several possible solutions to this problem are now emerging and this memo identifies important criteria to be borne in mind when evaluating these solutions. We also seek to identify serious issues that remain even when mechanisms meeting our criteria are adopted. We wish to stress that these solutions have a number of common, and potentially serious, issues.
"Runtime LMA Assignment Support for Proxy Mobile IPv6", Jouni Korhonen, Sri Gundavelli, Hidetoshi Yokota, 11-May-09. ( bytes): This document describes a redirect functionality and corresponding mobility options for Proxy Mobile IPv6. The redirect functionality allows a dynamic runtime assignment of a Local Mobility Anchor and redirecting the mobility session to the assigned Local Mobility Anchor.
"Media State under Preconditions in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, 3-Mar-09. ( bytes): In this document, we describe how a UAS (User Agent Server) involved in a session modification can explicitly signal the point where the new session parameters start being used. Explicitly signalling such a change in the session parameters can be useful so that network intermediaries such as B2BUAs (Back-to-back User Agents) have a clear picture of the session's state at every point.
"Clarification of RRO Node-Id Sub-Object", Harish Sitaraman, Yuji Kamite, 3-Mar-09. ( bytes): This document clarifies the RRO format and usage of the node-id sub- object as defined in [RFC4561]. The RRO stacking order and allowed formats when including the node-id sub-object is specified.
"Cryptographic Algorithms, Use, & Implementation Requirments for TCP Authentication Option", Gregory Lebovitz, 27-Jul-09. ( bytes): The TCP Authentication Option, TCP-AO, relies on security algorithms to provide authentication between two end-points. There are many such algorithms available, and two TCP-AO systems cannot interoperate unless they are using the same algorithm(s). This document specifies the algorithms and attributes that can be used in TCP-AO's current manual keying mechanism.
"LISP Mapping Versioning", Luigi Iannone, Damien Saucez, Olivier Bonaventure, 3-Mar-09. ( bytes): The present document sketches an alternative approach to provide information about changes to EID-to-RLOC mappings in the context of LISP. The proposed approach is based on a versioning system for the EID-to-RLOC mapping itself. When there is a change in the mapping (where change could mean adding/removing an RLOC or just a modification in the priority or weight of one or more RLOCs) a new version number is generated and propagated in the LISP data packet. In the LISP context, ETRs do not keep state that allows to know when an ITR changes a mapping. The versioning system is a data-driven mechanism to annonce those changes. In order to support such an approach, the LISP encapsulation need to be modified. In particular LISP-encapsulated data packets have to contain the version number of the mapings used to select the RLOCs in the outer header. These version numbers are contained in a "new" LISP header. The mappings are distributed as usual through the mapping distribution system (e.g., CONS, ALT); versioning is only a mean to announce that something has changed in the mapping. The infrastructure built by each specific mapping protocol does not change anyhow. Nevertheless, two modifications are needed. The first modification consist in including version number in the Map- Reply messages. The second modification consist in the introduction of a new message, the "Map-Update-Notification" message used by ETRs to notify ITRs that the mapping used to encapsulate the packet is old and needs to be updated. This message does not contain the mapping, it just suggests ITRs to perform a Map-Request in order to retrieve the updated mapping.
"Extensible Authentication Protocol Method for Trusted Computing Groups (TCG) Trusted Platform Modules", Carolin Latze, Ulrich Ultes-Nitsche, Florian Baumgartner, 27-Jul-09. ( bytes): This document describes an Extensible Authentication Protocol (EAP) [RFC3748] method for identity distribution, authentication and session key distribution using the Trusted Computing Group's (TCG) Trusted Platform Module (TPM). The TPM has been defined by the TCG in order to establish a root of trust and measurements in (consumer) computers. It provides several cryptographic functions and a secure storage for keys and hashes. There is also a TPM specification for mobile devices called Mobile Trusted Module (MTM), which can also be used for EAP-TPM. This new EAP method allows network authentication, which also supports user anonymity, the usage of different user identities for the authentication with different network operators, result indication, and a fast re-authentication.
"SIP Tracing Facility", Dale Worley, 3-Mar-09. ( bytes): This document defines a SIP option tag, "trace", to be used within SIP messages to request that SIP elements (both proxies and UASs) that receive the message reflect to the UAC the request they received and the response they gave by encapsulating the request and response in a provisional response. A new provisional response code "170" is defined to carry the request and response. This option tag is expected to be used solely for diagnostic purposes.
"LEDBAT Practices and Recommendations", Reinaldo Penno, Satish Raghunath, Janardhan Iyengar, 3-Mar-09. ( bytes): Applications routinely open multiple TCP connections. For example, P2P applications maintain connections to a number of different peers while web browsers perform concurrent download from the same web server. Application designers pursue different goals when doing so: P2P apps need to maintain a well-connected mesh in the swarm while web browsers mainly use multiple connections to parallelize requests that involve application latency on the web server side. But this practice also has impacts to the host and the network as a whole. For example, an application can obtain a larger fraction of the bottleneck than if it had used fewer connections. Although capacity is the most commonly considered bottleneck resource, middlebox state table entries are also an important resource for an end system communication. This documents clarifies the current practices of application design and reasons behind them, and discusses the tradeoffs surrounding the use of many concurrent TCP connections to one destination and/or to different destinations. Other resource types may exist, and the guidelines are expected to comprehensively discuss them.
"Diameter NAT Control Application", Frank Brockners, Cisco Systems, Cisco Systems, 3-Mar-09. ( bytes): This document describes the framework, messages, and procedures for the Diameter NAT Control Application (DNCA), allowing for per- endpoint control of large scale NAT devices, which are put in place to cope with IPv4-address space completion. The Diameter NAT Control Application allows external devices to configure and manage a Large Scale NAT (LSN) device - expanding the existing Diameter-based AAA and policy control capabilities with a NAT control component. These external devices can be network elements in the data plane such as a Network Access Server (NAS), or can be more centralized control plane devices such as AAA-servers. DNCA establishes a context to commonly identify and manage endpoints on a gateway or server, and a large scale NAT device. This includes, for example, the control of the total number of NAT-bindings allowed or the allocation of a specific NAT-binding for a particular endpoint. In addition, it allows large scale NAT devices to provide information relevant to accounting purposes.
"Running Code Considerations Section in RFCs", Marc Petit-Huguenin, Henry Sinnreich, 3-Mar-09. ( bytes): This document provides guidelines to IETF authors on the text that must be included in documents to reference running code and measurements.
"RADIUS attributes for IPv6 Access Networks", Benoit Lourdelet, Wojciech Dec, Behcet Sarikaya, Glen Zorn, 28-Jun-09. ( bytes): This document specifies new IPv6 RADIUS attributes used to support IPv6 network access. As IPv6 specifies two configuration mechanisms (DHCP and SLAAC), the new attributes are targeted at both protocols when that makes sense.
"Open Grid Protocol: Foundation", Mark Lentczner, 3-Mar-09. ( bytes): The Open Grid Protocol documents define the protocols by which a vast, Internet wide virtual world can operate. This protocol enables different regions of the virtual world to be operated independently, yet interoperate to form a cohesive experience. This document specifies the foundation upon which various suites of virtual world functionality are built. It describes the basic structure of OGP interaction and common methodology and terminology for protocols.
"A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations.", Huub Helvoort, Loa Andersson, Nurit Sprecher, 3-Mar-09. ( bytes): 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.
"Export of Structured Data in IPFIX", Stan Yates, 30-Jul-09. ( bytes): This document specifies an extension to IP Flow Information eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX information model specified in [RFC5102] to support hierarchical structured data and lists (sequences) of Information Elements in data records. This extension allows definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between Templates.
"Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for Access Network Discovery and Selection Function(ANDSF) Discovery", Subir Das, Gabor Bajko, 13-Jul-09. ( bytes): This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options that contain a list IP addresses and a list of domain names that can be mapped to ANDSF (Access Network Discovery and Selection Function) entities in an IP network. ANDSF is being developed in 3GPP (Release-8) and provides inter-system mobility policies and access network specific information to the mobile nodes(MNs) [3GPPTS23.402].
"MPLS-TP OAM Alarm Suppression Tools", Annamaria Fulignoli, Nurit Sprecher, Yaacov Weingarten, 13-Jul-09. ( bytes): The aim of this draft is to define an MPLS-TP OAM mechanism to meet the requirements for Alarm Suppression functionality as required in [3]. One packet format with two different function codes is here defined in order to distinguish among packets with Alarm Indication information and packets with Lock Indication Information.
"Top Level Domain Name Specification", Lars-Johan Liman, 3-Mar-09. ( bytes): RFC 1123 is ambiguous regarding the specification for top level domain (TLD) labels used in the domain name system. This document clarifies the specification, and aligns it with current praxis, including the use of Internationalized Domain Name (IDN) Labels in TLD names.
"A Load Balancing Mechanism for REsource LOcation And Discovery", Saumitra Das, Ashwin Swaminathan, Vidya Narayanan, 3-Mar-09. ( bytes): Load balancing is essential to effectively manage data and provide services on overlays. This draft presents a solution for load balancing the default topology plugin in RELOAD.
"ALTO Discovery Protocols", Gustavo Garcia, Marco Tomsu, Yu-Shun Wang, 3-Mar-09. ( bytes): The Application-Layer Traffic Optimization service aims to provide applications with information to perform better-than-random initial peer selection when multiple peers in the network are available to provide a resource or service. This document discusses the discovery protocols for the service.
"Protocol Analysis and Comparison of PPlive,PPstream and UUSee by Internet Measurement", Yunfei Zhang, Chunxi Li, 8-Jul-09. ( bytes): In this draft we introduce an Internet measurement work for pplive, ppstream and UUSee. First, we give a brief introduction about our motivation and target of this measurement. We then introduce the methodology, platform, data and modeling of our measurement. Finally we outline the p2p media streaming protocols by the measurement. Zhang Expires January 9,2010 [page 2] Internet-Draft Protocol Analysis and Comparison of PPlive, PPstream and UUSee by Internet Measurement July 2009
"vCard Format Extension : To Represent the Social Network Information of an Individual", Robins George, Barry Leiba, Alexey Melnikov, 13-Jul-09. ( bytes): This document defines an extension to the vCard data format for representing and exchanging a variety of social network information. Note A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to vcarddav@ietf.org.
"MAC Flush Loop Detection in VPLS", Mountain View, Pranjal Dutta, 3-Mar-09. ( bytes): MAC Address Withdrawal is a mechanism described in [RFC4762] to remove or unlearn MAC addresses that have been dynamically learned for faster convergence. Failure of mechanisms that control loop free connectivity among VPLS PE nodes may cause MAC Address Withdrawal messages looping among those nodes, leading to Denial of Service (DoS) or complete failure of control plane in the PE nodes. This document describes a mechanism to detect and prevent loops of MAC Address Withdrawal messages in a VPLS PE node.
"Multiple Interface Support with Proxy Mobile IPv6", Vijay Devarapalli, Nishi Kant, Heeseon Lim, Christian Vogt, 3-Mar-09. ( bytes): Proxy Mobile IPv6 enables network-based mobility for a regular IPv6 mobile node with no mobility management protocol. It makes it appear to the mobile node that its IP address does not change as the mobile node moves across the Proxy Mobile IPv6 domain. There have been some issues identified with supporting a host with multiple interfaces attaching to the Proxy Mobile IPv6 domain. This document describes and analyzes some of the scenarios associated with this. It also describes the requirements for a handover across interfaces using Proxy Mobile IPv6.
"Partial Handoff Support in PMIPv6", Mohana Jeyatharan, Chan-Wah Ng, Sri Gundavelli, Kent Leung, Vijay Devarapalli, 3-Mar-09. ( bytes): Proxy Mobile IPv6 (PMIPv6) only supports session continuity for one basic scenario of vertical handoff -- the transfer of all prefixes assigned from one interface to another. However, there are some other advanced scenarios associated with vertical handoff that involves only transferring one (or some, but not all) of the prefixes that are allocated to an existing interface to a newly powered on interface. This draft outlines extensions to PMIPv6 protocol in order for a multiple interfaced mobile node to achieve such partial vertical handoff of selected prefix(es).
"Targeted LDP Hello Reduction", Pranjal Dutta, 3-Mar-09. ( bytes): 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.
"A Pragmatic Approach for Reducing Delays in Publishing Documents within the Real-time Applications and Infrastructure (RAI) Area", Hannes Tschofenig, Henning Schulzrinne, Markus Isomaki, 3-Mar-09. ( bytes): During the last year, participants in the Real-time Applications and Infrastructure (RAI) area have been quite active in discussing proposals that could improve their way of working. This document is a contribution to that discussion and focuses on the reduction of delays experienced in producing specifications. We believe that this is one of the main problems in the RAI area (and quite likely in other areas of the IETF as well) and it requires attention. A number of side effects, caused by the long specification work, are illustrated in this document.
"P2P Streaming Protocol (PPSP) Requirements", Carl Williams, Ning Zong, Yunfei Zhang, Victor Pascual, 13-Jul-09. ( bytes): The Peer to Peer Streaming Protocol (PPSP) is a distributed real-time data retrieval protocol in one-to-many communication. This document describes the requirements for the PPSP.
"Extension of DHCP Relay Agent Information Option", Lu Huang, Xu Cheng, Lin Lin, 3-Mar-09. ( bytes): This Internet draft describes an extension of DHCP Relay Agent Information option for the IP address assignment diversity and the server-to-client replies forwarding convenience.
"Marking of Calls initiated by Public Safety Answering Points (PSAPs)", Henning Schulzrinne, Hannes Tschofenig, 3-Mar-09. ( bytes): After an emerency call is completed it is possible that the need for further communication between the call-taker and the emergency caller arises. For example, further assistance may be needed but the communication previously got interrupted. A call-taker may trigger a callback towards the emergency caller using the contact information provided with the initial emergency call. This callback would then be treated like any other call. As a consequence, it may get blocked by authorization policies configured by the person seeking help or may get forwarded to his answering machine. The current ECRIT framework document addresses callbacks in a limited fashion and thereby covers a few scenarios. This document discusses shortcomings and raises the question whether additional solution techniques are needed.
"LDP IGP Synchronization for broadcast networks", Sriganesh Kini, Wenhu Lu, 4-Mar-09. ( bytes): [LDP-IGP-SYNC] describes a mechanism to prevent black-holing traffic (e.g. VPN) when IGP is operational on a link but LDP is not. If this mechanism is applied to broadcast links that have more than one LDP/IGP peer, the cost-out procedure can only be applied to the link as a whole but not an individual peer. When a new LDP peer comes up on a broadcast network, this can result in loss of traffic through other established peers on that network. This document describes a mechanism to address that use-case without dropping traffic. The mechanism does not introduce any protocol changes.
"SIP extensions for media control", Shanmugalingam Sivasothy, Gyu Myoung Lee, Noel Crespi, 14-Jul-09. ( bytes): This draft presents a requirement and proposes a solution to integration of Session Initiation Protocol (SIP), to the Real Time Streaming Protocol (RTSP and RTSP v2) [RFC 2326 and IDRTSP] especially in the context of converged media services or IPTV services. The document develops a rationale for using SIP with streaming media applications. One service on top of IPTV service is sketched out, which required SIP optimally.
"Basic HTTP API interface for ACH", Theo Zourzouvillys, 8-Mar-09. ( bytes): This document defines a RESTful HTTP API that enables a SIP device (or agent activing on behalf of) a way to configure, enable, or disable services provided by the network.
"Benchmarking Methodology for Content-Aware Network Devices", Mike Hamilton, 9-Jul-09. ( bytes): The purpose of this document is to define a series of test scenarios which may be used to generate statistics that should help to better understand the performance of network devices under realistic loading conditions. Additionally, this document provides suggestions on which statistics may be the most useful for determining network device performance under realistic deployment scenarios.
"A Secure Call-ID for the Session Initiation Protocol (SIP)", Hadriel Kaplan, 4-Mar-09. ( bytes): Many SIP devices generate Call-ID values which contain their system IP Address, due to examples and normative text in RFC 3261. This Kaplan Expires September 1, 2009 [page 1] SIP Secure Call-ID March 2009 has led to some middleboxes, such as SBC's, to change the Call-ID for security reasons. This draft updates RFC 3261 to require SIP User Agents to generate benign Call-IDs, in such a manner that they can be detected as secure and not need to be changed.
"Evolution Towards Global Routing Scalability", Beichuan Zhang, Lixia Zhang, 9-Mar-09. ( bytes): Internet routing scalability has long been considered a serious problem. Over the years many efforts have been devoted to address this problem, however the IETF community as a whole is yet to achieve a shared understanding on what is the best way forward. We step up a level to re-examine the problem and the ongoing efforts, and conclude that, to effectively solve the routing scalability problem, we first need a clear understanding on how to introduce solutions to the Internet, which is a global scale deployed system. In this draft we sketch out our reasoning on the need for an evolutionary path towards scaling the global routing system, instead of attempting a new design.
"Multi-interface Connection Manager Implementation and Requirements", Jian Yang, Tao Sun, Shunan Fan, 4-Mar-09. ( bytes): This document presents the current implementation and problems encountered in practice of the "Connection Manager." The problems to be addressed exist within an operating system (OS) and platforms above OS. This document focuses on levels above OS and presents the solutions, especially for terminals with multiple interfaces. The scenarios of interface selections are described.
"Proxy MIP extension for local routing optimization", Wenson Wu, Behcet Sarikaya, 13-Jul-09. ( bytes): This document extends local routing in proxy Mobile IPv6 and defines a simplified localized routing optimization protocol within one PMIPv6 domain. The protocol supports IPv4 transport network operation, IPv4 home address mobility and handover. The Local mobility anchor/mobile access gateway initiates local routing for the mobile and correspondent node by sending messages to each mobile access gateway/local mobility anchor. In case the correspondent node is connected to another local mobility anchor, the local mobility anchors connected by the correspondent node needs to be discovered firstly so that it can notify its mobile access gateways to the mobile access gateway attached by the mobile node afterwards. Mobile access gateways create and refresh bindings using proxy binding update and acknowledgement messages.
"Open Grid Protocol: Service Establishment", Tess Chu, Meadhbh Hamrick, Mark Lentczner, 13-Jul-09. ( bytes): Service establishment in the Open Grid Protocol is the process of creating an application layer association between a client application and a remote service responsible for managing an end entity's identity. Before a service may be used, the requesting party must present credentials, handle any per-entity authentication- time maintenance requirements, and request capabilities the client intends to use. Peer hosts to be authenticated include end users and remote domain hosts. Multiple mechanisms are defined for authentication, but all authentication and service establishment requests follow the same pattern.
"IPv6 Autoconfig Filtering on Ethernet Switches", Nathan Ward, 4-Mar-09. ( bytes): Many ethernet switch vendors provide features for filtering IPv4 address assignment services - i.e. DHCP, Bootp. This document describes what is necessary for a switch to provide the same level of filtering for IPv6, as a standard on which operators can base equipment selection decisions.
"Transition Mechanisms for Routing Architecture for the Next Generation Internet (RANGI)", Xiaohu Xu, 12-Jul-09. ( bytes): The Routing Architecture for the Next Generation Internet (RANGI) described in [RANGI] is a proposal for solving routing scalability, mobility, multihoming, traffic engineering and other issues facing the current Internet. This document describes some transition mechanisms for the RANGI. With these mechanisms, legacy IPv4 and IPv6 hosts can communicate with RANGI hosts, and vice versa.
"Routing Architecture for the Next Generation Internet (RANGI)", Xiaohu Xu, 12-Jul-09. ( bytes): IRTF Routing Research Group (RRG) is exploring a new routing and addressing architecture to address the issues with the current Internet, e.g., mobility, multi-homing, traffic engineering, and especially the routing scalability. This document describes a new identifier (ID)/locator split based routing and addressing architecture, called Routing Architecture for the Next Generation Internet (RANGI), in an attempt to deal with the above problems.
"Low Extra Delay Background Transport (LEDBAT)", Stanislav Shalunov, 4-Mar-09. ( bytes): LEDBAT is an alternative experimental congestion control algorithm. LEDBAT enables an advanced networking application to minimize the extra delay it induces in the bottleneck while saturating the bottleneck. It thus implements an end-to-end version of scavenger service. LEDBAT has been been implemented in BitTorrent DNA, as the exclusive congestion control mechanism, and in uTorrent, as an experimental mechanism, and deployed in the wild with favorable results.
"Simultaneous Multi-Access and Flow Mobility Support for PMIPv6", Conny Larsson, Michael Eriksson, Petter Arvidsson, 4-Mar-09. ( bytes): This document specifies how flow mobility can be realized for a mobile node with multiple network interfaces, for which the network provides mobility support by means of Proxy Mobile IPv6 (PMIPv6). By introducing a "Primary Prefix", the mobile node is able to maintain IP data sessions when moving between different network interfaces. This document introduces a new set of ICMP and Mobility Header messages. It requires modifications of the mobile node. However, since support for simultaneous multi-access and flow mobility requires modifications of the mobile node anyway, the modifications suggested in this document are considered to be modest. The suggested enhancement is fully backwards compatible with the base Proxy Mobile IPv6 specification. The mobile node may be an IPv4-only node, IPv6-only node, or a dual-stack node.
"An Extension to the Session Initiation Protocol (SIP) for Request History Information", Mary Barnes, Francois Audet, 4-Mar-09. ( bytes): 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 call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests.
"BGP Advisory Message", Tom Scholl, John Scudder, 4-Mar-09. ( bytes): The BGP routing protocol is used with external as well as internal neighbors to propagate route advertisements. In the case of external BGP sessions, there is typically a demarcation of administrative responsibility between the two entities. Provisioning, maintenance and administrative actions are communicated via off-line methods such as email or telephone calls. While these methods have been used for many years, it can be troublesome for an operator to correlate a BGP- related event in the network with a notice that was transmitted in email. This document proposes a new BGP message type, the Advisory message, which can be used to convey advisory information to a BGP speaker's peer. A capability is used to ensure that the recipient of the Advisory message is capable of supporting it.
"Current Practices for Multiple Interface Hosts", Margaret Wasserman, 25-Mar-09. ( bytes): An increasing number of hosts are operating in multiple-interface environments, where different network interfaces are providing unequal levels of service or connectivity. This document describes how some common operating systems cope with the related challenges.
"Peer to Peer Localization Services and Edge Caches", Nicholas Weaver, 4-Mar-09. ( bytes): Without caches in the infrastructure, peer to peer content delivery's primary effect is cost shifting rather than cost savings. Even with perfect localization, depending on the relative cost of last-mile uplink bandwidth verses transport bandwidth, P2P may substantially increase aggregate cost. Yet the addition of edge caches, caches located in the ISPs near the customers, radically change the economics of P2P content delivery. Edge caches interact very strongly with localization services for P2P content delivery, and any localization service must be tightly integrated into edge-cache operation.
"Forcerenew Key Authentication", David Miles, Wojciech Dec, James Bristow, Roberta Maglione, 8-Mar-09. ( bytes): 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 Key Authentication the server exchanges a key with the client on the initial DHCP ACK that is used for subsequent validation of a Forcerenew message.
"BGP based Multi-homing in Virtual Private LAN Service", Wim Henderickx, Florin Balus, 4-Mar-09. ( bytes): Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private Network (VPN) that gives its customers the appearance that their sites are connected via a Local Area Network (LAN). It is often required for the Service Provider (SP) to give the customer redundant connectivity to some sites, often called "multi-homing". This memo shows how multi-homing can be offered in the context of LDP-based VPLS using BGP-AD.
"Reed-Solomon Forward Error Correction (FEC) Schemes for FECFRAME", Vincent Roca, Mathieu Cunche, Jerome Lacan, Amine Bouabdallah, Kazuhisa Matsuzono, 13-Jul-09. ( bytes): This document describes four fully-specified FEC schemes for Reed- Solomon codes that can be used to protect 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 sparse parity check based FEC codes. However, this complexity remains compatible with software codecs. The first scheme is for Reed-Solomon codes over GF(2^^m), with m in {2..16}, a simple FEC encoding and arbitrary packet flows. The second scheme is for Reed-Solomon codes over GF(2^^8), the interleaved FEC encoding, and arbitrary packet flows. The third (resp. fourth) scheme is similar to the first (resp. second) scheme, with the exception that it is for a single sequenced flow.
"Optimized Local Routing for PMIPv6", Desire Oulai, Suresh Krishnan, 4-Mar-09. ( bytes): Base Proxy Mobile IPv6 requires all communications to go through the local mobility anchor. As this can be suboptimal, local routing has been defined to allow mobile nodes attached to the same or different mobile access gateways to exchange traffic by using local forwarding or a direct tunnel between the gateways. This document proposes an initiation method and fast handover mechanisms for local routing. The solutions aim at reducing handover delay and packet loss.
"Potential Elements of Session Establishment Data", Alexander Mayrhofer, 4-Mar-09. ( bytes): This document provides a list of potential Session Establishment Data Elements in the Scope of SPEERMINT/DRINKS work. The list is provided to seek input from the community, and with the intent to aid in the definition of DRINKS requirements/protocols.
"SNMP optimizations for 6LoWPAN", Hamid Mukhtar, Seong-Soon Joo, Juergen Schoenwaelder, 2-Apr-09. ( bytes): This draft proposes SNMPv3 optimizations for its use in 6LoWPANs. The draft presents optimization goals, issues, and the optimization approaches to enable the use of SNMP under the given memory, processing, and message size constraints imposed by 6LoWPANs.
"ALTO Service Discovery", Haibin Song, Marco Tomsu, Gustavo Garcia, Yu-Shun Wang, Victor Pascual, 12-Jul-09. ( bytes): Application-Layer Traffic Optimization (ALTO) service aims to provide distributed applications with information to perform better-than- random initial peer selection when multiple peers in the network are available to provide a resource or service. In order to discover an Application-Layer Traffic Optimization (ALTO) Server, a set of mechanisms are required. These mechanisms enable applications to find an information source which provides them with information regarding the underlying network. This document discusses various scenarios of ALTO discovery and specifies the use of several available options such as DHCP or DNS.
"Operation of the Nominating and Recall Committees", James Galvin, 4-Mar-09. ( bytes): <1> The IETF uses two committees to manage the selection, confirmation, and recall of some or all of the individuals who serve terms of membership on the bodies that support its operation. As of the publication of this document the list of bodies includes the IESG, IAB, and the IAOC. This document is a self-consistent, organized compilation of the process as it was known at the time of publication.Discussion of this Draft <2> Please direct all comments, suggestions, and questions regarding this draft to the following mailing list: <3> ietf-nomcom@ietf.org
"Local Mobility Anchor Resolution for PMIPv6", Marco Liebsch, Paulo Loureiro, Jouni Korhonen, 4-Mar-09. ( bytes): The IETF is specifying a new Diameter Application to support mobility service authorization and home network prefix allocation for Proxy Mobile IPv6. The protocol operates between a Local Mobility Anchor and a AAA server. Furthermore, the associated specification extends the existing protocol for network access service to support dynamic assignment and discovery of a Local Mobility Anchor during the authentication procedure. The AAA server maintains mobile nodes' profile in a policy store, which includes information about the assigned Local Mobility Anchor as well as the home network prefix. This document proposes an extension to the Diameter PMIPv6 Application to allow Local Mobility Anchors benefit from the AAA server's policy store and resolve an unknown mobile node's IP address into a routable address of its assigned Local Mobility Anchor.
"MPLS-TP OAM based on Y.1731", Italo Busi, Huub Helvoort, Jia He, 14-Jul-09. ( bytes): This document specifies how 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 [6]. In particular, this document specifies 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.
"Addition of the new values to use the SEED Cipher Algorithm in the Multimedia Internet KEYing (MIKEY)", Seokung Yoon, IT Tower, Hwankuk Kim, Hyuncheol Jeong, Yoojae Won, 29-Jul-09. ( bytes): This document proposes the addition of new values to use the SEED block cipher algorithm for the Secure Real-time Transport Protocol (SRTP) and the secure Real-time Transport Control Protocol (SRTCP) in Multimedia Internet KEYing (MIKEY).
"Use cases to guide chartering MMOX interoperability work", Jon Watte, 4-Mar-09. ( bytes): Virtual worlds, typically implemented as multi-user shared simulations, are becoming increasingly used for serious work in addition to the traditional uses of research and entertainment. Based on actual need identified by interaction with various customers when working on virtual world interoperability over the last four years, this draft summarizes the main interoperability functions required to satisfy those needs. From these use cases, requirements for the MMOX virtual world interoperability charter can be derived.
"Burst Loss Metrics for IPPM", Nick Duffield, Al Morton, Joel Sommers, 9-Jul-09. ( bytes): The IPPM Working Group has developed a one way packet loss metric that measures the loss rate on a Poisson probe stream between two hosts. However, the burst properties of packet loss are required to understand the impact of packet loss on applications. This draft defines one-way burst packet loss metrics that express the frequency and duration of loss episode, i.e., maximal sets of consecutively lost probe packets. The draft also defines a probing methodology under which the burst loss metrics are to be measured.
"P4P Protocol Specification", Yu-Shun Wang, Richard Alimi, Doug Pasko, Laird Popkin, Yang Yang, 4-Mar-09. ( bytes): Provider Portal for Network Applications (P4P) is a framework that enables Internet Service Providers (ISPs) and network application software developers to work jointly and cooperatively to optimize application communications. The goals of this cooperation are to reduce network resource consumption and to accelerate applications. To achieve these goals, P4P allows ISPs to provide network information and guidance to network applications, allowing clients to exchange data more effectively. This document specifies the P4P protocol operations and message formats. The goal is provide a formal specification for developers to create inter-operable implementations.
"Mobile Node Group Identifier option", Sri Gundavelli, Kent Leung, Basavaraj Patil, Domagoj Premec, 2-Jun-09. ( bytes): This document specifies a new mobility option for use in Proxy Binding Update and Proxy Binding Acknowledgement messages. This option can be used by the mobility entities in a Proxy Mobile IPv6 domain for carrying the group affiliation of a mobile node in any of the mobility signaling messages.
"IAB Thoughts on IPv6 Network Address Translation", Dave Thaler, Lixia Zhang, 4-Mar-09. ( bytes): There has been much recent discussion on the topic of whether the IETF should develop standards for IPv6 Network Address Translators (NATs). This document articulates the architectural issues raised by IPv6 NATs, the pros and cons of having IPv6 NATs, and provides the IAB's thoughts on the current open issues and the solution space.
"Dynamic Host Configuration Protocol (DHCP) Location Shapes Option for Geopriv for IPv4 and IPv6", James Polk, Allan Thomson, Marc Linsner, 4-Mar-09. ( bytes): This document defines the Dynamic Host Configuration Protocol (DHCP) Option for downloading a location shape to a client, from a server. This is commonly called Location Configuration Information (LCI). Servers that provide this information to a client are doing so by communicating via a Location Configuration Protocol, or LCP.
"Threat Analysis for Peer-to-Peer Overlay Networks", Yinian Mao, Vidya Narayanan, Ashwin Swaminathan, 4-Mar-09. ( bytes): This document provides a threat analysis for peer-to-peer networks, where the system relies on each individual peer to route message, store data, and provide services. The threats against P2P network include those that target individual peers, those that target routing protocol, those that target identity management, and those that target stored data. Focusing on distributed hash table based P2P network, we first establish a threat model and perform a triage of various assets in a P2P system. We then describe each individual threat in details, including threat description, impact of attack, and possible mitigations. The threats and mitigations are discussed under the context of feasibility and practicality, with the ultimate goal of achieving better understanding of the threats for secure P2P system design.
"Address Selection Policy Configuration by DHCPv6 Option", Tao Sun, Hui Deng, Xiaodong Duan, 9-Mar-09. ( bytes): For hosts with multiple interfaces, the problem is how to make it run several applications simultaneously on variant interfaces such as GPRS, Wifi etc. To achieve this, one way is to select appropriate IP address so that the packets can be sent to the corresponding interface for forwarding. RFC 3484 defines a ''policy table'' for default IP address selection. This document extends the DHCPv6 option message so that the policy table can be dynamically updated.
"Route Configuration by DHCPv6 Option for Hosts with Multiple Interfaces", Tao Sun, Hui Deng, 9-Mar-09. ( bytes): For hosts with multiple interfaces, the problem is how to make it run several applications simultaneously on variant interfaces such as GPRS, Wifi etc. To achieve this, one key issue here is to select appropriate route according to RFC 1122. The approach presented in this document is extending DHCPv6 option to configure route tables of the hosts.
"PCE-based Computation Procedure To Compute Shortest Constrained P2MP Inter-domain Traffic Engineering Label Switched Paths", Quintin Zhao, David Amzallag, Daniel King, Fabien Verhaeghe, 13-Jul-09. ( bytes): 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, but their paths must first be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the 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.
"Relentless Congestion Control", Matt Mathis, 4-Mar-09. ( bytes): Relentless congestion control is a simple modification that can be applied to almost any AIMD style congestion control: instead of applying a multiplicative reduction to cwnd after a loss, cwnd is reduced by the number of lost segments. It can be modeled as a strict implementation of van Jacobson's Packet Conservation Principle. During recovery, new segments are injected into the network in exact accordance with the segments that are reported to have been delivered to the receiver by the returning ACKs. This algorithm offers a valuable new congestion control property: the TCP portion of the control loop has exactly unity gain, which should make it easier to implement simple controllers in network devices to accurately control queue sizes across a huge range of scales. Relentless Congestion Control conforms to neither the details nor the philosophy of current congestion control standards. These standards are based on the idea that the Internet can attain sufficient fairness by having relatively simple network devices send uniform congestion signals to all flows, and mandating that all protocols have equivalent responses to these congestion signals. To function appropriately in a shared environment, Relentless Congestion Control requires that the network allocates capacity through some technique such as Fair Queuing, Approximate Fair Dropping, etc. The salient features of these algorithms are that they segregate the traffic into distinct flows, and send different congestion signals to each flow. This alternative congestion control paradigm is described in a separate document, also under consideration by the ICCRG. The goal of the document is to illustrate some new protocol features and properties might be possible if we relax the "TCP-friendly" mandate. A secondary goal of Relentless TCP is to make a distinction between the bottlenecks that belong to protocol itself, vs standard congestion control and the "TCP-friendly" paradigm.
"The Use of the Secure Real-time Transport Protocol (SRTP) in Store-and-Forward Applications", Rolf Blom, Yi Cheng, Fredrik Lindholm, John Mattsson, Mats Naslund, Karl Norrman, 9-Jul-09. ( bytes): This memo describes the use of so called store-and-forward cryptographic transforms within the Secure Real-time Transport Protocol (SRTP). The motivation is to support use cases when two end-points communicate via one (or more) store-and-forward middleboxes that are not fully trusted to access the media content. One of the main aspects of the transform is to make the confidentiality and message authentication independent of the RTP header. Another central aspect is to enable identification of the cryptographic context (keys etc.). Besides the security of the end- points, also trust assumptions regarding the store-and-forward middleboxes are addressed.
"Layer2-Aware NAT", David Miles, Mark Townsley, 4-Mar-09. ( bytes): This document describes a "Layer2-Aware" IPv4-to-IPv4 (NAT44) Service Provider NAT function that identifies subscriber traffic based on IP- independent methods such as a link-layer address, VLAN, PPP session, tunnel, etc. in order to allow one to either avoid "double-NAT" (NAT444) of subscriber IP traffic altogether, the need for additional "Shared Service-Provider" IPv4 address space, or partitioning of RFC 1918 space between subscribers. While the mechanisms described in this document may be applicable to a variety of network architectures, the primary focus is on residential "fixed-line" Internet access.
"Trunk Group Use in ENUM", Daryl Malas, Tom Creighton, 4-Mar-09. ( bytes): This document concludes that incorporating trunk group parameters into an Electronic Number (ENUM) response for the Session Initiation Protocol (SIP) [RFC3261] service URI is a more effective approach compared to defining a new ENUM service type for a 'trunk'. Upon further review of the existing ENUM trunk group draft [I-D.ietf-enum-trunkgroup] and practical operator experience, this draft recommends the use of the current trunk group contexts as defined in [RFC4904] as additional parameters in the E2U+SIP enumservice NAPTR record [RFC3403] URI.
"Proxy Mobile IPv6 indication and discovery", Damjan Damic, 4-Mar-09. ( bytes): Proxy Mobile IPv6 (PMIPv6) is a network-based mobility protocol that enables mobility management for an IP host as it moves across different points of attachment within the mobility domain. An IP host whose mobility is being managed by the network is unaware of the access networks capability providing PMIPv6 mobility management on its behalf. This draft proposes mechanisms by which the host is informed of PMIPv6, as well as means to actively discover such capability in the network the host is attaching to. The ability of the host to discover or be aware of PMIPv6 support in the access network enables better decision making in terms of the network selection, attach procedure, choice of mobility management, as well as the service/session and even application configuration abilities.
"Guidelines and Protocol Extensions for Combining SIP Based Real-time Media Sessions With XMPP Based Instant Messaging and Presence Service.", Simo Veikkolainen, Markus Isomaki, 10-Jul-09. ( bytes): This memo defines guidelines and protocol extensions for combining Session Initiation Protocol (SIP) based real-time media sessions with Extensible Messaging and Presence Protocol (XMPP) based instant messaging and presence services in a seamless manner. This is accomplished by integration and protocol extension support in the endpoints, without requiring any changes in the SIP or XMPP server infrastructure. It is even possible that SIP and XMPP services are offered by different service providers.
"An Architecture of ALTO for P2P Applications", Yang Yang, Laird Popkin, Reinaldo Penno, Stanislav Shalunov, 4-Mar-09. ( bytes): ALTO enables Internet Service Providers (ISPs) and network application software distributors to work jointly and cooperatively to reduce network resource consumption and to improve application performance. In this document, we specify an architecture for integrating ALTO into peer-to-peer (P2P) applications.
"IPv6 Deployment and Statistics at a Conference", Eric Vyncke, Gunter Van de Velde, 8-Mar-09. ( bytes): During the Cisco [Cisco] European networkers Conference 2009 that ran from 26th to 29th January in Barcelona native IPv6 was added to the traditional IPv4 infrastructure. During this conference the 3500 attendees had dual stack access to both IPv4 and IPv6 simultaneously. The goal of this IPv6 deployment project was to gather usage statistics in a situation where the end-user just wants to access his/her enterprise VPN or simply get onto the Internet. The collected statistics are not only useful per se but this document presents easy ways to measure the quality of the IPv6 connectivity offered on such events. In essence the users were not conducting IPv6 technology tests, but were just using Internet services. The statistics collected give some pieces of information on the size and impact of IPv6 onto the normal userbase and will also derive the importance of IPv6 onto the infrastructiure and end-user operating systems and firewall technologies. The experiment ran in collaboration with Google [Google] and Tata-Communications [Tata].
"Referrals Across a NAT64", Dan Wing, 4-Mar-09. ( bytes): This document describes several scenarios where an IP address is referred across a NAT64 translator.
"MMOX Architecture Discussion", Christian Scholz, 4-Mar-09. ( bytes): This document tries to summarize the different problem areas in the MMOX field and proposed an approach to build interoperability from the bottom up starting with a flexible foundation. It also aims at identifying problem spaces which are more general than the virtual worlds field and also touch on problems found in today's social networks.
"Reverse HTTP", Mark Lentczner, Donovan Preston, 4-Mar-09. ( bytes): This memo explains a method for making HTTP requests to a host that cannot be contacted directly. Typically, such a host is behind a firewall and/or a network address translation system.
"Using TCP Selective Acknowledgement (SACK) Information to Determine Duplicate Acknowledgements for Loss Recovery Initiation", Ilpo Jarvinen, Markku Kojo, 5-Aug-09. ( bytes): This document describes a TCP sender algorithm to trigger loss recovery based on the information gathered on a SACK scoreboard instead of simply counting the number of arriving duplicate acknowledgements in the traditional way. The given algorithm is more robust to ACK losses, ACK reordering, missed duplicate acknowledgements due to delayed acknowledgements, and extra duplicate acknowledgements due to duplicated segments and out-of- window segments. The algorithm allows not only a timely initiation of TCP loss recovery but also reduces false fast retransmits. It has a low implementation cost on top of the SACK scoreboard defined in RFC 3517.
"Mobile DTLS", Michael Williams, Jeremey Barrett, 4-Mar-09. ( bytes): Mobile DTLS (Mobi-D) is an extension to DTLS that provides host mobility support. After obtaining a new IP address or port, a DTLS client mobile host can continue sending to its DTLS server correspondent host. The mobile host continues to use the existing set of security parameters, from the new address, without re- negotiation. The correspondent host accepts packets from the new IP address or port, also without re-negotiation. After receiving any valid DTLS packet from the mobile host's new address or port, the correspondent host uses the new address or port to send to the mobile host.
"The Diameter Capabilities Update Application", Glen Zorn, Jiao Kang, 12-Apr-09. ( bytes): This document defines a new Diameter application and associated command codes. The Capabilities Update application is intended to allow the dynamic update of Diameter peer capabilities while the peer-to-peer connection is in the open state.
"draft-hancock-sip-interconnect-guidelines-01", David Hancock, Daryl Malas, 13-Jul-09. ( bytes): As Session Initiation Protocol (SIP) peering becomes more widely accepted by service providers the need to define an interconnect guideline becomes of greater value. This document takes into consideration the SIP and commonly used SIP extensions, and it defines a fundamental set of requirements for SIP Service Providers (SSPs) to implement within their signaling functions (SFs) or Signaling Path Border Elements (SBEs) for peering.
"IP Router Alert Option Extension", Ashok Narayanan, Francois Le Faucheur, David Ward, Reshad Rahman, 4-Mar-09. ( bytes): The IP Router Alert Option is an IP option that alerts transit routers to more closely examine the contents of an IP packet. RSVP, PGM and IGMP are some of the protocols which make use of the IP Router Alert option. The current specification for the IP Router Alert Option does not define mechanisms to facilitate discriminating across different users of Router Alert. As a result, networks using router Alert may have more secuity exposure than necessary and/or may unnecessarily block some transit Router Alert packets. This document describes new rules for the IP Router-Alert Option that aid routers to process these packets more selectively.
"Multicast User Authentication", William Atwood, Salekul Islam, 4-Mar-09. ( bytes): RFC 1112 offers no facilities for participant control or accounting. This document explores the requirements for such facilities, and offers a potential solution, based on extending the IGMP and MLD "join" operations to carry EAP and/or ERP packets.
"DHCPv6 Extension for Configuring Hosts with multiple Interfaces", Behcet Sarikaya, Frank Xia, Pierrick Seite, 6-Mar-09. ( bytes): This document defines a DHCPv6 option to help configure a multi-homed host's routing table with new entries when the host attaches to a new network on a new interface.
"TLS Cached Certificates Extension", Stefan Santesson, 4-Mar-09. ( bytes): This document defines a Transport Layer Security (TLS) extension for cached certificates. This extension allows the TLS client to inform a server of a previously cached server certificate path, allowing the server to omit sending an identified certificate chain to the client during the TLS handshake protocol exchange.
"Qualifying the Harmfulness of Address Translation", Christian Vogt, 13-Jul-09. ( bytes): Address translation is widely considered harmful because it conflicts with design principles highly regarded within the Internet engineering community. Still, address translation has become common practice despite technical problems because it constitutes an easy- to-deploy solution to a set of common operational needs. Since some of these needs will continue to exist in IP version 6, there is concern within the Internet engineering community about the potential proliferation of harmful technology from IP version 4 to IP version 6. This document investigates this concern. It compares feasible address translator designs with respect to the harmful impact they may have, explains why the problems of address translation, as used today, are to a significant extent entailed by the shortage of global addresses in IP version 4, and shows how the problems can be mitigated in IP version 6.
"ALTO Protocol", Reinaldo Penno, Yang Yang, 13-Jul-09. ( bytes): Applications already have access to great amount of underlying network topology information. For example, views of the Internet routing table are easily available at looking glass servers and entirely practical to downloaded by clients. What is missing is network side information such as the network preference information -- what an ISP or Content Provider actually prefers -- and a way to distribute it. The ALTO Service provides information such as preferences of network resources with the goal of modifying network resource consumption patterns while maintaining or improving application performance. This document describes a protocol implementing the ALTO Service. While such service would primarily be provided by the network (i.e., the ISP), content providers and third parties could also operate this service. Applications that could use this service are those that have a choice in connection endpoints. Examples of such applications are peer-to-peer (P2P) and content delivery networks.
"HYDRO: A Hybrid Routing Protocol for Lossy and Low Power Networks", Arsalan Tavakoli, Stephen Dawson-Haggerty, Jonathan Hui, David Culler, 9-Mar-09. ( bytes): HYDRO is a hybrid routing protocol for Lossy and Low power Networks (L2Ns) that embraces centralized and distributed routing mechanisms. Through the use of standard ICMP Route Advertisements and Route Solicitations, Node Routers build Default Routes to Border Routers. These routes, which maintain multiple options per each Node Router when available, are maintained through data-driven link estimation. Node Routers periodically report a high-quality subset of their Default Route Table to Border Routers, which then form a global view of the topology. When a Node Router attempts to route to another Node Router in the network, if no matching entry exists in the Node Router's Flow Table, it forwards the packet to a Border Router, which then installs the correct Flow Table Entries in the network to enable more efficient subsequent routing.
"BRPC Extensions for Point-to-Multipoint Path Computation", Zafar Ali, Cisco Systems, Kenji Kumaki, 12-Jul-09. ( bytes): The ability to compute constrained Traffic Engineering Label Switched Paths (TE LSPs) for point-to-multipoint (P2MP) LSPs in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains (where 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) has been identified as a key requirement [PCEP-P2MP-REQ]. This document addresses this requirement by extending backward recursive path computation (BRPC) technique proposed for Point-to-Point (P2P) LSPs in [P2P-BRPC] for P2MP LSP path computation in a multiple domains network. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively.
"Session-Specific Explicit Diameter Request Routing", Tina Tsou (Ting ZOU), Glen Zorn, Tom Taylor, 5-Aug-09. ( bytes): This document describes a mechanism to enable specific Diameter proxies to remain in the path of all message exchanges constituting a Diameter session.
"Extensions to VPLS PE model for Provider Backbone Bridging", Ali Sajassi, Florin Balus, Raymond Zhang, 9-Mar-09. ( bytes): IEEE 802.1ah standard [IEEE802.1ah], also known as Provider Backbone Bridges (PBB) defines an architecture and bridge protocols for interconnection of multiple Provider Bridge Networks (PBNs). PBB was defined in IEEE as a connectionless technology based on multipoint VLAN tunnels. MSTP is used as the core control plane for loop avoidance and load balancing. As a result, the coverage of the solution is limited by STP scale in the core of large service provider networks. PBB on the other hand can be used to attain better scalability in terms of number of customer MAC addresses and number of service instances that can be supported. Virtual Private LAN Service (VPLS) [RFC4762] provides a solution for extending Ethernet LAN services, using MPLS tunneling capabilities, through a routed MPLS backbone without running (M)STP across the backbone. As a result, VPLS has been deployed on a large scale in service provider networks. This draft discusses extensions to the VPLS PE model required to incorporate desirable PBB components while maintaining the Service Provider fit of the initial model.
"Guidelines for the use of Variable Bit Rate Audio with Secure RTP", Colin Perkins, 13-Jul-09. ( bytes): This memo discusses potential security issues that arise when using variable bit rate audio with the secure RTP profile. Guidelines to mitigate these issues are suggested.
"Integrated Services (IntServ) Extension to Allow Multiple TSPECs", James Polk, Subha Dhesikan, 13-Jul-09. ( bytes): This document defines how Integrated Services (IntServ) includes multiple TSPECs and RSPECs in the same Resource Reservation Protocol (RSVPv1) reservation message exchange. This ability to send multiple TSPECs during reservation set-up helps optimize an agreeable bandwidth through a network between endpoints in a single round trip.
"RTP Payload Format for MPEG2-TS Preamble", Ali Begen, Eric Friedrich, 10-Jul-09. ( bytes): Demultiplexing and decoding an MPEG2 Transport Stream (MPEG2-TS) requires the knowledge of specific information about the transport stream, which we refer to as the MPEG2-TS Preamble. While this information is spread over different locations throughout the transport stream and can be eventually assembled after some time a receiver started receiving the MPEG2-TS, the time it takes to retrieve all this information (especially in multicast environments) may be long. Instead, having this information readily available as a Preamble and sending the Preamble to a receiver that will shortly start receiving the transport stream will virtually eliminate the waiting time and let the receiver start processing/decoding the MPEG2-TS sooner. In this document, we give an overview of the MPEG2-TS and the delay components in video systems, and motivate the need for constructing and using the MPEG2-TS Preamble for rapidly acquiring the source stream in RTP multicast sessions. We also define and register the RTP payload format for the MPEG2-TS Preamble.
"Best Current Practices for SIP Interoperability", Hadriel Kaplan, 11-Jul-09. ( bytes): This document identifies several commonly found interoperability issues with SIP, and provides guidance to implementers for how to avoid them. This is an initial set of commonly found problems.
"A Client to Service Query Response Protocol for ALTO", Saumitra Das, Vidya Narayanan, 4-Mar-09. ( bytes): ALTO aims to improve the peer selection in applications that have a choice to transfer data from multiple data resources. This draft presents a protocol for a flexible and extensible query response protocol between an ALTO aware client and ALTO service provider.
"Retrieving Specific Location from a Remote Entity using Session Initiation Protocol (SIP) Subscription Filters and Notifications", James Polk, 4-Mar-09. ( bytes): This document creates and describes the SIP subscription filters necessary to acquire the desired location information in the form of a Presence Information Data Format - Location Object (PIDF-LO) from a remote SIP user agent (UA).
"Multiple Interfaces on Windows", Gabriel Montenegro, Dave Thaler, Shyam Seshadri, 4-Mar-09. ( bytes): Increasingly, hosts have more than one network interface active at any given point in time. Such multiplicity of interfaces leads to multiple and potentially conflicting (or overlapping) sets of configuration information and policies. How these are arbitrated and managed influence how the host resolves DNS queries, and-with respect to outgoing packets-how it selects a source address and an outgoing interface.
"Group Management Protocol Operation Over Wireless Problem Statement", Behcet Sarikaya, Dirk von Hugo, 5-Mar-09. ( bytes): Multicast mobility using existing IETF protocols is inefficient. This document looks at the principal shorcomings in IGMP/MLD that arise from operating over three wireless links, IEEE 16e used in Mobile WiMAX, IEEE 802.11 used in Wi-Fi networks and 3GPP.
"Introduction of Distributed Services Network", Yunfei Zhang, 5-Mar-09. ( bytes): This draft briefly introduces DSN,a Distributed Service Network proposed by China Mobile in ITU-T as the evolution of NGN.PPSP is a protocol DSN plans to develop to support streaming services in future Internet.
"Virtual Presence Identity", Heiner Wolf, 5-Mar-09. ( bytes): A virtual presence client needs information to display people who meet. It needs a name, an image, maybe an animated avatar, and more. This document describes the storage and exchange of public user identity data. The virtual presence identity data format is optimized for VP applications, where many people need the public data of their peers, some only once, some repeatedly, where changes happen frequently and must be propagated quickly with minimum bandwidth.
"Atom Export Format", Geoffrey Sneddon, 23-May-09. ( bytes): This document specifies a method of using the Atom Syndication Format as an export format.
"6LoWPAN Management Information Base", Ki-Hyung Kim, Hamid Mukhtar, Seung Yoo, Soohong Daniel Park, 23-Mar-09. ( bytes): This draft defines a portion of the Management Information Base (MIB), the lowpan MIB for use with network management protocols. In particular it defines objects for managing functions related to a 6LoWPAN entity.
"Policy for defining new service-identifying labels", Andrea Forte, Henning Schulzrinne, 23-Mar-09. ( bytes): In order to provide location-based services, descriptive terms for services need to be defined. This document updates the policy for defining new service-identifying labels.
"IANA Allocation Guidelines for the IPv6 Routing Header", Jari Arkko, Scott Bradner, 23-Mar-09. ( bytes): This document specifies the IANA guidelines for allocating new values for the Routing Type field in the IPv6 Routing Header.
"SNMP ERROR STATUS MIB", Ban Shimin, Hao Liu, 24-Mar-09. ( bytes): This memo defines a portion of the Management Information Base (MIB), the SNMP Error Status MIB, for use with network management protocols. In particular, the SNMP Error Status MIB will be used to get the detailed error information of the SNMP request.
"Definition of a Uniform Resource Name (URN) Namespace for the Schema for Academia (SCHAC)", University Malaga, 3-May-09. ( bytes): This document describes a Uniform Resource Name (URN) namespace for the Schema for Academia (SCHAC). This namespace is for naming persistent resources defined by the SCHAC international activity participants, their working groups and other designated subordinates. The namespace main use will be the creation of controlled vocabulary values for attributes in the SCHAC schema. This values will be associated to particular instances of persons or objects belonging to any of the SCHAC object classes.
"Border Gateway Protocol(BGP) AS_PATH Fragmenting", Zhifeng Zhang, Jacni Qin, 24-Mar-09. ( bytes): This document discusses the issues of processing the AS_PATH attribute which provides sufficient information for constructing a graph of AS connectivity, and defines the detailed procedure of fragmenting or merging a sequence of AS PATH segments. This is necessary for the robust implementation of Border Gateway Protocol (BGP) and the interoperation of vendors.
"DHCP Authentication Analysis", John Jason Brzozowski, Ted Lemon, Geoffrey Holan, 25-Mar-09. ( bytes): This document analyzes and technically evaluate the techniques proposed to support end-user authentication using extensions to DHCP.
"Defining a centerpoint element for use in the Presence Information Data Format - Location Object (PIDF-LO)", James Polk, Allan Thomson, Marc Linsner, 25-Mar-09. ( bytes): This document creates a centerpoint element for use in the Presence Information Data Format - Location Object (PIDF-LO).
"Definition of IANA Registry for Timezone Names", Barry Leiba, 25-Mar-09. ( bytes): VCards need a stable, well defined list of timezone names, so that users can create VCards that refer to timezones. There is no common list of such names, and other standards need timezone names also. This document creates an IANA registry of timezone names, and initially populates the list.Initial version o Define timezone registry. o Defer initial population with Olsen database until we like the basic document.
"Binary Syntax for SIP Common Log Format", Adam Roach, 7-May-09. ( bytes): This document proposes a binary syntax for the SIP common log format (CLF). It does not cover semantic issues, and is meant to be evaluated in the context of the other efforts discussing SIP CLF.
"A Profile for Endpoint Identifier Origin Authorizations (IOA)", Roque Gagliano, 25-Mar-09. ( bytes): This document defines a standard profile for End-Point Identifiers Origin Authorizations (IOAs). An IOA is a digitally signed object that provides a means of verifying that the EID IP address block holder has authorized a set of Router Locators (RLOCs) as its de- encapsulation point in a Map & Encap mapping service.
"A Recommendation for IPv6 Address Text Representation", Seiichi Kawamura, Masanobu Kawashima, 11-Jun-09. ( bytes): As IPv6 network grows, there will be more engineers and also non- engineers who will have the need to use an IPv6 address in text. While the IPv6 address architecture RFC 4291 section 2.2 depicts a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and customers. This document will describe the problems that a flexible text representation has been causing. This document also recommends a canonical representation format that best avoids confusion. It is expected that the canonical format is followed by humans and systems when generating an address to represent as text, but all implementations must accept any legitimate RFC4291 format.
"An Extension to the Session Initiation Protocol (SIP) for Endpoint Session View", Chris Boulton, 26-Mar-09. ( bytes): This document defines a standard mechanism for capturing and providing important session information associated with the Session Initiation Protocol (SIP). Certain properties of a SIP protocol exchange are essential for further independent signalling interactions. In certain environments this information can be lost when traversing entities such as Back-to-Back User Agents (B2BUA). This document defines a new optional SIP header, Endpoint-View, for capturing appropriate information.
"Tunneling Header Compression (TuCP) for Tunneling over IP", Priyanka Rawat, J-M Bonnin, Ana Minaburo, Eun Paik, 26-Mar-09. ( bytes): The IP tunneling mechanisms have important applications in network solutions and are widely used in numerous contexts such as security (VPN), IPv4 to IPv6 transition, and mobility support (MobileIP and NEMO). However, these tunneling mechanisms induce a large overhead resulting from adding several protocol headers in each packet. This overhead deteriorates performance on wireless links which are scarce in resources. Header compression methods are often used on connection oriented communication (e.g., UMTS networks) to reduce the overhead on the wireless part. These header compression methods can be used on tunnel headers to reduce the protocol header overheads, independent of the payload type. Although, several header compression methods exist, the header compression profiles defined by them are not adapted to the characteristics of IP tunneling. This document specifies a tunneling header compression protocol for IP tunneling mechanisms.
"An Endpoint Control Package for the Session Initiation Protocol (SIP)", Chris Boulton, 26-Mar-09. ( bytes): This document defines a Session Initiation (SIP) Control Package for controlling endpoints. This Control Package provides a basic set of related operations and events that can occur between an endpoint and an authorised controlling entity.
"Defines Message media sub-type 'Disclaimer' to organize and handle Disclaimers in Email messages effectively", Ravishankar Nandagopalan, 28-Mar-09. ( bytes): This memo defines a new media subtype of Disclaimer to the media type 'Message'. Disclaimers are being used as a legal and commercial message that is intended to protect the interest of the sender and the recipient. At present form the disclaimers are messy to handle with multiple appends to an Email message conversation, making the Email bulky and difficult comprehend.
"The DTN URI Scheme", Kevin Fall, Scott Burleigh, Avri Doria, J�rg Ott, 31-Mar-09. ( bytes): This document describes the "dtn" Uniform Resource Identifier (URI) scheme. DTN URIs are used as DTN endpoint identifiers (EIDs).
"LLN Routing Fundamentals", Pascal Thubert, Thomas Watteyne, Zach Shelby, Dominique Barthel, 8-Apr-09. ( bytes): This document describes a basic set of fundamental mechanisms for routing on a Low-power and Lossy Network (LLN). It does not intend to specify a full-blown protocol. It is rather offered as a basis to support the discussion while designing the ROLL protocol.
"NFS Server-side Copy", James Lentini, Mike Eisler, Rahul Iyer, Deepak Kenchammana, Anshul Madan, 7-Jul-09. ( bytes): This document describes a set of NFS operations for offloading a file copy to a file server or between two file servers.
"Additive-Routes-Wanted Outbound Route Filter for BGP-4", Yuanchao Su, 29-Jun-09. ( bytes): This document describes a solution for overcoming the limitations of existing route reflect mechanism:even there are equal routes,route reflector(RR) would use the nexthop router ID to break tie and only reflect the route with lower router ID to its clients,so RR clients send all the traffic for the destination to only one nexthop which leads to traffic unbalanced in an AS. Additive-Routes-Wanted ORF extends ORF to not only filter BGP routes but also give RR client the ablility to ask RR for additive BGP routes in its BGP database. With the additive routes, RR clients could make inner-AS native IP and VPNV4 load sharing easier.
"Extensible Provisioning Protocol (EPP)", Scott Hollenbeck, 15-Jun-09. ( bytes): This document describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document is intended to obsolete RFC 4930.
"Using Trust Anchor Constraints During Certification Path Processing", Sam Ashmore, Carl Wallace, 3-Apr-09. ( bytes): This document describes how to use information associated with a trust anchor public key when validating certification paths. This information can be used to constrain the usage of a trust anchor. Typically, constraints are used to limit the certificate policies and names that can appear in certification paths validated using a trust anchor.
"Tunneling Header Compression (TuCP) for Tunneling over IP", Priyanka Rawat, J-M Bonnin, Ana Minaburo, Eun Paik, 5-Apr-09. ( bytes): The IP tunneling mechanisms have important applications in network solutions and are widely used in numerous contexts such as security (VPN), IPv4 to IPv6 transition, and mobility support (MobileIP and NEMO). However, these tunneling mechanisms induce a large overhead resulting from adding several protocol headers in each packet. This overhead deteriorates performance on wireless links which are scarce in resources. Header compression methods are often used on connection oriented communication (e.g., UMTS networks) to reduce the overhead on the wireless part. These header compression methods can be used on tunnel headers to reduce the protocol header overheads, independent of the payload type. Although, several header compression methods exist, the header compression profiles defined by them are not adapted to the characteristics of IP tunneling. This document specifies a tunneling header compression protocol for IP tunneling mechanisms.
"Addition of Camellia Elliptic Curve Cipher Suites with SHA-1 and SHA-2", Satoru Kanno, Masayuki Kanda, 5-Apr-09. ( bytes): This document specifies a set of elliptic curve cipher suites for the Transport Security Layer (TLS) protocol to support the Camellia encryption algorithm as a block cipher. This document describes sixteen new cipher suites for TLS that specify HMAC-SHA1 and HMAC- SHA2.
"The Camellia-XCBC-96 and Camellia-XCBC-PRF-128 Algorithms and Its Use with IPsec", Satoru Kanno, Masayuki Kanda, 5-Apr-09. ( bytes): This memo specifies two new algorithms. One is the usage of XCBC mode with Camellia block cipher on the authentication mechanism of the IPsec Encapsulating Security Payload and Authentication Header protocols. This algorithm is called Camellia-XCBC-96. Latter is pseudo-random function based on XCBC with Camellia block cipher for Internet Key Exchange. This algorithm is called Camellia-XCBC-PRF- 128.
"The Camellia Algorithm and Its Use wiht the Secure Real-time Transport Protocol(SRTP)", Satoru Kanno, Masayuki Kanda, 5-Apr-09. ( bytes): This document describes the use of the Camellia block cipher algorithm in 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).
"Extensible Provisioning Protocol (EPP) Host Mapping", Scott Hollenbeck, 14-May-09. ( bytes): This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. This document is intended to obsolete RFC 4932.
"Extensible Provisioning Protocol (EPP) Contact Mapping", Scott Hollenbeck, 15-Jun-09. ( bytes): This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. This document is intended to obsolete RFC 4933.
"Extensible Provisioning Protocol (EPP) Transport over TCP", Scott Hollenbeck, 23-Apr-09. ( bytes): This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. This document is intended to obsolete RFC 4934.
"IPv6-to-IPv4 translation FTP considerations", Iljitsch van Beijnum, 13-Jul-09. ( bytes): The File Transfer Protocol has a very long history, and despite the fact that today, other options exist to perform file transfers, FTP is still in common use. As such, it is important that in the situation where some client computers are IPv6-only while many servers are still IPv4-only and IPv6-to-IPv4 translators are used to bridge that gap, FTP is made to work through these translators as best it can. FTP has an active and a passive mode, both as original commands that are IPv4-specific, and as extended, IP version agnostic commands. The only FTP mode that works without changes through an IPv6-to-IPv4 translator is extended passive However, many existing FTP servers don't support this mode, and some clients don't ask for it. This document describes the optimal server, client and middlebox (if any) behavior to minimize this problem.
"Extensible Provisioning Protocol (EPP) Domain Name Mapping", Scott Hollenbeck, 14-May-09. ( bytes): This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. This document is intended to obsolete RFC 4931.
"NEtwork MObility (NEMO) Support for Proxy Mobile IPv6", Ryuji Wakikawa, Sri Gundavelli, Yuankui Zhao, 6-Apr-09. ( bytes): This document specifies an extension to Proxy Mobile IPv6 protocol for supporting network mobility. The solution leverages the extensions defined in [RFC3963], [ID-DHCPPD-NEMO] and [RFC3633] specification for achieving this.
"A Simple Way of DHCP Authentication Extension For DSL Connection", Li Hongyu, 7-Apr-09. ( bytes): This document defines option extension of Dynamic Host Configuration Protocol (DHCP) to provide a simple EAP-based authentication for DSL connection. The DHCP client is triggered by short lease time for EAP message exchanges.
"The Babel routing protocol", Juliusz Chroboczek, 30-Apr-09. ( bytes): Babel is a loop-free distance vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks.
"Validation of the root trust anchor for the DNS", Patrik Faltstrom, Jakob Schlyter, 8-Apr-09. ( bytes): This document describes practical requirements and needs for automatic validation of the root trust anchor for the DNS. It also proposes a mechanism using PGP and/or S/MIME that can be used to fulfil the requirements.
"Multicast-Based Rapid Acquisition of Multicast RTP Sessions", Ingemar Johansson, 8-Apr-09. ( bytes): This document proposes an improvement to the unicast based Rapid Acquisition for Multicast based Streaming discussed in [ID-Versteeg]. The outline of the improvement is to gather up Rapid Acquisition requests for many users and transmit them in dedicated multicast streams. With this technique the peak load on the retransmission server and on the outgoing link from the retransmission server can be reduced. For a problem description of the channel change problem in multicast based IPTV the reader is encouraged to read [ID-Versteeg].
"WiMAX Diameter Applications", Avi Lior, Alper Yegin, 8-Apr-09. ( bytes): This document registers a set of IANA Applications and Diameter Command Codes to be used in new vendor-specific Diameter applications defined for the Worldwide Interoperability for Microwave Access (WiMAX). These new Diameter applications are defined for the interaction of the Access Serving Network Gateway (ASNGW) with the AAA and the Policy and Charging Control infrastructure in the Connectivity Serving Network (CSN) and between the Home Agent (HA) and AAA servers. Applications and related commands are also defined to support Location Based Services.
"Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records for DNSSEC", Vasily Dolmatov, Artem Chuprina, Igor Ustinov, 5-Aug-09. ( bytes): This document describes how to produce GOST signature and hash algorithms DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). V.Dolmatov Expires February 05, 2010 [page 1]
"A Try and Error type approach for multihoming", Hirotaka Matsuoka, 8-Apr-09. ( bytes): [RFC5220] describes the possible problems which an end host may experience, if the end host has multiple prefixes in a single physical link. This document proposes a solution of so-called "try and error" type about these problems originated in "Source Address Selection" which is described in [RFC5220]. A new mechanism to settle almost all of these problems is described in this document, but actually it is not effective in some particular cases. Thus it is necessary for every end user/host to be able to select on/off of this mechanism.
"Control Packet Snooping Based Binding", Jun Bi, Jianping Wu, Guang Yao, Fred Baker, 29-Jul-09. ( bytes): This document specifies the Control Packet Snooping (CPS) mechanism for IP version 4 and IP version 6. This mechanism is used to set up binding between "authorized" source IP address of host and corresponding anchor on the access network device, including switch and wireless access point. The bindings are used to perform source address validation on packets sent by host.
"TLS Extension for Optimizing Application Protocols, Specifically SASL with GSS-API mechanisms", Nicolas Williams, 17-Apr-09. ( bytes): This document specifies an extension to Transport Layer Security (TLS) for carrying application data which is suitable for delayed integrity protection and does not require privacy protection. In particular we describe how to use this extension to reduce the number of round trips needed for application-layer authentication, specifically Simple Authentication (SASL), and through it, Generic Security Services (GSS-API). The use of this extension to optimize SASL/GSS-API authentication is termed "TLS/SA". This extension can also be used to optimize application protocols.
"OAuth Request Body Hash", Brian Eaton, Eran Hammer-Lahav, 11-Apr-09. ( bytes): This specification extends the OAuth signature to include integrity checks on HTTP request bodies with content types other than "application/x-www-form-urlencoded".
"The UDP Tunnel Transport mode", Gorry Fairhurst, 21-Jun-09. ( bytes): This document proposes a standards track protocol called the UDP Tunnel Transport. This protocol updates the UDP processing of RFC 2460 for hosts and routers. The update enables a sender to generate a UDP datagram where the UDP checksum is replaced by a header check determined only by the protocol header information. For this use, the document also updates the way the IPv6 UDP length field is interpreted. This mode is intended to minimise the processing cost for the transport of tunnel packets using UDP.
"A Hybrid ISP Platform (or Architecture) for IPv6: Problem Statement", Jiangfeng Xu, Sheng Jiang, 14-Apr-09. ( bytes): Global IPv6 deployment is inevitable. There are many solutions have been specified in order to provide IPv6 connectivity services. In order to provide IPv6 connectivity services to all kinds of host/client devices, ISP networks need to support as many as possible IPv6 connectivity solutions. This document proposes a hybrid ISP platform that supports the coexistence of variable IPv6 connectivity solutions and analyses the configuration requirements raised by this platform. Additionally, the applicability of different configuration mechanisms for performing this configuration is discussed.
"Discussion of Controversial PMIP Extensions", George Tsirtsis, 16-Apr-09. ( bytes): This document discusses the recent controversy regarding PMIP extensions for inter-technology handoffs and multihoming. Many of the arguments presented below have been discussed in NETEXT BOF and subsequent discussions on the mailing list. They are written here in an attempt to explain why some of the proposed PMIP extensions are so controversial.
"TCP Opportunistic Security (OPSEC) Option", Michael Paddon, Greg Rose, 27-Apr-09. ( bytes): The TCP Opportunistic Security (OPSEC) option enables cooperating peers to opportunistically negotiate the use of an end to end security protocol on a per connection basis. The negotiated protocol is used to transparently secure application data for the life of the connection, providing protection against all passive and some active attacks. Security protocols may operate anonymously or make opportunistic use of available key material. Backwards compatibility with non-OPSEC-aware hosts is maintained, thereby permitting incremental deployment of this mechanism.Comments and Discussion Please send feedback on this draft to tsv-area@ietf.org.
"A SIP/SIPS URI parameter for passing subscription data", Keith Drage, 19-Apr-09. ( bytes): This document provides a SIP/SIPS URI parameter to enable subscription data related to a SIP/SIPS URI to accompany that SIP/ SIPS URI when required by other entities in the same system. This can then be used by the receiving entity to assist in the provision of capabilities associated with that SIP/SIPS URI, either in this request or in other subsequent requests.
"Multiplexing Single-Application Multiple-Connection over TLS", Mohamad Badra, Ibrahim Hajjeh, James Blaisdell, 20-Apr-09. ( bytes): The Transport Layer Security (TLS) is the most widely deployed protocol for securing network traffic. It provides mutual authentication, data confidentiality and integrity, key generation and distribution, and security parameters negotiation. However, missing from the protocol is a way to multiplex single-application multiple-stream applications that commonly use parallel connections to the same logical and/or physical server application data. This document describes a mechanism to multiplex single-application multiple-stream over TLS. It extends TLS to multiplex parallel connections of a given application over a single TLS session, avoiding additional delay related to the TLS/TCP session/connection setup.
"IPv4 and IPv6 Greynets", Fred Baker, Warren Harrop, Grenville Armitage, 27-Jul-09. ( bytes): This note discusses a feature to support building Greynets for IPv4 and IPv6.
"Internet X.509 Public Key Infrastructure: Certificate Image", Stefan Santesson, Russ Housley, Siddharth Bajaj, Leonard Rosenthol, 21-Apr-09. ( bytes): This document specifies a method to bind a visual representation of a certificate in the form of a certificate image to a [RFC5280] public key certificate by defining a new otherLogos image type according to [RFC3709].
"IPv6 Firewall Routing Header", Tony Hain, 22-Apr-09. ( bytes): This document specifies a routing header for use by firewalls to enforce routing symmetry. The draft is being discussed on the ipv6@ietf.org list. Legal This documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
"Home Agent Initiated Flow Binding for Mobile IPv6", Frank Xia, Behcet Sarikaya, 22-Apr-09. ( bytes): This document defines two new Mobility Headers for a home agent to control flow binding in a mobile node.
"IPv4/IPv6 Translation Prefix Recommendation", Congxiao Bao, Fred Baker, Xing Li, 22-Apr-09. ( bytes): This document is part of a series of the IPv4/IPv6 translation documents. In this document, the address format and the corresponding prefix are recommended for representing IPv4 addresses in IPv6 and/or for representing IPv6 addresses in IPv4.
"mLDP based in-band signaling for Point-to-Multipoint and Multipoint-to- Multipoint Label Switched Paths", IJsbrand Wijnands, Toerless Eckert, Nicolai Leymann, Maria Napierala, 11-Jul-09. ( bytes): When an IP multicast tree needs to pass through an MPLS domain, it is advantageous to map the tree to a Point-to-Multipoint or Multipoint- to-Multipoint Label Switched Path. This document specifies a way to provide a one-one mapping between IP multicast trees and Label Switched Paths using mLDP signaling. The IP multicast control messages are translated into MPLS control messages when they enter the MPLS domain, and are translated back into IP multicast control messages at the far end of the MPLS domain. The IP multicast control information is coded into the MPLS control information in such a way as to ensure that a single Multipoint Label Switched Path gets set up for each IP multicast tree.
"NewReno Modification for Smooth Recovery After Fast Retransmission", Yoshifumi Nishida, 23-Apr-09. ( bytes): This memo describes a feeble point in Fast Recovery algorithm in NewReno defined in RFC3782 and proposes a simple modification to solve the problem.
"LIP: Label Information Protocol", Richard Kelsey, 23-Apr-09. ( bytes): LIP is an extension of MPLS for use in Lossy and Low power Networks (LLN). Use of MPLS allows rapid response to local topology changes within an LLN, while still using full IP routing both within the LLN and for packets that cross into other domains. LIP has optional RIP commands for discovering and maintaining label switched tree routes. To support local route repair, labeled packets include a path metric used to detect loops in label-switched paths. Labeled messages may optionally include a source route or route record at the label level in order to allow their use without losing the advantages of label switching.
"An Update to the Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", James Polk, Allan Thomson, Marc Linsner, 23-Apr-09. ( bytes): This document updates RFC 3825 (Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information) to allow versioning, and proposes changes that enable the ability to express confidence and uncertainty values as an alternative to expressing bits of resolution.
"NomCom Chair's Report: 2008-9", Joel Halpern, 24-Apr-09. ( bytes): This document reports on the work of the 2008-2009 IETF nominating committee (NomCom). This draft summarizes the process steps that were used this year, and the work that was done. This is followed by a discussion of process issues which caused difficulties for the committee, but which require community agreement to before changes can be made. Finally, there are some observations about things which can help future committees, and which may help the community to understand.
"Security Issues and Solutions in Peer-to-peer Systems for Realtime Communications", Henning Schulzrinne, Enrico Marocco, Emil Ivov, 7-Jul-09. ( bytes): Peer-to-peer (P2P) networks offer higher robustness against failure, easier configuration and are generally more economical than their client-server counterparts. It has therefore become reasonable for resource consuming and typically centralized applications like Voice over IP (VoIP) and, in general, realtime communication to adapt and exploit the benefits of P2P. Such a migration needs to address a new set of P2P specific security problems. This document describes some of the known issues found in common P2P networks, analyzing the relevance of such issues and the applicability of existing solutions when using P2P architectures for realtime communication.
"Definition of Managed Objects for Reporting Performance Counters' Statistics", Robert Cole, Joseph Macker, Al Morton, 28-Apr-09. ( bytes): 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 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.
"Redundancy and Load Balance Mechanism of NAT64", Xiaohu Xu, 29-Apr-09. ( bytes): NAT64 [NAT64], a simplified NAT-PT [RFC2766] without DNS-ALG, provides a method for IPv6 hosts to initiate communications with IPv4 hosts. This memo defines several mechanisms supporting redundancy and load balance amongst NAT64 boxes.
"Stateless IPv4-IPv6 Interconnection in the Context of DS-lite Deployment", Mohammed Boucadair, Christian Jacquenet, Jean-Luc Grimault, Mohamed Kassi-Lahlou, Pierre Levis, Dean Cheng, 18-May-09. ( bytes): This memo describes a proposal to enhance DS-lite solution with an additional feature to ease interconnection between IPv4 and IPv6 realms. When deployed, no dual-stack-enabled network is required for the delivery of both IPv4 and IPv6 connectivity to customers. Only IPv6 is required to be deployed in core and access networks. Particularly, IPv6 transfer capabilities are used for the transfer of IPv4-addressed packets in a completely stateless scheme between the interconnection segment and the DS-lite CGN node(s).
"Mobile IPv6 Home Link Detection Mechanism Security considerations", Arnaud Ebalard, 30-Apr-09. ( bytes): MIPv6 defines the concept of Home Network for a MN, in opposition to the foreign network where this entity may find itself. A ``Home Link Detection'' mechanism is also specified to allow the MN to detect when it is at home. MIPv6 specification mandates the use of IPsec for protecting main signaling traffic and also defines how IPsec can be used to protect data traffic between the MN and its HA. Even if optional, it is expected that many deployments of MIPv6 will use it by default for MN which may roam outside a trusted infrastructure (e.g. outside a mobile operator network). When a MN detects it is at home, it is expected to stop IPsec protection for data traffic exchanged with its Home Agent. That event is the result of the Home Return procedure, triggered by the Home Link Detection mechanism. This document discusses the possible threats and security impacts associated with the use of this insecure NDP-based mechanism as a trigger to drop IPsec protection of data traffic for the MN. It also provides some results on the implementation of the attacks against an existing MIPv6 module. Possible solutions are suggested.
"Definition of Binary Filter Description", George Tsirtsis, Gerardo Giaretta, Hesham Soliman, Nicolas Montavont, 1-May-09. ( bytes): This document defines binary formats for IPv4 and IPv6 flow descriptors to be used in conjuction with flow bindings for Mobile IPv6.
"HTTP Live Streaming", Roger Pantos, 8-Jun-09. ( bytes): This document describes a protocol for transmitting unbounded streams of multimedia data over HTTP. 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 1.0 of this protocol.
"LISP Internet Groper (LIG)", Dino Farinacci, Dave Meyer, 7-May-09. ( bytes): 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.
"Third Party Authorization in the Session Initiation Protocol", Scott Lawrence, 3-May-09. ( bytes): This draft describes some circumstances that are common in SIP deployments which lack a rigorous authorization model, and points out some ways in which this has resulted in poor security characteristics. The purpose of this document is to stimulate discussion of the identified problem and proposed requirements for any solution. Comments are solicited, and should be directed to the DISPATCH working group list at 'dispatch@ietf.org'.
""Son of 1036": News Article Format and Transmission", Henry Spencer, 28-Jul-09. ( bytes): By the early 1990s it had become clear that RFC 1036, the then specification for the Interchange of USENET Messages, was badly in need of repair. This "INTERNET DRAFT to be", though never formally published at that time, was widely circulated and became the de facto standard for implementors of News Servers and User Agents, rapidly acquiring the nickname "Son of 1036". Indeed, under that name, it could fairly be described as the best-known Internet Draft (n)ever published, and it formed the starting point for the recently adopted Proposed Standards for Netnews. It is being published now in order to provide the Historical Background out of which those standards have grown. Present-day implementors should be aware that it is NOT NOW APPROPRIATE for use in current implementations.
"Source FEC Payload Mapping Information for Sequence Flow", Zixuan Zou, 3-May-09. ( bytes): Per FEC framework, FEC source packet carries source FEC payload ID for FEC protection of arbitrary packet flow. This document specifies a FEC payload header and a source FEC payload mapping information unit (MIU) to enable carrying source FEC payload ID(s) in separate packet flow for FEC protection of sequence flow over unreliable transport. The FEC payload MIU consists of flexible source FEC payload ID(s) to be compatible with different FEC schemes.
"The Network Trouble Ticket Data Model", Dimitris Zisiadis, Spyros Kopsidas, Matina Tsavli, Leandros Tassiulas, Chrysostomos Tziouvaras, Guillaume Cessieux, Xavier Jeannin, 30-Apr-09. ( bytes): Handling multiple sets of network trouble tickets (TTs) originating from different participants inter-connected network environments poses a series of challenges for the involved institutions, Grid is a good example of such multi-domain project. Each of the participants follows different procedures for handling trouble in its domain, according to the local technical and linguistic profile. The TT systems of the participants collect, represent and disseminate TT information in different formats. As a result, management of the daily workload by a central Network Operations Centre (NOC) is a challenge on its own. Normalization of TTs to a common format for presentation and storing at the central NOC is mandatory. In the present document we provide a model for automating the collection and normalization of the TT received by multiple networks forming the Grid. Each of the participants is using its home TT system within its domain for handling trouble incidents, whereas the central NOC is gathering the tickets in the normalized format for repository and handling. XML is used as the common representation language. The model was defined and used as part of the networking support activity of the EGEE project (Enabling Grids for E-sciencE).
"BGP-4 message transport over SCTP", Kevin Fang, Feng Cai, 4-May-09. ( bytes): This memo defines using SCTP for BGP-4 transport routing message. SCTP has many benefit for Signaling/Message transportation , BGP-4 transport over SCTP will enhance the link stability and efficiency.
"Hierarchy Extensions to Atom Feeds", Colm Divilly, Nikunj Mehta, 5-May-09. ( bytes): This specification defines a mechanism to create and remove AtomPub collections using the AtomPub protocol as well as to express hierarchies of feeds within the Atom Syndication Format.Editorial Note To provide feedback on this Internet-Draft, join the atom-protocol mailing list (http://www.imc.org/atom-protocol/) [1].
"Experiment: Hash functions with parameters in CMS and S/MIME", Jim Schaad, 5-May-09. ( bytes): New hash algorithms are being developed and these algorithms may include parameters. CMS has not currently defined any hash algorithms with parameters, but anecdotic evidence suggests that defining one could cause major problems. In this document we define just such an algorithm and describe how to use it so that we can run experiments to find out how bad including hash parameters will be.
"Signer Info Algorithm Protection Attribute", Jim Schaad, 5-May-09. ( bytes): A new signed attribute is defined that allows for protection of the algorithm structures in an authenticated data or a signer info structure. By placing the information into a signed or authenticated attribute its value is then covered by the validation process.
"Extensions to Proxy Mobile IPv6 - Motivation", Sri Gundavelli, 5-May-09. ( bytes): Proxy Mobile IPv6 is a network-based mobility management protocol standardized in IETF and is being specified in various system architectures as a protocol for building a common and access independent mobile core. Currently, there are number of proposals and a huge amount of interest in NETEXT working group for extending the protocol to support various mobility extensions. This document identifies some of the critical extensions that are absolutely required and builds a case as why these extensions have to be supported.
"TCP-over-UDP", Salman Baset, Henning Schulzrinne, 7-Jun-09. ( bytes): We present TCP-over-UDP (ToU), an instance of TCP on top of UDP. It provides exactly the same congestion control, flow control, reliability, and extension mechanisms as offered by TCP. It is intended for use in scenarios where applications running on two hosts may not be able to establish a direct TCP connection but are able to exchange UDP packets.
"Additional S/MIME Capabilities", Sean Turner, 26-May-09. ( bytes): This document lists values for the S/MIME Capabilities Attribute. The attribute itself is defined in RFC TBD1, but the values for each are defined in separate algorithm documents and in some cases not at all. The SMIME Capability values can be included in S/MIME messages as a signed attribute and in public key certificates as an extension. //RFC EDITOR: Replace TBD1 with the # assigned to draft-ietf-smime- 3851bis-10.txt.
"One-ended multipath TCP", Iljitsch van Beijnum, 6-May-09. ( bytes): Normal TCP/IP operation is for the routing system to select a best path that remains stable for some time, and for TCP to adjust to the properties of this path to optimize throughput. A multipath TCP would be able to either use capacity on multiple paths, or dynamically find the best performing path, and therefore reach higher throughput. By adapting to the properties of several paths through the usual congestion control algorithms, a multipath TCP shifts its traffic to less congested paths, leaving more capacity available for traffic that can't move to another path on more congested paths. And when a path fails, this can be detected and worked around by TCP much more quickly than by waiting for the routing system to repair the failure. This memo specifies a multipath TCP that is implemented on the sending host only, without requiring modifications on the receiving host.
"TCP Extensions for Multipath Operation with Multiple Addresses", Alan Ford, Costin Raiciu, Mark Handley, Sebastien Barre, 13-Jul-09. ( bytes): Often endpoints are connected by multiple paths, but the nature of TCP/IP restricts communications to a single path per socket. Resource usage within the network would be more efficient were these multiple paths able to be used concurrently. This should enhance user experience through higher throughput and improved resilience to network failure. This document presents extensions to TCP in order to transparently provide this multi-path functionality at the transport layer, if at least one endpoint is multi-addressed.
"The Media Types application/mods+xml, application/mads+xml, application/mets+xml, application/marcxml+xml, application/sru+xml", Ray Denenberg, 7-May-09. ( bytes): This document specifies Media Types for the following formats: MODS (Metadata Object Description Schema), MADS (Metadata Authority Description Schema), METS (Metadata Encoding and Transmission Standard), MARCXML (MARC21 XML Schema), and the SRU (Search/Retrieve via URL Response Format) Protocol response XML schema. These are all XML schemas providing representations of various forms of information including metadata and search results.
"Multiplexing of Connections between Extensible Messaging and Presence Protocol (XMPP) Servers Using Transport Layer Security (TLS)", Joe Hildebrand, Peter Saint-Andre, 8-May-09. ( bytes): This document specifies requirements for multiplexing of connections between Extensible Messaging and Presence Protocol (XMPP) servers using Transport Layer Security (TLS).
"An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", Sheng Jiang, Dayong Guo, Brian Carpenter, 6-Jul-09. ( bytes): Global IPv6 deployment was slower than originally expected in the last ten years. As IPv4 address exhaustion gets closer, the IPv4/IPv6 transition issues become more critical and complicated. Host-based transition mechanisms are not able to meet the requirements while most end users are not sufficiently expert to configure or maintain these transition mechanisms. Carrier Grade NAT with integrated transition mechanisms can simplify the operation of end users during the IPv4/IPv6 migration or coexistence period. This document proposes an incremental Carrier-Grade NAT (CGN) approach for IPv6 transition. It can provide IPv6 access services for IPv6-enabled end hosts and IPv4 access services for IPv4 end hosts while remaining most of legacy IPv4 ISP networks unchanged. It is suitable for the initial stage of IPv4/IPv6 migration. Unlike CGN alone, it also supports and encourages transition towards dual-stack or IPv6-only ISP networks.
"A Generic Referral Object for Internet Entities", Brian Carpenter, Mohammed Boucadair, Scott Brim, Joel Halpern, Sheng Jiang, Keith Moore, 10-May-09. ( bytes): The purpose of a referral is to enable a given entity in a multiparty application to pass information to another party. This memo specifies a Generic Referral Object (GRO) to be used in the context of referrals. The proposed object is compact and is application- independent. Both IPv4 and IPv6 schemes are supported, as well as upper layer identifiers. Additional information to characterise an enclosed reference is also described. To allow proper interpretation of referrals, a new notion of scope identifiers is introduced.
"Configuring Cryptographically Generated Addresses (CGA) using DHCPv6", Sheng Jiang, Zhongqi Xia, 10-May-09. ( bytes): A Cryptographically Generated Address (CGA) 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 CGA generation. Administrators should be able to configure parameters used to generate CGA. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6), which enables network management to dynamically configure hosts, can be used in the CGA configuration. Furthermore, CGA generation consumes large computation power. This computational burden can be delegated to the DHCPv6 server. A new DHCPv6 options are also defined in this document to enable hosts delegate CGA generation to a DHCPv6 server.
"Classification of traffic using Application Tags", Jagannathan Pathra B, Prabhuraj K, 11-May-09. ( bytes): This document describes a solution to classify Application-Layer traffic on switches using Application Tags. The Application Tags can be passed on to other switches in the Enterprise Network and also to switches in the Service Provider Network. Thus it provides a mechanism to classify and apply Quality of Service based on the Application-Layer Traffic. The advantage of this solution is that it requires no hardware upgrade on switch nor any Deep Packet Inspection (DPI) function on the switch. 1. Conventions
"A Dedicated RPSL Interface Identifier for Operational Testing", Brian Haberman, 22-May-09. ( bytes): The deployment of new IP connectivity typically results in intermittent reachability for numerous reasons which are outside the scope of this document. In order to aid in the debugging of these persistent problems, this document proposes the creation of a new Routing Policy Specification Language object that allows a network to advertise an IP address which is reachable and can be used as a target for diagnostic tests (e.g., pings).
"An Adaptation Model for Mobile IPv6 support in lowPANs", Ricardo Silva, University Coimbra, 11-May-09. ( bytes): Real deployments of wireless sensor networks (WSN) are rare, and virtually all have considerable limitations when node mobility is concerned. On one hand, research in WSNs tends to favour complex multi-hop routing protocols and, on the other hand, IP and mobility are considered too demanding for these environments. In this document we contradict this general belief by proposing an adaptation model for Mobile IPv6 in 6lowPANs.
"The Eternal Non-Existence of SINK.ARPA (and other stories)", Joe Abley, Olafur Gudmundsson, 11-May-09. ( bytes): This document specifies a fully-qualified domain name in the Domain Name System (DNS) that can be relied upon never to exist. The availability of a name in the DNS which is guaranteed not to exist has useful operational applications. This document also provides a procedural framework for other names that have special characteristics to be reserved, and for those special characteristics to codified as modifications to the normal ARPA administration process.
"draft-valin-celt-rtp-profile-02 RTP Payload Format for the CELT Codec", Jean-Marc Valin, Gregory Maxwell, 13-Jul-09. ( bytes): CELT is an open-source voice codec suitable for use in very low delay audio communication applications, including Voice over IP (VoIP). This document describes the payload format for CELT generated bit streams within an RTP packet. Also included here are the necessary details for the use of CELT with the Session Description Protocol (SDP). At the time of this writing, the CELT bit-stream has NOT been finalized yet, and compatibility is usually broken with every new release of the codec.
"Publish-subscribe over the generic Peer-to-Peer Protocols", Paulina Adamska, Adam Wierzbicki, Tomasz Kaszuba, 18-May-09. ( bytes): This document introduces a generic publish-subscribe protocol, that can be built on top of RELOAD or P2PP. It works both for the unstructured and DHT-based Peer-to-Peer networks. Moreover it is highly customizable to address the optimization issues and support different topology structures. It can be used to implement P2P-SIP services such as presence or event notification. (This Internet-Draft is also available in PDF format [ bytes].)
"Proxy Mobile IPv6 Basic Multicast Support Solution", Behcet Sarikaya, Thomas Schmidt, Suresh Krishnan, 13-May-09. ( bytes): This document describes how multicast routing can be supported in Proxy Mobile IPv6 in a way similar to Mobile IPv6. Mobile Access Gateway tunnels MLD messages from the mobile nodes to local mobility anchor. Local mobility anchor joins the multicast group and starts forwarding the received multicast packets to the mobile access gateway. In case of handover the tunnel end point changes but the operation remains anchored at the local mobility anchor.
"RANGER Scenarios", Steven Russert, Eric Fleischman, Fred Templin, 13-May-09. ( bytes): Routing and Addressing in Next-Generation EnteRprises (RANGER) [I-D.templin-RANGER] provides an architectural framework for scalable routing and addressing. It provides for scalability, provider independence, mobility, multihoming and security for the next generation Internet. This document describes a series of use cases in order to showcase RANGER capabilities. It further shows how the RANGER architecture restores the network-within-network principles originally intended for the sustained growth of the Internet.
"A P2PSIP Client Routing for Reload", Lin Xiao, Yunfei Zhang, 13-May-09. ( bytes): This document analyses the routing requirements of different types of clients, and then proposes a P2P client routing mechanism for REsource LOcation And Discovery (RELOAD). This mechanism is designed to solve the issues in one of the client routing options described in the RELOAD Base protocol [I-D.ietf-p2psip-base], where clients are allowed to connect with arbitrary peers. The solution is to store the information of a client's Attached Peer in the overlay together with the registration data of the client. The extension could be deployed on SIP usage of RELOAD easily [I-D.draft-ietf-p2psip-sip].
"Open Grid Protocol: Introduction and Requirements", Meadhbh Hamrick, 14-May-09. ( bytes): The Open Grid Protocol (OGP) defines interactions between hosts which collaborate to create an shared, internet scale virtual world experience. This document introduces the protocol, the objectives it attempts to achieve and requirements it imposes on systems and users utilizing the protocol. This document also describes the model assumed by the protocol (to the extent it affects protocol interactions.)
"A Description of the ARIA Encryption Algorithm", Jungkeun Lee, Jooyoung Lee, Jaeheon Kim, Daesung Kwon, Choonsoo Kim, 28-Jul-09. ( bytes): This document describes the ARIA encryption algorithm. ARIA is a 128- bit block cipher with 128-, 192-, and 256-bit keys. The algorithm consists of key scheduling part and data randomizing part.
"The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS & GMPLS", Daniel King, Adrian Farrel, 13-Jul-09. ( bytes): Computing optimum routes for Label Switched Paths (LSPs) across multiple domains in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (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. This document examines techniques to establish the optimum path when the sequence of domains is not known in advance. The document provides mechanisms that allow the optimum sequence of domains to be selected and the optimum end-to-end path to be derived.
"Dynamic Host Configuration Protocol (DHCPv6) Options for Shared IP Addresses Solutions", Mohammed Boucadair, Pierre Levis, Jean-Luc Grimault, Teemu Savolainen, Gabor Bajko, 18-May-09. ( bytes): This memo defines Dynamic Host Configuration Protocol version 6 (DHCPv6) Options to be used in the context of shared IP address solutions. In some deployment scenarios, DHCP (IPv4) cannot be used to configure customer devices because only IPv6 capabilities are deployed (e.g. DS-lite context or IPv6 Port Range). Therefore, DHCPv6 may be used to convey IPv4-related configuration information such as Port Range and/or Port Extended IPv4 addresses. This document defines also a DHCPv6 Option aiming to convey the IPv6 prefix to be used to build IPv4-inferred IPv6 addresses required in the context of stateless IPv4-in-IPv6 encapsulation.
"Diameter Base Protocol MIB", Glen Zorn, Subash Comerica, 18-May-09. ( bytes): Along with providing support for certain basic authentication, authorization and accounting functions, the Diameter protocol is designed to provide a framework for AAA applications. This document defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage an implementation of the Diameter protocol.
"Diameter Credit Control Application MIB", Glen Zorn, Subash Comerica, 18-May-09. ( bytes): Along with providing support for certain basic authentication, authorization and accounting functions, the Diameter base protocol is intended to provide a framework for AAA applications. This document defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage an implementation of the Diameter Credit Control application.
"Diameter Attribute-Value Pairs for Cryptographic Key Transport", Wenson Wu, Glen Zorn, 7-Jul-09. ( bytes): Some 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.
"Hierarchy Relations for Atom", Colm Divilly, Nikunj Mehta, 1-Jul-09. ( bytes): This specification defines link relations for hierarchical navigation among Atom feeds and entries.Editorial Note To provide feedback on this Internet-Draft, join the atom-syntax mailing list (http://www.imc.org/atom-syntax/) [1].
"AtomPub Guidelines for Collection Discovery", Colm Divilly, Nikunj Mehta, 20-May-09. ( bytes): This document recommends best practices for discovering AtomPub Collection resources as applicable to various content representation formats.Editorial Note To provide feedback on this Internet-Draft, join the atom-protocol mailing list (http://www.imc.org/atom-protocol/).
"Problem Statement of IPv4 Support for PMIPv6 Localized Routing", Wenson Wu, Jouni Korhonen, Yungui Wang, 22-Jun-09. ( bytes): [ID-PMIP6-RO-PS] describes the problem space of localized routing which allows end-to-end user traffic forwarding between MN and CN directly without involving Local Mobility Anchor (LMA) in a single Proxy Mobile IPv6 [RFC5213] domain. However, localized routing with IPv4 support which allows IPv4 transport between MAG and LMA and/or IPv4 enabled user traffic between MN and CN is not considered. This document details the scenarios and problem statement for localized routing with IPv4 support.
"XML Configuration format for DHCPv6 Servers", A. Gregory Rabil, 21-May-09. ( bytes): This memo describes an Extensible Markup Language (XML) schema for specifying configuration information for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Servers.
"A Childless Initiation of the IKE SA", Yoav Nir, Hannes Tschofenig, Hui Deng, 17-Jun-09. ( bytes): This document describes an extension to the IKEv2 protocol that allows an IKE SA to be created and authenticated without generating a child SA.
"IPv6-to-IPv4 translation fragmentation issue", Iljitsch van Beijnum, 21-May-09. ( bytes): This draft outlines a way to handle IPv4 MTUs smaller than 1280 bytes and a way to handle the identification field in fragmentation that are different from the ones specified in [RFC2460] for the purposes of discussion in the BEHAVE working group.
"A Trust Framework for Low Power and Lossy Networks", Theodore Zahariadis, Helen Leligou, Panagiotis Karkazis, Panagiotis Trakadas, Sotiris Maniatis, 21-May-09. ( bytes): This document presents a trust framework, which may improve the security and reliability of routing over Low Power and Lossy Networks (LLN), against an increased set of attacks. The development of the framework builds upon previous work on trust and secure routing, adapting the trust assessments to the issues and constraints specific to LLNs. The proposed trust management scheme is based on direct and indirect interactions with neighboring nodes, to compute their trust value and thus select the most trusted path or forwarding node. To reduce the overhead of nodes' communication during the indirect trust value retrieval procedure, indirect trust information is requested from a limited number of neighbors, which respond only when they have highly reliable trust information
"Dispatching Sound Level Indicators in Conferences (Problem Statement)", Emil Ivov, Enrico Marocco, 21-May-09. ( bytes): The Conferencing Framework described in RFC 4353 defines the semantics necessary for conducting conference calls with the session initiation protocol. It also introduces a mixer entity responsible for combining all media streams and delivering them to the participants of the call. This document presents the lack of a standardized way for such mixers to deliver information about the audio activity (sound level) of participants in a conference call. The document describes the problem and discusses a few possible ways of transporting such information.
"Use of SRV records for locating email services", Cyrus Daboo, 7-Jul-09. ( bytes): This specification describes how SRV records can be used to locate email services.
"Use of SRV records for locating CalDAV calendar services", Cyrus Daboo, 21-May-09. ( bytes): This specification describes how SRV records can be used to locate a CalDAV based calendar service.
"Intentional Naming in DTN", Prithwish Basu, Dan Brown, Stephen Polit, Rajesh Krishnan, 22-May-09. ( bytes): This document describes an extension to the naming mechanism of disruption tolerant networks (RFC4838) to support intentional naming. Intentional naming is a means by which a source node specifies the destination node(s) for a bundle in terms of predicates on attributes of the node(s), instead of by a canonical endpoint identifier (EID) of the node. Intentional naming is closely tied to the concept of binding, as described in RFC 4838. Since information required to route an intentionally named bundle may not be available at the source node, this information must be supplied at one or more subsequent nodes along the bundle's path toward its destination(s). The architecture required for an intentional naming capability in a DTN must support the notion that a bundle can make progress toward its destination(s) in the absence of complete binding information. In this document we describe a framework for intentional naming in a DTN, propose a syntax for intentional names, and describe a distributed procedure for late or partial binding. We also present sample use cases for late binding and a notional name binding algorithm, called GRAIN, that can deliver bundles to intentional names with geographic and role attributes, e.g. "first responders within a kilometer of a specified location." Finally, we discuss the limitations in our current ability to field an ideal intentional naming system (i.e., one that can support generic intentional names), and we suggest a somewhat restrictive framework that is both useful and feasible to deploy.
"VA-Based IPv6 Transition", Yong Cui, Shengling Wang, Mingwei Xu, Jianping Wu, Xing Li, 22-May-09. ( bytes): With the increasing deployment of IPv6 networks, IPv6 transition has become one of the key problems in developing IPv6 networks. Among various transition scenarios, one is common where connectivity between IPv4 networks is desired across IPv6-only backbone network. In such case, ISP operating the IPv6 backbone will accommodate connectivity and offer transit services for attached IPv4 networks. Softwire WG defined softwire mesh mechanism for both of the IPv4- over-IPv6 scenario and the opposite scenario of IPv6-over-IPv4. Softwire mesh uses automatic softwire tunnels employing multi- protocol BGP extensions for distributing IPv4 routes, where BGP and tunnuls should be configured or setup as a full-mesh architecture. This draft, however, proposed an aggregated, centralized mechanism similar to Virtual Aggregation (VA) mechanism, which can significantly shrink the forwarding information base (FIB) size of Address Family Border Routers (AFBRs), reduce the total amount of routing activity, and provide the IPv6 ISP with an easy way to manage the transit service.
"WSON Signal Characteristics and Network Element Compatibility Constraints for GMPLS", Greg Bernstein, Downers Grove, 22-May-09. ( bytes): While the current GMPLS WSON formalism can deal with many types of wavelength switching systems there is a desire to extend this control plane to include other common optical or hybrid electro optical systems such as OEO switches, regenerators, and wavelength converters. This document provides a WSON signal definition and characterization based on ITU-T interface and signal class standards and describes the signal compatibility constraints of this extended set of network elements. The signal characterization and network element compatibility constraints enable GMPLS routing and signaling to control these devices and PCE to compute optical light-paths subject to signal compatibility attributes.
"B2BUA with Survivability Feature", Klimov Andrey, 25-May-09. ( bytes): This draft describes the behavior of Session Initiation Protocol (SIP) [RFC3261] Back-To-Back User-Agent (B2BUA) with survivability feature, we can define it as a survivable SIP proxy (SSP), and how it should process calls in two different modes one is normal (no- failure) mode and the other is survivable (breakdown) mode.
"SMTP Recipient Address Verification Using the Dynamic Delegation Discovery Service (DDDS)", S. Moonesamy, 25-May-09. ( bytes): This memo proposes a mechanism based on the Dynamic Delegation Discovery Service (DDDS) which can be used for the verification of SMTP recipient addresses.
"Local Mobile Anchor Discovery Using DNS by Service Name", Behcet Sarikaya, Frank Xia, 13-Jul-09. ( bytes): This draft defines a Domain Name System (DNS)-based scheme to enable dynamic discovery of a Local Mobility Anchor (LMA) in Proxy Mobile IPv6. DNS Service Resource Record option is used allowing a Mobile Access Gateway (MAG) to request the LMA's Fully Qualified Domain Name (FQDN) and possibly IP address via the DNS response. IPv4 case is also covered.
"Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)", Lee Speakman, Kenichi Mase, 25-May-09. ( bytes): This document describes the routing loop and packet looping issues in mobile ad hoc network (MANET) running proactive routing protocols using hop count metric. Mechanisms of loop formation are identified and how the problem of loop formation is exacerbated by the use of Link Layer Notification is described. The effect of the looping packets on the network are shown by comparing against the case where the looping packets are detected and discarded, showing the need for routing loops or looping packets to be dealt with in MANETs.
"The i;codepoint collation", Bjoern Hoehrmann, 25-May-09. ( bytes): 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.
"A SIP server event package for SIP server farm", Tao Ma, LiChun Li, Chunhong Zhang, Xituchen Beijing, Yang Ji, 26-May-09. ( bytes): This document defines the Session Initiation Protocol (SIP) server even package for SIP server farm using the SIP event framework. The SIP server event package allows clients to subscribe to the servers for server information in the server farm, and serves to communicate information with each other. Based on this, an overall view of the SIP server farm is built and delivered to the entity (including SIP phone proxy or other SIP servers) which subscribes and receives the event packages. The view would help failover and load balancing in the server farm. The event notification mechanism of SIP event framework guarantees its adaption to the dynamic changes of server state. We instantiate the usage of SIP server event package in three scenarios: client based failover, DNS based failover, load balancer based load balancing. To be added, we introduce some specific usage in Peer-to-Peer SIP(P2PSIP) and service discovery to expand and explore the potential usage space. Compared with the failover and load balancing mechanisms in traditional SIP, the new SIP event package would apply its explicit and dynamic notification mechanism to improve the efficiency and service availability of SIP server farm. This mechanism using server event package can also be a complementary way for the DNS functionality defined in RFC 3263[RFC 3263] to locate SIP servers.
"Requirements for a Condition-based URI Selection (CBUS) using the Session Initiation Protocol (SIP)", Christer Holmberg, 27-May-09. ( bytes): This specification defines CBUS requirements for the SIP interface between the CBUS Client and the CBUS server, based on the requirements in OMA.
"Extensions of Host Identity Protocol (HIP) with Hierarchical Information", Dacheng Zhang, Xiaohu Xu, 27-May-09. ( bytes): This document briefly introduces the benefits brought by extending the Host Identity Protocol (HIP) with hierarchical information. In addition, two hierarchical extensions of HIP are introduced. The first one aims to transport hierarchical information in a parameter of the HIP header, while the second one extends DNS resource records in order to contain hierarchical information.
"Host Identifier Revocation in HIP", Dacheng Zhang, Xiaohu Xu, 27-May-09. ( bytes): This document mainly analyzes the key revocation issue with host identities (HI) in the Host Identity Protocol (HIP), which has not attracted enough attention from HIP community yet. As a core component of key management mechanism, key revocation is critical for security systems especially which are expected to execute for a long period. Apart from that, this document also discusses the possible challenges that the designers of HI revocation mechanisms have to face and introduces several possible solutions.
"Nominating Committee Process: Incumbent Review Model", John Klensin, Spencer Dawkins, 13-Jul-09. ( bytes): The traditional IETF Nomcom model treats incumbents and new nominees (for the same and other positions) as equivalent. This has not proven realistic in practice and has had a number of undesirable side effects. This document reviews the issues and the specific changes to the model that take advantage of the differences between incumbents and new nominees.
"Transport Instance BGP", Robert Raszuk, Keyur Patel, 27-May-09. ( bytes): BGP4 protocol is a well established single standard of an inter- domain Internet routing and non Internet routing information distribution today. For many applications it is a lso the protocol of choice to disseminate various application based information intra- domain. It's popularity and it's wide use has been effectively provided by it's reliable transport, session protection as well as loop free build in mechanism. It has been observed in both intra-domain as well as inter-domain applications that reliable information distribution is an extremely desired tool for many services. Introduction of Multiprotocol Extensions to BGP even further attracted various sorts of new information to be carried over BGP4. The observation proves that amount and nature of information carried by BGP increases and diverges from the original goal of interconnection for IP Internet Autonomous Systems at a rather fast pace. This draft proposes BGP to divide information into two broad categories: Internet routing critical and non Internet routing critical that would also include information carried by BGP which is not related directly to routing. For the purpose of this document we will refer to the latter case as second BGP instance. This draft proposes that the current BGP infrastructure will continue to be used to disseminate Internet routing related information while non routing information or private routing data is recommended to be carried by independent transport instance BGP.
"An ABNF Extension for code generation", Jong Kim, Munjo Yu, 27-May-09. ( bytes): This document describes an ABNF extension for code generation. The extension has two features; extension rule and non-sequence group notations. The extension rules are used to direct the parser generator with things like data types, variable names, forced value for a variable, etc. The non-sequence group feature was proposed as part of RFC 2234 in the past, but dropped due to its ambiguities. The feature is proposed again in this document not as a fundamental building block, but as an add-on. The elements of a non-sequence group are unordered, and are allowed multiple appearance.We attempt to minimize the ambiguities stemmed from repetition of an element by defining specific repetition rules for elements of a non-sequence group and non-sequence group themselves.
"Generation of ICMPv6 Echo Replies for Teredo Clients", Teemu Savolainen, Remi Denis-Courmont, 28-May-09. ( bytes): Teredo uses return routing to discover the closest Teredo relay corresponding to any given peer. Discovery is achieved by sending an ICMPv6 Echo Request and waiting for the appropriate relay to forward the ICMPv6 Echo Reply back. Unanswered ICMPv6 Echo Requests make Teredo clients assume that the peer is unreachable. This document identifies two scenarios where a middlebox should detect the lack of ICMPv6 Echo Reply and craft one toward the Teredo client in order to avoid possibly erroneous peer unreachability assumptions.
"RFC 4648 Implementation Report", Simon Josefsson, 28-May-09. ( bytes): This is an implementation report of RFC4648, for the purpose of advancing the document to Draft Standard. See for more information.
"E6 Addressing Scheme and Network Architecture", Dmitry Zaitsev, 1-Jun-09. ( bytes): This document describes new E6 addressing scheme for the creation of world-wide networks totally constructed on the base of Ethernet technology. Hierarchic E6 addresses with the length of 6 octets are used instead of both Ethernet MAC-addresses and IP-addresses which allows the routing within world-wide networks and cuts overhead of TCP, IP headers; the address space is extended in 16K times regarding IP addresses. Standard Ethernet LLC2 facilities are employed for guaranteed delivery of information. E6 Network Architecture simplifies packets processing aglorithms that improves the network performance and QoS.
"RFC 2731 is Obsolete", Julian Reschke, 1-Jun-09. ( bytes): This document recommends that RFC 2731, on Encoding Dublin Core Metadata in HTML, be reclassified as Historic, as further development of this specification has moved to the Dublin Core Metadata Initiative.
"Preference Level based Binding Table", Eric Levy-Abegnoli, 4-Aug-09. ( bytes): [fcfs] proposes a simple preference scheme to resolve binding entry collisions (same l3 address, different anchors): it keeps the first entry and rejects any others. However, there are cases where keeping the first entry is not the best choice, and others cases where it is bogus. This draft analyses what are these cases, and proposes a different algorithm (preference based) to fix the problem.
"Updated IANA Considerations for Diameter Command Code Allocations", Dan Romascanu, Hannes Tschofenig, 2-Jun-09. ( bytes): The Diameter Base specification, described in RFC 3588, provides a number of ways to extend Diameter, with new Diameter commands, i.e. messages used by Diameter applications, and applications as the most extensive enhancements. RFC 3588 illustrates the conditions that lead to the need to define a new Diameter application or a new command code. Depending on the scope of the Diameter extension IETF actions are necessary. Although defining new Diameter applications does not require IETF consensus, defining new Diameter commands requires IETF consensus per RFC 3588. This has lead to questionable design decisions by other Standards Development Organizations which chose to define new applications on existing commands rather than asking for assignment of new command codes for the pure purpose of avoiding bringing their specifications to the IETF. In some cases interoperability problems were causes as an effect of the poor design caused by overloading existing commands. This document aligns the extensibility rules of Diameter application with the Diameter commands offering ways to delegate work on Diameter to other SDOs to extend Diameter in a way that does not lead to poor design choices.
"Transport of Real-time Inter-network Defense (RID) Messages", Kathleen Moriarty, Brian Trammell, 2-Jun-09. ( bytes): Documents intended to be shared among multiple constituencies must share a common format and transport mechanism. The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Realtime Internetwork Defense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises. This document outlines the transport of IODEF and RID messages over HTTP/TLS.
"Signaling Root-Initiated Point-to-Multipoint Pseudowires using LDP", Luca Martini, Sami Boutros, Siva Sivabalan, Maciek Konstantynowicz, Gianni Vecchio, Thomas Nadeau, 2-Jun-09. ( bytes): 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.
"Retransmitted Message Identification Option for Proxy Mobile IPv6", Sri Gundavelli, Kent Leung, Rajeev Koodli, 2-Jun-09. ( bytes): The Proxy Mobile IPv6 base protocol does not provide any mechanism for the receiver of a mobility signaling message to determine if the received message is the original message or a retransmitted message of an earlier sent message. The absence of such a semantic in some cases results in inefficient processing of the signaling messages and will lead to additional processing load and network traffic. This document defines a new mobility option, Retransmitted Message Identification option for use in Proxy Binding Update and Proxy Binding Acknowledgement messages. This option enables the mobility entities to use proper message identifiers and retransmit markings on the signaling messages.
"Best Practices for Checking of Server Identities in the Context of Transport Layer Security (TLS)", Peter Saint-Andre, Kurt Zeilenga, Jeff Hodges, 3-Jun-09. ( bytes): This document specifies the how an entity establishing a TLS connection, or other PKI-based interaction, with a server should verify the server identity.
"iCalendar XML Representation", Cyrus Daboo, Mike Douglass, Steven Lees, 4-Jun-09. ( bytes): This specification defines a format for representing iCalendar data in XML.
"An Extension to the Session Initiation Protocol (SIP) for Request History Information", Francois Audet, The Netherlands, Christer Holmberg, 13-Jul-09. ( bytes): 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 call arrives at a specific application or user. This document defines an optional SIP header, History-Info, for capturing the history information in requests.
"Diameter support for EAP Re-authentication Protocol (ERP)", Sebastien Decugis, 7-Jun-09. ( bytes): The EAP Re-authentication Protocol (ERP) provides a mechanism to optimize EAP authentication delay in the case of re-authentication, which can be significant in roaming mobile situation. This mechanism assumes that a protocol for Authentication, Authorization and Accounting (AAA) is available to transport ERP between the authenticator(s) and the EAP/ERP server. draft-gaonkar-radext-erp-attrs-03 specifies the transport of ERP using RADIUS. This document specifies the transport of ERP using Diameter.
"Requirements for End-to-End Encryption in the Extensible Messaging and Presence Protocol (XMPP)", Peter Saint-Andre, 29-Jun-09. ( bytes): This document describes requirements for end-to-end encryption in the Extensible Messaging and Presence Protocol (XMPP).
"Delay/Disruption Tolerant Networking - Network Management Requirements", Will Ivancic, 5-Jun-09. ( bytes): This document contains four main sections. The first section provide some a short introduction of what Delay (or Disruption or Disconnected) Networking is. The second section describes various DTN operational environments. The third section provides requirements and desired properties for managing Delay and Disruption Tolerant Networks. The fourth section describes characteristics that can be found in DTN systems and suggests items that should be considered for monitoring and/or configuration.
"DHCPv4 Options for Home Information Discovery in Dual Stack MIPv6", Frank Xia, Behcet Sarikaya, 7-Jun-09. ( bytes): 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.
"LDAP Schema for vCard v4.0", Stephen (Sly) Gryphon, 7-Jun-09. ( bytes): This document works to harmonize the vCard directory information card and Lightweight Directory Access Protocol (LDAP) standards by extending both standards to support a common directory card entity. Additional LDAP attributes and object classes, and additional properties for vCard are defined. A standard mapping process between the two designed to support vCard's goal of being a transport format between directories (not just LDAP) is defined.
"Mobility Anchor Point (MAP) Reliability Extension", Xiangsong Cui, 8-Jun-09. ( bytes): This document introduces an extension to allow an adapted multiple binding in hierarchical mobile network. Mobile node registers its RCoA and LCoA in the home agent at same time to get two separate connections between the mobile node and the home agent, or between the mobile node and the correspondent node in Route Optimization scenario. These connections provide a robust communication between the mobile node and correspondent nodes and mobile node can overcome the failure on MAP.
"HTTP Multipart Batched Request Format", James Snell, 12-Jun-09. ( bytes): This document specifies a format for packaging multiple, independent HTTP requests into a single multipart payload.
"Delivery of Request-URI Targets to User Agents", Jonathan Rosenberg, The Netherlands, Christer Holmberg, Francois Audet, 9-Jun-09. ( bytes): When a Session Initiation Protocol (SIP) proxy receives a request targeted at a URI identifying a user or resource it is responsible for, the proxy translates the URI to a configured URI, or to a registered contact URI, of an agent representing that user or resource. In the process, the original URI is removed from the request. Numerous use cases have arisen which require this information to be delivered to the user agent. This document describes these use cases and defines an extension to the History- Info header field which allows it to be used to support those cases.
"Redundancy and Load Balancing Mechanisms for Stateful Network Address Translators (NAT)", Xiaohu Xu, 9-Jun-09. ( bytes): This document defines some redundancy and/or load balancing mechanisms for stateful Network Address Translators (NAT), including IPv4->IPv4 NAT, IPv4->IPv6 NAT and IPv6->IPv4 NAT.
"SIP endpoint security case study", Hendrik Scholz, 9-Jun-09. ( bytes): SIP endpoints are subject to unwanted communication often perceived as Spam over Internet Telephony (SPIT). This document describes caveats on various layers which can be abused to send unsolicited messages. As a result users receive a degraded experience. The issues found are based on case studies of various events seen in VoIP provider networks.
"In-lining Extensions for Atom", Nikunj Mehta, 29-Jun-09. ( bytes): This specification defines mechanisms for in-lining representations of linked Atom resources.Editorial Note To provide feedback on this Internet-Draft, join the atom-syntax mailing list (http://www.imc.org/atom-syntax/) [1].
"GOST R 34.10-2001 digital signature algorithm", Vasily Dolmatov, Dmitry Kabelev, Igor Ustinov, Sergey Vyshensky, 5-Aug-09. ( bytes): This document is intended to be a source of information about the Russian Federal standard for for electronic digital signature generation and verification processes GOST R 34.10-2001 [GOST3410]. GOST R 34.10-2001 is one of the official standards in the Russian cryptography, used in Russian algorithms (GOST algorithms). Recently, the Russian cryptography started to be used in different applications intended to work with the OpenSSL cryptographic library. Thus, this document has been created for the informational purposes for users of Russian cryptography.
"GOST R 34.11-94 Hash function algorithm", Vasily Dolmatov, Dmitry Kabelev, Igor Ustinov, Sergey Vyshensky, 5-Aug-09. ( bytes): This document is intended to be a source of information about the Russian Federal standard for hash function GOST R 34.11-94 [GOST3411]. GOST R 34.11-94 is one of the official standards in the Russian cryptography, used in Russian algorithms (GOST algorithms). Recently, the Russian cryptography started to be used in different applications intended to work with the OpenSSL cryptographic library. Thus, this document has been created for the informational purposes for users of Russian cryptography.
"Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP", Salvatore Loreto, Peter Saint-Andre, Greg Wilkins, Stefano Salsano, 11-Jun-09. ( bytes): There is widespread interest in using the Hypertext Transfer Protocol (HTTP) to enable asynchronous or server-initiated communication from a server to a client as well as from a client to a server. This document describes how to better use HTTP, as it exists today, to enable such "bidirectional HTTP" using "long polling" and "HTTP streaming" mechanisms.
"Realm-Based Redirection In Diameter", Tina Tsou (Ting ZOU), Tom Taylor, 13-Jul-09. ( bytes): 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 the means by which this can be achieved.
"Link Relations for Simple Version Navigation", Al Brown, Geoffrey Clemm, Julian Reschke, 13-Jul-09. ( bytes): This specification defines Atom link relations for navigation between a resource and its versions.
"IPv4 Address Blocks Reserved for Documentation", Jari Arkko, Michelle Cotton, Leo Vegoda, 25-Jun-09. ( bytes): Three IPv4 unicast address blocks are reserved for use in examples in specifications and other documents. This document describes the use of these blocks.
"The Subnetwork Encapsulation and Adaptation Layer (SEAL)", Fred Templin, 2-Jul-09. ( bytes): For the purpose of this document, subnetworks are defined as virtual topologies that span connected network regions bounded by encapsulating border nodes. These virtual topologies may span multiple IP and/or sub-IP layer forwarding hops, and can introduce failure modes due to packet duplication and/or links with diverse Maximum Transmission Units (MTUs). This document specifies a Subnetwork Encapsulation and Adaptation Layer (SEAL) that accommodates such virtual topologies over diverse underlying link technologies.
"SAVI for Delegated IPv6 Prefixes", John Kaippallimalil, Frank Xia, 12-Jun-09. ( bytes): This memo introduces a public access topology which includes hosts, Customer Premise Equipment Router (CPE-R), switches and access routers. A CPE-R advertises prefixes to a host for its address configuration, while these prefixes are in turn delegated to the CPE-R from the access router. A switch located between the CPE-R and the router builds filtering table for traffic originating from the host by snooping prefix delegating signaling.
"DNSSEC OK buffer minimum size requirement and error handling", Olafur Gudmundsson, 28-Jul-09. ( bytes): RFC3226 mandated support for EDNS0 in DNS entities claiming to support either DNS Security Extensions or IPv6 address records. This requirement was motivated because these new features increase the size of DNS messages. If EDNS0 is not supported fall back to TCP will happen, having a detrimental impact on query latency and DNS server load.
"A Minimal Deployment Option for Multicast Listeners in PMIPv6 Domains", Thomas Schmidt, Matthias Waehlisch, Behcet Sarikaya, Suresh Krishnan, 1-Jul-09. ( bytes): This document describes deployment options for activating multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards. Similar to Home Agents in Mobile IPv6, PMIPv6 Local Mobility Anchors serve as multicast subscription anchor points, while Mobile Access Gateways provide MLD proxy functions. In this scenario, Mobile Nodes remain agnostic of multicast mobility operations.
"Multicast Receiver Mobility (MultiReM) Architecture", Hui Liu, 14-Jun-09. ( bytes): This document proposes the architecture and solution options for multicast receiver mobility. The discussions are restricted only to the receiver mobility with the assumption that the multicast source and network are stationary while the receiver is in the moving state. The suggestions are given on how to integrate mobile IP and fixed multicast protocols to provide the feasible solutions, which involves the aspects of mobile receiver registration, group membership management, tunnel or optimal multicast routing, and handover optimization.
"Chopan - Compressed HTTP Over PANs", Brian Frank, 15-Jun-09. ( bytes): This document describes a method for compressing HTTP messages into a binary format to be transmitted using UDP over 6LoWPAN wireless networks.
"draft-zhipeng-pkix-drm-proxy-architecture-00", Zhipeng Zhou, 15-Jun-09. ( bytes): This document specifies a method and its architecture for proxy DRM application based on the PKI environment with X.509 certificate [X.509]. It can be a common solution for the proxy DRM application regardless the specific DRM standard that is implemented on the interface between the Client Device and Service Server.
"How Host A learns the IP address of Host B", Congxiao Bao, Xing Li, 15-Jun-09. ( bytes): This document describes how host A learns the IP address of host B in BEHAVE's "An IPv6 network to the IPv4 Internet" scenario. In this scenario, an IPv6-only host A must know the IPv6 address representation of host B.
"Delivering Conference Participant Sound Level Indicators in RTP Streams", Emil Ivov, Enrico Marocco, 15-Jun-09. ( bytes): This document describes a mechanism for RTP-level mixers in audio conferences to deliver information about the sound level information on the individual participants. Such sound level indicators are transported in the same RTP packets as the audio data they pertain to.
"Use Cases and interpretation of RPKI objects for issuers and relying parties", Terry Manderson, Kotikalapudi Sriram, Russ White, 15-Jun-09. ( bytes): This document provides use cases directions, and interpretations for organisations and relying parties when creating or encountering RPKI object scenarios in the public RPKI in relation to public internet routing.
"PCAP-compatible Binary Syntax for SIP Common Log File Format", Hadriel Kaplan, 16-Jun-09. ( bytes): This document proposes a libpcap/PCAP-compatible binary syntax for the SIP common log format (CLF). It does not cover semantic issues, and is meant to be evaluated in the context of the other efforts discussing SIP CLF.
"SIP/SDP Overlap with RTSP", Jan Lindquist, Jouni Maenpaa, Priya Rajagopal, Xavier Marjou, 16-Jun-09. ( bytes): The Session Initiation Protocol (SIP) is widely used for establishing multimedia sessions, whereas the Real Time Streaming Protocol (RTSP) is a protocol for use 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 RTSP is also used for session establishment, there exists an overlap between the functionality provided by SIP and RTSP. In this document, we analyze a model 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 also for RTSP-based streaming.
"HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", Hugo Krawczyk, Pasi Eronen, 17-Jun-09. ( bytes): This document specifies a simple HMAC-based key derivation function (HKDF) which can be used as a building block in various protocols and applications. The KDF is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions.
"A Real-Time Transport Protocol (RTP) Extension Header for Audio Level Indication", Jonathan Lennox, 17-Jun-09. ( bytes): This document defines a mechanism by which packets of Real-Time Transport Protocol (RTP) audio streams can indicate, in an RTP extension header, the audio level of the audio sample carried in the RTP packet. In large conferences, this can reduce the load on an audio mixer or other middlebox which wants to forward only a few of the loudest audio streams, without requiring it to decode and measure every stream that is received.
"A lock feature to SNMP", Washam Fan, Tony Meng, 17-Jun-09. ( bytes): This memo is intended to provide a lock mechanism to SNMP for protecting SET operations from being interrupted by any other network management operations such as NETCONF or CLI writes. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it extends LOCK-MIB defined in [I-D.meng-fan-lock-mib] to define objects for managing SNMP locks. The lock acquisition and release can be achieved through manipulating those objects.
"Signaling Compression dictionary for SIP", Lei Zhu, 18-Jun-09. ( bytes): The SigComp static dictionary for Session Initiation Protocol (SIP) signalling was done by first version RFC3485. SIP protocol related extensions were completed and published in a series IETF documents. Those SIP protocol extensions had been used in 3GPP IMS and IMS based applications. The new extensions to SIP protocol weaken the intention of static dictionary for SIP signalling compressing which is to reduce overload risks in radio access network and core network involving wireless network
"ECP Groups for IKE and IKEv2", David Fu, Jerome Solinas, 20-Jun-09. ( bytes): This document describes new Elliptic Curve Cryptography (ECC) groups for use in the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols in addition to previously defined groups. Specifically, the new curve groups are based on modular arithmetic rather than binary arithmetic. These new groups are defined to align IKE and IKEv2 with other ECC implementations and standards, particularly NIST standards. In addition, the curves defined here can provide more efficient implementation than previously defined ECC groups. This version incorporates the erratum for RFC 4753, which changes the format of the Diffie-Hellman shared secret value.
"Secure Beacon: Securely Detecting a Trusted Network", Yaron Sheffer, Yoav Nir, 21-Jun-09. ( bytes): Remote access clients, in particular IPsec-based ones, are heavily deployed in enterprise environments. In many enterprises the security policy allows remote-access clients to switch to unprotected operation when entering the trusted network. This document specifies a method that lets a client detect this situation in a secure manner, with the help of a security gateway. We propose a minor extension to IKEv2 to achieve this goal.
"SIPFIX: Use Cases and Problem Statement for VoIP Monitoring and Exporting", Felipe Huici, Saverio Niccolini, Sven Anderson, 22-Jun-09. ( bytes): The deployment of Voice-over-IP (VoIP) telephony is increasing fast. VoIP's paradigm and the features it offers differ significantly from that of regular telephony, and, as a result, its monitoring requirements do so as well. This draft employs use cases to derive these requirements and introduces SIPFIX, an extension to IPFIX (IP Flow Information eXchange), that meets them.
"LDP Graceful Restart for Pseudowire", Albert Jiang, Kan Hu, Luo Jian, 23-Jun-09. ( bytes): This document describes a LDP graceful restart(GR) mechanism that helps to minimize the negative effects on single or multi-segment pseudowire traffic caused by Provider Edge (PE) control plane restart, specifically by the restart of its Label Distribution Protocol (LDP) component.
"IANA Considerations for NLPIDs", Donald Eastlake 3rd, 24-Jun-09. ( bytes): Some protocols being developed or extended by the IETF make use of the ISO/IEC Network Layer Protocol Identifier (NLPID). This document provides NLPID IANA Considerations.
"Softwire Concentrator Discovery Using DHCP", Dayong Guo, Sheng Jiang, 12-Jul-09. ( bytes): Several types of Carrier-Grade-NATs (CGNs) have been proposed to simplify IPv4/IPv6 transition of the edge network by integrating tunnels and NAT. A very common scenario is that many users set up softwires (i.e. tunnels) to a softwire concentrator for public or private access services. In order to establish softwires successfully, a new mechanism is required to enable users in the edge network to discover the information of the concentrator. This document describes how a host or CPE (Customer Premises Equipment) discovers the remote softwire concentrator or CGN in a hub and spoke network using DHCP. Based on two new Softwire Concentrator or CGN Discovery DHCP Options, proposed in the document, a user can obtain softwire concentrator or CGN information and then set up a tunnel to the softwire concentrator or CGN.
"Mobility Session Suspend Support in PMIPv6", Ahmad Muhanna, Vijay Devarapalli, Sri Gundavelli, 25-Jun-09. ( bytes): This specification defines a new extension to Proxy Mobile IPv6 for suspending a mobility session by using a new Mobility Session Suspend option. This option is used by the mobile access gateway in the Proxy Binding Update to request the local mobility anchor to suspend a specific mobile node mobility session. When the local mobility anchor successfully processes the Proxy Binding Update, the local mobility anchor suspends the delivery of the downlink traffic to the specified mobile node mobility session. The mobile access gateway sends another Proxy Binding Update with the mobility session suspend option and the suspend flag cleared to indicate to the local mobility anchor to resume sending the downlink traffic for the mobile node mobility session.
"Sieve Email Filtering: Use of Presence Information with Auto Responder functionality", Robins George, Alexey Melnikov, 25-Jun-09. ( bytes): This document describes how Sieve email filtering language can be used for automatically responding to an incoming electronic mail messages based on the presence information of the user.
"A Session Initiation Protocol (SIP) Event Package for Communication Diversion Information in support of the Communication Diversion (CDIV) Notification (CDIVN) CDIV service", Ranjit Avasarala, Subir Saha, John-Luc Bakker, 28-Jul-09. ( bytes): 3GPP and ETSI TISPAN are defining PSTN/ISDN simulation services and in particular the Communication Diversion (CDIV) using IP Multimedia (IM) core Network (CN) subsystem supplementary service. As part of CDIV, a (SIP) Event Notification Framework-based mechanism is used for notifying Users about diversions (re-directions or forwarding) of their incoming communication sessions. A new event package is proposed for allowing users to subscribe for and receive such notifications. Users have further capability to define filters controlling the selection, rate and content of such notifications. This SIP event package is applicable to the IMS and may not be applicable to the general Internet.
"RT-Constrain Lite for Provider Edge Routers", John Scudder, James Uttaro, Pradosh Mohapatra, 25-Jun-09. ( bytes): RFC 4684, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)" provides a powerful and general means for BGP speakers to exchange and propagate Route Target reachability information which is used for cooperative route filtering. However, the complexity of implementing the entire specification may have impeded its widespread deployment. This document specifies the subset of functionality which is required for a provider edge router ("PE") to originate Route Target NLRI. Such PEs need not implement any filtering functionality.
"Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Amendment3 and G.sup43 Optical Transport Networks Control", Xihua Fu, Ming Ke, Yuanlin Bao, 6-Jul-09. ( bytes): This document updates the "draft-ke-ccamp-gmpls-odu0-00.txt". It describes the extensions of GMPLS signaling to control Optical Transport Networks (OTN) including ODU0, ODU1, ODU2, ODU2e, ODU3, ODU3e1, ODU3e2, ODU4 and ODUflex. It also covers the interworking of control plane between pre-G.709 controlling and G.709 Amendment3 controlling.
"Label Switched Path (LSP) Data Path Delay Metric in Generalized MPLS/ MPLS-TE Networks", Weiqiang Sun, Guoying Zhang, Jianhua Gao, Guowu Xie, Rajiv Papneja, Bin Gu, Xueqing Wei, Tomohiro Otani, Ruiquan Jing, 26-Jun-09. ( bytes): 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.
"Comcast's Protocol-Agnostic Congestion Management System", Chris Bastian, Tom Klieber, Jason Livingood, Jim Mills, Richard Woundy, 26-Jun-09. ( bytes): This document describes the congestion management system of Comcast Cable, a large cable broadband Internet Service Provider (ISP) in the U.S. Comcast completed deployment of this congestion management system on December 31, 2008.
"NFS operation over IPv4 and IPv6", Alex RN, Bhargo Sunil, Dhawal Bhagwat, Dipankar Roy, Rishikesh Barooah, 26-Jun-09. ( bytes): This Internet-Draft provides the description of problem set faced by NFS and its various side band protocols when implemented over IPv6 in various deployment scenarios. Solution to the various problems are also given in the draft and are sought for approval in the respective NFS and side band protocol versions. Foreword This "forward" section is an unnumbered section that is not included in the table of contents. It is primarily used for the IESG to make comments about the document. It can also be used for comments about the status of the document and sometimes is used for the RFC2119 requirements language statement.
"Open Grid Protocol : Client Application Launch Message", Meadhbh Hamrick, John Hurliman, 26-Jun-09. ( bytes): This document describes the LLIDL interface description for the Open Grid Protocol (OGP) Client Application Launch message format. Messages in this format are intended to be used in conjunction with standard web authentication or authorization technologies such as OpenID or OAuth. This document describes the message format, the processing expectations and three MIME types that may be used to identify requests to initiate a virtual worlds session.
"A Distance Vector Protocol for Routing Over Low Power and Lossy Networks", Mukul Goyal, 27-Jul-09. ( bytes): This draft describes a distance vector protocol for routing over low power and lossy networks (LLN).
"Reusing Transport Layer Connections in Session Initiation Protocol (SIP)", Rajnish Jain, Vijay Gurbani, Hadriel Kaplan, 28-Jun-09. ( bytes): The current Session Initiation Protocol (SIP) specification dictates that a transport layer connection can carry SIP requests in only one direction i.e. from the client to the server. This presents scalability problems as twice the number of connections are needed for each pair of SIP entities that communicate with each other. The internet-draft [I-D.ietf-sip-connect-reuse] specifies a mechanism for reusing SIP over TLS connections. However, that document is predicated on secure TLS mutual authentication and specifically refrains connection reuse for transports such as SIP over TCP and SCTP. There are many situations, such as in Trust Domains [RFC3324], where TLS mutual authentication may not be required but where connection reuse is beneficial. This document specifies connection reuse for SIP over connection-oriented transports such as TCP and SCTP. It specifies the same mechanism for connection reuse as specified in [I-D.ietf-sip-connect-reuse], however, the solution is presented in the context of Trust Domains.
"RPL: Routing Protocol for Low Power and Lossy Networks", Tim Winter, ROLL Team, 13-Jul-09. ( bytes): This document specifies the Routing Protocol for Low Power and Lossy Networks (RPL), in accordance with the requirements described in [I-D.ietf-roll-building-routing-reqs], [I-D.ietf-roll-home-routing-reqs], [I-D.ietf-roll-indus-routing-reqs], and [RFC5548].
"Requirements for secure caller identification in the Session Initiation Protocol (SIP)", John Elwell, Victor Pascual, 28-Jun-09. ( bytes): This document examines requirements for secure caller identification in SIP. Although existing mechanisms exist to achieve this, there are some known shortcomings or deployment difficulties. This work is being discussed on the dispatch@ietf.org mailing list.
"Chunk Discovery for P2P Streaming", Ning Zong, 28-Jun-09. ( bytes): This document describes several mechanisms of Chunk Discovery in P2P Streaming use case. The Chunk Discovery for P2P streaming provides the functionality of streaming sources registrar and discovery in a fully-distributed system. It provides register, update and lookup service for video chunks in the P2P Streaming applications. The mechanisms include a P2P streaming usage for REsource LOcation And Discovery (RELOAD), and a combined Trakcer and Peer Gossip method.
"Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 amendment 3 Optical Transport Networks Control", Daniele Ceccarelli, Diego Caviglia, Francesco Fondelli, Marco Corsi, 29-Jun-09. ( bytes): This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling documents. It describes the technology- specific information needed to extend GMPLS signaling to control Optical Transport Networks (OTN) based on ITU-T G.709 amendment 3 reccomandation.
"Content Sharing Usage for RELOAD", Jun Wang, Jiong Shen, Yu Meng, 29-Jun-09. ( bytes): This document defines a content sharing usage for REsource LOcation And Discovery (RELOAD). The content sharing usage provides the functionality of distributing and fetching shared content to and from a P2P overlay network. The shared content including such as streaming media, files etc. are provided by those shared content service providers. Using content sharing usage of RELOAD can construct a peer-to-peer overlay, the overlay performs as Content Delivery Network and is service insensitive.
"A Generic MIB for Centralized Network Architecture", Yang Shi, Ju Wang, 29-Jun-09. ( bytes): This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes the managed objects for a generic model to manage the centralized network architecture.
"Security Extension for Unidirectional Lightweight Encapsulation Protocol", Michael Noisternig, Prashant Pillai, Haitham Cruickshank, 13-Jul-09. ( bytes): The Unidirectional Lightweight Encapsulation (ULE) protocol provides an efficient mechanism for transporting IP and other network layer protocol data over MPEG-2 networks. Such networks, widely used especially for providing digital TV services, often use broadcast wireless transmission media, and are hence vulnerable to various types of security attacks. This document describes a new mandatory ULE extension to protect ULE traffic using security features such as data confidentiality, data integrity, data origin authentication, and prevention against replay attacks. Additionally, destination addresses may be hidden from unauthorized receiver devices using the identity protection feature. The format of the security extension header as well as the processing at receivers and transmitters are described in detail. The extension aims to be lightweight and flexible such that it may be implemented in low-cost, resource-scarce transceivers, and different levels of security may be selected. The security extension may be easily adapted to the Generic Stream Encapsulation (GSE) protocol, which uses a similar extension header mechanism.
"An ALTO Service based on BGP Routing Information", Peter Racz, Zoran Despotovic, 29-Jun-09. ( bytes): Overlay applications, like Peer-to-Peer (P2P) file-sharing and video streaming, attract a lot of users and generate a huge amount of data. Most overlay applications do not take into account the underlying network topology in their routing decisions and connection establishment in general. Due to this fact and the large amount of P2P traffic, overlay applications waste network resources, cause problems in network management, and result in high costs for ISPs, especially because of the expensive interconnection links between ISPs. Therefore, the objective of the ALTO Working Group Charter [ALTO-charter] is to design and specify an Application-Layer Traffic Optimization (ALTO) service that will assist P2P applications in their peer selection process in order to achieve a more efficient usage of network resources, to reduce operational costs of ISPs, and to increase the overlay application performance at the same time. This draft proposes a possible ALTO service that uses BGP routing information in order to calculate a rating value for peers providing a certain resource (resource providers). The service is operated by the ISP. Since BGP routing information is available in any ISP network and the service accesses the routing information from the local ISP network, the deployment of the service does not require changes in the network and the ALTO server can retrieve routing information automatically.
"PCEP Requirements for WSON Impairments", Greg Bernstein, 29-Jun-09. ( bytes): This memo provides application-specific requirements for the Path Computation Element communication Protocol (PCEP) for the support of Impairments in Wavelength Switched Optical Networks (WSON). From a path computation perspective, optical impairments are additional constraints on the process of determining an optical light path.
"Virtual Enterprise Traversal (VET)", Fred Templin, 27-Jul-09. ( bytes): Enterprise networks connect routers over various link types, and may also connect to provider networks and/or the global Internet. Enterprise network nodes require a means to automatically provision IP addresses/prefixes and support internetworking operation in a wide variety of use cases including Small Office, Home Office (SOHO) networks, Mobile Ad hoc Networks (MANETs), ISP networks, multi- organizational corporate networks and the interdomain core of the global Internet itself. This document specifies a Virtual Enterprise Traversal (VET) abstraction for autoconfiguration and operation of nodes in enterprise networks.
"Service Flow Identifier in Proxy Mobile IPv6", Min Hui, Gang Chen, Hui Deng, 29-Jun-09. ( bytes): Proxy Mobile IPv6 enables network-based mobility for a regular IPv6 mobile node without requiring its participation in any mobility- related signaling. This document introduces extensions to Proxy Mobile IPv6 that allows network dynamically binding each service flow to the mobile node, respectively. Therefore, multiple service flows of the mobile node can be separately controlled based on the service flow identifier in the Proxy Binding Update and Acknowledge messages.
"Differentiated Services Support for Proxy Mobile IPv6", Frank Xia, Behcet Sarikaya, 29-Jun-09. ( bytes): This document describes Quality of Service (QoS) provisioning in a Proxy Mobile IPv6 domain through enabling differentiated services. When a packet is encapsulated in a mobile access gateway (or a local mobility anchor), the differentiated services codepoint (DSCP) field in the outer header is mapped to the priority of a mobile node, or the precedence of an application of the mobile node. Intermediary routers between the mobile access gateway and the local mobility anchor, which forward the packet based on the outer header of the packet, prioritize the packet according to the DSCP value of the outer header.
"Fast Handover for Multicast in Proxy Mobile IPv6", Min Hui, Gang Chen, Hui Deng, 29-Jun-09. ( bytes): This document specifies the 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.
"MPLS-TP General Authentication TLV for G-ACH", Vishwas Manral, 30-Jun-09. ( bytes): This document defines a new generalized authentication TLV, to be used in the ACH header RFC5586 [2]. This can be used for both the MPLS and MPLS-TP networks.
"DNSSEC Trust Anchor History Service", Wouter Wijngaards, 9-Jul-09. ( bytes): When DNS validators have trusted keys, but have been offline for a longer period, key rollover will fail and they are stuck with stale trust anchors. History service allows validators to query for older DNSKEY RRsets and pick up the rollover trail where they left off.
"MulTFRC: TFRC with weighted fairness", Michael Welzl, Dragana Damjanovic, 30-Jun-09. ( bytes): This document specifies the MulTFRC congestion control mechanism. MulTFRC is derived from TFRC and can be implemented by carrying out a few small and simple changes to the original mechanism. Its behavior differs from TFRC in that it emulates a number of TFRC flows with more flexibility than what would be practical or even possible using multiple real TFRC flows. Additionally, MulTFRC better preserves the original features of TFRC than multiple real TFRCs do.
"A Hybrid ISP Framework for IPv6 Services and IPv6/IPv4 Inter-communication", Jiangfeng Xu, Sheng Jiang, Brian Carpenter, 30-Jun-09. ( bytes): Global IPv6 deployment is expected. Many solutions have been specified in order to provide IPv6 connectivity service. In order to provide IPv6 connectivity service to all kinds of host/client devices, ISP networks may need to support as many as possible IPv6 connectivity solutions. This document proposes a hybrid ISP framework that supports the coexistence of various IPv6 connectivity solutions and analyses the configuration requirements raised by this framework. Additionally, the applicability of different configuration mechanisms for performing this configuration is discussed.
"Enhanced Client Support for RELOAD", Vidya Narayanan, Ashwin Swaminathan, 30-Jun-09. ( bytes): RELOAD [1] defines a class of devices termed as clients that may attach to peers and use the overlay, without having to provide overlay routing or storage. These devices may attach to the identity owner on the overlay or to any arbitrary peer. This document provides a mechanism to attach to any arbitrary peer with some state on the overlay for routing purposes. This avoids needing application specific means of providing a destination list for contact information for the client and also inherently handles client mobility.
"LISP Mobility Architecture", Dino Farinacci, Vince Fuller, Darrel Lewis, Dave Meyer, 1-Jul-09. ( bytes): 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 Mobility Architecture uses standard LISP functionality to provide scalable mobility for LISP mobile nodes.
"Protection for P2MP Ring in MPLS-TP Networks", Xuehui Dai, Wu Bo, Jian Yang, Guoman Liu, 1-Jul-09. ( bytes): This document provides two possible solutions for protecting point to multipoint (P2MP) traffic distribution over a ring topology in MPLS-TP networks. These two methods can protect any link or node(except the root node)failure once a failure is detected through MPLS-TP OAM mechanism.
"A Childless Initiation of the IKE SA", Yoav Nir, Hannes Tschofenig, Hui Deng, Rajeshwar Jenwar, 13-Jul-09. ( bytes): This document describes an extension to the IKEv2 protocol that allows an IKE SA to be created and authenticated without generating a child SA.
"RTP Payload Format for Reed Solomon FEC of Multiple Flows", Sarit Galanos, 1-Jul-09. ( bytes): This document defines a new RTP payload format for the Forward Error Correction (FEC) that uses Reed-Solomon codes. The format defined by this document enables the protection of multiple source flows with one or more repair flows and is based on the FEC framework (described in [I-D.ietf-fecframe-framework]) and the SDP Elements for FEC Framework (described in [I-D.ietf-fecframe-sdp-elements]). The Reed- Solomon codes used in this document belong to the class of Maximum Distance Separable (MDS) codes which means they offer optimal protection against random and bursty packet losses.
"MPLS-TP recovery control plane analysis", Andrew Rhodes, Nic Neate, David McWalter, 1-Jul-09. ( bytes): Segment recovery function can be signaled using the GMPLS Segment Recovery protocol, or by using LSP Hierarchy with End-to-End Recovery. This draft contrasts the two techniques, with particular attention to differences in control plane function and administrative options, and with regard to requirements for the MPLS-TP control plane. This draft discusses existing protocols. It proposes nothing new.
"Ethernet PW Congestion Handling Mechanisms", Yaakov Stein, 1-Jul-09. ( bytes): Mechanisms for handling congestion in Ethernet pseudowires are presented. These mechanisms extend capabilities of the native service across the PSN, and require use of the PWE3 control word.
"Local Mobility Anchor Based Prefix Management for PMIPv6 Using DHCPv6PD", Behcet Sarikaya, Frank Xia, 1-Jul-09. ( bytes): In Proxy Mobile IPv6, prefixes can only be assigned to one interface of a mobile node by the local mobility anchor (LMA) and different mobile nodes can not share these home network prefixes. Managing per-MN's interface home network prefixes is likely to increase the processing load at the LMA. Based on the idea that Dynamic Host Configuration Protocol for IPv6 (DHCPv6) servers can manage prefixes, we propose a new technique in which LMA offloads delegation and release tasks of the prefixes to the DHCPv6 server. LMA requests prefixes for an incoming mobile node to the DHCPv6 server. Based on these prefixes, the mobile node can create home addresses for its interface. When the mobile node leaves the network, the prefixes are returned to the DHCPv6 server. Authentication, Authorization and Accounting (AAA) servers can also play a role in prefix authorization.
"Web Categories", Sam Johnston, 1-Jul-09. ( bytes): This document specifies the Category header-field for HyperText Transfer Protocol (HTTP), which enables the sending of taxonomy information in HTTP headers.
"MS-PW based L2VPN provisioning, auto-discovery, signaling", Simon Delord, Yuji Kamite, Mark Latham, 1-Jul-09. ( bytes): [RFC5254] describes the requirements for service providers to extend Pseudowires (PWs) across multiple network domains via the use of multi-segment Pseudowires (MS-PWs). The architecture of MS-PWs is described in [MS-PW ARCH] and several tools relating to provisioning, auto-discovery and signaling have been developed to allow the dynamic setup of MS-PWs. However there is no end to end view that describes how these tools can be used in carrier networks. This document aims at providing this view by describing the different stages required for an end to end L2VPN service setup relying on MS-PWs. These stages are VPN provisioning, auto-discovery (network and service), signaling and monitoring.
"Use Cases and Requirements for an IPv6 CPE Router", Chris Donley, Deepak Kharbanda, John Jason Brzozowski, Yiu Lee, Jason Weil, Kirk Erichsen, Lee Howard, Jean-Francois Tremblay, 2-Jul-09. ( bytes): This document captures use cases and associated requirements for an IPv6 Customer Premises Equipment (CPE) router. Specifically, the current version of this document focuses on the provisioning of an IPv6 CPE router and the provisioning of IPv6 Home Devices attached to it. It also addresses IPv6 traffic forwarding and IPv6 CPE Router security. This document also identifies areas for future consideration. These areas include prefix sub-delegation, IPv6 multicast, transition and tunneling mechanisms, provisioning consistency between DHCPv4 and DHCPv6, and DNS support. This document does not address IPv4 use cases or requirements, as they are widely understood; however, it is expected that IPv6 CPE Routers will also support IPv4.
"Happy Eyeballs: Successful Introduction of New Technology to HTTP", Dan Wing, Andrew Yourtchenko, Preethi Natarajan, 2-Jul-09. ( bytes): People like their computers to work quickly. During the transition to new technology, both old and new technologies have to peacefully co-exist. However, if users experience connection delays attributed to the new technology the new technology will be shunned. HTTP ("The Web") is one of the most visible and time-critical applications that is used by nearly every Internet user. It is critical that new technologies which improve HTTP not impair or delay the display of HTTP content. It is also important that users retain the ability to share URIs amongst friends and colleagues, even if the other users have not upgraded to the new technology. This draft makes several recommendations to ensure user satisfaction and a smooth transition from HTTP's pervasive IPv4 to IPv6 and from TCP to SCTP. The audience for this draft is application developers and content providers. This draft is discussed on the Applications Discuss mailing list, https://www.ietf.org/mailman/listinfo/apps-discuss.
"Deterministic Replication for RELOAD", Vidya Narayanan, Saumitra Das, Ashwin Swaminathan, 2-Jul-09. ( bytes): RELOAD [1] provides successor replication of data to protect against data loss occurring from churn on the overlay. It specifies storing of two redundant copies of data on the two immediate successors of a particular node. This provides for basic replication and is highly essential for stability of the overlay. However, it does not address the problem of replication to meet the availability requirements for a particular piece of data or to have the replicas be useful in some inherent load balancing on the overlay. This document specifies a mechanism to provide application-agnostic, deterministic replication on the overlay to meet these needs.
"Non-Deterministic IPv6 Tunnels considered Harmful", Gunter Van de Velde, Ole Troan, Tim Chown, 2-Jul-09. ( bytes): IPv6 is ongoing and natively being deployed by a growing community and it is important that the quality perception and traffic flows are as optimal as possible. Ideally it would be as good as the IPv4 perceptive experience. This paper looks into a set of transitional technologies where the actual user has IPv6 connectivity through the means of IPv6-in-IPv4 tunnels. A subset of the available tunnels has the property of being non-deterministic (i.e. 6to4 [RFC3056] and Teredo [RFC4380] ) because neither the egress path nor the ingress path is always fully controlled. While native IPv6 deployments will keep growing it is uncertain or even expected that these non-deterministic traffic flows will be providing the same user experience and operational quality as deterministic tunnels or native IPv6 connectivity. This paper will detail some considerations around non-deterministic tunnels and will document the harmful element of these for the future growth of networks and the Internet.
"Diameter IKEv2: Support for Interaction between IKEv2 Server and Diameter Server", Violeta Cakulev, Avi Lior, 2-Jul-09. ( bytes): Internet Key Exchange is a component of IPsec used for performing mutual authentication as well as establishing and maintaining security associations (SAs) between two parties such as a user and a network entity. Internet Key Exchange v2 (IKEv2) protocol allows several different mechanisms for authenticating a user, namely the Extensible Authentication Protocol, certificates, and pre-shared secrets. To authenticate and/or authorize the user, the network element such as the Access Gateway may need to dynamically bootstrap a security association based on interaction with the Diameter server. This document specifies the interaction between the Access Gateway and Diameter server for the IKEv2 based on pre-shared secrets.
"RSVP-TE Extensions for MPLS-TP OAM Configuration", Elisa Bellagamba, Loa Andersson, Pontus Skoldstrom, 2-Jul-09. ( bytes): This document defines a method for the configuration of the Bidirectional Forwarding Detection (BFD) OAM mechanism through RSVP-TE Control Plane. The procedures described are experimental and are intended to be possibly updated with other proposed OAM tools and BFD future extensions.
"Multiprotocol Traffic Selector Bindings for IPsec", Greg Daley, Simon Delord, Raymond Key, Suresh Krishnan, 2-Jul-09. ( bytes): In IPsec, secure connectivity is provided for network layer entities. Traffic Selectors which specify interesting traffic for security association encapsulation are identified only by network and transport layer addressing. This document extends traffic selectors to allow more generic definitions of interesting traffic.
"Framework for IPv4/IPv6 Multicast Translation", Stig Venaas, 2-Jul-09. ( bytes): This draft describes how IPv4/IPv6 multicast translation may be used in various scenarios and attempts to be a framework for possible solutions. This can be seen as a companion document to the draft "Framework for IPv4/IPv6 translation" by Baker et al. When considering scenarios and solutions for unicast translation, one should also see how they may be extended to provide multicast translation.
"Enhancing Mobile IPv6 Route Optimization Mode with Secure Social Dimension", Wassim Haddad, 13-Jul-09. ( bytes): This memo describes an enhancement to Mobile IPv6 route optimization mode which is derived from introducing a social dimension within the home network.
"Inter-technology handover in PMIPv6 domain", Teemu Savolainen, Domagoj Premec, 2-Jul-09. ( bytes): Proxy Mobile IPv6 [RFC5213] is a network based mobility management protocol which provides IP mobility service to a host in a way which is transparent to the host itself. This document analyses the scenarios in which a multi-interfaced Mobile Node roams in a Proxy Mobile IPv6 domain which consists of access networks that are of different types. In order to support session continuity as the Mobile Node moves between access networks within the PMIP6 domain, the Mobile Node either needs to use host based Mobile IP or be enhanced with various capabilities described in this document.
"Requirements for Transporting User to User Call Control Information in SIP for ISDN Interworking", Alan Johnston, Joanne McMillen, 2-Jul-09. ( bytes): Several approaches to transporting the ITU-T Q.931 User to User Information Element (UU IE) data in SIP have been proposed. As networks move to SIP it is important that applications requiring this data can continue to function in SIP networks as well as the ability to interwork with this ISDN service for end-to-end transparency. This document discusses requirements and approaches. This extension will also be used for native SIP endpoints implementing similar services and interworking with ISDN services. Example use cases include an exchange between two user agents, retargeting by a proxy, and redirection. An example application is an Automatic Call Distributor (ACD) in a contact center.
"Multicast in MPLS/BGP IP VPN Configuration BGP Extended Communities", Mark Fine, Ray Qiu, 2-Jul-09. ( bytes): This document defines new BGP extended communities for exchanging Multicast in MPLS/BGP IP VPN configuration.
"SEAL with Reliability Extensions (SEAL-RE)", Fred Templin, 6-Jul-09. ( bytes): The Subnetwork Encapsulation and Adaptation Layer (SEAL) includes two basic modes of operation known as "SEAL with Fragmentation Sensing (SEAL-FS)" and "SEAL with Traffic Engineering (SEAL-TE)". This document specifies an additional mode known as "SEAL with Reliability Extensions (SEAL-RE)".
"Negotiating IPv6 Encapsulating Security Payload (ESP) Security Association (SA) with Cryptographically Generated Addresses (CGA)", Dong Zhang, Sean Shen, 2-Jul-09. ( bytes): This memo describes an approach to negotiate ESP SA when both sides are using CGAs as IP address. The solution provides as an alternate solution of IKE when CGAs are available. One round of message exchanges is described in order to take place of the initial exchanges of IKEv2 or the phase 1 exchange of IKE. A new IPv6 extension header, CGA extension header, is described in order to carry CGA related payloads.
"Return Path Specified LSP Ping", Mach Chen, Xinchun Guo, Wei Cao, So Ning, Frederic JOUNAY, 2-Jul-09. ( bytes): This document defines extensions to LSP Ping [RFC 4379] to enable the return path(s) of an echo reply message, so that it can be specified when sending an echo request message to perform LSP failure detection, and the echo reply message is extended to detect the return path(s). This capability could improve the reliability of echo reply and allows failure detection of a Bidirectional LSP or two unidirectional LSPs being performed by one message, resulting in operational saving.
"Identity-Based Encryption (IBE) Cipher Suites for Transport Layer Security (TLS)", Min Huang, 3-Jul-09. ( bytes): This document describes a new key exchange method, Identity-Based Encryption (IBE) for the Transport Layer Security (TLS) protocol. This memo specifies an alternative method for transmitting premaster secret securely between the client and server in a TLS handshake process. Some new cipher suites are thus introduced into TLS protocol.
"Requirements for PCE Applied in OTN", Fei Zhang, Feng Gao, Yuanlin Bao, 3-Jul-09. ( bytes): This document describes specific requirements for applying Path Computation Element (PCE) in Optical Transport Networks (OTN). Lightpath provisioning in OTN needs the pre-consideration of the Optical Data Unit (ODUk) cross connection because of the additional optical impairments constraints on the Optical Channel (OCh) lightpath available for use.
"Performance evaluation of termination in CL-algorithm", Daisuke Satoh, Harutaka Ueno, Michael Menth, 3-Jul-09. ( bytes): Pre-congestion notification (PCN) gives information to support admission control and flow termination in order to protect the quality of service (QoS) of inelastic flows. [I-D.taylor-cl-edge- behaviour] describes one boundary node behaviours for three-state measurement-based load control, known informally as CL [I-D.briscoe- tsvwg-cl-phb]. In [I-D.taylor-cl-edge-behaviour], flow termination is required if excess-traffic-marked packets were observed and the end of one measurement period MUST be the beginning of the next one, independently of current flow conditions. According to this termination, PCN-flows in some ingress-egress (IE) pairs may be terminated during measurement period of other IE pairs unless round- trip times (RTT) of all the IE pairs are the same. We illustrate that this can lead to over-termination. Our simulation confirms that accuracy of termination is improved when no PCN-flows in some IE pairs are terminated during measurement period of other IE pairs.
"Multiple Preemption Priority Policy Element for RSVP", Francois Le Faucheur, Arun Kudur, Ashok Narayanan, 3-Jul-09. ( bytes): RSVP Extensions are being defined allowing an endpoint to signal alternate "bandwidths" of interest in case the preferred bandwidth is not available and allowing the RSVP routers to collectively establish the reservation with the highest currently achievable bandwidth among the signaled set. This can be used to achieve efficient dynamic endpoint codec adjustment. The present document presents a complementary set of extensions, allowing the dynamic bandwidth selection to reflect a different reservation priority for each of the multiple "bandwidth" associated with a reservation.
"Multihoming extensions for Proxy Mobile IPv6", Carlos Bernardos, Telemaco Melia, Pierrick Seite, 3-Jul-09. ( bytes): 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. PMIPv6 also provides limited multi- homing support to multi-mode mobile devices. Recently Netext WG is being chartered to work on optimizations for PMIPv6. While multi- homing item has been proposed to be part of the approved charter, discussions showed there are still many controversial issues to be addressed (i.e. the no-host modification theorem). This document, leveraging parallel activities in the MIF WG, explores solutions for the multi-homing use case aiming at helping Netext community where possible.
"BT Requirements for MPLS-TP features", Ben Niven-Jenkins, Simon Fiddian, 3-Jul-09. ( bytes): This document outlines BT's requirements for MPLS-TP features based on our current thinking for how we may utilise functionality being defined as part of the MPLS-TP standardisation effort within our existing deployed MPLS networks. This document is not intended to describe all future requirements for MPLS-TP features, only for those features that we have a currently defined requirement for today and which we would like to see priority be given to them when specifying and standardising MPLS-TP within IETF. These features are required in order to enable us to enhance live, revenue generating services.
"URN Namespace for National Emergency Number Association (NENA)", Brian Rosen, 3-Jul-09. ( bytes): This document describes the Namespace Identifier (NID) for Uniform Resource Namespace (URN) resources published by National Emergency Number Association (NENA). NENA defines and manages resources that utilize this URN name model. Management activities for these and other resource types are provided by the National Emergency Number Association (NENA) Registry System (NRS). For the processes that NRS uses to manage this and other registries, see NENA ??-???
"Interior Location in PIDF-LO", Brian Rosen, 3-Jul-09. ( bytes): RFC5139 defines explicit tags for interior building location such as "BLD" (building), "UNIT", "ROOM". There is wide variation in how interior spaces are named, and the rigid element names provided do not allow accurate representation of interior spaces that don't use the element tags defined. This memo provides an alternative mechanism that provides an extensible flexible way to name spaces in any kind of addressible location.
"Prefix elements for Road and House Numbers in PIDF-LO", Brian Rosen, 3-Jul-09. ( bytes): RFC4119 updated by RFC5139 defines suffixes for street names and house numbers, but does not define prefixes. Both occur regularly in addresses and CAtypes are needed for them. This memo defines STP Street Prefix and HNP house number prefix CAtypes.
"LDPC-Staircase Forward Error Correction (FEC) Schemes for FECFRAME", Vincent Roca, Mathieu Cunche, Jerome Lacan, 3-Jul-09. ( bytes): This document describes two fully-specified FEC schemes for LDPC- Staircase codes that can be used to protect media streams along the lines defined by the FECFRAME framework. It inherits from RFC5170 the specifications of LDPC-Staircase codes. More specifically, these codes belong to the well-known class of "Low Density Parity Check" codes. They are large block FEC codes, in the sense of RFC3453, since they can efficiently deal with a large number of source symbols. They are also systematic codes, since the source symbols are part of the encoding symbols. Finally, they can perform close to ideal codes in many use-cases, since decoding is often possible after receiving a small number of encoding symbols in addition to the strict minimum, while keeping very high encoding and decoding throughputs with a software codec. LDPC-Staircase codes are therefore a good solution for the protection of high bitrate ADU flows, or when several mid-bitrate flows are protected together by 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. The first scheme describes the use of LDPC-Staircase codes in a FECFRAME instance in order to protect arbitrary ADU flows. The second scheme is similar to the first scheme, with the exception that it is for a single sequenced ADU flow.
"Design Considerations for Protocol Extensions", Brian Carpenter, Bernard Aboba, Stuart Cheshire, 3-Jul-09. ( bytes): This document discusses issues related to the extensibility of Internet protocols, with a focus on the architectural design considerations involved. Case study examples are included. It is intended to assist designers of both base protocols and extensions.
"Mobile Multicasting Support in Proxy Mobile IPv6", Seil Jeon, Younghan Kim, Jaehwoon Lee, 4-Jul-09. ( bytes): To support IP-based group communication such as mobile IPTV in mobile environment, IP multicasting is required. Two major constraints in mobile multicasting are the tunnel convergence problem and high handover latency. To reduce the constraints, several mobile multicasting schemes based on Mobile IP have been proposed. To provide efficient mobile multicast service related to two problems, we present a multicasting architecture and fast handover scheme for Proxy Mobile IPv6 (PMIPv6).
"Internationalized Domain Names Registration and Administration Guideline for European languages using Cyrillic", Sergey Sharikov, Desiree Miloshevic, John Klensin, 4-Jul-09. ( bytes): This document is a guideline for Registries and Registrars on registering internationalized domain names (IDNs) based on (in alphabetical order) Bosnian, Bulgarian, Byelorussian, Macedonian, Montenegrin, Russian, Serbian, and Ukrainian languages in a DNS zone. For completeness of the "European" languages, it also discusses the additional characters needed for Moldovan and Kildin Sami. It describes appropriate characters for registration and variant considerations for characters from Greek and Latin scripts with similar appearances and/or derivations.
"Constrained-Energy Lapped Transform (CELT) Codec", Jean-Marc Valin, Timothy Terriberry, Gregory Maxwell, Christopher Montgomery, 13-Jul-09. ( bytes): CELT [celt-website] is an open-source voice codec suitable for use in very low delay Voice over IP (VoIP) type applications. This document describes the encoding and decoding process.
"The EAP-WAI Authentication Protocol", Yang Shi, Li Li, Zibin Cai, 4-Jul-09. ( bytes): The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. The WLAN Authentication and Privacy Infrastructure (WAPI) provides the protection to the WLAN link-level security, and support the mutual authentication between the Authentication Supplicant Entity (ASUE) and the Authenticator Entity(AE). This document defines EAP-WAI, which enable the WAPI infrastructure to reuse the AAA architecture.
"The RADIUS-Diameter Gateway (RADIA) Application", Glen Zorn, Lionel Morand, 5-Jul-09. ( bytes): 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.
"Review of NAT Control Protocols", Frank Brockners, Cisco Systems, Shashank Vikram, Pallavi Mishra, 5-Jul-09. ( bytes): This document reviews NAT control capabilities of a set of protocols and evaluates their applicability to per endpoint control of a Large Scale NAT device.
"3GPP MN-AR interface", Telemaco Melia, Carlos Bernardos, Juan Zuniga, 5-Jul-09. ( bytes): This ID documents the interface between the Mobile Node and the Mobility Access Gateway in the context of 3GPP Evolved Packet Core networks. The main goal is to support the Netext working group in the discussions on the MN to AR interface showing how RFC 5213 has been deployed by other SDOs. This document has been inspired by considerations expressed in [I-D.gundavelli-netext-extensions-motivation].
"Multihoming extensions for Proxy Mobile IPv6", Telemaco Melia, Bruno Mongazon-Cazavet, 5-Jul-09. ( bytes): This document provides extensions to Proxy Mobile IPv6 in order to support multihomed mobile nodes (MN). These extensions are intended to permit such mobile nodes to send and receive IP packets on multiple interfaces in a simultaneous and possibly discriminated manner when attached to a PMIPv6 domain. A typical usage of these extensions is to perform downlink flow discrimination through multiple interfaces based on filtering rules (i.e. dedicate one MN interface to VOIP traffic and another MN interface to HTTP traffic). The proposed extensions to PMIPv6 attempt to increment in a backward compatible manner the current PMIPv6 specification. In addition these extensions use, when possible, existing specifications related to multihoming support at IETF and conform to the problem statement of Netext Working Group.
"Distribution of diverse BGP paths.", Robert Raszuk, Keyur Patel, Isidor Kouvelas, Rex Fernando, Danny McPherson, 5-Jul-09. ( bytes): The BGP4 protocol specifies the selection and propagation of a single best path for each prefix. As defined today BGP has no mechanisms to distribute paths other then best path between it's 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. It also compares existing solutions and proposed ideas that enable distribution of more paths than just the best path. This proposal does not specify any changes to the BGP protocol definition. It does not require upgrades to provider edge or core routers nor does it need network wide upgrades. The authors believe that the GROW WG would be the best place for this work.
"The Diameter Document Set", Glen Zorn, 5-Jul-09. ( bytes): This note contains a brief description of the current Diameter document set. Although the document included are all published RFCs, not all are products of the IETF.
"IP Fast Reroute Using Tunnel-AT", Mingwei Xu, Lingtao Pan, Qing Li, 5-Jul-09. ( bytes): This draft decribes Tunnel-AT mechanism that improves the Tunnel IP fast re-route mechanism. Tunnel-AT provides 100% node protection coverage in a symmetric biconnected network at a computational cost of less than one full SPT calculation.
"DNSSEC Policy & Practice Statement Framework", Fredrik Ljunggren, Anne-Marie Eklund-Lowinder, 5-Jul-09. ( bytes): This document presents a framework to assist writers of DNSSEC policy and practice statements such as registry managers on both TLD and secondary level, who have deployed DNSSEC. DNSSEC is a set of security extensions to the DNS that allows validating DNS answers by to establishing a 'chains of trust' from known public keys to the data being validated. The aim of this framework is to describe an overall policy for serving secured DNS data and key management. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) needs to be covered in a DNSSEC policy definition and practice statement.
"STUN/TURN using PHP in Despair", Klaus Hartke, Carsten Bormann, 5-Jul-09. ( bytes): NAT (Network Address Translator) Traversal may require TURN (Traversal Using Relays around NAT) functionality in certain cases that are not unlikely to occur. There is little incentive to deploy TURN servers, except by those who need them -- who may not be in a position to deploy a new protocol on an Internet-connected node, in particular not one with deployment requirements as high as those of TURN. "STUN/TURN using PHP in Despair" is a highly deployable protocol for obtaining TURN-like functionality, while also providing the most important function of STUN.
"UTF-8 POP3 Scenarios", Joseph Yee, 5-Jul-09. ( bytes): This document presents client scenarios in different combinations of Post Office Protocol v3 (POP3) servers and clients (UTF-8, ASCII only). Technical details are also documented, potential as test case reference.
"Global HA to HA Protocol Specification", Ryuji Wakikawa, Zhenkai Zhu, Lixia Zhang, 13-Jul-09. ( bytes): This document presents a revised version of the global HAHA protocol specification. This version clarified several issues that were vague in the original specification. All the protocol specifications for the global HAHA are now added on top of the Home Agent Reliability protocol.
"Traffic safety applications requirements", Georgios Karagiannis, Ryuji Wakikawa, John Kenney, 5-Jul-09. ( bytes): This document describes a number of communication performance requirements that are imposed by traffic safety applications on a network layer. These traffic safety applications and requirements have been derived during the VSC (Vehicular Safety Communications) and VSC-A (VSC-Applications) projects. The goal of this document is to stimulate the discussion on judging whether these performance requirements could or could not be supported (currently and in the future) by IP based network solutions.
"Extensions to View-based Access Control Model for use with RADIUS", Kaushik Narayan, David Nelson, 5-Jul-09. ( bytes): This memo describes a backward compatible extension to the View-based Access Control Model for SNMPv3 for use with RADIUS and other AAA services to provide authorization of MIB database access. This extension is intended to be used in conjunction with secure SNMP Transport Models that facilitate RADIUS authentication, such as the Secure Shell Transport Model.
"NFSv4 Multi-Domain Access", Andy Adamson, Kevin Coffman, 3-Jul-09. ( bytes): The NFS Version 4 [NFSv40] protocol enables the construction of a distributed file system which can join NFSv4.0 or NFSv4.1 [NFSv41] servers, which potentially use separate name translation services and separate security services, into a common name space. The protocol supports multiple authentication methods and does not restrict how users are represented or authenticated. As such a user's view of the name space may be limited by the authentication and authorization privileges they have on the different file servers in the name space. This document discusses authentication and authorization management and proposes two name service attributes that are used for NFSv4 name and security principal translations to enable users to traverse and access files in a secure, multi-domain NFS Version 4 name space.
"Problem Statement for DHCP Relay Agent", Lu Huang, Hui Deng, Pavan Kurapati, Bharat Joshi, 5-Jul-09. ( bytes): RFC 3046 allows only the first Relay Agent to append Relay Agent Information option. In some networks, Layer 2 Relay Agents and Layer 3 Relay Agents are deployed but only Layer 2 Relay Agent appends the Relay Agent Information option. This document describes two pretty common network scenarios that uses Layer 2 and Layer 3 Relay Agents and their unique requirements where either DHCP server or Relay Agent need more information to handle DHCP messages.
"Distributed Autonomous Depth-first Routing Protocol in LLN", Tadashige Iwao, 5-Jul-09. ( bytes): This document is a proposal of the distributed autonomous depth-first routing (DADR) protocol which is quite different from conventional algorithms such as AODV and OLSR. It proposes a traversable algorithm which can determine a direct path between the global source and the global destination in a low power and lossy network (LLN). We propose the DADR algorithm whose characteristics work well in LLNs with more than 10^4 nodes. This algorithm selects a direct path between the global source and the global destination based on a routing-cost- function which identifies path-candidates with good communication quality between each pair of nodes on the path. This protocol does not need to configure the equipment such as setting IP addresses, and thisresults in saving cost and time in deploying, establishing and operating a large scale network. Iwao, et al. Expires January 2, 2010 [page 2] Internet-Draft DADR Protocol July 2009
"Session Initiation Protocol (SIP) Implicit Registrations", Hadriel Kaplan, 5-Jul-09. ( bytes): This document identifies several approaches to provide reachability information for a domain or multiple AoR's using a single SIP REGISTER method transaction, in ways not originally envisioned or documented by RFC 3261.
"Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control", Fatai Zhang, Guoying Zhang, Yi Lin, Yunbin Xu, 13-Jul-09. ( bytes): Recent revisions of ITU-T Recommendation G.709 have introduced new features for Optical Transport Networks (OTN) ODU0, ODU4, ODU2e, ODU3e1, ODU3e2 and ODUflex. Several recent documents have proposed ways to modify GMPLS signaling protocols to support the new OTN features. Expires January 2010 [page 1] draft-zhang-ccamp-gmpls-evolving-g709-01.txt July 2009 It is important that a single solution is developed for use in GMPLS signaling and routing protocols. This solution must address all of the new features, must be acceptable to all equipment vendors, and must be extensible for the evolving OTN. This document describes the extensions to the Generalized Multi- Protocol Label Switching (GMPLS) signaling to control the evolving Optical Transport Networks (OTN) with new features including ODU0, ODU4, ODU2e, ODU3e1, ODU3e2 and ODUflex.
"Femtocell synchronization analysis", Lei Xie, Michel Ouellette, 5-Jul-09. ( bytes): This document analyses the aspect of providing synchronization to cellular femtocells. It discusses some challenges that should be considered during the development of TICTOC application requirements and network architecture.
"6LowApp: Problem Statement for 6LoWPAN and LLN Application Protocols", Carsten Bormann, Don Sturek, Zach Shelby, 13-Jul-09. ( bytes): The 6LoWPAN and ROLL WGs are laying the groundwork to make the Wireless Embedded Internet a reality, but what application protocols will we use? Request-response protocols like HTTP are a poor fit to a communication model with battery-operated, mostly sleeping nodes. In addition, the usual data formats (both headers and body) are perceived to be too chatty for the 50-60 byte payloads possible in LoWPANs and to require too much code for the 8-bit and 16-bit processors dominating the Internet of Things. Still, it would be a mistake to start a new silo of application protocols that do not benefit from existing application area Internet experience. This document provides a problem statement for possible work on of application protocols in 6LoWPAN networks or, more generally, in low- power, lossy networks, as well as some considerations for required related work.
"Synchronized Playback in Rapid Acquisition of Multicast Sessions", Peilin Yang, Ye-Kui Wang, 5-Jul-09. ( bytes): When watching the same IPTV channel, different TV sets may not render the same picture and the associated audio at the same moment. This variation of end-to-end delay between users is referred to as inter-user playback delay. Unicast based rapid acquisition of multicast RTP sessions (RAMS) as specified in [I-D.ietf-avt-rapid- acquisition-for-rtp] is an important technique in achieving fast channel switching in IPTV applications. In addition, RAMS also significantly relaxes the requirement of relatively short random access point period in encoding of video streams in multicast applications, thus allowing significantly improved compression efficiency. However, on the other hand, the use of RAMS increases inter-user playback delay. This document specifies a mechanism to help reduce inter-user playback delay in RAMS.
"Indication of Client Failure in MPLS-TP", Jia He, Han Li, 6-Jul-09. ( bytes): This document describes a Multi-Protocol Label Switching Transport Profile (MPLS-TP) Operations, Administration and Maintenance (OAM) tool to propagate a client failure indication across an MPLS-TP network in case the propagation of failure status in the client layer is not supported.
"Introduction of MTN", Wu Juan, Long Bin, Pang Tao, Huang Hai, 6-Jul-09. ( bytes): This draft briefly introduces MTN, the Median Telecom Network built by China Telecom to support streaming and file download services with peer to peer technologies.
"Improved Rapid Acquisition of Multicast Sessions", Ye-Kui Wang, Jinliang Dai, Jiangping Feng, 6-Jul-09. ( bytes): This document describes an improvement to unicast based rapid acquisition of multicast RTP sessions (RAMS) described in [I- D.ietf-avt-rapid-acquisition-for-rtp]. The improved method allows a receiver to simultaneously request a unicast burst stream and join the multicast group, and then select one of the two streams to be first processed.
"Geodetic-Civic Address Translation Protocol", Robins George, Qian Sun, 13-Jul-09. ( bytes): This document explains how to map a geodetic datum to a civic address and vice versa. Server accepts an HTTP POST with one form of user specified location addresses and return whatever other form it has.
"Considerations of address selection policy conflicts", Arifumi Matsumoto, Tomohiro Fujisaki, Ruri Hiromi, 6-Jul-09. ( bytes): This document tries to speculate how policy conflicts happen, and how to address the conflicts. After classifying address selection policies, we proposed how to solve the merging conflicting policies for each classes.
"DNS Extensions to Support IPv4 and IPv6", Lianyuan Li, Zhenqiang Li, Xiaodong Duan, 13-Jul-09. ( bytes): In the DNS architecture, two kinds of record types for maintaining host's IP addresses are supported: one is A type which records IPv4 and AAAA for IPv6 addresses. This document defines a new TYPE, which is mainly used in queries in order to get both IPv4 and IPv6 addresses. The main advantage is to avoid sending several requests in order to resolve the location of a given resource. A single request may be sufficient. The proposed solution does not require the definition of any new record type.
"Preserving the reachability of LISP ETRs in case of failures", Olivier Bonaventure, Pierre Francois, Damien Saucez, 6-Jul-09. ( bytes): Maintaining reachability of an EID prefix despite the failures of ETRs is a key concern in the LISP architecture. In this document, we first analyse this problem in comparison with traditional routing protocols. Then, we explain how Internet Service Providers could offer a service that preserves the reachability of the LISP ETRs of their customers in case of failures.
"Interaction of dynamic firewall control protocols and SIP", Sebastian Kiesel, 6-Jul-09. ( bytes): SIP-based multimedia applications dynamically negotiate parameters for the related media streams, such as UDP port numbers. Therefore, firewalls that want to inspect these streams have to interact with the session signaling. Several architectures and protocols have been developed for the dynamic control of firewalls on the media path, e. g., MIDCOM, SIMCO, and the NSIS NAT/FW NSLP. This document investigates problems with the interaction of standard SIP (as of RFC 3261) and these firewall control protocols, especially with respect to error handling. It will be pointed out how existing SIP extensions can be used for improving the interaction, and which additional mechanisms need to be specified. While the actual specification of such additional mechanisms is out of the scope of this document, it solicits feedback and discussion.
"A Survey on Research on the Application-Layer Traffic Optimization (ALTO) Problem", Ivica Rimac, Volker Hilt, Marco Tomsu, Vijay Gurbani, Enrico Marocco, 6-Jul-09. ( bytes): A significant part of the Internet traffic today is generated by peer-to-peer (P2P) applications used traditionally for file-sharing, and more recently for real-time communications and live media streaming. Such applications discover a route to each other through an overlay network with little knowledge of the underlying network topology. As a result, they may choose peers based on information deduced from empirical measurements, which can lead to suboptimal choices. We refer to this as the Application Layer Traffic Optimization (ALTO) problem. In this draft we present a survey of existing literature on discovering topology characteristics.
"HIP and User Authentication", Samu Varjonen, 6-Jul-09. ( bytes): This document specifies how to use Extensible Authentication Protocol (EAP) in HIP to incorporate user authentication in the IPsec tunnel creation. This document describes two new parameters for transporting EAP messages inside HIP control packets. The main focus of this document is to describe how to use these parameters to combine needed EAP negotiation in order to authenticate the user. This document also describes how on-path middleboxes can take part in the negotiation as authenticators.
"Datagram Transport Layer Security Heartbeat Extension", Robin Seggelmann, Michael Tuexen, Michael Williams, 6-Jul-09. ( bytes): This document describes the Heartbeat Extension for the Datagram Transport Layer Security (DTLS) protocol. The Heartbeat Extension provides a new protocol for DTLS allowing the usage of keep-alive functionality without performing a renegotiation.
"Local domain name discovery", Wenson Wu, 6-Jul-09. ( bytes): As described in [RFC5296], the local domain name can be learnt by the peer though the ERP exchange or via lower-layer announcement. However lower-layer announcement for local domain name is not specified. This document specifies one local domain name discovery mechanism based on DHCP extension.
"1588v2 modules of time synchronization with frequency layer support", Fei Su, Li He, 6-Jul-09. ( bytes): This I-D introduce a set of functional components of 1588v2 time/ phase synchronization system with frequency layer support and some optimized schemes for time synchronization devices based on PTP.
"DHCP Option for Local Domain Name Discovery", Yungui Wang, Wenson Wu, 6-Jul-09. ( bytes): This document defines the local domain name option for DHCPv4 and DHCPv6. This option is used by the Peer (DHCP client) to request local domain name described in [RFC5296] which is used to derive the local root key, e.g., DSRK defined in [RFC5295].
"GMPLS RSVP-TE Extensions for OTN and SONET/SDH OAM Configuration", Andras Kern, Attila Takacs, 6-Jul-09. ( bytes): GMPLS has been extended to support connection establishment in both SONET/SDH [RFC4606] and OTN [RFC4328] networks. These documents do not support the configuration of the supervision functions. Both SONET/SDH and OTN implement supervision functions to qualify the transported signals. [GMPLS-OAM-FWK] defines a technology-agnostic framework for GMPLS to support the establishment and configuration of pro-active OAM monitoring of signalled connections. This document defines extensions to RSVP-TE for SONET/SDH and OTN OAM configuration.
"ALTO-FCP: Application Layer Traffic Optimization Feedback-Based Client Protocol", Zoran Despotovic, Wolfgang Kellerer, Spiros Spirou, Dirk Staehle, Maria Rodriguez, Ioanna Papafili, 6-Jul-09. ( bytes): In some networked applications, such as peer-to-peer file sharing, the same resource (e.g., a file or a server process) is available at several potential resource providers. Resource consumers typically try to select providers so that application performance is improved, establishing an overlay topology of direct logical links in the process. However, lack of reliable information about the underlying network can lead to poor choices and suboptimal application performance. In addition, resulting application traffic is largely oblivious to technical, economical, and political constraints at the network level, causing problems for network operators. This document describes a protocol that facilitates the exchange of information between an overlay and the underlying network. Such information can be used at each layer to make decisions that are not detrimental to the other layer or, ideally, are beneficial to both.
"Session Description Protocol (SDP) Connectivity Capability (CCAP) Attribute", Mohammed Boucadair, Hadriel Kaplan, 6-Jul-09. ( bytes): This memo proposes a mechanism which allows to carry multiple IP addresses, of different address families (e.g., IPv4, IPv6), in the same SDP offer/answer. The proposed attribute solves the backward compatibility problem which plagued ANAT, due to its syntax.
"IGMP and MLD Optimization for Mobile Hosts and Routers", Hitoshi Asaeda, 6-Jul-09. ( bytes): To notify neighboring multicast routers of their IP multicast group memberships, hosts must support IGMP and MLD protocols. This document describes the ways of IGMPv3 and MLDv2 protocol optimization for mobility. The optimization includes a query timer tuning and an explicit membership notification operation.
"The Session Initiation Protocol (SIP) P-Private-Network-Indication Private-Header (P-Header)", The Netherlands, Keith Drage, 6-Jul-09. ( bytes): This document specifies the SIP P-Private-Network-Indication P-header. The use of this private network indication extension is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport and usage of such information. A private network indication allows nodes in such a domain to treat private network traffic according to a different set of rules than the set applicable to public network traffic. The indication also distinguishes traffic from one private network from another private network.
"Virtual Network Management Information Model", Hideki Okita, Masahiro Yoshizawa, 6-Jul-09. ( bytes): Virtual switches on server virtualization platforms cause a problem in managing data center networks containing several hundred switches. Accordingly, a management information model for the network structure of data center networks containing virtual switches is proposed. The proposed model consists of a physical layer (which represents connections between physical switches) and a virtual layer (which represents connections between virtual switches). These layers also represent the association of the virtual switch with the corresponding physical switch. The model shortens the virtual LAN (VLAN) configuration time taken by operators of data center networks by a maximum of 35%. This result shows that the proposed model is effective in reducing the management time of data center networks containing virtual switches.
"Transport Layer Security-based Mobile IPv6 Security Framework for Mobile Node to Home Agent Communication", Jouni Korhonen, Basavaraj Patil, Hannes Tschofenig, 13-Jul-09. ( bytes): Mobile IPv6 signaling between the mobile node and 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 part of the IP stack and the IKE/IPsec part of the IP stack. Implementation and deployment concerns exist with such a security architecture. This document proposes an alternate security framework, which relies on Transport Layer Security for establishing keying material and other parameters required to protecting Mobile IPv6 signaling and data traffic between the mobile node and home agent.
"Threat to BGP Policies : limited-scope more specific prefix injection", Pierre Francois, Bruno Quoitin, 6-Jul-09. ( bytes): This draft describes potential threats to the respect of Internet routing policies by the routers of one ISP, that are due to a restricted propagation of more specific BGP prefixes by its neighboring domains.
"On the association of GMPLS Recovery LSPs", Lou Berger, 6-Jul-09. ( bytes): End-to-End and Segment Recovery are defined for GMPLS (Generalized Multi-Protocol Label Switching) controlled label switched paths (LSPs) in RFC 4872 and RFC 4873 respectively. Both definitions use the ASSOCIATION object to associate recovery LSPs with the LSP they are protecting. This document provides additional narrative on how such associations are to be identified. This document does not define any new procedures or mechanisms and is strictly informative in nature. It may not be obvious to the informed reader why this document is necessary.
"Line identification in IPv6 Neighbour Solicitation messages", Li Hongyu, Li Yizhou, 6-Jul-09. ( bytes): Duplicate address detection of link-local address in DSL access network is a mandatory part for IPv6 netwrok. In N:1 VLAN model, simple DAD does not work due to the user isolation. NAS should perform a DAD proxy function for the task. This documents proposes to include the line identification information in neighbour solicitation and neighbour advertisement messages to help DAD proxy to perform the function.
"Source Address Validation via Shared Key", Li Hongyu, Li Yizhou, 6-Jul-09. ( bytes): This document describes a mechanism to provide source address validation for IPv6 networks using a shared key (Skey) signature approach. The basic idea is that a device generates a signature using a shared key and its IP address and then the signature is sent to a validating device for source address validation. The proposed mechanism is intended to complement ingress filtering techniques with a finer granularity on the control of the source addresses used.
"IPPM standard compliance testing", Ruediger Geib, Reza Fardid, 6-Jul-09. ( bytes): This document specifies tests to determine if multiple, independent, and interoperable implementations of a metrics specification document are at hand so that the metrics specification can be advanced to an Internet standard. Results of different IPPM implementations can be compared if they measure under the same underlying network conditions. Results are compared using state of the art statistical methods.
"Reverse DNS in IPv6 for Internet Service Providers", Lee Howard, Alain Durand, 6-Jul-09. ( bytes): In IPv4, Internet Service Providers (ISPs) commonly provide IN- ADDR.ARPA. information by prepopulating the zone with one PTR record for every available address. This practice does not scale in IPv6. This document analyses different approaches to managing the ip6.arpa zone for broadband customers. .
"Prefix NAT: Host based IPv6 translation", Bill Huang, Hui Deng, 13-Jul-09. ( bytes): IPv4 migrating to IPv6 is a network layer issue, it is not easy to mandate the application in the host to change in the first place, the network layer may have to have a solution to support conventional IPv4 appliations in the IPv6 only network, especially when there are multiple applications need to be supported. This document describes a mechanism for providing a host-based IPv6 translation technology which could guarantee IPv4 application backward compatibility. A new well known IPv6 prefix is used for the destination address translation and network assigned prefix will be used for source address translation.
"The Internet Assigned Number Authority (IANA) Application Configurations Access Protocol (ACAP) Vendor Subtrees Registry", Dave Cridland, 6-Jul-09. ( bytes): The original ACAP specification included a vendor registry now used in other protocols. This document updates the description of this registry, removing the need for a direct normative reference to ACAP, and removing ambiguity.
"MPLS-TP Ring Protection", Stewart Bryant, Yaacov Weingarten, Nurit Sprecher, 6-Jul-09. ( bytes): This document describes mechanisms to address the requirements for protection of ring topologies for Multi-Protocol Label Switching Transport Profile (MPLS-TP) Label Switched Paths (LSP) and Pseudowires (PW) on multiple layers. Ring topologies offer the possibility of reducing the OAM overhead while providing a simplified protection mechanism. The document analyzes two basic ring protection schemes and explains how ring protection can be viewed as an application of linear protection.
"Analysis and Scenarios of generating the Multi-Path Routings", Jungsoo Park, HongJong Jeong, Dongkyun Kim, Hyoung-Jun Kim, 6-Jul-09. ( bytes): This document discusses the use of multiple interfaces of Mobile Ad hoc NETworks (MANETs) nodes and multiple path MANET routings protocols with respect to traditional, single network interface based ones. It then describes the design principles and methods of multiple path routing over MANET nodes with multiple interfaces.
"Analysis of paths selection modes for Add-Paths", Place Barbe, Pierre Francois, 6-Jul-09. ( bytes): This document is aimed at discussing the various alternatives for the selection of the paths that are to be advertised with add-paths. The goal is to summarize the properties of those selection methods depending on which application they are used for.
"The isup-oli SIP URI Parameter", John Haluska, 6-Jul-09. ( bytes): A SIP URI parameter "isup-oli" is being used for interworking the ISUP Originating Line Information parameter or equivalent PSTN signaling information with SIP. This parameter has been also been discussed in various documentation, but nowhere is it formally documented. This document formally documents the usage, syntax, and semantics of this parameter, providing a reference for discussion of this parameter. It does not seek to achieve standardization of this parameter.
"A Topology Plug-in for REsource LOcation And Discovery", Jouni Maenpaa, Ashwin Swaminathan, Saumitra Das, Gonzalo Camarillo, Jani Hautakorpi, 6-Jul-09. ( bytes): REsource LOcation And Discovery (RELOAD) is a peer-to-peer signaling protocol that can be used to maintain an overlay network, and to store data in and retrieve data from the overlay. This document defines a new topology plug-in for RELOAD that is more appropriate for real world large scale overlays. This topology plug-in implements three important functionalities that allow RELOAD to operate under real world constraints. First, it includes a load balancing algorithm that specifies efficient allocation of load to different nodes in the network. Second, the document describes robust techniques for stabilization of fingers and successors and specifies self tuning mechanisms that allow dynamic and automatic adjustment of parameters needed for these advanced techniques in the topology plug-in. Finally, it specifies a locality aware finger selection algorithm that reduces average lookup latency.
"Recommendations for the Remediation of Bots in Large ISP Networks", Jason Livingood, Nirmal Mody, Comcast Communications, 6-Jul-09. ( bytes): This document contains recommendations on how large Internet Service Providers (ISPs) can manage the effects of large numbers of bot infected computers used by their subscribers via various remediation techniques. At the time that this document was published, computers infected by bots and the users of those computers comprise a substantial number of users for large ISPs. Those Internet users are exposed to risks such as loss of personal data, increased susceptibility to online fraud and/or phishing, and becoming an inadvertent participant in or component of an online crime, spam, and/or phishing network. Mitigating the effects of and remediating the installations of bots affecting large numbers of Internet users will make it more difficult for bot nets to operate and could reduce the level of online crime on the Internet in general and/or on a particular ISP's network.
"The Diameter Precongestion Notification (PCN) Data Collection Application", Fortune Huang, Tom Taylor, Glen Zorn, 12-Jul-09. ( bytes): Pre-Congestion notification (PCN) is a technique for maintaining QoS for inelastic flows in a DIFFServ domain. The PCN architecture requires that egress nodes send reports of congestion-related events (flow admission state change, excess flow) reliably to a policy decision point. The ITU-T is working on a variant of this architecture which places the policy decision point in a central node rather than ingress or egress nodes of the network. In this case the policy decision point must request and obtain certain data from an ingress node when it receives an excess flow report affecting that ingress node. This memo defines a Diameter application to support egress node reporting and data collection from the ingress node. The nature of the data flows requires the policy decision point to act both as server and as client. Hence this memo draws upon the precedent established by the Rw application (RFC 5431 and ITU-T Recommendation Q.3303.3).
"VALID", Philip Hoyer, Tim Moses, Mingliang Pei, Salah Machani, 6-Jul-09. ( bytes): This document describes a Web-service interface standard for an authentication-data validation service that supports risk-based, multi-factor authentication.This standard enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure.
"GMPLS Synchronized Signaling for Optical Lightpath Setup", Giovanni Martinelli, Andrea Zanardi, 13-Jul-09. ( bytes): In Generalized Multi-Protocol Label Switching (GMPLS) several extension are proposed to cope with constrain provide Wavelength Switched Optical Networks (WSON). One of the technology constrain related to Dense Wavelength Division Multiplexing (DWDM) systems is the bi-directionality of the lightpath. This memo provides some consideration about how extending the signaling phase to cope with the bi-directional requirements. The procedure is independent from the wavelength continuity constrain in both direction.
"Re-INVITE Handling in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, Christer Holmberg, Gao yang, 6-Jul-09. ( bytes): In this document, we clarify the handling of re-INVITEs in SIP. We clarify in which situations a UAS (User Agent Server) should generate a success response and in which situations a UAS should generate an error response to a re-INVITE. Additionally, we clarify issues related to target refresh requests.
"Dynamic Port Range Re-Assignments for Address Sharing", Andreas Ripke, Juergen Quittek, Marcus Brunner, 6-Jul-09. ( bytes): This document proposes an extension regarding dynamic port range re- assignment to an IPv4 address sharing framework (SHARA), to overcome IPv4 address shortage. It allows an entity which is responsible for address and port distribution to apply a more flexible handling of already assigned port ranges. An adjustment of number of ports per customer according to the current consumption pattern is possible with this enhancement.
"Host-based Translation Problem Statement", Gang Chen, Bo Zhou, 6-Jul-09. ( bytes): When operators start to customize user terminals, host-based IPv6 translation will be feasible. Host-based translation should overcome single-point failure problems and support various connections between two IP families networks simultaneously. In addition, legacy IPv4 applications should not be modified. This document will discuss host-based translation applicable scenarios and corresponding issues.
"An Incremental Deployable Mapping Service for Scalable Routing Architecture", Gang Chen, Hui Deng, Bo Zhou, Mingwei Xu, Dong Huo, Yu Cao, 12-Jul-09. ( bytes): This document describes a mechanism of providing mapping service for LISP-like architecture. The mapping service comprises of EID Router (ER) mechanism and supplementary DHT Mapping Overlay (MO), in which ER mechanism is for reducing forwarding entries in routers while driving the packets to the destination through tunnels, and the DHT MO serves as a supplement that provides specific mappings to reduce the number of tunnels. The mechanism is flexibly deployable for ISPs since it costs little and is easy to progress.
"Connection Identifier for Proxy Mobile IPv6", Gyorgy Wolfner, Jouni Korhonen, 6-Jul-09. ( bytes): This document describes a Connection Identifier mobility option for Proxy Mobile IPv6. The new mobility option can be used to uniquely identify multiple mobility sessions to the same selected service, for example, in the Evolved Packet System scope.
"Dual-stack Lite Mobility Solutions", Behcet Sarikaya, Frank Xia, 6-Jul-09. ( bytes): Two solutions are presented to show how to use Dual-Stack Lite transition technique in mobile networks: one for Proxy Mobile IPv6 and the other for Dual-Stack Mobile IPv6. Proxy Mobile IPv6 allows IPv4 nodes to receive mobility services using an IPv4 home address. Mobile node can have IPv4 only operation by sending IPv4 datagrams which are encapsulated by the Mobile Access Gateway (MAG) at the DS- lite home router and and tunneled to Local Mobility Anchor (LMA) which is also DS-lite carrier-grade Network Address Translator (NAT). In case of client based mobility using DSMIPv6, mobile node is a dual-stack node and it can receive an IPv4 home address from the home agent which is co-located with DS-lite carrier-grade NAT. Mobile node (MN) encapsulates IPv4 datagrams in IPv6 which are decapsulated at the home agent (HA). Mobile network could be WiMAX network or 3GPP Long Term Evolution network.
"Proxy Mobile IPv6 Basic Multicast Support Solution", Suresh Krishnan, Behcet Sarikaya, Thomas Schmidt, 6-Jul-09. ( bytes): This document describes how multicast routing can be supported in Proxy Mobile IPv6 in a way similar to Mobile IPv6. The Mobile Access Gateway tunnels MLD messages from the mobile nodes to local mobility anchor. The Local Mobility Anchor joins the multicast group and starts forwarding the received multicast packets to the mobile access gateway. In case of a handover the tunnel end point changes but the operation remains anchored at the local mobility anchor.
"Disaggregated Media in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, Salvatore Loreto, 6-Jul-09. ( bytes): Disaggregated media refers to the ability for a user to create a multimedia session combining different media streams, coming from different devices under his or her control, so that they are treated by the far end of the session as a single media session. This document lists several use cases that involve disaggregated media in SIP. Additionally, this document analyzes what types of disaggregated media can be implemented using existing protocol mechanisms, and the pros and cons of using each of those mechanisms. Finally, this document describes scenarios that are not covered by current mechanisms and proposes new IETF work to cover them.
"Suite VPN-D: Cryptographic Algorithm Suite with 112-bit Security for IPSEC", David McGrew, Anthony Grieco, 6-Jul-09. ( bytes): This document defines a suite of cryptographic algorithms that target a 112-bit security level. Additionally, this document defines the use of these algorithms for use in IPSEC.
"Extranet in BGP Multicast VPN", Rahul Aggarwal, Yakhov Rekhter, Thomas Morin, Wim Henderickx, Praveen Muley, 6-Jul-09. ( bytes): This document describes clarifications 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.
"MPLS-TP BFD for Proactive CC-CV and RDI", Sami Boutros, Martin Vigoureux, Annamaria Fulignoli, 7-Jul-09. ( bytes): Several documents on BFD based OAM for MPLS-TP has been put forward and the dependencies between those drafts are not yet fully sorted out; this document is one of these drafts. It is published in now to make ideas, motivations and approaches available. However we expect the final BFD based solution for MPLS-TP will be a cooperation of the parties between the existing drafts and that the BFD based OAM solution for MPLS-TP will merge into an agreed set of drafts approved by the MEAD team. This document specifies the BFD extension and behaviour to meet the requirements for MPLS-TP proactive Continuity Check and Connectivity Verification functionality and the RDI functionality as defined in [3].
"Support for RSVP-TE in L3VPNs", Kenji Kumaki, Tomoki Murai, 6-Jul-09. ( bytes): It is highly desirable for VPN customers to be able to establish their MPLS TE LSPs in the context of a BGP/MPLS IP-VPN. In such a scenario, it is necessary that RSVP control messages, such as Path messages and Resv messages, are appropriately handled by the PE routers. This document defines new object types in SESSION, SENDER_TEMPLATE and FILTERSPEC object to establish a customer MPLS TE LSP in the context of BGP/IP-VPNs and describes a procedure of RSVP control messages including the new object types.
"VA-Based Softwire", Yong Cui, Peng Wu, Shengling Wang, Mingwei Xu, Jianping Wu, Xing Li, Lixia Zhang, Chris Metz, 6-Jul-09. ( bytes): The increasing deployment of IPv6 networks in both customer networks and ISP networks leads to two common traversing transition scenarios: in the first scenario, an IPv6-only backbone network needs to provide IP connectivity between IPv4 networks, we call it IPv4-over-IPv6 scenario; In the second scenario, IPv6 networks need to be interconnected over an IPv4 transit network, we call it IPv6-over- IPv4 scenario. In both scenarios, the ISP operating the transit network of one address family must offer transit services for attached client networks of the other address family. The Softwire WG has defined softwire mesh mechanism [RFC5565] for the two traversing scenarios. Softwire mesh uses automatic softwire tunnels employing multi-protocol BGP extensions for distributing E-IP routes, where both BGP peers and tunnels between PEs forms a full-mesh architecture. Inspired by the Virtual Aggregation approach [I-D.ietf-grow-va] to IPv4 routing scalability, in this draft we proposed a scalable mechanism for distributing E-IP routes over the transit network. Our solution can significantly reduce the forwarding information base (FIB) size at Address Family Border Routers (AFBRs) as well as the total amount of routing updates, and offers the ISP an easy way to manage the transit service.
"MANET Cryptographical Signature TLV Definition", Ulrich Herberg, Thomas Clausen, 27-Jul-09. ( bytes): This document describes a general and flexible TLV (type-length-value structure) for representing cryptographic signatures as well as timestamps, using the generalized MANET packet/message format [RFC5444]. It defines two Message TLVs and two Packet TLVs, for affixing a cryptographic signature and a timestamp to a packet and message, respectively.
"Requirements for Session Recording Protocol (SRP)", Rajnish Jain, Leon Portman, Vijay Gurbani, Hadriel Kaplan, Andrew Hutton, Ken Rehor, 6-Jul-09. ( bytes): Session recording is a critical requirement in many business communications environments such as call centers and financial trading floors. In some of these environments, all calls must be recorded for regulatory and compliance reasons. In others, calls may be recorded for quality control or business analytics. Recording is typically done by sending a copy of the media to the recording devices. This document specifies requirements for a protocol that will manage delivery of media from an end-point that originates media or that has access to it to a recording device. This protocol is being referred to as Session Recording Protocol and will most likely be based on SIP.
"Session Peering Provisioning Protocol", Jean-Francois Mule, Kenneth Cartwright, Debbie Guyton, Alexander Mayrhofer, 13-Jul-09. ( bytes): This document defines a protocol for provisioning session establishment data into Session Data Registries or SIP Service Provider data stores. The provisioned data may then be used by various network elements for session peering. This document focuses on the Session Peering Provisioning Protocol used by clients to provision registries. The document provides a set of guiding principles for the design of this protocol like extensibility and independent transport definitions, a basic data model that meets some of the requirements discussed in DRINKS and an early XML Schema Document.
"Proxy Mobile IPv6 Localized Routing", Paulo Loureiro, Marco Liebsch, 13-Jul-09. ( bytes): The IETF specified Proxy Mobile IPv6 as protocol for network-based mobility management. In Proxy Mobile IPv6, mobile nodes are attached to the network through Mobility Access Gateways and registered with a Local Mobility Anchor. Traffic from and to the mobile node traverses the mobile node's Local Mobility Anchor, irrespective of the location of the mobile node's corresponding communication endpoint. This document specifies a protocol extension to Proxy Mobile IPv6 which allows the set up and maintenance of an optimized routing path between two communicating mobile nodes' Mobility Access Gateways without traversing the mobile nodes' Local Mobility Anchor(s). The protocol component of a rendezvous control point ensures stable maintenance of routing states during handover in scenarios with multiple mobility anchors, where states for the two communication endpoints are distributed between these anchors.
"Host Identity Protocol (HIP) Multi-hop Routing Extension", Gonzalo Camarillo, Ari Keraenen, 6-Jul-09. ( bytes): This document specifies two extensions to HIP to implement multi-hop routing. The first extension allows a HIP packet to carry the list of hosts that forwarded it. The second extension allows implementing source routing in HIP. That is, a host sending a HIP packet can define a set of hosts that the HIP packet should traverse.
"SMTP Extension for Internationalized Email Address", Jiankang Yao, Wei MAO, 6-Jul-09. ( bytes): This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. Communication with systems that do not implement this specification is specified in another document. This document updates some syntaxes and rules defined in RFC 2821 and RFC 2822, and has some material updating RFC 4952.
"Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)", Ari Keraenen, Gonzalo Camarillo, 6-Jul-09. ( bytes): This document specifies the HIP BONE instance specification for RELOAD. It provides the details needed to build a RELOAD-based overlay that uses HIP.
"Pseudowire Status for Static Pseudowires", Luca Martini, George Swallow, Matthew Bocci, 13-Jul-09. ( bytes): This document specifies a mechanism to signal Pseudowire (PW) status messages using an PW associated channel (ACh). Such a mechanism is suitable for use where no PW dynamic control plane exits, known as static PWs, or where a Terminating Provider Edge (T-PE) needs to send a PW status message directly to a far end T-PE. The mechanism allows PW OAM message mapping and PW redundancy to operate on static PWs.
"A SIP Flight Data Recorder Extension", Victor Pascual, J. Janak, J Kuthan, Raphael Coeffic, 6-Jul-09. ( bytes): A major responsibility of Session Initiation Protocol (SIP) servers is to provide application-layer routing. SIP routing can be quite complex and lead to similarly complicated paths that SIP requests traverse on the way to their actual destinations. It is therefore important to be in position to troubleshoot errors that occur along a SIP path, inside and outside troubleshooters' administrative domains. Particularly important for the troubleshooters is knowledge of where an error occurred in a SIP path. This document introduces a new header field called Debug. The purpose of the header field is to convey extra debugging information that can be used to locate errors in SIP implementations involved in processing of a SIP transaction.
"Traffic localization for RELOAD", Gang Li, Lifeng Le, Naibao Zhou, 6-Jul-09. ( bytes): This document describes the traffic problems due to randomly distributed data storage in P2PSIP overlay, identifies the traffic localization requirements, and then proposes an overlay construction and data storage mechanism to implement traffic localization for REsource LOcation And Discovery (RELOAD). Specifically, it's proposed to add location indicator to the Peer node ID, for example, the beginning 5 bit hash ID stands for the peer location, and user data with the location indication shall be possible to be stored in local peer, thus to achieve traffic localization, reduce backbone network traffic, and improve the efficiency and QoS of the whole network.
"Fundamental Elliptic Curve Cryptography Algorithms", David McGrew, 6-Jul-09. ( bytes): This note describes the fundamental algorithms of Elliptic Curve Cryptography (ECC) as they are defined in some early references. These descriptions may be useful to those who want to implement the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves based on fields of character greater than three are in scope.
"Requirements for IP multicast performance monitoring", Mario Bianchetti, Giovanni Picciano, Mach Chen, Jian Qiu, 6-Jul-09. ( bytes): With increasing deployment of IP multicast in service provider (SP) network, SPs need a carrier-grade IP multicast performance monitoring solution. This document describes the requirements for such a system for a SP network. This system enables efficient performance monitoring in SPs' production network and provides diagnostic information in case of performance degradation or failure.
"Session Recording for Conferences using SMIL", Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Simon Romano, 6-Jul-09. ( bytes): 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.
"Use of Wildcard in S-PMSI Auto-Discovery Routes", Rahul Aggarwal, Wim Henderickx, Praveen Muley, Yakhov Rekhter, 28-Jul-09. ( bytes): The current MVPN specifications do not define encoding and procedures for advertising in a single route binding of multiple multicast streams of a given MVPN customer to a single provider's tunnel. This document defines such encoding and procedures. These procedures allow in certain situations to reduce MVPN control plane load (note though that these procedures have no impact on the data plane load). The procedures specified in this document assume that BGP is used for transmission of MVPN customers' routing information within the service provider(s) infrastructure.
"SMTP Service Extension for Message Recall", Barry Leiba, 6-Jul-09. ( bytes): End users occasionally send email messages that they later want to recall, perhaps because they sent incorrect information, or had second thoughts about what they said in the message. Proprietary email systems often provide such a recall function. This document specifies a standard mechanism for providing it with Internet email. Note A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to morg@ietf.org.
"LMA Handovers for Proxy Mobile IPv6", Yujin Lim, Sanghyun Ahn, JungSoo Park, HyeongJun Kim, 6-Jul-09. ( bytes): This document describes a mechanism for context transfer between Local Mobility Anchors (LMAs) in a large Proxy MIPv6 domain to provide the IP ongoing session continuity of mobile nodes. In order to enhance the performance of the LMA handover, a bi-directional tunnel between a previous LMA and a new target LMA is established.
"Problems and Possible Solutions for Advancing Metrics on the Standards Track", Al Morton, 6-Jul-09. ( bytes): This memo identifies some issues with the process of progressing performance metric RFCs along the standards track. This memo takes the position that the metric definitions themselves should be the primary focus, rather than the implementations of metrics. This appears to allow some simplification of the task at hand and subsequently leads to solutions for the issues raised.
"Extending YANG with Language Abstractions", Bernd Linowski, Mehmet Ersue, 6-Jul-09. ( bytes): YANG - the NETCONF Data Modeling Language - supports modeling of a tree of data elements that represent the configuration and runtime status of a particular network element managed via NETCONF. This memo suggests to enhance YANG with supplementary modeling features and language abstractions with the aim to improve the model extensibility and reuse.
"Architecture for Fast EAP Re-authentication based on a new EAP method (EAP-FRM) working on standalone mode", Rafael Lopez, Fernando Pereniguez-Garcia, Fernando Bernal-Hidalgo, Antonio Gomez-Skarmeta, 6-Jul-09. ( bytes): This document describes an architecture aimed for reducing the latency of network access authentication based on the Extensible Authentication Protocol (EAP). The architecture is based on the design of a new EAP method for which a standalone authenticator is used, and does not require any change to the EAP specification or the specifications of existing EAP lower-layers.
"Signaling BFD configuration for a backup path in an FRR environment", Mohammad Hanif, Lisa Nguyen, 6-Jul-09. ( bytes): Today there is no support in the RSVP protocol to dynamically signal the enabling and configuring of the BFD (Bi-directional Forwarding Detection) on a backup path. This document introduces a new RSVP object called "FRR backup BFD object". The procedures described in this document are only applicable to Fast Reroute LSPs [RFC4090].
"The OAuth Security Model for Delegated Authorization", Richard Barnes, Matt Lepinski, 8-Jul-09. ( bytes): This document describes the security model for the OAuth authorization system, which allows a party that holds some authorization to delegate a subset of that authorization to another party, without requiring either party to disclose its credentials to the other. In this document, we describe a set of design constraints, a high-level work flow for establishing authorizations subject to those constraints, and set of security requirements for protocols that implement this model.
"IP Addressing Model in Ad Hoc Networks", Emmanuel Baccelli, Mark Townsley, 10-Jul-09. ( bytes): This document describes a model for configuration of IP addresses and subnet prefixes on the interfaces of routers which connect to links with undetermined connectivity properties.
"IAB Thoughts on Encodings for Internationalized Domain Names", Dave Thaler, 6-Jul-09. ( bytes): This document explores issues with Internationalized Domain Names (IDNs) that result from the use of various encoding schemes such as Punycode and UTF-8.
"LSP-Ping and BFD for MPLS-TP", Nitin Bahadur, Rahul Aggarwal, Thomas Nadeau, Nurit Sprecher, Yaacov Weingarten, 6-Jul-09. ( bytes): LSP-Ping and BFD for MPLS are existing and widely deployment OAM mechanisms for MPLS LSPs. This document describes how LSP-Ping and BFD for MPLS can be used to perform OAM on MPLS-TP LSPs. This document describes extensions to LSP-Ping when IP addressing is not in use, in a MPLS-TP deployment scenario. These extensions are also meant to be applicable when it is desirable to avoid the use of IP encapsulation for exchanging LSP-Ping OAM messages. This document also clarifies the use of BFD for MPLS-TP LSPs when IP addressing may not be available and/or it may not be desirable to encapsulate BFD packets in IP.
"Recommendations for Implementing IPFIX over DTLS", Daniel Mentz, Gerhard Muenz, Lothar Braun, 6-Jul-09. ( bytes): This document discusses problems and solutions regarding the implementation of the IPFIX protocol over SCTP and DTLS.
"LDP Multipoint Opaque Value Element Types", Sandeep Bishnoi, Pranjal Dutta, IJsbrand Wijnands, 6-Jul-09. ( bytes): [MLDP] describes extensions to the Label Distribution Protocol (LDP) for setup of point to multi-point (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths (LSPs). LDP forwarding equivalence class (FEC) elements used to establish P2MP and MP2MP LSPs include type- length-value (TLV) fields that carry information meaningful to Ingress LSRs and Leaf LSRs and are termed as Opaque Value Elements in [MLDP]. This document defines Opaque Value Element structure to be used for provisioning P2MP and MP2MP Provider tunnels (P-Tunnels) for Multicast Virtual Private Network (MVPN). It is envisioned that this would be useful for security and manageability of P-Tunnels used for MVPN from the ones provisioned for other applications and vice-versa.
"Shim6 with IPv4 locators through 6to4", Iljitsch van Beijnum, 13-Jul-09. ( bytes): A limitation of Shim6 is that it only works with IPv6. With 6to4, it is possible for hosts that only have IPv4 connectivity to still enjoy Shim6's multihoming benefits.
"A Next Generation Transport Services Architecture", Janardhan Iyengar, Bryan Ford, 6-Jul-09. ( bytes): While there is substantial community interest in next-generation multipath-capable Internet transports, evolutionary pressures have gradually eroded the simplicity of the Internet's original transport architecture to a point where it is no longer realistically applicable to new tranports. This document proposes a new architectural framework for next-generation multipath-capable transport protocols, focusing immediately on multipath TCP but taking care to allow for generalization to other multipath-capable transports. The architecture places emphasis on enabling new multipath features in a safe, TCP-friendly, and backward-compatible fashion, retaining full interoperability with both existing applications and existing network infrastructure, and enabling reuse of existing protocols as much as possible while providing incremental deployment paths to new, more powerful and/or more efficient protocols. The architecture re-establishes the long-lost principles of end-to-end reliability and fate sharing, in the presence of existing and future network middleboxes, and enables the deployment of transport-neutral end-to-end protection without interfering with these policy-enforcing or performance-enhancing middleboxes. This document describes architecture goals, a layering model supporting these goals, abstract properties of the interfaces between the architecture's new layers, general approaches to multipath congestion control and how they fit into the architecture, realistic protocol design and incremental deployment paths, and ways in which this document complements and relates to ongoing protocol design activities in the IETF.
"VALARM Extensions for iCalendar", Cyrus Daboo, 6-Jul-09. ( bytes): This document defines a set of extensions to the iCalendar VALARM component to enhance use of alarms and improve interoperability between clients and servers.
"SILK Speech Codec", Koen Vos, Soeren Skak Jensen, Karsten Vandborg Soerensen, 6-Jul-09. ( bytes): This document describes SILK, a speech codec for real-time, packet- based voice communications. Targeting a diverse range of operating environments, SILK provides scalability in several dimensions. Four different sampling frequencies are supported for encoding the audio input signal. Adaptation to network characteristics is provided through control of bitrate, packet rate, packet loss resilience and use of discontinuous transmission (DTX). And several different complexity levels let SILK take advantage of available processing power without relying on it. Each of these properties can be adjusted during operation of the codec on a frame-by-frame basis.
"Multi-Class DSTE Support for the Path Computation Element Communication Protocol", Quintin Zhao, Suresh Babu, Daniel King, 6-Jul-09. ( bytes): Diffserv-Aware Traffic Engineering (DS-TE) can be used by Service Providers to perform fine grain bandwidth management of a subset, or sub-pool, of traffic flows. Typically in DS-TE a diffserv class will use a single Label Switch Path (LSP) that satisfies the bandwidth required. Where traffic with different diffserv characteristics must be mapped to a single LSP. Multi-Class DS-TE can be used to select an LSP that satisfy the bandwidth requirement of all classes required. This document specifies the PCEP extentions to support Multi-Class Type DS-TE where path computation is performed with the aid of a Path Computation Element (PCE).
"DSA with SHA-2 for DNSSEC", Paul Hoffman, 6-Jul-09. ( bytes): This document describes how to specify DSA keys and signatures based on SHA-256 with a specific set of parameters in DNSSEC. The keys used are 2048 bits, and have an equivalent security level of 112 bits.
"Elliptic Curve DSA for DNSSEC", Paul Hoffman, 6-Jul-09. ( bytes): This document describes how to specify Elliptic Curve DSA keys and signatures in DNSSEC. It lists curves of different sizes, and uses the SHA-2 family of hashes for signatures.
"Connection Verification and Continuity Check for MPLS Transport Profile Label Switched Path", Sami Boutros, Siva Sivabalan, George Swallow, David Ward, Stewart Bryant, 6-Jul-09. ( bytes): Connection Verification (CV) and Continuity Check (CC) are important Operations, Administration, and Management (OAM)functions of MPLS Transport Profile (MPLS-TP). This document specifies methods for CV and CC for MPLS-TP Label Switched Path (LSP) using Bidirectional Forwarding Detection (BFD).
"The rsync URI Scheme", Samuel Weiler, David Ward, Russ Housley, 27-Jul-09. ( bytes): This document specifies the rsync Uniform Resource Identifier (URI) scheme.
"Connection verification for MPLS Transport Profile LSP", Sami Boutros, Siva Sivabalan, George Swallow, David Ward, Stewart Bryant, 6-Jul-09. ( bytes): This document specifies method for verifying the connection of an MPLS Transport Profile(MPLS-TP) Label Switched Path (LSP) for management purpose. The proposed extension is based on MPLS Operation, Administration, and Maintenance (OAM). The goal is to verify that an MPLS-TP LSP is properly setup in both control and data planes, as well as to record the identities of all the LSRs along the path of MPLS-TP LSP.
"PET-based solution for IPv4/IPv6 coexistence", Yong Cui, Mingwei Xu, Shengling Wang, Xing Li, Jianping Wu, 6-Jul-09. ( bytes): IPv6 offers significant advantages over IPv4, however it will take long time to replace IPv4 with IPv6. Therefore, these two protocols are expected to coexist during the transition period. Currently, there are many transition devices deployed to solve transition problems. Most of them only use one technology (either translation or tunneling). However, any transition technology has limitation and application scope. In transition scenarios, besides IP version of source, middle and destination network, the network characteristic (a regular edge network or a backbone) has key impact on system performance of transition methods. Therefore, we need to decide which transition method should be used in some typical transition scenarios and how the transition and tunneling devices collaborate for solving transition problems. This draft introduces a smart toolbox named PET (shortfor Prefixing, encapsulation and translation) which includes all fundamental elements needed in all transition scenarios, such as the control and data plane operations of tunneling and translation. Based on PET, we propose a network side transition solution. In this framework, there deploys only one kind of transition device, i.e. PET. Through the collaboration of PETs, the transition problems can be solved. In this draft, we give the advantages and disadvantages of all transition methods PET may adopt according to IP version of source, middle and destination network, and the network characteristic.
"Recommended Configuration and Use of DNS Redirect by Service Providers", Tom Creighton, Chris Griffiths, Jason Livingood, Ralf Weber, 6-Jul-09. ( bytes): The objective of this document is to describe the design of so-called DNS Redirect services deployed today by Internet Service Providers (ISPs), DNS Application Service Providers (ASPs), and other organizations providing so-called DNS Redirect services via their recursive DNS services, as well as to describe the recommended best current practices regarding such systems.
"Storing Host Locators in HIP Resource Record", Oleg Ponomarev, 13-Jul-09. ( bytes): There is a resource record (RR) in the Domain Name System (DNS) used for the Host Identity Protocol (HIP). This document proposes to store the host locators in the HIP resource records as well.
"Hierarchical P2PSIP Overlay", Lifeng Le, 6-Jul-09. ( bytes): This draft discusses the hierarchical overlay architecture in Peer- to-Peer (P2P) SIP system. The P2P SIP is defined as a distributed network and each peer is equal in it. But actually peers are different from each other on many aspects, e.g., physical performance, network performance or system performance (e.g., uptime). So node heterogeneity should been considered enough in P2P SIP system, which affects the scalability and service availability of P2P SIP overlays. This draft introduces the performance concerns of P2P SIP overlay without consideration of node heterogeneity at first. After that, an alternative architecture of hierarchical P2P SIP overlay is brought up.
"Host Identity Protocol-based Mobile Proxy", Jan Melen, Jukka Ylitalo, Patrik Salmela, 28-Jul-09. ( bytes): This drafts defines a HIP proxy node that enables non-HIP host to communicate with HIP host through a proxy node.
"IP/IPVPN services with IEEE 802.1aq SPBB networks", Susan Hares, Roger Lapuh, Paul Unbehagen, 6-Jul-09. ( bytes): This document describes a compact method of using a IEEE 802.1aq Shortest Path Backbone Bridging SPBB network to natively enable and carry IP and IPVPN services for both unicast and multicast traffic on native Ethernet links. Further this documents the extensions to SPBB's control protocol, IS-IS, required to allow it to be a single mechanism for providing all these services types. On its own SPBB 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 SPBB network can also be leveraged to provide IP based services.
"MIF Problem Requirements and Scenarios", Carl Williams, Jacni Qin, 6-Jul-09. ( bytes): This document provides the problem statement requirements and scenarios for MIF. These requirements and use case scenarios are intended to define an approach to solving common problems presented in MIF. These MIF requirements and scenarios are based around the common and prevalent problem of adaptation of a host to attach to multiple networks simultaneously. Such a host not only has to make decisions about selection of service parameters but also how to deal with issues relating to contradictory configuration objects. These MIF scenarios are intended to be part of a set of such scenarios that together define the purpose, scope and requirements for proposed and realized capabilities.
"A Session Description Protocol (SDP) Attribute for Maximum Media Source Count Indication", Jonathan Lennox, 6-Jul-09. ( bytes): The Real-Time Transport Protocol (RTP) is a multi-point protocol, supporting multiple simultaneous sending sources in an RTP session. However, many existing RTP endpoints cannot usefully receive more than one simultaneous source. This document provides a Session Description Protocol (SDP) attribute that allows endpoints to indicate the maximum number of sources they can usefully receive.
"Mechanisms for Media Source Selection in the Session Description Protocol (SDP)", Jonathan Lennox, 6-Jul-09. ( bytes): Source-Specific Media Attributes in the Session Description Protocol (SDP) provide a declarative mechanism by which endpoints can describe Real-Time Transport Protocol (RTP) sources within a media stream. This document extends that mechanism by defining mechanisms by which participants in a multimedia session can request specific sources from a remote party.
"RSVP Extensions for Flexible Resource Sharing", Ashok Narayanan, Francois Le Faucheur, Subha Dhesikan, 6-Jul-09. ( bytes): RSVP signaling can be used to make end-to-end resource reservations in an IP network in order to guarantee the QoS required by certain flows. ...
"Explicit Congestion Notification (ECN) for RTP over UDP", Magnus Westerlund, Ingemar Johansson, Colin Perkins, 6-Jul-09. ( bytes): This document specifies how explicit congestion notification (ECN) can be used with RTP/UDP flows that use RTCP as feedback mechanism.
"MIF Security Analysis", Nam-Seok Ko, Carl Williams, Jacni Qin, 6-Jul-09. ( bytes): MIF is working to describe the issues of attaching to multiple networks on hosts and document existing practice. The group is also expected to analyze the impacts and effectiveness of these existing mechanisms. A MIF node will have various security considerations that must be reviewed. This document provides security analysis for MIF. MIF security requirements are also presented.
"Shortest Path Bridging and Backbone Bridging with IS-IS", Don Fedyk, Peter Ashwood-Smith, Nigel Bragg, David Allan, J�r�me Chiabaut, 6-Jul-09. ( bytes): Several techniques are being developed which use IS-IS to deliver link state based layer 2 forwarding. The superset of the extensions proposed to IS-IS to allow these capabilities is found in [IS-IS- L2]. One technique for layer 2 forwarding is being specified in the IEEE 802.1aq task group, under the over-arching title of "Shortest Path Bridging" (SPB). SPB however only requires a subset of the proposed IS-IS extensions in [IS-IS-L2]. For clarity this informational draft documents only the subset required by SPB. In addition a high level introduction, describing how these TLVs are used is provided for those who do not follow the IEEE work in detail. A reference is also given to the normative IEEE 802.1aq document The ordering of material in this document follows that of Clause 28 of IEEE 802.1aq, to aid cross-referencing.
"Extensions to LDP Signaling for PBB-VPLS", Florin Balus, 6-Jul-09. ( bytes): Extensions to VPLS PE model to accommodate PBB components where discussed in [PBB-VPLS Model]. This draft discusses optional extensions to the LDP Signaling procedures in [RFC4762] required to further enhance the PBB-VPLS solution.
"Point-to-Multipoint Pseudo-Wire Encapsulation", Rahul Aggarwal, 6-Jul-09. ( bytes): A Point-to-Multipoint (P2MP) Pseudo Wire (PW) is a mechanism that emulates the essential attributes of a unidirectional P2MP Telecommunications service such as P2MP ATM over a Packet Switched Network (PSN). This document describes the encapsulation and data plane procedures for a P2MP PW. These procedures are meant to be independent of the control plane used to signal a P2MP PW.
"IPv6 Addressing of IPv6/IPv4 Translators", Dave Thaler, 6-Jul-09. ( bytes): This document discusses how an individual IPv6 address can be algorithmically translated to a corresponding IPv4 address, and vice versa, using only statically configured information. This technique is used in IPv6/IPv4 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv6/IPv4 scenarios.
"HTTP Extensions for Simultaneous Download from Multiple Mirrors", Alan Ford, Mark Handley, 6-Jul-09. ( bytes): This document describes an extension to HTTP by which servers can automatically inform clients of mirrors of resources. Clients can then simultaneously request segments of the resource from different servers, enhancing both network and server utilisation, download speeds, and thus user experience.
"IPv6 via IPv4 Service Provider Networks", Mark Townsley, Ole Troan, 27-Jul-09. ( bytes): This document specifies a protocol mechanism tailored to advance deployment of IPv6 to end users via a Service Provider's IPv4 network infrastructure. Key aspects include automatic IPv6 prefix delegation to sites, stateless operation, simple provisioning, and service which is equivalent to native IPv6 outside of the SP's IPv4 network infrastructure.
"Simple Public Key Trust Alternatives", Leif Johansson, 6-Jul-09. ( bytes): This document describes often used patterns for establishing technical trust for public key-based security architectures other than traditional PKIX-based public key infrastructure. The intent is that this document be useful as a reference for protocol specification authors who use technology like PKIX, PGP or S/MIME as part of their protocols.
"Improving Remote Participation in IETF WG Meetings", Thomas Narten, 6-Jul-09. ( bytes): This document discusses some steps for improving the ability of people to remotely participate in IETF meetings. This document makes some recommendations of "best practice", that if adopted, could improve the ability for people to participate in IETF meetings without needing to physically attend meetings. Improving the ability of participants to contribute and participate remotely would improve the overall effectiveness of the IETF and improve the quality of the work it produces.
"Achieving Addressing Functions in IPv6 without using NAT", Greg Daley, 13-Jul-09. ( bytes): Proposals have been made to include Network Address Translation (NAT) in IPv6. Network Address Translation substitutes a source address in the outbound Packet headers at the Internet Egress point for one present at the network edge. It then matches the responding packets by destination address, and restores the original headers. NAT itself is not a feature. It is a mechanism which provides features at an application cost. This document identifies features which are supplied by NAT in IPv4 and how these features may be provisioned in IPv6. Both NAT and application-friendly alternatives are presented.
"Geocoding and Reverse-geocoding Using Location-to-Service Translation", James Polk, 6-Jul-09. ( bytes): This document creates new service URNs for geocoding and reverse geocoding location formats to be used by location-to-service translation protocol (LoST) to convert location values into a format of choice.
"MPLS-TP Identifiers", Matthew Bocci, George Swallow, 13-Jul-09. ( bytes): This document specifies identifiers for MPLS-TP objects. Included are identifiers conformant to existing ITU conventions and identifiers which are compatible with existing IP, MPLS, GMPLS, and Pseudowire definitions.
"Security Framework for MPLS-TP", Luyuan Fang, Ben Niven-Jenkins, 6-Jul-09. ( bytes): [page 1] MPLS-TP Security framework July 2009 This document provides a security framework for Multiprotocol Label Switching Transport Profile (MPLS-TP). MPLS-TP Requirements and MPLS-TP Framework are defined in [MPLS-TP REQ] and [MPLS-TP FW]. Extended from MPLS technologies, MPLS-TP introduces new OAM capabilities, transport oriented path protection mechanism, and strong emphasis on static provisioning supported by network management systems. This document addresses the security aspects that are relevant in the context of MPLS-TP specifically. It describes the security requirements for MPLS-TP; potential securities threats and migration procedures for MPLS-TP networks and MPLS-TP inter-connection to MPLS, GMPLS networks. The general security analysis and guidelines for MPLS and GMPLS are addressed in [MPLS/GMPLS Security FW], will not be covered in this document.
"EDNS0 OWNER Option", Stuart Cheshire, Marc Krochmal, 6-Jul-09. ( bytes): The DNS-SD Sleep Proxy Service uses a message format identical to that used by standard DNS Update, with two additional pieces of information: the identity of the sleeping server to which the records belong, and the Wake-on-LAN Magic Packet bit pattern which should be used to wake the sleeping server. This document specifies the EDNS0 option used to carry that additional information.
"Reliable and Scalable NAT mechanism (RS-NAT) based on BGP for IPv4/6 Transition", Gang Chen, Hui Deng, Bo Zhou, Mingwei Xu, Linjian Song, Yong Cui, 13-Jul-09. ( bytes): For the rapid exhaustion of IPv4 address pool against the slow development of IPv6, IPv4/6 coexistence/transition proved to be a long period. In the IPv4/6 transition process, there are many NAT- like technologies existing in the internet. However the NAT boxes such as IPv4 NAT, IPv4/6 NAT is insufficient in their reliability and scalability, which might cause a single point of failure in IPv4/6 transition architecture. This document defines a reliable and scalable NAT(RS-NAT) mechanism to solve the problem.
"Network File System (NFS) version 4 pNFS back end protocol extensions", Trond Myklebust, 6-Jul-09. ( bytes): This document describes an extension to the NFSv4.1 draft protocol to allow NFS clients to act as pNFS data servers towards other NFS clients. The intention is to reduce the load on the actual data servers by allowing some trusted clients to share the contents of their data caches with other clients.Keywords
"Network File System (NFS) version 4 pNFS back end protocol extensions", Trond Myklebust, 6-Jul-09. ( bytes): This document describes an extension to the NFSv4.1 draft protocol to allow NFS clients to act as pNFS data servers towards other NFS clients. The intention is to reduce the load on the actual data servers by allowing some trusted clients to share the contents of their data caches with other clients.
"Arcband Shape Binary Encoding", Gabor Bajko, Hannes Tschofenig, 6-Jul-09. ( bytes): This document describes a binary encoding format for an arcband, which is compatible with the binary encoding defined by 3GPP [3GPP23.032], and which is widely used in today's cellular networks. This encoding can additionally be used by a number of other protocols, which demand a bandwidth efficient encoding of location information, eg link layers like IEEE 802.11.
"A Conversion of Location Related eXtensible Markup Language (XML) Elements to Type-Length-Value (TLV) Fields", James Polk, Allan Thomson, Marc Linsner, 6-Jul-09. ( bytes): This document specifies how to translate geolocation related eXtensible Markup Language (XML) elements to Type-Length-Value (TLV) fields, specifically where XML is not optimal or not appropriate to use for transporting geolocation related values. This document specifies a payload for binary protocols to use. This document makes no recommendations about which protocols should use this payload.
"Trace Control Support for Proxy Mobile IPv6", Yungui Wang, Wenson Wu, 6-Jul-09. ( bytes): In some Proxy Mobile IPv6 (PMIPv6) [RFC5213] deployments, a mobility session needs to be traced by the back-end network manager for network diagnosis, troubleshooting, new service testing, etc. This document defines a Trace Session option for PMIPv6 protocol to control and manage (activation and de-activation) a trace session associated with a mobility session of the mobile node. This option is sent by the mobile access gateway in Proxy Binding Update message to request the local mobile anchor to activate the trace session. When the local mobile anchor successfully processes the Proxy Binding Update, it then activates the trace session and starts to record/report the traced mobility session based on the corresponding trace parameters.
"BGP based Multi-homing in Virtual Private LAN Service", Bhupesh Kothari, Kireeti Kompella, Wim Henderickx, Florin Balus, 13-Jul-09. ( bytes): Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private Network (VPN) that gives its customers the appearance that their sites are connected via a Local Area Network (LAN). It is often required for the Service Provider (SP) to give the customer redundant connectivity to some sites, often called "multi-homing". This memo shows how BGP-based multi-homing can be offered in the context of LDP and BGP VPLS solutions.
"RTP Payload Format and File Storage Format for SILK Speech and Audio Codec", Julian Spittka, Henrik Astrom, Koen Vos, 6-Jul-09. ( bytes): This document defines the Real-time Transport Protocol (RTP) payload format and file storage format for packetization of SILK encoded speech and audio data that is essential to implement SILK in the most compatible way. Further, media type registrations are described for the RTP payload format and the file storage format.
"PET-based framework for IPv4/IPv6 coexistence", Yong Cui, Mingwei Xu, Shengling Wang, Xing Li, Jianping Wu, 6-Jul-09. ( bytes): IPv6 offers significant advantages over IPv4, however it will take a long time to replace IPv4 with IPv6. Therefore, these two protocols are expected to coexist during the transition period. Currently, there are many transition technologies, such as translation and tunneling. In some typical transition scenarios, both tunneling and translation are needed. However, either translation or tunneling has limitation and application scope. In addition, besides IP version of source, middle and destination network, the network property (a regular edge network or a backbone) has key impact on system performance. Therefore, we need to decide which transition method should be used in some typical transition scenarios and how transition and tunneling collaborate for solving transition problems. This draft presents an IPv4-IPv6 transition framework, which is a network side transition solution. It introduces a toolbox named PET (short for Prefixing, encapsulation and translation) to solve IPv4- IPv6 transition. PET includes fundamental elements needed in transition scenarios, which provides the flexibility for network to decide the proper transition methods. In addition, this draft also addresses how to deploy PETs and analyze the advantages and disadvantages of all transition methods that PET may adopt.
"Improved INSIGNIA Based on Network measurement", Tan Yang, ShuGuang Zhang, Yidong Cui, Yuehui Jin, 6-Jul-09. ( bytes): This document specifies an improved version of INSIGNIA[1][2], which is a framework supporting quality of service(QOS) in mobile ad hoc networks. INSIGNIA is an in-band signaling system, and 'in-band signaling' means the control information is carried along with data in IP packets. In this memo we introduce network measurement into INSIGNIA, and then this system can highly responsive to changes of performance on mobile ad hoc networks.
"DNS Encoding of Domain Reputation and IP# Classification", Yuming Huang, 6-Jul-09. ( bytes): This document defines the format of a new Resource Record (RR) for the Domain Naming System (DNS), (and reserves a corresponding DNS type mnemonic: DRIC and numerical code - to be done) This definition deals with associating a reputation measure to a domain, a host name, or a url before domain name resolution. It also deals with associating a classification of the result ip# after domain name resolution. The data shown in this document is fictitious and does not necessarily reflect the real Internet.
"URN Namespace for news-related resources", Michael Steidl, Jayson Lorenzen, 7-Jul-09. ( bytes): This document describes a URN (Uniform Resource Name) namespace for identifying news-related data items. A news-related data item is an information resource used for news exchange that is expressed as an instance complying with a specific data schema. This may be the schema of IPTC news standards specifications such as NewsML 1 and the G2-Standards or the specification of any other body.
"IVIT(IVI+Tunnel)", Mingwei Xu, Chunmei Xia, Xing Li, Yong Cui, Jianping Wu, 6-Jul-09. ( bytes): This document proposes a mechanism, IVIT (IVI+Tunnel), to support non-IVI IPv6 hosts to communicate with IPv4 hosts, and vice versa. IVIT combines IVI translation and Tunnel methods with the IVI translation at the core and the tunnel at the edge. In this document, IVIT provides two modes. One is the dual-stack host mode, which supports the communication between a dual-stack host in an IPv4 network and a non-IVI IPv6 host, especially the communication scenario between a dual-stack server in an IPv4 network and a non-IVI IPv6 host. The other is the CPE mode, which supports the communication between an IPv4-only host and a non-IVI IPv6 host, especially the bidirectional communication scenario between a private IPv4 network and a non-IVI IPv6 network. Combined with IVI, IVIT can support the communication between IPv4 networks and IPv6 networks statelessly at the core.
"IPv4/IPv6 Coexistence Framework (PET)", Yong Cui, Mingwei Xu, Shengling Wang, Jianping Wu, Xing Li, Chris Metz, 7-Jul-09. ( bytes): IPv6 offers significant advantages over IPv4. However IPv4 and IPv6 protocols are expected to coexist during a long period. Currently, there are many IPv4/IPv6 transition/coexistence technologies, which can be generally devided into two kinds: translation and tunneling. In some typical transition scenarios, both tunneling and translation are needed. However, either translation or tunneling has limitation and application scope. In addition to the IP versions of source networks and destination networks, the IP version of transport network (the middle part along end-to-end path) also plays an important role during IPv4/IPv6 transition/coexistence. Therefore, we need to decide which transition methods should be used in different typical transition scenarios and how transition and tunneling collaborate for solving transition/coexistence problems. This draft presents an IPv4-IPv6 transition/coexistence framework named PET (short for Prefixing, Encapsulation and Translation), which is a network side solution. PET includes fundamental elements needed in transition scenarios, which provides the flexibility for network operators to decide the proper transition technology. In addition, this draft also addresses how to deploy PETs and analyze the advantages and disadvantages of typical transition technologies that PET may adopt.
"IXFR-ONLY to Prevent IXFR Fallback to AXFR", Ondrej Sury, Shane Kerr, 7-Jul-09. ( bytes): Presents IXFR-ONLY, a way for a DNS slave to prevent a DNS master from falling back from IXFR to AXFR.
"Naming Architecture for Object to Object Communications", Gyu Myoung Lee, Jun Kyun Choi, Seng Kyoun Jo, Jeong Yun Kim, 7-Jul-09. ( bytes): This document explains the concept of object to object communications and describes naming issues for object identification. In order to develop protocols for object to object communications, this document provides the naming architecture according to mapping relationships between host and object(s). In addition, considerations of protocols for naming object are specified.
"Correct transaction handling for 200 responses to Session Initiation Protocol INVITE requests", Robert Sparks, Theo Zourzouvillys, 8-Jul-09. ( bytes): This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address an error in the specified handling of success (200 class) responses to INVITE requests. Elements following RFC 3261 exactly will misidentify retransmissions of the request as a new, unassociated, request. The correction involves modifying the INVITE transaction state machines. The correction also changes the way responses that cannot be matched to an existing transaction are handled to address a security risk.
"Multicast security algorithm based on agent node", Anni Wei, 8-Jul-09. ( bytes): Multicast security algorithm based on agent node can select the group node corresponding to the smallest path cost to be the agent node, and multicast in accordance with the optimal multicast routing. In addition, the multicast source node uses the key different from the group key to encrypt multicast data to meet the requirements of multicast security. The agent nodes can be different for different multicast sources, which can spread the burden of the agent node and avoid the excessive burden problem when the same node as the agent node of different sources.
"IKEv2 Redirect and Authentication Offload", A Padmakumar, Manikchand Bafna, Pratima Sethi, 27-Jul-09. ( bytes): IKEv2 supports multiple authentication mechanisms like public key signatures, shared secrets and EAP. EAP based authentication requires server to maintain information about the client until EAP completes. Public key based authentication mechanisms are highly computational intensive and demands server CPU resources. Redirect Mechanism for IKEv2 proposes a mechanism for IKEv2 that enables a VPN gateway to redirect the VPN client to another VPN gateway, for example, based on the load condition. Redirect mechanism can also be used to redirect a client to another router (trust anchor) to do mutual authentication on behalf of the server. This redirection happens during the IKE_SA_INIT and server does not maintain any information about the redirected client. After mutual authentication Trust anchor can redirect the client back to the server with an Access Token which can be used as a dynamic pre- shared key between the server and client for password based IKE_AUTH exchange. Mechanism described here allows servers to compute the same pre-shared key dynamically, without contacting trust anchors, based on the information provided by the client during IKE_AUTH exchange. Such a mechanism is useful especially for low power devices like handsets. For example, a mobile node can redirect such authentications to its home agent. This proposal explains a mechanism to offload such verifications to a set of less critical routers or to a service provider who offers trust as a service.
"Basic Security Requirements of Authentication Protocol on Ad hoc", Weihong Wang, Tieming Chen, Yubing Lin, Yiling Cui, 9-Jul-09. ( bytes): This document specifies basic security standards for authentication protocol on Ad hoc. The security standards are based on the ECDH to discover a authentication protocol between two nodes, and on the TinyOS simulation platform and Mica nodes. This document also defines elements of procedure for authentication protocol, including System Initialization, Key extract and the identity authentication. With these standards, authentication between two nodes can be completed in a certain time and a certain circles.
"Using Advanced Encryption Standard (AES) Counter Mode with IKEv2", S murthy, Sean Shen, Yu Mao, 9-Jul-09. ( bytes): This document describes the usage of Advanced Encryption Standard Counter Mode (AES-CTR), with an explicit initialization vector, by IKEv2 for encrypting IKE-SA and Child-SA negotiations.
"Mechanism for Peer-to-Peer Group Management using Multiple Overlays", Otso Kassinen, Timo Koskela, Erkki Harjula, Mika Ylianttila, 10-Jul-09. ( bytes): This document introduces a mechanism for managing peer groups in structured peer-to-peer (P2P) overlay networks. Group management enables efficient and secure interaction between the group members (peers), by controlling the scope of propagation for the group- specific P2P messaging and other communications. The mechanism for group management, introduced in this document, is based on a multiple-overlay scheme. Each group is a separate overlay network with its own address space, resources, and message routing information. A common overlay is used for sharing information about the group overlays (sub-overlays).
"SAFE (Server-side Asynchronous Framework Execution) Scripting Method", Austin Cheney, 4-Aug-09. ( bytes): SAFE Scripting Method is a model for allowing application interactivity in email while simultaneously elminating security vulnerabilities associated with client-side scripting.
"RTP payload format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW)", Zheng Fang, 13-Jul-09. ( bytes): 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.
"Routing algorithm based on the flow sensing parameter", Anni Wei, 13-Jul-09. ( bytes): The packet loss rate of each path between the source node and destination node can be obtained through two methods, one is direct measurement, another approach is proposed in this document calculating the packet loss rate based on the flow sensing parameter. The core idea of the calculating approach is the flow sensing parameter, which can be used to calculate the packet loss rate of each path between the source node and destination node and select the path whose packet loss rate is smallest to be the data transmission path.
"Extension Mechanisms for DNS (EDNS0)", Paul Vixie, Michael Graff, 13-Jul-09. ( bytes): 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 clients to advertise their capabilities to servers. This document describes backward compatible mechanisms for allowing the protocol to grow. This document is a starting point to update the EDNS0 RFC after 10 years of operational experience.
"Centrally Assigned IPv6 Unicast Unique Local Address Prefixes", Tony Hain, Robert Hinden, Geoff Huston, Thomas Narten, 13-Jul-09. ( bytes): This document defines Centrally Allocated IPv6 Unique Local address prefixes. These prefixes are globally unique and are intended for local communications, usually within a single network administration. They are not intended to be used in place of Provider Independent (PI) address prefixes available from the Regional Internet Registries (RIR) , and should not appear in the global routing table for the Internet. The draft is being discussed on the ipv6@ietf.org list.
"End to End NAT", Masataka Ohta, 13-Jul-09. ( bytes): According to the end to end argument, NAT function can completely and correctly be implemented only with the knowledge and help of end hosts. By making NAT visible to the end hosts of NAT clients and let the hosts help NAT gateways, NAT actually becomes correct, complete, and end to end transparent. End to end NAT is upper compatible to legacy NAT while enabling various transport protocols (ICMP, SCTP, IPSEC), DNS reverse look up, Multicast and Mobile IP.
"OGPX layering and architectural patterns", David Levine, 13-Jul-09. ( bytes): Architectural layering and patterns for OGPX.
"Client Capabilities for OGPX", David Levine, 13-Jul-09. ( bytes): client side capabilities for OGPX.
"Prefix Sub-delegation in a SOHO/SMB Environment", Fred Baker, 27-Jul-09. ( bytes): This memo considers the question of IPv6 prefix sub-delegation.
"LMA Redirection Solution", Xiangsong Cui, 27-Jul-09. ( bytes): In network-based mobility management domain, LMA is used to manage the mobility of IP node attached to MAG. LMA discovery and LMA redirection mechanism are used to improve the network flexibility. This document is used to introduce a recommended solution for this purpose. In this solution Redirect Agent function is adopted to accomplish the requirement.
"Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for evolutive OTNs control", Daniele Ceccarelli, Diego Caviglia, Francesco Fondelli, Xihua Fu, Ming Ke, Yuanlin Bao, Marco Corsi, 27-Jul-09. ( bytes): This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling documents. It describes the technology- specific information needed to extend GMPLS signaling to control Optical Transport Networks (OTN) based on ITU-T G.709 amendment 3 reccomandation. References also to G.sup43 are provided.
"Multi-Screen Application for SVC Video", Nan Wang, 27-Jul-09. ( bytes): This memo proposes a supplement to existing draft, RTP payload Format for SVC Video. One new application, Multi-Screen is added. SVC is very suitable for Multi-Screen application, which has some different characteristics from the existing applications in the current draft. This proposal provides a paradigm and addresses potential issues and consideration.
"Global Navigation Satellite System (GNSS) Reference Information Protocol (GRIP)", Martin Thomson, 27-Jul-09. ( bytes): This document describes a means of acquiring Global Navigation Satellite System (GNSS) assistance data using HTTP. Assistance data aids GNSS receivers in acquiring and measuring satellite signals, as well as being useful in calculating positions. The GNSS Reference Information Protocol (GRIP) provides a framework for discovering resources capable of providing any kind of location-based assistance data.
"Global Navigation Satellite System (GNSS) Reference Information Protocol (GRIP) - Global Positioning System (GPS) Assistance Data", Martin Thomson, 27-Jul-09. ( bytes): This document defines assistance data formats for the Global Positioning System (GPS). These formats can be used with the Global Navigation Satellite System (GNSS) Reference Information Protocol (GRIP) by a GPS receiver to acquire assistance data.
"Session Initiation Protocol (SIP) Event Package for OMA Content Push Delivery", Martin Dolly, Bryan Sullivan, Salvatore Loreto, Kent Bogestam, 27-Jul-09. ( bytes): This document specifies a new event package for OMA Push-based service over SIP. The purpose is to allow an OMA application or a UA to subscribe to updates to its own OMA application events containing either content or references to the content. This document further describes how content can be pushed out to an application by the use of OMA Push-based events.
"The atypes media feature tag for Session Initiation Protocol (SIP)", Mohammed Boucadair, Yoann Noisette, Andrew Allen, 27-Jul-09. ( bytes): This specification defines a new media feature tag called atypes. This new media feature tag indicates the IP address type capabilities of the UA (User Agent) and can aid the routing process and ease the invocation of required functions when heterogeneous (i.e. IPv4 and IPv6) parties are involved in a given SIP session.
"A New SIP Usage for RELOAD", Gao yang, Yu Meng, 27-Jul-09. ( bytes): This document points out the main drawbacks of the solution in "draft-ietf-p2psip-sip-01". And solve such problems by introducing a new way.
"Session Hijack in Neighbor Discovery", Fred Baker, 28-Jul-09. ( bytes): This memo is to point out a security issue in IPv6 Neighbor Discovery.
"Address Selection Using Source Address Specific Routing Tables", Aleksi Suhonen, 29-Jul-09. ( bytes): RFC 3484 defines two algorithms for default source and destination address selection, but it has several shortcomings as specified in RFC 5220. RFC 5221 lists some requirements for any attempts to update the original RFC. This document specifies an alternate address selection algorithm to fulfill those requirements.
"A Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure", Geoff Huston, 29-Jul-09. ( bytes): This document defines a profile for the algorithm and key size to be used for signatures applied to certificates, Certificate Revocation Lists, and signed objects in the context of the Resource Public Key Infrastructure.
"Fast Content Switching with RTSP 2.0", Thorsten Lohmar, Jamie Gordon, Torbjorn Einarsson, 29-Jul-09. ( bytes): RTSP defines the setup and control for on demand and live streaming media sessions, which are delivered via an external media transport protocol such as RTP/UDP. RTSP does not define a mechanism to change the content during an on-going streaming session. Such a mechanism improves the streaming experience when a user browses through multiple offerings on a single streaming site. This document describes several methods to improve content switching. The basic principle is to re-use already established transport sessions (e.g. RTP/UDP sessions) and negotiate new content to be delivered on the existing sessions. If additional transport sessions are necessary, those sessions are established separately. This principle of re-using the RTSP control and transport sessions decreases the content switch delay to a large extent and improves the end-user experience. The present document defines a mechanism for switching to new content, both when the client already has the content description available and when it does not. This document additionally considers switching of a single media stream in a session, when several alternative media components are available. For instance, the content may provide several alternate audio tracks in different languages to be played with a single video stream. The principle of Fast Content Switching and Start-up is also defined in 3GPP TS 26.234 [3GPP.26.234] for RTSP 1.0 [RFC2326].
"Revised IAOC Membership", John Klensin, 30-Jul-09. ( bytes): The original specification of the membership of the IAOC included the IETF and IAB Chairs as voting members. While probably desirable initially, this has turned out to have unfortunate side effects. This document discusses those side effects and replaces those specific individuals with liaisons from the IAB and IESG.
"Consideration of Network Mobility in PMIPv6", Zhi-wei Yan, Hong-Ke Zhang, Hua-chun Zhou, Jian-feng Guan, Si-Dong Zhang, 31-Jul-09. ( bytes): The NetLMM WG is specifying Proxy Mobile IPv6 (PMIPv6) for network- based localized mobility management (NetLMM), taking basic support for registration, de-registration and handover of signal Mobile Node (MN) into account in the RFC 5213 [1]. When a whole network moves into the PMIPv6 domain through the Mobile Router (MR), the scheme should be considered to provide and maintain the connectivity for the Mobile Network Node (MNN) in the mobile network (NEMO). This document discusses the deployment consideration of NEMO support in PMIPv6 network and proposes the possible solution accordingly.
"Selective transmission of RTP Session", Peilin Yang, 31-Jul-09. ( bytes): Selective transmission is an effective technique implementation for media stream transport when network congestion occurs or dynamic transient burst stream transfers on a bandwidth constrained network.
"Session Description Protocol (SDP) - Revised Offer/Answer Protocol (SDPCapNeg & MediaCapNeg) - Offer/Answer Examples", Albrecht Schwarz, Juergen Stoetzer-Bradler, 31-Jul-09. ( bytes): This document gives examples of Session Description Protocol (SDP) offer/answer exchanges. The SDP offer/answer protocol was revised by [SDPCapNeg] and [MediaCapNeg] plus other extensions. Examples include the indication, negotiation and selection of media configurations ("codecs"). This document discusses examples of IP bearer emulation scenarios for PSTN modem calls in SIP-controlled VoIP networks.
"Deprecate DES support for Kerberos", Love Astrand, 2-Aug-09. ( bytes): A long long time ago DES was standardized. Some 30 years later (2003) is was withdrawn as a standard by NIST, today 6 years later, its time for DES to finally die. By 2008 it was possible to brute force DES keys in 6.4 days using less than USD 10k worth of hardware. So by 2008 DES had passed its sell-by date. Use in Kerberos should therefore stop.1. Requirements Notation
"TCP Option for Transparent Middlebox Discovery", Andrew Knutsen, Ron Frederick, Jamshid Mahdavi, Qing Li, Wei Yeh, 3-Aug-09. ( bytes): This document describes a TCP option intended to facilitate transparent detection of middleboxes (or services playing that role) along the path of a TCP connection as the connection is made. The option has no effect if an appropriate middlebox is not on the path.
"GOST 28147-89 encryption, decryption and MAC algorithms", Vasily Dolmatov, Dmitry Kabelev, Igor Ustinov, Irene Emelianova, 5-Aug-09. ( bytes): This document is intended to be a source of information about the Russian Federal standard for for electronic encryption, decryption and MAC algorithms (GOST 28147-89) [GOST28147], which is one of the official standards in the Russian cryptography, used in Russian algorithms (GOST algorithms). Recently, the Russian cryptography started to be used in different applications intended to work with the OpenSSL cryptographic library. Thus, this document has been created for the informational purposes for users of Russian cryptography.
"ALTO Information Redistribution Considered Harmful", Martin Stiemerling, 7-Aug-09. ( bytes): The merged ALTO protocol proposal proposes several mechanisms to increase scalability of the protocol. One of the proposed mechanisms is the distribution of ALTO information directly between the peers without any involvement of the server. This memo discusses why the proposed mechanism is considered harmful and why the proposed security framework is deployable.
"A routing method based on detection frames over LLNs", Anni Wei, 7-Aug-09. ( bytes): This document presents a routing method through sending detection frames including address of destination node to the neighbor nodes to reduce delay of data transmission because of the dormant nodes will increase data transmission delay in low power and lossy networks(LLNs). When receives the response from the neighbor nodes, the sending node can select a neighboring node as the next hop node to sent data, which has the lower cost parameter than the cost parameter between the sending node and the destination node stored in the routing table of sending node. This routing method finds a route in real-time by broadcasting detection frames. As long as any neighbor node that can reach the destination is active, data can be sent and then the data transmission delay will be reduced.
"HTTP State Management Mechanism", Adam Barth, 7-Aug-09. ( bytes): This document defines the HTTP Cookie and Set-Cookie headers. NOTE: This document is currently a "straw-man" cookie proposal. Much of the text herein is completely wrong. If you have suggestions for improving the draft, please send email to http-state@ietf.org. Suggestions with test cases are especially appriciated.

IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.

Return to Internet-Draft directory.

Return to IETF home page.