| |
|
| |
| | Mailing Lists and Internationalized Email Addresses |
| |
|
This document describes considerations for mailing lists with the introduction of internationalized email addresses. This document makes some specific recommendations on how mailing lists should act in various situations. |
| | POP3 Support for UTF-8 |
| |
|
This specification extends the Post Office Protocol version 3 (POP3) to support un-encoded international characters in user names, passwords, mail addresses, message headers, and protocol-level textual error strings. |
| | ENUM Implementation Issues and Experiences |
| |
|
This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it clarifies the ENUM and Dynamic Delegation Discovery System standards. Its aim is to help others by reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. It does not revise the standards, but it is intended to provide technical input to future revisions of those documents. |
| | Dissemination of flow specification rules |
| |
| | draft-ietf-idr-flow-spec-03.txt |
| | Date: |
20/11/2008 |
| | Authors: |
Pedro Roque Marques, Nischal Sheth, Robert Raszuk, Barry Greene, Danny McPherson |
| | Working Group: |
Inter-Domain Routing (idr) |
| | Formats: |
txt |
|
This document defines a new BGP NLRI encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more-specific components of the traffic aggregate defined by an IP destination prefix. Additionally it defines two applications of that encoding format. One that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial of service attacks. And a second application to traffic filtering in the context of a BGP/MPLS VPN service. The information is carried via the Border Gateway Protocol (BGP), thereby reusing protocol algorithms, operational experience and administrative processes such as inter-provider peering agreements. |
| | NEMO Management Information Base |
| |
| | draft-ietf-mext-nemo-mib-02.txt |
| | Date: |
20/11/2008 |
| | Authors: |
Sri Gundavelli, Glenn Mansfield, Kazuhide Koide, Kenichi Nagami |
| | Working Group: |
Mobility EXTensions for IPv6 (mext) |
| | Formats: |
xml txt |
|
This memo defines a portion of the Management Information Base (MIB), the network mobility support (NEMO) MIB, for use with network management protocols in the Internet community. In particular, the NEMO MIB will be used to monitor and control a Mobile IPv6 node with NEMO functionality. |
| | Signaling media decoding dependency in Session Description Protocol (SDP) |
| |
|
This memo defines semantics that allow for signaling the decoding dependency of different media descriptions with the same media type in the Session Description Protocol (SDP). This is required, for example, if media data is separated and transported in different network streamsas a result of the use of a layered or multiple descriptive media coding process. A new grouping type "DDP" -- decoding dependency -- is defined, to be used in conjunction with RFC 3388 entitled "Grouping of Media Lines in the Session Description Protocol". In addition, an attribute is specified describing the relationship of the media streams in a "DDP" group indicated by media identification attribute(s) and media format description(s). |
| | MPLS-TP Requirements |
| |
|
This document specifies the requirements for a MPLS Transport Profile (MPLS-TP). This document is a product of a joint International Telecommunications Union (ITU)-IETF effort to include a MPLS Transport Profile within the IETF MPLS architecture to support the capabilities and functionalities of a packet transport network as defined by International Telecommunications Union - Telecommunications Standardization Sector (ITU-T). This work is based on two sources of requirements, MPLS architecture as defined by IETF and packet transport networks as defined by ITU-T. |
| | The SIEVE mail filtering language - extension for accessing mailbox metadata |
| |
|
This memo defines an extension to the SIEVE mail filtering language (RFC 5228) for accessing mailbox and server annotations (variables). |
| | Usecases and Benefits of end to end ECN support in PCN Domains |
| |
|
This document provides an informative overview of possible use cases where ECN marking can be used for inelastic traffic. It outlines benefits of preserving the ECN support in a PCN domain. As ECN provides with a simple mechanism for network nodes to inform the end points about possible upcoming congestion and resulting packet losses and delay increase, the scheme can be useful for adaptive real-time media applications, thus enabling them to adjust the transmission rate to avoid quality degradation due to congestion. By showing the benefits of ECN this memo asks the working group to consider end to end ECN support in PCN domain. |
| | Usage Agnostic Overlay Operation in RELOAD |
| |
|
RELOAD [1] defines an overlay framework for providing peer-to-peer connectivity and storage/retreival primitives for applications. Applications or usages are expected to reside on top of such an overlay. In general, this is a good design that allows multiple applications to use the same overlay framework. In such a design, however, there are some decisions to be made in terms of what is an overlay function and what must be defined by a usage. These decisions should generally be based on whether the particular function is expecting an operation or guarantee from the overlay nodes in general or from a particular usage only. This type of separation is especially crucial to avoid needing flag days for upgrading nodes in order to accommodate a newer usage version for performing the overlay operation. |
| | A SIP Event Package for Subscribing to Changes to an HTTP Resource |
| |
|
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 |
| |
|
This document proposes an alternative to the Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations [I-D.ietf-behave-turn-tcp] document. |
| | Sieve Email Filtering: MIME part Tests,Iteration,Extraction,Replacement and Enclosure |
| |
|
This document defines extensions to the Sieve email filtering language to permit analysis and manipulation of the MIME body parts of an email message. Note This document is being discussed on the MTA-FILTERS mailing list, ietf-mta-filters@imc.org. |
| | Location Conveyance for the Session Initiation Protocol |
| |
|
This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The extension covers end to end conveyance as well as location-based routing, where SIP servers make routing decisions based on the location of the user agent clients. |
| | Use of DNS SRV and NAPTR Records for SPEERMINT |
| |
|
The objective of this document is to specify the Best Current Practice (BCP) adopted by a service provider providing multimedia communication services such as Voice over Internet Protocol(VoIP) in order to locate another service provider to peer with in the context of Session PEERing for Multimedia INTerconnect. |
| |
|
| |
| | Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction |
| |
| | draft-ietf-dime-mip6-integrated-11.txt |
| | Date: |
19/11/2008 |
| | Authors: |
Jouni Korhonen, Julien Bournelle, Hannes Tschofenig, Charles Perkins, Kuntal Chowdhury |
| | Working Group: |
Diameter Maintenance and Extensions (dime) |
| | Formats: |
txt |
|
A Mobile IPv6 node requires a home agent address, a home address, and a security association with its home agent before it can start utilizing Mobile IPv6. RFC 3775 requires that some or all of these parameters are statically configured. Mobile IPv6 bootstrapping work aims to make this information dynamically available to the Mobile Node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing authentication, authorization and accounting infrastructure. This document describes MIPv6 bootstrapping using the Diameter Network Access Server (NAS) to home Authentication, Authorization and Accounting server (HAAA) interface. |
| | Deprecation of HMAC-MD5 in DNS TSIG and TKEY Resource Records |
| |
|
The main goal of this document is to deprecate the use of HMAC-MD5 as an algorithm for the TSIG (secret key transaction authentication) resource record in the DNS (domain name system). |
| | EAP Generalized Pre-Shared Key (EAP-GPSK) Method |
| |
|
This Internet Draft defines an Extensible Authentication Protocol (EAP) method called EAP Generalized Pre-Shared Key (EAP-GPSK). This method is a lightweight shared-key authentication protocol supporting mutual authentication and key derivation. |
| | BGP Monitoring Protocol |
| |
| | draft-ietf-grow-bmp-00.txt |
| | Date: |
19/11/2008 |
| | Authors: |
John Scudder, Rex Fernando, Stephen Stuart |
| | Working Group: |
Global Routing Operations (grow) |
| | Formats: |
txt |
|
This document proposes a simple protocol, BMP, which can be used to monitor BGP sessions. BMP is intended to provide a more convenient interface for obtaining route views for research purpose than the screen-scraping approach in common use today. The design goals are to keep BMP simple, useful, easily implemented, and minimally service-affecting. BMP is not suitable for use as a routing protocol. |
| | The Unicode code points and IDNA |
| |
|
This document specifies rules for deciding whether a code point, considered in isolation, is a candidate for inclusion in an Internationalized Domain Name. It is part of the specification of IDNA2008. |
| | L2TPv3 Extended Circuit Status Values |
| |
|
This document defines additional Layer 2 Tunneling Protocol Version 3 (L2TPv3) bit values to be used within the "Circuit Status" Attribute Value Pair (AVP) to communicate more granular error states for Access Circuits and Pseudowires. It also deprecates the use of the New bit in the "Circuit Status" AVP, updating RFC3931. |
| | Salted Challenge Response (SCRAM) SASL Mechanism |
| |
|
The secure authentication mechanism most widely deployed and used by Internet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS). There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS. Unfortunately, the challenge response mechanisms presently on the standards track all fail to meet requirements necessary for widespread deployment, and have had success only in limited use. This specification describes a family of authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which addresses the security concerns and meets the deployability requirements. When used in combination with TLS or an equivalent security layer, a mechanism from this family could improve the status-quo for application protocol authentication and provide a suitable choice for a mandatory-to-implement mechanism for future application protocol standards. |
| | DTCP: Dynamic Tasking Control Protocol |
| |
|
Dynamic Tasking Control Protocol is a message-based interface by which an authorized client may connect to a server -- usually a network element (NE) or security policy enforcement point (PEP) -- and issue dynamic requests for data. These tasking requests contain, among other parameters, packet matching criteria that may apply to certain packets flowing through that network element. The primary intent of the tasking request is to instruct that network element to send copies of packets matching those criteria to a destination (usually via tunneling) for further inspection or other action. The protocol contains a security architecture to address client or server spoofing as well as replay prevention. The protocol assumes that multiple clients may simultaneously control a single server. |
| | EAP Authentication Using Only A Password |
| |
|
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. |
| | Common Functions of Large Scale NAT (LSN) |
| |
| | draft-nishitani-cgn-01.txt |
| | Date: |
19/11/2008 |
| | 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. |
| | IESG Procedures for Handling of Independent and IRTF Stream Submissions |
| |
|
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. |
| | LDAP schema for storing SCRAM secrets |
| |
|
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. |
| | Applicability of NAT-PMP with Service Provider Deployments of Network Address Translation |
| |
|
In an effort to conserve global scope IPv4 address allocations, service providers are deploying network address/port translators in their interior routing domain and assigning private addresses to residential and small office subscriber sites. This document discusses the applicability of NAT-PMP is such networks to support application requiring dynamic TCP and UDP port forwarding. |
| | Single PCN Threshold Marking by using PCN baseline encoding for both admission and termination controls |
| |
|
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 proposed algorithm uses threshold marking whose TBthreshold.threshold is set to the number of bits of a metered-packet smaller than the token bucket size. Another threshold for the token bucket is required to change the marking. frequency. Under the flow termination state, all the packets are to be threshold-marked. Under the admission stop state, 1/Nth of packets are to be threshold-marked when the meter indicates. We evaluates the performance of the proposed algorithm by simulations. Our simulation indicates that the performance is almost the same as that of the CL[I-D.briscoe-tsvwg-cl-architecture] algorithm. |
| | LDAP Dereference Control |
| |
|
This document describes the Dereference Control for LDAP. This control is intended to provide a concise means to collect extra information related to cross-links present in entries returned as part of search responses. |
| | LDAP "What Failed?" Control |
| |
|
This document describes the LDAP "What Failed?" control. This control allows DUAs to request, in response to a failed operation request, the object identifier of those extensions that caused the operation to fail. |
| | UDP Convergence Layers for the DTN Bundle and LTP Protocols |
| |
|
This document specifies the use of the User Datagram Protocol (UDP) as a method for transporting DTN protocol data over the Internet. The specification covers both the use of UDP as a convergence layer for the Bundle Protocol as well as the use of UDP to carry LTP segments. |
| | Destination-Driven On-Demand Multicast Routing Protocol |
| |
|
Our protocol embeds a destination-driven feature into the on-demand multicast structure building process of an existing multicast protocol ODMRP (On-Demand Multicast Routing Protocol), which is a mesh-based multicast scheme and uses a forwarding group concept. The design objective of destination-driven on-demand multicast routing protocol (D-ODMRP) is to improve the multicast forwarding efficiency for wireless Ad Hoc networks. To achieve this goal, the path to reach a multicast destination is biased towards those paths passing through another multicast destination. |
| | Path Computation Element (PCE) Communication Protocol (PCEP) |
| |
| | draft-ietf-pce-pcep-19.txt |
| | Date: |
19/11/2008 |
| | Authors: |
Arthi Ayyangar, Adrian Farrel, Eiji Oki, Alia Atlas, Andrew Dolganow, Yuichi Ikejiri, Kenji Kumaki, JP Vasseur, Jean-Louis Le Roux |
| | Working Group: |
Path Computation Element (pce) |
| | Formats: |
txt |
|
This document specifies the Path Computation Element Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. |
| | Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS) |
| |
|
This memo describes the requirements for a crypto-agility solution for Remote Authentication Dial-In User Service (RADIUS). |
| | Home Automation Routing Requirements in Low Power and Lossy Networks |
| |
|
This document presents home control and automation application specific requirements for Routing Over Low power and Lossy networks (ROLL). In a modern home, a high number of wireless devices are used for a wide set of purposes. Examples include actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure) and advanced controllers. Because such devices only cover a limited radio range, routing is often required. The aim of this document is to specify the routing requirements for networks comprising such constrained devices in a home control and automation environment. |
| |
|
| |
| | Transmission of IP over Ethernet over IEEE 802.16 Networks |
| |
|
This document describes the transmission of IPv4 over Ethernet as well as IPv6 over Ethernet in an access network deploying the IEEE 802.16 cellular radio transmission technology. The Ethernet on top of IEEE 802.16 is realized by bridging connections which the IEEE 802.16 provides between a base station and its associated subscriber stations. Due to the resource constraints of radio transmission systems and the limitations of the IEEE 802.16 MAC functionality for the realization of an Ethernet, the transmission of IP over Ethernet over IEEE 802.16 may considerably benefit by adding IP specific support functions in the Ethernet over IEEE 802.16 while maintaining full compatibility with standard IP over Ethernet behavior. |
| | Neighbor Discovery for 6LoWPAN |
| |
| | draft-ietf-6lowpan-nd-00.txt |
| | Date: |
18/11/2008 |
| | Authors: |
Zach Shelby, Pascal Thubert, Jonathan Hui, Samita Chakrabarti, Erik Nordmark |
| | Working Group: |
IPv6 over Low power WPAN (6lowpan) |
| | Formats: |
xml txt |
|
This document specifies Neighbor Discovery optimized for 6LoWPAN. The 6LoWPAN format allows IPv6 to be used over very low-power, low- bandwidth wireless networks often making use of extended multihop topologies. However, the use of standard IPv6 Neighbor Discovery over 6LoWPAN networks has several problems. Standard Neighbor Discovery was not designed for wireless links, the standard IPv6 link concept and heavy use of multicast makes it inefficient. This document spefies a new mechanism allowing efficient Duplicate Address Detection over entire 6LoWPAN networks. In addition it specifies prefix and context dissemination for use with router advertisements, allows for stateless address assignment, and the use of Neighbor Discovery Proxy. This document is an identical replacement of draft-shelby-6lowpan-nd-01. This document was now submitted as a 6lowpan working group document. |
| | Problem Statement and Requirements for 6LoWPAN Routing |
| |
|
This document provides the problem statement for 6LoWPAN routing. It also defines the requirements for 6LoWPAN routing considering IEEE 802.15.4 specificities and the low-power characteristics of the network and its devices. |
| | Support for Reduced-Size RTCP,Opportunities and Consequences |
| |
|
This memo discusses benefits and issues that arise when allowing RTCP packets to be transmitted with reduced size. The size can be reduced if the rules on how to create compound packets outlined in RFC3550 are removed or changed. Based on that analysis this memo defines certain changes to the rules to allow feedback messages to be sent as reduced-size RTCP packets under certain conditions when using the RTP AVPF profile (RFC 4585). This document updates [RFC3550], [RFC3711] and [RFC4585]. |
| | Test vectors for STUN |
| |
|
The Session Traversal Utilities for NAT (STUN) protocol defines several STUN attributes. The content of some of these -- FINGERPRINT, MESSAGE-INTEGRITY and XOR-MAPPED-ADDRESS -- involve binary-logical operations (hashing, xor). This document provides test vectors for those attributes. |
| | Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS) |
| |
|
This document describes requirements for, and use of, the Generalized Multi-Protocol Label Switching (GMPLS) control plane in conjunction with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing mechanism and its companion Link Capacity Adjustment Scheme (LCAS) which can be used for hitless dynamic resizing of the inverse multiplex group. These techniques apply to Optical Transport Network (OTN), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals. |
| | DHCPv6 option for network boot |
| |
|
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a framework for passing configuration information to nodes on a network. This document describes a new option for DHCPv6 to convey information, required for network booting, to the nodes. |
| | ForCES Protocol Specification |
| |
| | draft-ietf-forces-protocol-19.txt |
| | Date: |
18/11/2008 |
| | Authors: |
Ligang Dong, Avri Doria, Ram Gopal, Robert HAAS, Jamal Salim, Hormuzd Khosravi, Weiming Wang |
| | Working Group: |
Forwarding and Control Element Separation (forces) |
| | Formats: |
txt xml |
|
This document specifies the Forwarding and Control Element Separation (ForCES) protocol. ForCES protocol is used for communications between Control Elements(CEs) and Forwarding Elements (FEs) in a ForCES Network Element (ForCES NE). This specification is intended to meet the ForCES protocol requirements defined in RFC3654. Besides the ForCES protocol, this specification also defines the requirements for the Transport Mapping Layer (TML).Authors The participants in the ForCES Protocol Team, primary co-authors and co-editors, of this protocol specification, are: Ligang Dong (Zhejiang Gongshang University), Avri Doria (Lulea University of Technology), Ram Gopal (Nokia), Robert Haas (IBM), Jamal Hadi Salim (Znyx), Hormuzd M Khosravi (Intel), and Weiming Wang (Zhejiang Gongshang University). Special acknowledgement goes to Joel Halpern who has done extensive editing in support of congruence between the model and this protocol specification. Without his participation and persistence, this specification might never have been completed. |
| | Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework |
| |
|
This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. |
| | Capabilities Advertisement with BGP-4 |
| |
|
This document defines an Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated. This document obsoletes RFC 3392. |
| | IPv6 Configuration in IKEv2 |
| |
|
When IKEv2 is used for remote VPN access (client to VPN gateway), the gateway assigns the client an IP address from the internal network using IKEv2 configuration payloads. The configuration payloads specified in RFC 4306 work well for IPv4, but make it difficult to use certain features of IPv6. This document describes the limitations of current IKEv2 configuration payloads for IPv6, and explores possible solutions that would allow IKEv2 to set up full- featured virtual IPv6 interfaces. |
| | Simplified Extension of LSP Space for IS-IS |
| |
| | draft-ietf-isis-wg-extlsp-04.txt |
| | Date: |
18/11/2008 |
| | Authors: |
Les Ginsberg, Stefano Previdi, Mike Shand, Danny McPherson |
| | Working Group: |
IS-IS for IP Internets (isis) |
| | Formats: |
txt |
|
This draft describes a simplified method for extending the LSP space beyond the 256 Link State PDU (LSP) limit defined in [IS-IS]. This method is intended as a preferred replacement for the method defined in [RFC 3786]. |
| | IS-IS Generic Cryptographic Authentication |
| |
|
This document proposes an extension to Intermediate System to Intermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already documented authentication schemes, described in the base specification and RFC 5304. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. Although this document has been written specifically for using the Hashed Message Authentication Code (HMAC) construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future. |
| | Considerations about Multicast for BGP/MPLS VPN Standardization |
| |
|
The current proposal for multicast in BGP/MPLS includes multiple alternative mechanisms for some of the required building blocks of the solution. The aim of this document is to leverage previously documented requirements to identify the key elements and help move forward solution design, toward the definition of a standard having a well defined set of mandatory procedures. The different proposed alternative mechanisms are examined in the light of requirements identified for multicast in L3VPNs, and suggestions are made about which of these mechanisms standardization should favor. Issues related to existing deployments of early implementations are also addressed. |
| | Generalized MANET Packet/Message Format |
| |
| | draft-ietf-manet-packetbb-17.txt |
| | Date: |
18/11/2008 |
| | Authors: |
Thomas Clausen, Christopher Dearlove, Justin Dean, Cedric Adjih |
| | Working Group: |
Mobile Ad-hoc Networks (manet) |
| | Formats: |
txt |
|
This document specifies a packet format capable of carrying multiple messages that may be used by mobile ad hoc network routing protocols. |
| | Dual Stack Mobile IPv4 |
| |
|
This specification provides IPv6 extensions to the Mobile IPv4 protocol. The extensions allow a dual stack node to use IPv4 and IPv6 home addresses as well as to move between IPv4 and dual stack network infrastructures. |
| | Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Server (MoS) discovery |
| |
|
This document defines a number of Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options that contain a list of domain names or IP addresses that can be mapped to servers providing IEEE 802.21 type of Mobility Services [MSFD]. These Mobility Services are used to assist an MN in handover preparation (network discovery) and handover decision (network selection). The services addressed in this document are the Media Independent Handover Services defined in [IEEE802.21]. |
| | Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP) |
| |
|
The offer/answer model for SDP assumes that endpoints establish somehow the QoS required for the media streams they establish. Endpoints in closed environments typically agree out of band (e.g., using configuration information) which QoS mechanism to use. However, on the Internet, there is more than one QoS service available. Consequently, there is a need for a mechanism to negotiate which QoS mechanism to use for a particular media stream. This document defines such a mechanism. |
| | IMAP METADATA Extension |
| |
|
The METADATA extension to the Internet Message Access Protocol permits clients and servers to maintain "annotations" or "meta data" on IMAP servers. It is possible to have annotations on a per-mailbox basis or on the server as a whole. For example, this would allow comments about the purpose of a particular mailbox to be "attached" to that mailbox, or a "message of the day" containing server status information to be made available to anyone logging in to the server. |
| | The Session Initiation Protocol (SIP) P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem |
| |
|
This document specifies the SIP P-Served-User P-header. This header field addresses an issue that was found in the 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) between an S-CSCF (Serving Call Session Control Function) and an AS (Application Server) on the ISC (IMS Subsystem Service Control) interface. This header field conveys the identity of the served user and the session case that applies to this particular communication session and application invocation. |
| | Layer 2 Tunneling Protocol (L2TP) Access Line Information Attribute Value Pair (AVP) Extensions |
| |
|
This document describes a set of Layer 2 Tunneling Protocol (L2TP) Attribute Value Pair (AVP) extensions designed to carry the subscriber Access Line identification and characterization information that arrives at the Broadband Remote Access Server (BRAS) with LAC functionality. It also describes a mechanism to report connection speed changes, after the initial connection speeds are sent during session establishment. The primary purpose of this document is to provide a reference for DSL equipment vendors wishing to interoperate with other vendors' products. The L2TP AVPs defined in this document are applicable to both L2TPv2 and L2TPv3. |
| | Multicast Mobility in MIPv6: Problem Statement and Brief Survey |
| |
|
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. |
| | Diameter ITU-T Rw Policy Enforcement Interface Application |
| |
|
This document describes the need for a new pair of IANA Diameter Command Codes to be used in a vendor-specific new application, namely for the ITU-T Rec. Q.3303.3 - Rw interface used to send a request/ responses for authorizing network QoS resources and policy enforcement in a network element, as one of the recommendations of the International Telecommunication Union - Telecommunication Standardization Sector (ITU-T). |
| | Simplified View-based Access Control Model (SVACM) for the Simple Network Management Protocol (SNMP) |
| |
|
This document introduces a Simplified View-based Access Control Model (SVACM) for the Simple Network Management Protocol (SNMP), which is useful for the access control application of SNMP protocol. This document describes the procedure of access control in SVACM with Remote Authentication Dial In User Service (RADIUS) server for authorization. This document also includes a Management Information Base (MIB) for remotely managing the configuration parameters for SVACM. |
| | Lightweight DHCPv6 Relay Agent (LDRA) |
| |
| | draft-miles-dhc-dhcpv6-ldra-02.txt |
| | Date: |
18/11/2008 |
| | Authors: |
David Miles, Sven Ooghe, Wojciech Dec, Suresh Krishnan, Alan Kavanagh |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that is used to insert relay agent options in DHCPv6 message exchanges identifying client-facing interfaces. The LDRA can be implemented in existing access nodes (such as DSLAMs and Ethernet switches) that do not support IPv6 control or routing functions. |
| | Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA') |
| |
|
This specification defines a new EAP method, EAP-AKA', a small revision of the EAP-AKA method. The change is a new key derivation function that binds the keys derived within the method to the name of the access network. The new key derivation mechanism has been defined in the 3rd Generation Partnership Project (3GPP). This specification allows its use in EAP in an interoperable manner. In addition, EAP-AKA' employs SHA-256 instead of SHA-1. This specification also updates RFC 4187 EAP-AKA to prevent bidding down attacks from EAP-AKA'. |
| | Hierarchical OLSR |
| |
|
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 nodes 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 node'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. |
| | An IRI/URI Namespace for International Object Identifiers (OIDs) |
| |
|
This internet draft defines the IRI/URI scheme for International Object Identifiers. The syntax and semantics of the IRI is specified below using the International Object Identifier tree specified in [ITU-T X.660]. |
| | The Remote Framebuffer Protocol |
| |
|
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. |
| | BFD Generic Cryptographic Authentication |
| |
|
This document proposes an extension for Bidirectional Forwarding Detection (BFD) to allow the use of any cryptographic authentication algorithm in addition to the already documented authentication schemes, described in the base specification. Although this document has been written specifically to introduce two new Authentication types it describes how BFD can use Hashed Message Authentication Code (HMAC) construct along with the Secure Hash algorithm (SHA) [FIPS-180-3] family of cryptographic hash functions to authenticate the control packets. The method described in this document is generic and can be used to extend BFD to support any cryptographic hash function in the future. |
| | Using SCTP as a Transport Layer Protocol for HTTP |
| |
|
Hyper-Text Transfer Protocol (HTTP) [RFC2116] 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 other innovative services unavailable in TCP. The objectives of this draft are three-fold: (i) to highlight SCTP services that better match HTTP's needs than TCP, (ii) to propose a design for persistent and pipelined HTTP 1.1 transactions over SCTP's multistreaming service, and (iii) to share some lessons learned from implementing HTTP over SCTP. Finally, open issues warranting more discussion and/or investigation are listed. |
| | CRAM-MD5 to historic |
| |
|
This document recommends the retirement of the CRAM-MD5 authentication mechanism, and discusses the reasons for doing so. This document recommends RFC 2195 and its predecessor, RFC 2095, be moved to Historic status. |
| | Ethernet MAC Destination Address for Multicast MPLS |
| |
|
This document identifies a set of required clarifications to make it explicit what Ethernet MAC destination address is to be used for multicast MPLS packets, and intends to provide an update to RFC5332. |
| | vCard XML Schema |
| |
|
This document defines the XML schema of the vCard data format. |
| | A Session Identifier for the Session Initiation Protocol (SIP) |
| |
|
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. Kaplan Expires May 18, 2009 [page 1] SIP Session Identifier November 2008 |
| | Oxum: Octet Stream Sum http://www.ietf.org/internet-drafts/draft-kunze-oxum-00.txt |
| |
|
This document specifies "oxum", a two-part number, OCTETS.STREAMS, that is a kind of simple size summary for complex digital objects. In the mainstream case of a complex object that is a set of files, the STREAMS part is the total number of files and the OCTETS part is the total number of 8-bit bytes across all those files; for example, an oxum of 876543.21 could mean a total of 876,543 bytes across 21 files. Which set of streams comprises a complex object for an oxum computation depends in general on the object's type. One important type is the stream set defined by the set of files contained in a file hierarchy. An oxum is not a checksum in that, while a changed oxum means a changed object, an unchanged oxum does not mean an unchanged object.1. The size of a digital object It can be hard to characterize the size of an arbitrary digital object. Word count, page count, image dimensions, video running time, or number of database records might all be useful metrics, depending on the type of the object. For a single file, one crude but easily obtained metric is the number of octets (8-bit bytes) in the file. This document introduces an analogous metric for a _complex digital object_, by which we mean an object that is not equivalent to a single file. A complex object may consist of a group of files or parts of one or more files (e.g., a database).2. The octet stream sum (oxum) A complex digital object that has a well-defined set of octet streams, such as a document represented by a group of 14 text and image files, has a well-defined "oxum" (octet stream sum). The oxum is a two part number such as 567898.14 which corresponds to 567,898 octets spread over 14 files. The general form of an oxum is OCTETS.STREAMS where STREAMS is the total number of streams (e.g., files) and OCTETS is the total number of octets across all those streams. In general, these two numbers will be positive integers, although there may be situations (not described here) in which it makes sense for either one of them to be left unspecified with a hyphen ('-'). The period ('.') separator is required. Other examples: 1998.10 # 1998 octets spread over 10 streams 105.3 # 105 octets, 3 streams (not 105 and 3 tenths) 21436794142.831 # almost 19 Gigabytes spread over 831 streams 709895249489.8756 # about 661 Gb, or 710 Gb if you divide by 1000 -.1 # one stream, but number of octets not known yet The oxum is designed to be machine readable and to fit into a variety of syntactic contexts, such as command lines, file paths, URL [RFC3986] query strings, and XML [XML] tags. Note that the oxum is _not_ designed as a secure digest or checksum. While an oxum cannot change without a change to the object, an unchanged oxum absolutely does not imply an unchanged object. Do not use oxum in place of a cryptographic digest algorithm (cf. SHA1 [RFC3174]).3. Oxum complex object types An _oxum object type_ is used to describe how to derive an object's stream set. For oxum to be meaningful for an object type, the type must have a well-defined, canonical stream set. Once the stream set is known, the oxum computation is straightforward and the streams can be processed in any order. One especially natural way to derive a stream set is to define a way to reduce an object type to a file group. Files are primal streams. In this document, a "regular" file is a contiguous sequence of octets with a well-defined start and end, whether the sequence is named in static storage (e.g., "memo.pdf") or is unnamed and recently retrieved (e.g., a web page) from a network socket. There are many filesystem entities that are not regular files, including directory nodes, block special files, and symbolic links. In this document, the word "file" usually refers to a regular file. A (regular) file is an oxum-ready stream. As a base case, a complex object consisting of exactly one file has an oxum of the form "OCTETS.1", as in 12345.1 Things get more interesting when dealing with more than one file. Any private or public agreement can be made about what constitutes a file group, hence a stream set, for the purposes of an oxum computation. A stream set might be declared to comprise all the attachments of an email message, or all the files resulting from a normalized dump procedure run against the tables of a database. An easily delineated group is all the files contained in a directory. Any recognized group of regular files can form on oxum stream set, including a simple manifest or list of filenames. For example, a transfer protocol might use oxum to help set the receiver's expectations in terms of total bytes and files contained in a transferred package [GRABIT]. |
| | P4P: Provider Portal for P2P Applications |
| |
| | draft-p4p-framework-00.txt |
| | Date: |
18/11/2008 |
| | Authors: |
Richard Alimi, Doug Pasko, Laird Popkin, Ye Wang, Yang Yang |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
P4P is a framework that enables Internet Service Providers (ISPs) and network application software distributors to work jointly and cooperatively to optimize application communications. The goals of this cooperation are to reduce network resource consumption and to accelerate network applications. In this document, we specify how P4P allows ISPs to provide network guidance to applications, allowing clients to exchange data more effectively. The applications we focus on are those that can have a choice in connection patterns, in particular peer-to-peer (P2P) applications. |
| | Applicability Statement of NSIS Protocols in Mobile Environments |
| |
|
Mobility of an IP-based node affects routing paths, and as a result, can have a significant effect on the protocol operation and state management. This draft discusses the effects mobility can cause to the NSIS protocol suite, and how the protocols operate in different scenarios, with mobility management protocols. |
| | Advertising a Router's Local Addresses in OSPF TE Extensions |
| |
|
OSPF Traffic Engineering (TE) extensions are used to advertise TE Link State Advertisements (LSAs) containing information about TE- enabled links. The only addresses belonging to a router that are advertised in TE LSAs are the local addresses corresponding to TE- enabled links, and the local address corresponding to the Router ID. In order to allow other routers in a network to compute Multiprotocol Label Switching (MPLS) traffic engineered Label Switched Paths (TE LSPs) to a given router's local addresses, those addresses must also be advertised by OSPF TE. This document describes procedures that enhance OSPF TE to advertise a router's local addresses. |
| | OSPF Version 2 MIB for Multi-Topology (MT) Routing |
| |
|
This memo defines an extension to the Open Shortest Path First version 2 Management Information Base (OSPFv2 MIB) for use with network management protocols in the Internet community. In particular it describes objects and lists considerations for the management of OSPF Multi-Topology routing. |
| | Reliable Server Pooling: Management Information Base using SMIv2 |
| |
|
RSerPool [RFC5351] is a framework to provide reliable server pooling. This document defines a SMIv2 compliant Management Information Base (MIB) providing access to managed objects in an RSerPool implementation. |
| | Message Body Handling in the Session Initiation Protocol (SIP) |
| |
|
This document specifies how message bodies are handled in SIP. Additionally, this document specifies SIP user agent support for MIME (Multipurpose Internet Mail Extensions) in message bodies. |
| | SPEERMINT Terminology |
| |
|
This document defines the terminology that is to be used in describing Session PEERing for Multimedia INTerconnect (SPEERMINT). |