|
Internet Drafts - IDs for Jun/2009
Index - Month Index of IDs
All IDs - sorted by date)
30/06/2009
| |
|
| |
| | ForCES LFB Library |
| |
| | draft-ietf-forces-lfb-lib-00.txt |
| | Date: |
30/06/2009 |
| | Authors: |
Weiming Wang, Evangelos Haleplidis, Kentaro Ogawa, Fenggen Jia, Joel Halpern |
| | Working Group: |
Forwarding and Control Element Separation (forces) |
| | Formats: |
txt xml |
|
The forwarding and Control Element Separation (ForCES) protocol defines a standard communication and control mechanism through which a Control Element (CE) can control the behavior of a Forwarding Element (FE). That control is accomplished through manipulating components of Logical Function Blocks (LFBs), whose structure is defined in a model RFC produced by the working group.In order to build an actual solution using this protocol, there needs to be a set of Logical Function Block definitions that can be instantiated by FEs and controlled by CEs. This document provides a sample space of such definitions. It is anticipated that additional defining documents will be produced over time. |
| | DNSSEC Trust Anchor History Service |
| |
|
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. |
| | Header Protection for S/MIME |
| |
|
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. |
| | URI Scheme for Java(tm) Message Service 1.0 |
| |
| | draft-merrick-jms-uri-06.txt |
| | Date: |
30/06/2009 |
| | Authors: |
Mark Phillips, Peter Easton, Derek Rokicki, Eric Johnson |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
xml txt |
|
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. |
| | LoWPAN simple fragment Recovery |
| |
|
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. |
| | MPLS-TP General Authentication TLV for G-ACH |
| |
|
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. |
| | Enhanced Client Support for RELOAD |
| |
|
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. |
| | A Hybrid ISP Framework for IPv6 Services and IPv6/IPv4 Inter-communication |
| |
|
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. |
| | P2PSIP Overlay Diagnostics |
| |
|
This document describes mechanisms for P2PSIP diagnostics. It describes the usage scenarios and defines several simple methods for performing diagnostics in P2PSIP overlay networks. It also describes the diagnostic information which is useful for the connection and node status monitoring. The methods and message formats are specified as extensions to P2PSIP base protocol RELOAD. |
| | An Extensible Markup Language (XML) Document Format for Indicating A Change in XML Configuration Access Protocol (XCAP) Resources |
| |
| | draft-ietf-simple-xcap-diff-13.txt |
| | Date: |
30/06/2009 |
| | Authors: |
Jonathan Rosenberg, Jari Urpalainen |
| | Working Group: |
SIP for Instant Messaging and Presence Leveraging Extensions (simple) |
| | Formats: |
txt |
|
This specification defines a document format that can be used to indicate that a change has occurred in a document managed by the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). This format indicates the document that has changed and its former and new entity tags. It also can indicate the specific change that was made in the document, using an XML patch format. This format allows also indications of element and attribute content of an XML document. XCAP diff documents can be delivered to clients using a number of means, including a Session Initiation Protocol (SIP) event package. |
29/06/2009
| |
|
| |
| | Nested Nemo Tree Discovery |
| |
|
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. |
| | PCEP Requirements for WSON Routing and Wavelength Assignment |
| |
|
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. |
| | MVPN Profiles Using PIM Control Plane |
| |
|
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. |
| | ECC in OpenPGP |
| |
|
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. |
| | RTCP Extended Report for ECN Marked Packets |
| |
|
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. |
| | XTLS: End-to-End Encryption for the Extensible Messaging and Presence Protocol (XMPP) Using Transport Layer Security (TLS) |
| |
|
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. |
| | Additive-Routes-Wanted Outbound Route Filter for BGP-4 |
| |
|
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. |
| | Requirements for End-to-End Encryption in the Extensible Messaging and Presence Protocol (XMPP) |
| |
|
This document describes requirements for end-to-end encryption in the Extensible Messaging and Presence Protocol (XMPP). |
| | In-lining Extensions for Atom |
| |
|
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]. |
| | Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 amendment 3 Optical Transport Networks Control |
| |
|
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. |
| | Fast Handover for Multicast in Proxy Mobile IPv6 |
| |
|
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. |
| | PCEP Requirements for WSON Impairments |
| |
|
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. |
| | An ALTO Service based on BGP Routing Information |
| |
|
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. |
| | A Generic MIB for Centralized Network Architecture |
| |
|
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. |
| | Content Sharing Usage for RELOAD |
| |
|
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. |
| | Differentiated Services Support for Proxy Mobile IPv6 |
| |
|
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. |
| | Application of Ethernet Pseudowires to MPLS Transport Networks |
| |
| | draft-ietf-pwe3-mpls-transport-04.txt |
| | Date: |
29/06/2009 |
| | Authors: |
Stewart Bryant, Monique Morrow, George Swallow, Thomas Nadeau, Neil Harrison, Ben Niven-Jenkins |
| | Working Group: |
Pseudowire Emulation Edge to Edge (pwe3) |
| | Formats: |
txt xml |
|
A requirement has been identified by the operator community for the transparent carriage of the MPLS(-TP) network of one party over the MPLS(-TP) network of another party. This document describes a method of satisfying this need using the existing PWE3 Ethernet pseudowire standard RFC4448. |
28/06/2009
| |
|
| |
| | The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force |
| |
|
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. |
| | RADIUS attributes for IPv6 Access Networks |
| |
|
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. |
| | Reusing Transport Layer Connections in Session Initiation Protocol (SIP) |
| |
|
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. |
| | Chunk Discovery for P2P Streaming |
| |
|
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. |
26/06/2009
| |
|
| |
| | CGA Extension Header of IPv6 |
| |
|
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. |
| | NFS operation over IPv4 and IPv6 |
| |
| | draft-alexrn-nfsv4-ipv6-00.txt |
| | Date: |
26/06/2009 |
| | Authors: |
Alex RN, Bhargo Sunil, Dhawal Bhagwat, Dipankar Roy, Rishikesh Barooah |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
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 |
| |
|
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. |
| | Label Switched Path (LSP) Data Path Delay Metric in Generalized MPLS/ MPLS-TE Networks |
| |
| | draft-sun-ccamp-dpm-00.txt |
| | Date: |
26/06/2009 |
| | Authors: |
Weiqiang Sun, Guoying Zhang, Jianhua Gao, Guowu Xie, Rajiv Papneja, Bin Gu, Xueqing Wei, Tomohiro Otani, Ruiquan Jing |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
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. |
| | PCN Encoding for Packet-Specific Dual Marking (PSDM) |
| |
| | draft-ietf-pcn-psdm-encoding-00.txt |
| | Date: |
26/06/2009 |
| | Authors: |
Michael Menth, Jozef Babiarz, T Moncaster, Bob Briscoe |
| | Working Group: |
Congestion and Pre-Congestion Notification (pcn) |
| | Formats: |
txt |
|
This document proposes how PCN marks can be encoded into the IP header. The presented encoding reuses the ECN field of the Voice- Admit DSCP in a single PCN domain. The encoding of unmarked PCN packets indicates whether they are subject to either excess- or exhaustive-marking. This is useful, e.g., when data and probe packets require different marking mechanisms. Status This memo is posted as an Internet-Draft with an intent to eventually be published as an experimental RFC. |
25/06/2009
| |
|
| |
| | Extended Optional Parameters Length for BGP OPEN Message |
| |
|
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. |
| | Sieve Email Filtering: Use of Presence Information with Auto Responder functionality |
| |
|
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. |
| | Mobility Session Suspend Support in PMIPv6 |
| |
|
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. |
| | RT-Constrain Lite for Provider Edge Routers |
| |
|
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. |
| | Pseudo Wire (PW) OAM Message Mapping |
| |
| | draft-ietf-pwe3-oam-msg-map-11.txt |
| | Date: |
25/06/2009 |
| | Authors: |
Luca Martini, Thomas Nadeau, Mustapha Aissaoui, David Allan, Yaakov Stein |
| | Working Group: |
Pseudowire Emulation Edge to Edge (pwe3) |
| | Formats: |
txt |
|
This document specifies the mapping and notification of defect states between a Pseudo Wire and the Attachment Circuits (AC) of the end-to- end emulated service. This document covers the case whereby the ACs and the PWs are of the same type in accordance to the PWE3 architecture [RFC3985] such that a homogenous PW service can be constructed. |
24/06/2009
| |
|
| |
| | The BagIt File Packaging Format (V0.96) http://www.ietf.org/internet-drafts/draft-kunze-bagit-04.txt |
| |
| | draft-kunze-bagit-04.txt |
| | Date: |
24/06/2009 |
| | Authors: |
Andy Boyko, John Kunze, Justin Littman, Liz Madden, Brian Vargas |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
xml txt |
|
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. |
| | Transport Layer Security Transport Model for SNMP |
| |
|
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. |
| | Mapping and interworking of Diversion information Between Diversion and History-Info Headers in the Session Initiation Protocol (SIP) |
| |
|
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. |
| | Robust Configuration Management within NETCONF |
| |
|
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. |
23/06/2009
| |
|
| |
| | Application Mechanism for maintaining alive the Network Address Translator (NAT) mappings associated to RTP flows. |
| |
|
This document lists the different mechanisms that enable applications using Real-time Transport Protocol (RTP) to maintain their RTP Network Address Translator (NAT) mappings alive. It also makes a recommendation for a preferred mechanism. This document is not applicable to Interactive Connectivity Establishment (ICE) agents. |
| | Framework for Metric Composition |
| |
|
This memo describes a detailed framework for composing and aggregating metrics (both in time and in space) originally defined by the IP Performance Metrics (IPPM) RFC 2330 and developed by the IETF. This new framework memo describes the generic composition and aggregation mechanisms. The memo provides a basis for additional documents that implement the framework to define detailed compositions and aggregations of metrics which are useful in practice. |
| | LDP Graceful Restart for Pseudowire |
| |
|
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. |
| | NSIS Operation Over IP Tunnels |
| |
| | draft-ietf-nsis-tunnel-06.txt |
| | Date: |
23/06/2009 |
| | Authors: |
Charles Shen, Henning Schulzrinne, Sung-Hyuck Lee, Jong Bang |
| | Working Group: |
Next Steps in Signaling (nsis) |
| | Formats: |
txt |
|
This draft presents an NSIS operation over IP tunnel scheme using QoS NSLP as the NSIS signaling application. Both sender-initiated and receiver-initiated NSIS signaling modes are discussed. The scheme creates individual or aggregate tunnel sessions for end-to-end sessions traversing the tunnel. Packets belonging to qualified end- to-end sessions are mapped to corresponding tunnel sessions and assigned special flow IDs to be distinguished from the rest of the tunnel traffic. Tunnel endpoints keep the association of the end-to- end and tunnel session mapping, so that adjustment in one session can be reflected in the other. |
22/06/2009
| |
|
| |
| | Non-Renegable Selective Acknowledgements (NR-SACKs) for SCTP |
| |
|
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. |
| | IPv4 Address Shortage: Needs and Open Issues |
| |
|
This document analyses the main issues related to IPv4 Internet access in the context of public IPv4 address exhaustion. |
| | Problem Statement of IPv4 Support for PMIPv6 Localized Routing |
| |
|
[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. |
| | SIPFIX: Use Cases and Problem Statement for VoIP Monitoring and Exporting |
| |
|
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. |
21/06/2009
| |
|
| |
| | Enhanced validation of domains for HTTP State Management Cookies using DNS |
| |
|
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 |
| |
|
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. |
| | Specifying Location Quality Requirements in Location Protocols |
| |
|
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. |
| | Expressing Confidence in a Location Object |
| |
|
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. |
| | Verified-Hello SMTP extension |
| |
|
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. |
| | Secure Beacon: Securely Detecting a Trusted Network |
| |
|
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. |
20/06/2009
| |
|
| |
| | ECP Groups for IKE and IKEv2 |
| |
|
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. |
18/06/2009
| |
|
| |
| | BGP ACCEPT_OWN Standards Action Community Attribute |
| |
|
Under certain conditions it is desirable for a BGP route reflector to be able to modify the Route Target list of a VPN route that is distributed by the route reflector, enabling the route reflector to control how a route originated within one VRF is imported into other VRFs. This technique works effectively as long as the VRF that exports the route is not on the same PE as the VRF(s) that import the route. However, due to the constraints of the BGP protocol, it does not work if the two are on the same PE. This document describes a modification to the BGP protocol allowing this technique to work when the VRFs are on the same PE, allowing the technique to be used in a standard manner throughout an autonomous system. |
17/06/2009
| |
|
| |
| | A Childless Initiation of the IKE SA |
| |
|
This document describes an extension to the IKEv2 protocol that allows an IKE SA to be created and authenticated without generating a child SA. |
| | A lock feature to SNMP |
| |
|
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. |
| | HMAC-based Extract-and-Expand Key Derivation Function (HKDF) |
| |
|
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. |
| | Pseudowire Congestion Control Framework |
| |
|
Pseudowires are sometimes used to carry non-TCP data flows. In these circumstances the service payload will not react to network congestion by reducing its offered load. Pseudowires should therefore reduces their network bandwidth demands in the face of significant packet loss, including if necessary completely ceasing transmission. Since it is difficult to determine a priori the number of equivalent TCP flow that a pseudowire represents, a suitably "fair" rate of back-off cannot be pre-determined. This document describes pseudowire congestion problem and provides guidance on the development suitable solutions. |
16/06/2009
| |
|
| |
| | RTP Payload Format for Bluetooth's SBC audio codec |
| |
|
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. |
| | PCAP-compatible Binary Syntax for SIP Common Log File Format |
| |
|
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 |
| |
|
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. |
15/06/2009
| |
|
| |
| | The SEED Cipher Algorithm and Its Use with the Secure Real-time Transport Protocol (SRTP) |
| |
| | draft-ietf-avt-seed-srtp-14.txt |
| | Date: |
15/06/2009 |
| | Authors: |
Seokung Yoon, Joongman Kim, Haeryong Park, Hyuncheol Jeong, Yoojae Won |
| | Working Group: |
Audio/Video Transport (avt) |
| | Formats: |
txt |
|
This document describes the use of the SEED 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). |
| | Location Measurements for IEEE 802.16e Devices |
| |
|
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. |
| | How Host A learns the IP address of Host B |
| |
|
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. |
| | Chopan - Compressed HTTP Over PANs |
| |
|
This document describes a method for compressing HTTP messages into a binary format to be transmitted using UDP over 6LoWPAN wireless networks. |
14/06/2009
| |
|
| |
| | Transmission of IPv4 packets over IEEE 802.16's IP Convergence Sublayer |
| |
|
IEEE 802.16 is an air interface specification for wireless broadband access. IEEE 802.16 has specified multiple service specific Convergence Sublayers for transmitting upper layer protocols. The packet CS (Packet Convergence Sublayer) is used for the transport of all packet-based protocols such as Internet Protocol (IP) and IEEE 802.3 (Ethernet). The IP-specific part of the Packet CS enables the transport of IPv4 packets directly over the IEEE 802.16 MAC. This document specifies the frame format, the Maximum Transmission Unit (MTU) and address assignment procedures for transmitting IPv4 packets over the IP-specific part of the Packet Convergence Sublayer of IEEE 802.16. |
| | Service Provider Requirements for Ethernet control with GMPLS |
| |
|
Generalized Multi-Protocol Label Switching (GMPLS) is applicable to Ethernet switches supporting Provider Backbone Bridge Traffic Engineering (PBB-TE) networks. The GMPLS controlled Ethernet label switch network not only automates creation of Ethernet Label Switched Paths(Eth-LSPs), it also provides sophisticated Eth-LSP recovery Mechanisms such as protection and restoration of an Eth-LSP. This document describes the requirements for the set of solutions of GMPLS controlled Ethernet label switch networks. |
| | Multicast Receiver Mobility (MultiReM) Architecture |
| |
|
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. |
13/06/2009
| |
|
| |
| | The CERNET IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition |
| |
| | draft-xli-behave-ivi-02.txt |
| | Date: |
13/06/2009 |
| | Authors: |
Xing Li, Congxiao Bao, Maoke Chen, Hong Zhang, Jianping Wu |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
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. |
12/06/2009
| |
|
| |
| | The References Header for SIP |
| |
|
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. |
| | HTTP Multipart Batched Request Format |
| |
|
This document specifies a format for packaging multiple, independent HTTP requests into a single multipart payload. |
| | SAVI for Delegated IPv6 Prefixes |
| |
|
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. |
| | A set of monitoring tools for Path Computation Element based Architecture |
| |
|
A Path Computation Element (PCE) based architecture has been specified for the computation of Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks in the context of single or multiple domains (where a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems). Path Computation Clients (PCCs) send computation requests to PCEs, and these may forward the requests to and cooperate with other PCEs forming a "path computation chain". In PCE-based environments, it is thus critical to monitor the state of the path computation chain for troubleshooting and performance monitoring purposes: liveness of each element (PCE) involved in the PCE chain, detection of potential resource contention states and statistics in term of path computation times are examples of such metrics of interest. This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) in order to gather such information. |
10/06/2009
| |
|
| |
| | Diameter MIP6 Feature Vector Additional Bit Allocations |
| |
|
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. |
09/06/2009
| |
|
| |
| | DTLS transport mapping for SYSLOG |
| |
|
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. |
| | Atom Bidirectional Attribute |
| |
|
This document adds a new attribute to the Atom Syndication Format used to indicate the base directionality of directionally-neutral characters. |
| | EAP Authentication Extensions for the Dynamic Host Configuration Protocol for Broadband |
| |
|
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). |
| | DTLS as a Transport Layer for RADIUS |
| |
|
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. |
| | Delivery of Request-URI Targets to User Agents |
| |
|
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. |
| | SIP endpoint security case study |
| |
|
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. |
08/06/2009
| |
|
| |
| | The Atom "deleted-entry" Element |
| |
|
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. |
| | Implementing Call Park and Retrieve using the Session Initiation Protocol (SIP) |
| |
|
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. |
| | HIP support for RFID |
| |
|
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 |
| |
|
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. |
07/06/2009
| |
|
| |
| | TCP-over-UDP |
| |
|
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. |
| | Diameter support for EAP Re-authentication Protocol (ERP) |
| |
|
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. |
| | LDAP Schema for vCard v4.0 |
| |
|
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. |
| | DHCPv4 Options for Home Information Discovery in Dual Stack MIPv6 |
| |
|
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. |
05/06/2009
| |
|
| |
| | Definition of ACH TLV Structure |
| |
| | draft-ietf-mpls-tp-ach-tlv-00.txt |
| | Date: |
05/06/2009 |
| | Authors: |
Sami Boutros, Stewart Bryant, Siva Sivabalan, George Swallow, David Ward |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
| | Formats: |
txt xml |
|
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. The following notes (up until the start of "Requirements Language" will be deleted before Working Group Last Call 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. NOTE The intension is to keep this document as a living list of TLVs for some time. When the Working Groups consider that we have captured the majority of the TLVs we will close the document and submit for publication. |
| | A Framework for Distributed Conferencing |
| |
| | draft-romano-dcon-framework-05.txt |
| | Date: |
05/06/2009 |
| | Authors: |
Simon Romano, Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Alfonso Buono |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt xml |
|
This document defines the framework for Distributed Conferencing (DCON). The framework draws inspiration from the work carried out in the XCON working group, which has defined a complete architecture for centralized conferencing. DCON is based on the idea that a distributed conference can be setup by appropriately orchestrating the operation of a number of XCON focus elements, each in charge of managing a certain number of participants. Interaction between each participant and the corresponding conference focus is based on the standard XCON framework, whereas inter-focus interaction is defined in this document. |
| | Requirements for Distributed Conferencing |
| |
|
This document examines the requirements for Distributed Conferencing (DCON). Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols as needed. Together, these documents will provide a guideline for building interoperable conferencing applications. The current works in SIPPING and XCON working groups marginally address the matter, which is nonetheless considered as out-of-scope. The requirements listed in this document are in part based on thoughts derived from the cited working groups activities. |
| | Requirements for the XCON-DCON Synchronization Protocol |
| |
| | draft-romano-dcon-xdsp-reqs-05.txt |
| | Date: |
05/06/2009 |
| | Authors: |
Simon Romano, Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Alfonso Buono |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt xml |
|
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. |
| | Support for Multiple Signature Algorithms in Cryptographically Generated Addresses (CGAs) |
| |
|
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 |
| |
|
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. |
| | Delay/Disruption Tolerant Networking - Network Management Requirements |
| |
|
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. |
| | Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) |
| |
|
This document describes how to use Elliptic Curve Cryptography (ECC) public-key algorithms in the Cryptographic Message Syntax (CMS). The ECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the NIST FIPS 186-3 for digital signature, NIST SP800-56A and SEC1 for key agreement, RFC 3370 and RFC 3565 for key wrap and content encryption, NIST FIPS 180- 3 for message digest, SEC1 for key derivation, and RFC 2104 and RFC 4231 for message authentication code standards. This document obsoletes RFC 3278. |
04/06/2009
| |
|
| |
| | ARP Mediation for IP Interworking of Layer 2 VPN |
| |
|
The VPWS service [L2VPN-FRM] provides point-to-point connections between pairs of Customer Edge (CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge, PE, device) to a pseudowire (connecting the two PEs). In general, the Attachment Circuits must be of the same technology (e.g., both Ethernet, both ATM), and the pseudowire must carry the frames of that technology. However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the pseudowire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as "ARP Mediation". ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit. The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP. |
| | iCalendar XML Representation |
| |
|
This specification defines a format for representing iCalendar data in XML. |
| | Applicability of Keying Methods for RSVP Security |
| |
|
The Resource reSerVation Protocol (RSVP) allows hop-by-hop authentication of RSVP neighbors. This requires messages to be cryptographically signed using a shared secret between participating nodes. This document compares group keying for RSVP with per neighbor or per interface keying, and discusses the associated key provisioning methods as well as applicability and limitations of these approaches. The present document also discusses applicability of group keying to RSVP encryption. |
03/06/2009
| |
|
| |
| | Forcerenew Nonce Authentication |
| |
|
DHCP Forcerenew allows for the reconfiguration of a single host by forcing the DHCP client into a Renew state on a trigger from the DHCP server. In Forcerenew Nonce Authentication the server exchanges a nonce with the client on the initial DHCP ACK that is used for subsequent validation of a Forcerenew message. |
| | Representation of Uncertainty and Confidence in PIDF-LO |
| |
|
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. |
| | GIST: General Internet Signalling Transport |
| |
| | draft-ietf-nsis-ntlp-20.txt |
| | Date: |
03/06/2009 |
| | Authors: |
Henning Schulzrinne, Martin Stiemerling |
| | Working Group: |
Next Steps in Signaling (nsis) |
| | Formats: |
txt |
|
This document specifies protocol stacks for the routing and transport of per-flow signalling messages along the path taken by that flow through the network. The design uses existing transport and security protocols under a common messaging layer, the General Internet Signalling Transport (GIST), which provides a common service for diverse signalling applications. GIST does not handle signalling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path. The combination of GIST and the lower layer transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signalling" framework. |
| | Essential correction for IPv6 ABNF and URI comparison in RFC3261 |
| |
|
This memo corrects the Augmented Backus-Naur Form (ABNF) production rule associated with generating IPv6 literals in RFC3261. It also clarifies the rule for Uniform Resource Identifier (URI) comparison when the URIs contain textual representation of IP addresses. |
02/06/2009
| |
|
| |
| | Access Right Distribution Protocol (ARDP) |
| |
|
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. |
| | Using Imprecise Location for Emergency Context Resolution |
| |
|
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. |
| | Mobile Node Group Identifier option |
| |
|
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. |
| | Retransmitted Message Identification Option for Proxy Mobile IPv6 |
| |
|
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. |
| | Transport of Real-time Inter-network Defense (RID) Messages |
| |
|
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. |
| | Updated IANA Considerations for Diameter Command Code Allocations |
| |
|
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. |
01/06/2009
| |
|
| |
| | Interactions between PMIPv6 and MIPv6: scenarios and related issues |
| |
|
The scenarios where Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6) protocols are both deployed in a network require some analysis and considerations. This document describes all identified possible scenarios, which require an interaction between PMIPv6 and MIPv6 and discusses all issues related to these scenarios. Solutions and recommendations to enable these scenarios are also described. |
| | Common Functions of Large Scale NAT (LSN) |
| |
| | draft-nishitani-cgn-02.txt |
| | Date: |
01/06/2009 |
| | Authors: |
Tomohiro Nishitani, Shin Miyakawa, Akira Nakagawa, Hiroyuki Ashida |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document defines common functions of multiple types of Large Scale Network Address Translation (NAT) that handles Unicast UDP, TCP and ICMP. |
| | Multiprotocol Label Switching Transport Profile Bidirectional Notify Message Packet |
| |
|
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). |
| | E6 Addressing Scheme and Network Architecture |
| |
|
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. |
|
