|
Internet Drafts - Sorted by name
| | | | |
| draft-abeille-netlmm-proxymip6ro-01.txt |
| | Route Optimization for Proxy Mobile IPv6 |
| |
|
The IETF is specifying a protocol for network-based localized mobility management, which takes basic operation for registration, tunnel management and de-registration into account. This document specifies a protocol for route optimization in networks, which support network-based mobility management. The specified protocol focuses on efficient set up and maintenance of a route optimized path between two mobile nodes and suits complex mobility scenarios as well as networks with multiple mobility anchors. |
| | | | |
| draft-abhi-covert-00.txt |
| | Normalization in the unused header fields of TCP/IP |
| |
|
The unused fields in TCP/IP can be used to establish malicious communication channel[1][2][3]. This draft presents the fieldsin TCP/IP and ICMP messages and the values which must be enforced before the packets are streamed to the network so as to prevent the malicious communication channel. |
| | | | |
| draft-abhi-eap-radius-00.txt |
| | Secure Communication of EAP - Radius messages |
| |
|
EAP is used to establish secure communication channel in IKEv2 and in Wireless Security. EAP-TLS, EAP-TTLS, EAP-MD5, EAP-SIM uses radius protocol for communication bewteen radius server and the client. These protocols are used in both Wireless network authentication and in IKEV2 authentication to establish VPN tunnel. +----------+ +----------+ +----------+ | | EAPOL | EAP | RADIUS | | | EAP |<------>| Server |<------>| RADIUS | | Client | EAPOW | | (EAP) | Server | | | | | | | +----------+ +----------+ +----------+ This draft presents the security protocol which can be used to establish the secure communication channel between the radius server and pass through server. Pass through server is access point in the case of wireless communication and it is gateway in case of IKEV2 authnetication. |
| | | | |
| draft-aboba-radext-wlan-07.txt |
| | RADIUS Attributes for IEEE 802 Networks |
| |
|
RFC 3580 provides guidelines for the use of the Remote Authentication Dialin User Service (RADIUS) within IEEE 802 local area networks (LANs). This document proposes additional attributes for use within IEEE 802 networks. The attributes defined in this document are usable both within RADIUS and Diameter. |
| | | | |
| draft-acee-mip4-bulk-revocation-01.txt |
| | Bulk Registration Revocation in Mobile IPv4 |
| |
|
This document describes an extension to Mobile IPv4 Registration Revocation (as described in RFC 3543) for a home or foreign agent to revoke mobile IP services for multiple bindings or visitors with a single registration revocation exchange. |
| | | | |
| draft-acee-ospf-multi-instance-01.txt |
| | OSPF Multi-Instance Extensions |
| |
|
OSPFv3 includes a mechanism for supporting multiple instances on the same link. OSPFv2 could benefit from such a mechanism in order to support multiple routing domains on the same subnet. The OSPFv2 instance ID is reserved for support of separate OSPFv2 protocol instances. This is different from OSPFv3 where it could be used for other purposes such as putting the same link in multiple areas. OSPFv2 supports this capability using a separate subnet or the OSPF multi-area adjacency capability. |
| | | | |
| draft-adolf-dvb-urn-03.txt |
| | A Uniform Resource Name (URN) Namespace for the Digital Video Broadcasting Project (DVB) |
| |
|
This document describes a Uniform Resource Name (URN) namespace for the Digital Video Broadcasting Project (DVB) for naming persistent resources defined within DVB standards. Example resources include technical documents and specifications, eXtensible Markup Language (XML) Schemas, classification schemes, XML Document Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by DVB. |
| | | | |
| draft-ahrenholz-hiprg-dht-02.txt |
| | HIP DHT Interface |
| |
|
This document specifies a common interface for using HIP with a Distributed Hash Table service to provide a HIT-to-address lookup service and an unmanaged name-to-HIT lookup service. |
| | | | |
| draft-aitken-ipfix-new-infos-03.txt |
| | New Information Elements from the IPFIX Information Model |
| |
|
This document specifies the IPFIX protocol that serves for transmitting IP traffic flow information over the network. In order Aitken, Claise Standard Track [page 1] New Information Elements for the IPFIX Information Model March 2008 to transmit IP traffic flow information from an exporting process to an information collecting process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX data and templates records are carried over a number of transport protocols from an IPFIX exporting process to an IPFIX collecting process. |
| | | | |
| draft-akhter-bmwg-mpls-meth-03.txt |
| | MPLS Benchmarking Methodology |
| |
|
The purpose of this draft is to describe a methodology specific to the benchmarking of MPLS forwarding devices. The scope of this benchmarking will be limited to various types of packet-forwarding and delay measurements. It builds upon the tenets set forth in RFC2544 [RFC2544], RFC1242 [RFC1242] and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the MPLS paradigm. The BMWG produces two major classes of documents: Benchmarking |
| | | | |
| draft-alexander-bmwg-wlan-switch-meth-01.txt |
| | Benchmarking Methodology for Wireless LAN Switching Systems |
| |
|
This document provides a framework and methodology for performing performance test and benchmarking of wireless LAN (WLAN) switches and controllers, including systems comprising groups of controllers and WTPs. This document defines and discusses a number of tests and associated test conditions that may be used to characterize the performance of such systems, and also supplies the methods used to calculate the expected results of these tests. Specific formats for reporting the results of the tests are also provided, where applicable. The tests described in this document extend the methodology defined for benchmarking network interconnect devices in RFC 2544, and LAN switches in RFC 2889, to WLAN switch controller systems. The methodology herein is to be used together with the companion terminology document. |
| | | | |
| draft-alexander-bmwg-wlan-switch-term-01.txt |
| | Benchmarking Terminology for Wireless LAN Switching Systems |
| |
|
This document provides a terminology to be used when performing performance test and benchmarking of wireless LAN (WLAN) switches and controllers, including systems comprising groups of controllers and Access Points. The various wireless-specific device nomenclature, as well as the definitions of configuration parameters and test conditions that may be used to characterize the performance of these devices, are provided. The document also defines some of the metrics used during WLAN switch benchmarking. This terminology is to be used in conjunction with the companion methodology document. |
| | | | |
| draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-06.txt |
| | Address Resolution for GMPLS controlled PSC Ethernet Interfaces |
| |
|
This document outlines some interoperability issues observed with the use of ARP over GMPLS controlled Ethernet router-to- router (PSC) interfaces transiting from a non-Ethernet core, e.g., FSC or LSC core. The document also recommends some procedures to address these issues. The aim of this document is to facilitate and ensure better interworking of GMPLS- capable Label Switching Routers (LSRs), based on experience gained in interoperability testing. |
| | | | |
| draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt |
| | Ping and Traceroute with Evidence Collection in Photonic Networks |
| |
|
Z. Ali, et Al. Expires August 2008 [page 1] Internet-Draft draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07 [RFC4379] describes procedures for ping and tracerouting for LSPs with PSC (packet switch capable) transit switching capability. An important implication of using transparent (non-PSC) nodes in GMPLS network is that LSP Ping solution described in [RFC4379] are not applicable to LSP with non-PSC switching capability. Another important difference between PSC and non-PSC switching technologies is the data and control plan separation in the latter case. An implication of the separation of data and control planes in GMPLS networks is that LSP traceroute procedures described in [RFC4379] are not directly applicable to GMPLS networks with separation of data and control planes. The scope of this draft is cases where data plane does not provide the OAM functions addressed by this draft. This document is assumed that OAM mechanisms provided by the underlying data plan technology MUST be used, whenever possible. E.g., G.709 addresses the problem of trace routing in DWDM network. However, G.709 OAM mechanisms are only applicable to OEO (Optical-Electrical-Optical) capable node. This document fills in such gaps; in particular it addresses GMPLS OAM functionality in optical networks with wavelength routers, ROADMs nodes, etc. with no OEO conversion capability. For this purpose, the draft relies on control plan mechanism to provide required OAM functions. Specifically the proposed solutions are based on Link Management Protocol (LMP) [RFC4204] and RSVP-TE [RFC3209], [RFC3473] and do not require any extension to the data plan. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. |
| | | | |
| draft-altman-telnet-rfc2941bis-02.txt |
| | Telnet Authentication Option |
| |
|
This document describes the authentication option to the Telnet protocol, RFC 854, as a generic method for negotiating an authentication type and mode including whether encryption should be used and if credentials should be forwarded. While this document summarizes currently utilized commands and types it does not define a specific authentication type. Separate documents are to be published defining each authentication type. This document updates a previous specification of the Telnet authentication option, RFC 2941, to allow the AUTHENTICATION option to be used in conjunction with the START_TLS option, RFC XXXX. |
| | | | |
| draft-altman-telnet-rfc2942bis-02.txt |
| | Telnet Authentication: Kerberos Version 5 |
| |
|
This document describes how Kerberos Version 5 [RFC 4120] is used with the Telnet protocol [RFC 854]. It describes an Telnet Authentication suboption to be used with the Telnet Authentication option [RFC YYYY]. This mechanism can also used to provide keying material to provide data confidentiality services in conjunction with the Telnet Encryption option [RFC 2946]. This document updates a previous specification of the Telnet Authentication Kerberos 5 method, RFC 2942 [4], to allow Kerberos 5 Telnet authentication to be used in conjunction with the START_TLS option [RFC XXXX]. |
| | | | |
| draft-altman-telnet-rfc2944bis-02.txt |
| | Telnet Authentication: SRP |
| |
|
This document specifies an authentication scheme for the Telnet protocol [RFC 854] under the framework described in [RFC YYYY], using the Secure Remote Password Protocol (SRP) authentication mechanism. The specific mechanism, SRP-SHA1, is described in [RFC2945]. This document updates a previous specification of the Telnet Authentication SRP method, RFC 2944, to allow SRP Telnet authentication to be used in conjunction with the Telnet START_TLS option [RFC YYYY]. |
| | | | |
| draft-altman-telnet-starttls-02.txt |
| | Telnet START-TLS Option |
| |
|
Telnet service has long been a standard Internet protocol. However, a standard way of ensuring privacy and integrity of Telnet sessions has been lacking. This document proposes a standard method for Telnet servers and clients to use the Transport Layer Security (TLS) protocol. It describes how two Telnet participants can decide whether or not to attempt TLS negotiation, and how the two participants should process authentication credentials exchanged as a part of TLS startup. |
| | | | |
| draft-alvestrand-idna-bidi-04.txt |
| | An updated IDNA criterion for right-to-left scripts |
| |
|
The use of right-to-left scripts in internationalized domain names has presented several challenges. This memo discusses some problems with these scripts, and some shortcomings in the 2003 IDNA BIDI criterion. Based on this discussion, it proposes a new BIDI criterion for IDNA labels. |
| | | | |
| draft-amante-oam-ng-requirements-01.txt |
| | Operations and Maintenance Next Generation Requirements |
| |
|
Current IP and MPLS OAM techniques need to be extended to permit operators to effectively diagnose load-balancing issues. Specifically, new ad-hoc OAM techniques are needed to diganose various link-bundling techniques, such as IP/MPLS Equal Cost Multi- Path (ECMP) and Link Aggregation Groups (LAG). In addition, these OAM tools should also be extended to permit performance monitoring over longer time durations. This document defines requirements for the next generation of OAM solutions. |
| | | | |
| draft-andersson-mpls-expbits-def-00.txt |
| | MPLS EXP-bits definition |
| |
|
- Table of Contents |
| | | | |
| draft-andreasen-mgcp-fax-08.txt |
| | Media Gateway Control Protocol Fax Package |
| |
|
This document defines a Media Gateway Control Protocol (MGCP) package to support fax calls. The package allows for fax calls to be supported in two different ways. The first one utilizes ITU-T Recommendation T.38 for fax relay under the control of the Call Agent. The second one lets the gateway decide upon a method for fax transmission as well as handle the details of the fax call without Call Agent involvement. |
| | | | |
| draft-andreasen-sipping-rfc3603bis-05.txt |
| | Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture |
| |
|
In order to deploy a residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol (SIP) [RFC3261] for supporting the exchange of customer information and billing information between trusted entities in the PacketCable Distributed Call Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required. |
| | | | |
| draft-antoine-mip4-proxymobike-01.txt |
| | Mobility using Proxy MIP and Mobike |
| |
|
The simultaneous use of Mobike and Mobile IPv4 has been proposed to provide secure connectivity and session continuity to roaming corporate users. Optimization of this solution have eliminated the tunneling overhead of Mobile IPv4 in the vpn tunnel by having a Foreign Agent co-located to the mobile vpn gateway. This document further proposes an interaction between Mobike and Proxy Mobile IP that simplifies implementation and deployment of the previous methods. The mobile vpn gateway is co-located to the Mobility Proxy Agent and each Access Point in the corporate network is equipped with Proxy Mobile IP. When moving outside the corporate network, the Mobile Node secure connectivity and session continuity is handled by Mobike. Proxy Mobile IP alone is used to handle mobility when the Mobile Node moves within the corporate network. This document introduces an interaction between Internet Key Exchange v2 and Proxy Mobile IP in which the Internet Key Exchange AUTH request triggers the Proxy Mobile IP registration request to the internal Home Agent. This interaction easily allows the Mobile Node's home address to be used as vpn Tunnel Inner Address. |
| | | | |
| draft-arberg-ancp-vendorspecific-00.txt |
| | Vendor Specific Message for ANCP. |
| |
|
This document is aimed at presenting Access Node Control Protocol (ANCP) with a vendor specific protocol extension. |
| | | | |
| draft-arends-nscp-00.txt |
| | Name Server Control Protocol |
| |
|
This document describes the Name Server Control Protocol (NSCP). The NSCP will permit the management of diverse name server implementations. The NSCP uses NETCONF as framework. |
| | | | |
| draft-arkko-mext-rfc3775-altcoa-check-01.txt |
| | Verifying Correctness of Alternate Care-of Address Option |
| |
|
This document revises the RFC 3775 rules on how Alternate Care-of Address option is processed. Alternate Care-of Address option is used to carry the current care-of address inside a Mobility Header message. This is used in addition to the source address in the packet in order to ensure that the care-of address is protected by IPsec ESP, the security mechanism that protects Mobility Header messages. Unfortunately, RFC 3775 did not require verification that the source address and care-of address are the same. This document adds that requirement. |
| | | | |
| draft-asaeda-multimob-igmp-mld-mobility-extensions-00.txt |
| | IGMP and MLD Extensions for Mobile Hosts and Routers |
| |
|
This document describes the IGMP and MLD protocol extensions for mobile hosts and routers. IGMP and MLD are necessary protocols for hosts to request join or leave multicast sessions. While the regular IGMP and MLD protocols support communication between mobile hosts and routers over wireless networks, this document discusses the conditions how mobile hosts and routers use IGMP and MLD in their communication more effectively. |
| | | | |
| draft-asati-fecframe-config-signaling-00.txt |
| | Signaling Protocol to convey FEC Framework Configuration Information |
| |
|
FEC Framework document [FECARCH] defines the FEC Framework Configuration Information necessary for the FEC framework operation. This document describes one signaling protocol to determine and communicate the Configuration information between sender(s) and receiver(s). Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. |
| | | | |
| draft-asati-mpls-ldp-end-of-lib-01.txt |
| | LDP End-of-LIB |
| |
|
There are situations following LDP session establishment where it would be useful for an LDP speaker to know when its peer has advertised all of its labels. These include session establishment when LDP-IGP sync is in use and session re-establishment following loss of an LDP session when LDP graceful restart is in use. The LDP specification provides no mechanism for an LDP speaker to notify a peer when it has completed its initial label advertisements to that peer. This document specifies means for an LDP speaker to signal completion of its initial label advertisements following session establishment. |
| | | | |
| draft-asveren-dime-state-recovery-02.txt |
| | Diameter State Recovery Considerations |
| |
|
This document discusses parameters to consider, different approaches and design strategies to synchronize and/or recover state in Diameter applications after failure of an active instance. |
| | | | |
| draft-atlas-bryant-shand-lf-timers-04.txt |
| | Synchronisation of Loop Free Timer Values |
| |
|
This draft describes a mechanism that enables routers to agree on a common convergence delay time for use in loop-free convergence. |
| | | | |
| draft-atlas-icmp-unnumbered-04.txt |
| | Extending ICMP to Identify the Receiving Interface |
| |
|
This memo defines ICMP extensions, using ICMP multi-part messages, through which a router or host can explicitly identify the interface upon which an undeliverable datagram anrrived. The incoming interface can be identified by ifIndex, name, and/or address, as already used in MIBs and by OSPF. The extensions defined herein are particularly useful when troubleshooting networks with unnumbered interfaces, parallel interfaces and/or asymmetric routing. |
| | | | |
| draft-audet-sipping-feature-ref-00.txt |
| | Feature Referral in the Session Initiation Protocol (SIP) |
| |
|
Feature referral allows for an application to make a high level request to a User Agent to perform an action or "feature", and let the the User Agent actually execute the feature as it sees fit. Feature referral uses the SIP REFER method with a Refer-To header field containing a URN. |
| | | | |
| draft-babiarz-pcn-3sm-01.txt |
| | Three State PCN Marking |
| |
| | draft-babiarz-pcn-3sm-01.txt |
| | Date: |
18/11/2007 |
| | Authors: |
Jozef Babiarz, Xiao-Gao Liu, Kwok Ho Chan, Michael Menth |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document proposes a mechanism for admission control and flow termination. It is based on the concept of pre-congestion notification (PCN) using three different codepoints: "no pre- congestion", "admission-stop", and "excess-traffic" for packet marking. Therefore, the proposal is called three state marking (3sm). The behaviour of edge nodes is presented which distinguishes from other proposals through little complexity and its ability to cope with multipath routing. Algorithms required for packet metering and marking are explained in detail. |
| | | | |
| draft-babiarz-pcn-explicit-marking-02.txt |
| | Simulations Results for 3sm |
| |
|
This document describes the simulation setups and results for testing the Three State PCN Marking approach. Simulations done to date, demonstrate that the three state PCN marking approach has certain ability to support admission control and flow termination of real- time application flows at the congestion point(s) of the PCN-enabled network. The real-time traffic used in the simulation covers voice and video traffic with large and small numbers of flows. |
| | | | |
| draft-badra-tls-express-01.txt |
| | TLS Express |
| |
|
This document defines a new extension that may be used to add Pre Shared Key authentication functionality to TLS. It is based on the TLS abbreviated handshake and it provides the ability to share a session key for data encryption. |
| | | | |
| draft-badra-tls-password-ext-01.txt |
| | Password Extension for the TLS Client Authentication |
| |
|
This document specifies a new Transport Layer Security (TLS) extension and a new TLS message providing TLS client authentication using passwords. It provides client credential protection. |
| | | | |
| draft-badra-tls-psk-new-mac-aes-gcm-02.txt |
| | Pre-Shared Key Cipher Suites for Transport Layer Security (TLS) with SHA-256/384 and AES Galois Counter Mode |
| |
|
RFC 4279 and RFC 4785 describe pre-shared key cipher suites for Transport Layer Security (TLS). However, all those cipher suites use SHA-1 as their MAC algorithm. This document describes a set of cipher suites for TLS/DTLS which uses stronger digest algorithms (i.e., SHA-256 or SHA-384) and another which uses the Advanced Encryption Standard (AES) in Galois Counter Mode (GCM). |
| | | | |
| draft-bagnulo-6man-rfc3484-update-00.txt |
| | Updating RFC 3484 for multihoming support |
| |
|
This note describes the limitations of RFC 3484 in multihomed environments and proposes possible updates to the default address selection mechanisms in order to cope with the identified limitations. |
| | | | |
| draft-bagnulo-pshim6-02.txt |
| | Proxy Shim6 (P-Shim6) |
| |
|
This draft discusses extensions to the shim6 architecture to support shim6 proxies that would allow the provision of the following capabilities: o Provide Upper Layer Identifier portability. o Provide Traffic Engineering policy enforcement. o Off-load of the shim6 context management from the actual peers of the communication. o Enable legacy IPv6 nodes located in the multihomed site to obtain full multihoming support (no modification of the end nodes). |
| | | | |
| draft-bagnulo-v6ops-6man-nat64-pb-statement-01.txt |
| | IPv4/IPv6 Coexistence and Transition: Requirements for solutions |
| |
|
This note presents the problem statement, analysis and requirements for solutions to IPv4/IPv6 coexistence and eventual transition in a scenario in which dual stack operation is not the norm. |
| | | | |
| draft-bajko-mip6-rrtfw-03.txt |
| | Firewall friendly Return-Routability Test (RRT) for Mobile IPv6 |
| |
|
This document defines a slightly modified Return Routability Test (RRT) for MIPv6 [RFC3775]. The herein defined RRT mechanism is intended for CoA exchanges between the MN and the CN. Once the MN and CN find out their peers' valid addresses, an additional mechanism, defined in [I-D.tschofenig-mip6-ice], will be used to run connectivity checks to figure out which of the address pairs have connectivity and, if needed, open the required pinholes in the firewalls as described in [4]. The defined mechanism is intended to work with current firewalls without requiring any support from them. |
| | | | |
| draft-bajko-mos-dhcp-options-02.txt |
| | Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for Mobility Server (MoS) discovery |
| |
|
This document defines a number of Dynamic Host Configuration Protocol (DHCP-for-IPv4 and DHCP-for-IPv6) 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. These Mobility Services are used to assist an MN in handover preparation (network discovery) and handover decision (network selection). The services addressed by this document are the Media Independent Handover Services defined in [IEEE802.21]. |
| | | | |
| draft-bajko-mos-dns-discovery-01.txt |
| | Locating Mobility Servers |
| |
|
This document defines application service tags that allow service location without relying on rigid domain naming conventions, and DNS procedures for discovering servers which provide Mobility Services. Mobility Services are used to assist an MN in handover preparation (network discovery) and handover decision (network selection). The services addressed by this document are the Media Independent Handover Services defined in [1]. |
| | | | |
| draft-bakker-sipping-3gpp-ims-xml-body-handling-00.txt |
| | Specification of 3GPP IM CN Subsystem XML body handling |
| |
|
This document registers new disposition-types for the Content- Disposition header that apply to the application/3gpp-ims+xml body used by 3GPP, since Release 5. The applicability of these content- disposition values are limited to 3GPP IMS. The application/ 3gpp-ims+xml body has the following two distinct uses: (1) for redirecting the emergency session to use a different domain (e.g. using a Circuit Switched call), and (2) for delivering user profile specific information from the SIP registrar to an Application Server. |
| | | | |
| draft-balus-l2vpn-vpls-802.1ah-02.txt |
| | VPLS Extensions for Provider Backbone Bridging |
| |
|
IEEE 802.1ah draft standard [IEEE802.1ah], also known as Provider Backbone Bridges (PBB) defines an architecture and bridge protocols for interconnection of multiple Provider Bridge Networks (PBNs). PBB was defined in IEEE as a connectionless technology based on multipoint VLAN tunnels. MSTP is used as the core control plane for loop avoidance and load balancing. As a result, the coverage of the solution is limited by STP scale in the core of large service provider networks. Virtual Private LAN Service (VPLS) [RFC4762] provides a solution for extending Ethernet LAN services, using MPLS tunneling capabilities, through a routed MPLS backbone without running (M)STP across the backbone. As a result, VPLS has been deployed on a large scale in service provider networks. This draft discusses extensions to the VPLS model required to incorporate desirable PBB components while maintaining the Service Provider fit of the initial model. |
| | | | |
| draft-bambenek-doubleflux-00.txt |
| | Double Flux Defense in the DNS Protocol |
| |
|
The memo provides information and proposed standards for developers of applications based on the DNS protocol and for administrators of servers and networks. It proposes new standards for DNS and DNSSEC implementations that would prevent abuse of the DNS protocol such as those seen by "Double Flux" service networks. Specifically, this document recommends that all resource records for NS records with Time-To-Live (TTL) settings under 24 hours be dropped as potentially malicious records designed to attack users. This document would update RFCs 1123, 1912, 2181 and 2535. |
| | | | |
| draft-barnes-ecrit-rough-loc-00.txt |
| | 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. |
| | | | |
| draft-barnes-geopriv-lo-sec-02.txt |
| | Security Requirements for the Geopriv Location System |
| |
|
Internet protocols that deal with presence-based location objects support a wide variety of applications. However, the dissemination of location objects from sources of location to consumers is a common feature of all location-based applications. In order to enable the development of broadly-applicable security and privacy mechanisms for dissemination of location objects, this document describes an end-to- end architecture for policy-constrained location distribution. In this architecture, location distribution is accomplished by a set of distributed actors. We describe the assurances that these actors require from the architecture, and derive more a more detailed description of the security features required to provide those assurances. |
| | | | |
| draft-barnes-xcon-ccmp-04.txt |
| | Centralized Conferencing Manipulation Protocol |
| |
| | draft-barnes-xcon-ccmp-04.txt |
| | Date: |
25/02/2008 |
| | Authors: |
Mary Barnes, Chris Boulton, Henning Schulzrinne |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
The Centralized Conferencing Manipulation Protocol (CCMP) defined in this document provides the mechanisms to create, change and delete objects related to centralized conferences, including participants, their media and their roles. The protocol relies on web services and SIP event notification as its infrastructure, but can control conferences that use any signaling protocol to invite users. CCMP is based on the Simple Object Access Protocol (SOAP), with the data necessary for the interactions specified via Web Services Description Language (WSDL). |
| | | | |
| draft-barre-shim6-impl-00.txt |
| | Shim6 Implementation Report : LinShim6 |
| |
|
LinShim6 is an implementation of the Shim6 and REAP protocols, on the Linux platform. This draft provides a brief description of the architecture and describes the current state of our implementation. For each feature of the protocols, its level of support is described. Protocol conformance is evaluated against [1] and [2]. |
| | | | |
| draft-barreto-ietf-dhhmac-sas-00.txt |
| | MIKEY DHHMAC-SAS: The New MIKEY Transportation Mode |
| |
|
This document presents a new transport mode to the Multimedia Internet KEYing (MIKE) protocol, the MIKEY-DHHMAC-SAS. The MIKEY has as its objective the negotiation of cryptography parameters necessaries to the establishment of a secure (SRTP/SRTCP) end-to-end multimedia channel, but all its operation modes have some kind of limitation that prevents it of being used to this purpose. The MIKEY-DHHMAC-SAS solves theses existing limitations in MIKEY-DH and MIKEY-DHHMAC modes by adding the features of key continuity and Short Authentication String (SAS), making possible its use in any end-to- end multimedia scenario. |
| | | | |
| draft-baset-p2psip-p2pp-01.txt |
| | Peer-to-Peer Protocol (P2PP) |
| |
| | draft-baset-p2psip-p2pp-01.txt |
| | Date: |
19/11/2007 |
| | Authors: |
Salman Baset, Henning Schulzrinne, Marcin Matuszewski |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document defines the Peer-to-Peer Protocol (P2PP), an application-layer binary protocol, for creating and maintaining an overlay of participant nodes. The overlay can be created using various structured and unstructured peer-to-peer protocols such as Bamboo, Chord, Pastry, Kademlia, Gnutella, and Gia. P2PP uses a secure transport, supports an application API, has mechanisms for NAT and firewall traversal, exchanging node capabilities, and diagnostic information. P2PP is designed to support a P2P Session Initiation Protocol (SIP) network, but it can be used for other applications as well. |
| | | | |
| draft-baumgart-p2psip-p2pns-00.txt |
| | Peer-to-Peer Name Service (P2PNS) |
| |
|
This document describes P2PNS, a secure distributed name service for P2PSIP. P2PNS can be used to resolve SIP AoRs to Contact URIs without using DNS or central SIP servers. P2PNS provides several security mechanisms to efficiently prevent identity theft and to ensure the uniqueness of SIP AoRs in a completely decentralized and untrusted network without login servers. The proposed proxy architecture allows a seamless integration of legacy SIP UAs, avoids modifications to the complex SIP protocol stack and facilitates the deployment of P2PSIP networks. Because P2PNS provides a generic name service it is not limited to P2PSIP but can also be used e.g. to build a distributed DNS system. |
| | | | |
| draft-bberry-pppoe-scaled-credits-metrics-01.txt |
| | PPP Over Ethernet (PPPoE) Extensions for Scaled Credits and Link Metrics |
| |
|
This document specifies a method for optional flow control credit scaling and link quality metric scaling for Point-to-Point over Ethernet (PPPoE). Credit and metric scaling is required when connecting to high performance devices that employ the PPPoE credit flow control and link metric reports as defined in RFC 4938. |
| | | | |
| draft-bberry-rfc4938bis-00.txt |
| | PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics |
| |
| | draft-bberry-rfc4938bis-00.txt |
| | Date: |
24/04/2008 |
| | Authors: |
Bo Berry, Stan Ratliff, Ed Paradise, Tim Kaiser, Mike Adams |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document extends the Point-to-Point over Ethernet (PPPoE) Protocol with an optional credit-based flow control mechanism and an optional Link Quality Metric report. These optional extensions improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile point-to-point radio links. |
| | | | |
| draft-begen-fecframe-1d2d-parity-scheme-00.txt |
| | 1-D and 2-D Parity FEC Scheme for FEC Framework |
| |
|
This document describes a Fully-Specified Forward Error Correction (FEC) Scheme for the one-dimensional (1-D) and two-dimensional (2-D) parity codes and its application to reliable delivery of media streams in the context of FEC Framework. The 1-D and 2-D parity codes are systematic codes, where a number of repair symbols are generated from a set of source symbols and sent in one or more repair flows in addition to the source symbols that are sent to the receiver(s) within a source flow. The 1-D and 2-D parity codes offer a good protection against random and bursty packet losses at a cost of decent complexity. This document also specifies an RTP payload format for the FEC that is generated by the 1-D and 2-D parity codes from a source media encapsulated in RTP. The FEC defined in this document is not backward compatible with RFC 5109. |
| | | | |
| draft-begen-mmusic-fec-grouping-issues-00.txt |
| | FEC Grouping Issues in Session Description Protocol |
| |
|
The Session Description Protocol (SDP) currently supports grouping media lines. SDP also has semantics defined for grouping the associated source and Forward Error Correction (FEC)-based repair flows. However, the existing specifications have strict requirements that severely limit the use of the new features that are currently under development in the FECFRAME WG. These new features will allow applications to use FEC in a more flexible way but they require changes in the current specifications. This document provides a list of the required changes and discusses potential approaches to make these changes. |
| | | | |
| draft-bellis-enum-send-n-01.txt |
| | IANA Registrations for the 'Send-N' Enumservice |
| |
|
This document requests IANA registration of an Enumservice 'Send-N' and extends the definition of the 'pstndata:' URI scheme. This service allows more efficient support for overlapped dialling in E.164 Number Mapping (ENUM) enabled applications. |
| | | | |
| draft-bellovin-useipsec-07.txt |
| | Guidelines for Mandating the Use of IPsec Version 2 |
| |
|
The Security Considerations sections of many Internet Drafts say, in effect, "just use IPsec". While this is sometimes correct, more often it will leave users without real, interoperable security mechanisms. This memo offers some guidance on when IPsec Version 2 should and should not be specified. |
| | | | |
| draft-berger-ccamp-gmpls-ether-svcs-01.txt |
| | Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching |
| |
|
This document describes a method for controlling two specific types of Ethernet switching via Generalized Multi-Protocol Label Switching (GMPLS). This document supports the types of switching required to implied by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. Specifically, switching in support of Ethernet private line service and Ethernet virtual private line service. Support for MEF and ITU defined parameters are also covered. Some of the extensions defined in this document are generic in nature and not specific to Ethernet.Contents |
| | | | |
| draft-berger-ccamp-gmpls-mef-uni-02.txt |
| | Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 User-Network Interface (UNI) |
| |
|
This document describes a method for controlling two specific types of Ethernet switching via a Generalized Multi-Protocol Label Switching (GMPLS) based User-Network Interface (UNI). This document supports the types of switching required to implied by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. This document is the UNI companion to "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching". This document does not define or limit the underlying intra-domain or Internal NNI (I-NNI) technology used to support the UNI.Contents |
| | | | |
| draft-berger-idr-encaps-ipsec-01.txt |
| | BGP IPSec Tunnel Encapsulation Attribute |
| |
|
The BGP Encapsulation Subsequence Address Family Identifiers (SAFI) provides a method for the dynamic exchange of encapsulation information, and the indication of encapsulation protocol types to be used for different next hops. Currently support for GRE and L2TPv3 tunnel types are defined. This document defines support for IPsec tunnel types.Contents |
| | | | |
| draft-bergren-mmusic-rtsp-ermi-extensions-00.txt |
| | Extensions to RTSP based on the CableLabs Edge Resource Management Interface Specification (ERMI) |
| |
|
This document provides a description of the RTSP extensions used in the CableLabs Edge Resource Manager Interface specification. It is provided as an informational note based on a recent liaison statement received by CableLabs from the IETF MMUSIC working group. |
| | | | |
| draft-bernardos-autoconf-backbone-mesh-reqs-00.txt |
| | Requirements for IP Autoconfiguration Mechanisms in Backbone Wireless Mesh Network scenarios |
| |
|
This Internet Draft presents the multi-hop Backbone Wireless Mesh Network scenario, summarising its basic characteristics and describing the requirements and desired properties of an IP Autoconfiguration mechanism aimed at being used in this kind of networks. Once that the AUTOCONF WG has almost finalised the documents that describe the general architecture of MANETs and the IP autoconfiguration problem statement in MANETs, the WG is expected to start working on solutions. This document describes an ad-hoc scenario that is getting a lot of attention from both telecommunication operators and end-users: Backbone/infrastructure Wireless Mesh Networking. This document identifies and explains the requirements posed by this particular scenario to an IP autoconfiguration mechanism. The goal is to help the AUTOCONF WG identify the requirements that need to be taken into account when designing IP autoconfiguration solution(s) suitable for this Wireless Mesh environment. |
| | | | |
| draft-bernardos-autoconf-evaluation-considerations-02.txt |
| | Evaluation Considerations for IP Autoconfiguration Mechanisms in MANETs |
| |
|
This Internet Draft aims at providing general guidelines for the AUTOCONF solution space, through providing a set of evaluation considerations for IP autoconfiguration mechanisms in MANETs. These evaluation considerations conform to the AUTOCONF problem statement draft and the MANET architecture draft. The main objective of this draft is to illustrate some key features and highlight some important behaviours for the different autoconf mechanisms, and thus aiming to help solution developers during mechanisms' design and to help implementers in the choice of the autoconf mechanism that fits better their particular requirements, taking into consideration a number of important factors that are discussed in this draft. |
| | | | |
| draft-bernardos-autoconf-solution-space-01.txt |
| | Ad-Hoc IP Autoconfiguration Solution Space Analysis |
| |
|
This draft aims at analysing the solution space for the ad hoc IP autoconfiguration problem, based on the problem statement draft and the MANET architecture draft. Some evaluation considerations, are also taken into account. This draft classifies, at a generic level, the solution space of the possible approaches that could be followed to solve the IPv6 autoconfiguration for MANETs problem. The various approaches of IPv6 autoconfiguration for MANETs are illustrated, and the benefits and tradeoffs in different aspects of IPv6 autoconfiguration are explored. |
| | | | |
| draft-bernardos-manet-autoconf-survey-03.txt |
| | Survey of IP address autoconfiguration mechanisms for MANETs |
| |
|
This Internet Draft provides a detailed description of most of the existing IP autoconfiguration solutions proposed so far. The main aim of this document is to serve as a general reference for the AUTOCONF solution space. We present most of the previously proposed IP AUTOCONF mechanisms in MANETs, showing their key characteristics, conforming to the AUTOCONF problem statement draft and the MANET architecture draft. Furthermore, each solution is analysed based on a number of evaluation considerations. |
| | | | |
| draft-bernstein-ccamp-wavelength-switched-03.txt |
| | Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks |
| |
| |