|
Internet Drafts - Sorted by name
| | | | |
| draft-abade-xcast20-routing-engine-spec-00.txt |
| | Design and Implementation of an XCAST6 Routing Engine |
| |
|
XCAST6 (Explicit Multiunicast on IPv6) is a new protocol defined in RFC 5058. In XCAST, the list of destinations is explicitly encoded within the data packets instead of using a multicast group address. Research is currently ongoing on two versions of XCAST6 and this document describes the design and implementation of a routing engine for the new version in which the use of hop-by-hop options header has been eliminated. This draft explains why there is a need for an XCAST6 routing engine, highlights the requirements for its implementation, the design process and how to eventually implement the routing engine to allow for deployment of XCAST6 protocol. |
| | | | |
| draft-abarth-cookie-04.txt |
| | HTTP State Management Mechanism |
| |
|
This document defines the HTTP Cookie and Set-Cookie headers. NOTE: Much of the text herein is completely wrong. If you have suggestions for improving the draft, please send email to http-state@ietf.org. Suggestions with test cases are especially appreciated. |
| | | | |
| draft-abarth-mime-sniff-03.txt |
| | Content-Type Processing Model |
| |
|
Many web servers supply incorrect Content-Type headers with their HTTP responses. In order to be compatible with these servers, user agents consider the content of HTTP responses as well as the Content- Type header when determining the effective media type of the response. This document describes an algorithm for determining the effective media type of HTTP responses that balances security and compatibility considerations. |
| | | | |
| draft-abarth-origin-05.txt |
| | The HTTP Origin Header |
| |
|
This document defines the HTTP Origin header. The Origin header is added by the user agent to describe the security contexts that caused the user agent to initiate an HTTP request. HTTP servers can use the Origin header to mitigate against Cross-Site Request Forgery (CSRF) vulnerabilities. |
| | | | |
| draft-abfb-mpls-tp-control-plane-framework-01.txt |
| | MPLS-TP Control Plane Framework |
| |
|
The MPLS Transport Profile (MPLS-TP) supports both static provisioning of transport paths via an NMS/OSS, and dynamic provisioning of transport paths via a control plane. This document provides the framework for MPLS-TP dynamic provisioning, and covers control plane signaling, routing, addressing, traffic engineering, path computation, and recovery in the event of network failures. The document focuses on the control of Label Switched Paths (LSPs) as the Pseudowire (PW) control plane is not modified by MPLS-TP. MPLS-TP uses GMPLS as the control plane for MPLS-TP LSPs. Backwards compatibility to MPLS is required. Management plane functions such as manual configuration, the initiation of LSP setup are out of scope of this document. |
| | | | |
| draft-aboba-radext-wlan-12.txt |
| | RADIUS Attributes for IEEE 802 Networks |
| |
| | draft-aboba-radext-wlan-12.txt |
| | Date: |
25/10/2009 |
| | Authors: |
Bernard Aboba, Jouni Malinen, Paul Congdon, Joseph Salowey |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
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-adams-tsvwg-flow-signaling-identification-00.txt |
| | Flow State Aware signalling standardisation,and a proposal for alerting nodes or end-systems on data related to a flow |
| |
|
This document describes the motivation for Flow State Aware signalling and proposes a method of enabling Flow State Aware signalling packets to be identified. |
| | | | |
| draft-adamson-nfsv4-multi-domain-access-02.txt |
| | NFSv4 Multi-Domain Access |
| |
|
The Network File System, version 4 (NFSv4) uses a representation of identity that allows the use of users and groups from multiple, distinct administrative domains, and NFSv4 allows the use of security mechanisms that authenticate principals from multiple, distinct administrative domains. This document describes methods by which NFSv4 clients and servers can handle principals, users, groups from multiple administrative domains. |
| | | | |
| draft-ahrenholz-hiprg-dht-06.txt |
| | HIP DHT Interface |
| |
|
This document specifies a common interface for using HIP with a Distributed Hash Table service to provide a name-to-HIT lookup service and a HIT-to-address lookup service. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. |
| | | | |
| draft-alexeitsev-bliss-alert-info-urns-02.txt |
| | Alert-Info URNs for the Session Initiation Protocol (SIP) |
| |
|
The Session Initiation Protocol (SIP) supports the capability to provide a reference to the alternative ringback tone (RBT) for caller, or ring tone (RT) for callee using the Alert-Info header. However, the reference addresses only the network resources with specific rendering properties. There is currently no support for predefined standard identifiers for ringback tones or semantic indications without tied rendering. To overcome this limitations and support new applications a family of the URNs is defined in this specification. |
| | | | |
| draft-alexrn-nfsv4-ipv6-00.txt |
| | 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. |
| | | | |
| draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-03.txt |
| | Signaling RSVP-TE P2MP LSPs in an Inter-domain Environment |
| |
|
Point-to-MultiPoint (P2MP) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques described in [RFC4875]. However, [RFC4875] does not address issues that arise when a P2MP-TE LSP is signaled in multi-domain networks. Specifically, it does not provide a mechanism to avoid re-merges in inter-domain P2MP TE LSPs. This document provides a framework and protocol extensions for establishing and controlling P2MP MPLS and GMPLS TE LSPs in multi-domain networks. This document borrows inter-domain TE terminology from [RFC4726], e.g., for the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes). |
| | | | |
| draft-ali-mpls-sig-pid-multiplexing-case-02.txt |
| | Signaled PID When Multiplexing Multiple PIDs over RSVP-TE LSPs |
| |
|
There are many deployment scenarios where an RSVP-TE LSP carries multiple payloads. In these cases, it gets ambiguous on what should value should be carried as L3PID in the Label Request Object [RFC3209] or G-PID in the Generalized Label Request Object [RFC3471], [RFC3473]. The document proposes use of some dedicated PID values to cover some typical cases of multiple payloads carried by the LSP. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. |
| | | | |
| draft-ali-pce-brpc-p2mp-ext-01.txt |
| | BRPC Extensions for Point-to-Multipoint Path Computation |
| |
|
The ability to compute constrained Traffic Engineering Label Switched Paths (TE LSPs) for point-to-multipoint (P2MP) LSPs in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains (where a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems) has been identified as a key requirement [PCEP-P2MP-REQ]. This document addresses this requirement by extending backward recursive path computation (BRPC) technique proposed for Point-to-Point (P2P) LSPs in [P2P-BRPC] for P2MP LSP path computation in a multiple domains network. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. |
| | | | |
| draft-allbery-afs-srv-records-01.txt |
| | DNS SRV Resource Records for AFS |
| |
|
This document specifies how to use DNS (Domain Name Service) SRV RRs (Resource Records) to locate services for the AFS distributed file system and how the priority and weight values of the SRV RR should be interpreted in the server ranking system used by AFS. It deprecates use of the AFSDB RR to locate AFS cell database servers and provides guidance for backward compatibility. Internet Draft Comments Comments are solicited. Please include the AFS Standardization mailing list at afs3-standardization@openafs.org as a recipient of any comments. |
| | | | |
| draft-altman-tls-channel-bindings-07.txt |
| | Channel Bindings for TLS |
| |
|
This document defines three channel binding types for Transport Layer Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for- telnet, in accordance with RFC 5056 (On Channel Binding). |
| | | | |
| draft-ananth-tcpm-persist-01.txt |
| | Clarification of sender behaviour in persist condition. |
| |
|
This document attempts to clarify the notion of the Zero Window Probes (ZWP) described in RFC 1122 [RFC1122]. In particular, it clarifies the actions that can be taken on connections which are experiencing the ZWP condition. The motivation for this document stems from the belief that TCP implementations strictly adhering to the current RFC language have the potential to become vulnerable to Denial of Service (DoS) scenarios. |
| | | | |
| draft-ancp-restart-01.txt |
| | Graceful ANCP restarts on NAS |
| |
|
This document describes proposed extensions to the ANCP protocol to allow a graceful recovery of an ANCP session and associated information after an existing session is reset. Such a reset may be due to a NAS restart , or a loss of connectivity between the NAS and the AN. |
| | | | |
| draft-arifumi-6man-addr-select-conflict-01.txt |
| | Considerations of address selection policy conflicts |
| |
|
This document tries to speculate how policy conflicts happen, and how to address the conflicts. After making it clear what kind of address selection policy should be necessary, we proposed how to merge the possibily conflicting policies for each of the destination address selection policy and source address selection policy. |
| | | | |
| draft-arifumi-6man-rfc3484-revise-02.txt |
| | Things To Be Considered for RFC 3484 Revision |
| |
|
RFC 3484 has several known issues to be fixed mainly because of the deprecation of IPv6 site-local unicast address and the coming of ULA. Additionally, the rule 9 of the destination address selection rules, namely the longest matching rule, is known for its adverse effect on the round robin DNS technique. This document covers these essential points to be modified and proposes possible useful changes to be included in the revision of RFC 3484. |
| | | | |
| draft-arkko-pppext-bap-ianafix-02.txt |
| | IANA Allocation Guidelines for the PPP Bandwidth Allocation Protocol (BAP) |
| |
|
This document specifies the IANA guidelines for allocating new values in the PPP Bandwidth Allocation and Bandwidth Allocation Control Protocols. |
| | | | |
| draft-arkko-townsley-coexistence-03.txt |
| | IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios |
| |
|
When IPv6 was designed, it was expected that the transition from IPv4 to IPv6 would occur more smoothly and expeditiously than experience has revealed. The growth of the IPv4 Internet and predicted depletion of the free pool of IPv4 address blocks on a foreseeable horizon has highlighted an urgent need to revisit IPv6 deployment models. This document provides an overview of deployment scenarios with the goal of helping to understand what types of additional tools the industry needs to assist in IPv4 and IPv6 co-existence and transition. This document was originally created as input to the Montreal co- existence interim meeting in October 2008, which led to the rechartering of the Behave and Softwire working groups to take on new IPv4 and IPv6 coexistence work. This document is published as a historical record of the thinking at the time. |
| | | | |
| draft-asaeda-multimob-igmp-mld-mobility-extensions-03.txt |
| | IGMP and MLD Hold and Release Extensions for Mobility |
| |
|
This document describes IGMP and MLD Hold and Release protocol extensions for hosts and routers. The interoperability with the standard IGMPv3/MLDv2 protocols and these previous versions is also taken into account. |
| | | | |
| draft-asaeda-multimob-igmp-mld-optimization-01.txt |
| | IGMP and MLD Optimization for Mobile Hosts and Routers |
| |
|
IGMP and MLD are the protocols used by hosts to report their IP multicast group memberships to neighboring multicast routers. This document describes the ways of IGMPv3 and MLDv2 protocol optimization for mobility. The optimization includes a query timer tuning and an explicit membership notification operation. |
| | | | |
| draft-asaeda-multimob-pmip6-extension-02.txt |
| | PMIPv6 Extensions for Multicast |
| |
|
This document describes Proxy Mobile IPv6 (PMIPv6) extensions to support IP multicast. The Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA) are the mobility entities defined in the PMIPv6 protocol. The proposed protocol extension provides; 1) a dedicated multicast tunnel (M-Tunnel) between LMA and MAG, and 2) local routing to deliver IP multicast packets for mobile nodes. This document defines the roles of LMA and MAG to support IP multicast for the mobile nodes. |
| | | | |
| draft-asati-bmwg-reset-00.txt |
| | Reset Characterization |
| |
|
A forwarding device may get reset (automatically or manualy) and subsequently may experience an outage. It is deemed useful to know how long a device would take to recover after such an event. <> The forwarding devices in the network may go out of service due to (hardware or software) reset event. It is deemed useful to know how long a device would take to recover after such an event. <> Moreover, there are varieties of reset triggers each deserving special attention. Hence, clarity and consistency in reset procedures (above & beyond what's specified in RFC2544) are crucial to derive the meaningful results. This document specifies a methodology for characterizing reset during benchmarking of forwarding devices, and provides clarity and consistency in reset procedures beyond what's specified in RFC2544. |
| | | | |
| draft-asm-mpls-tp-bfd-cc-cv-01.txt |
| | Proactive Connection Verification,Continuity Check and Remote Defect indication for MPLS Transport Profile |
| |
|
Continuity Check (CC), Proactive Connectivity Verification (CV) and Remote Defect Indication (RDI) functionalities are MPLS-TP OAM requirements listed in [3]. Continuity Check monitors the integrity of the continuity of the path for any loss of continuity defect. Connectivity verification monitors the integrity of the routing of the path between sink and source for any connectivity issues. RDI enables an End Point to report, to its associated End Point, a fault or defect condition that it detects on a PW, LSP or Section. It is RECOMMENDED that a protocol solution, meeting one or more functional requirement(s), be the same for PWs, LSPs and Sections as per [3]. This document specifies methods for proactive CV, CC, and RDI for MPLS-TP Label Switched Path (LSP), PWs and Sections using Bidirectional Forwarding Detection (BFD). |
| | | | |
| draft-atlas-icmp-unnumbered-07.txt |
| | Extending ICMP for Interface and Next-hop Identification |
| |
|
This memo defines a data structure that can be appended to selected ICMP messages. The ICMP extension defined herein can be used identify any combination of the following: the IP interface upon which a datagram arrived, the sub-IP component of an IP interface upon which a datagram arrived, the IP interface through which the datagram would have been for forwarded had it been forwardable, the IP next hop to which the datagram would have been forwarded. Devices can use this ICMP extension to identify interfaces and their components by any combination of the following: ifIndex, IPv4 address, IPv6 address, name and MTU. ICMP-aware devices can use these extensions to identify both numbered and unnumbered interfaces. |
| | | | |
| draft-avasarala-dispatch-comm-div-notification-02.txt |
| | A Session Initiation Protocol (SIP) Event Package for Communication Diversion Information in support of the Communication Diversion (CDIV) Notification (CDIVN) CDIV service |
| |
|
3GPP and ETSI TISPAN are defining PSTN/ISDN simulation services and in particular the Communication Diversion (CDIV) using IP Multimedia (IM) core Network (CN) subsystem supplementary service. As part of CDIV, a (SIP) Event Notification Framework-based mechanism is used for notifying Users about diversions (re-directions or forwarding) of their incoming communication sessions. A new event package is proposed for allowing users to subscribe for and receive such notifications. Users have further capability to define filters controlling the selection, rate and content of such notifications. This SIP event package is applicable to the IMS and may not be applicable to the general Internet. |
| | | | |
| draft-axu-addr-sel-00.txt |
| | Address Selection Using Source Address Specific Routing Tables |
| |
|
RFC 3484 defines two algorithms for default source and destination address selection, but it has several shortcomings as specified in RFC 5220. RFC 5221 lists some requirements for any attempts to update the original RFC. This document specifies an alternate address selection algorithm to fulfill those requirements. |
| | | | |
| draft-azinger-additional-private-ipv4-space-issues-01.txt |
| | Additional Private IPv4 Space Issues |
| |
|
When a private network or internetwork grows very large it is sometimes not possible to address it using private IPv4 address space. This document describes the problems faced by those networks, the available options and the issues involved in assigning a new block of private IPv4 address space. |
| | | | |
| draft-baccelli-autoconf-adhoc-addr-model-03.txt |
| | IP Addressing Model in Ad Hoc Networks |
| |
|
This document describes a model for configuring IP addresses and subnet prefixes on the interfaces of routers which connect to links with undetermined connectivity properties. |
| | | | |
| draft-baccelli-multi-hop-wireless-communication-03.txt |
| | Multi-hop Ad Hoc Wireless Communication |
| |
|
This document describes some important characteristics of communication between nodes in a multi-hop ad hoc wireless network. These are not requirements in the sense usually understood as applying to formulation of a requirements document. Nevertheless, protocol engineers and system analysts involved with designing solutions for ad hoc networks must maintain awareness of these characteristics. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 21, 2010.Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. |
| | | | |
| draft-bagnulo-mptcp-threat-00.txt |
| | Threat Analysis for Multi-addressed/Multi-path TCP |
| |
|
Multi-addresses/Multi-path TCP (MPTCP for short) describes the extensions proposed for TCP so that each endpoint of a given TCP connection can use multiple IP addresses to exchange data (instead of a single IP address per endpoint as currently defined). Such extensions enable the exchange if segments using different source- destination address pairs, resulting in the capability of using multiple paths in a significant number of scenarios. In particular, some level of multihoming and mobility support can be achieved through these extensions. However, the support for multiple IP addresses per endpoint may have implications on the security of the resulting MPTCP protocol. This note includes a threat analysis for MPTCP. |
| | | | |
| draft-bajko-arcband-shape-00.txt |
| | Arcband Shape Binary Encoding |
| |
|
This document describes a binary encoding format for an arcband, which is compatible with the binary encoding defined by 3GPP [3GPP23.032], and which is widely used in today's cellular networks. This encoding can additionally be used by a number of other protocols, which demand a bandwidth efficient encoding of location information, eg link layers like IEEE 802.11. |
| | | | |
| draft-bajko-pripaddrassign-02.txt |
| | Port Restricted IP Address Assignment |
| |
| | draft-bajko-pripaddrassign-02.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Gabor Bajko, Teemu Savolainen, Mohammed Boucadair, Pierre Levis |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
When IPv6 was designed, the assumption was that the transition from IPv4 to IPv6 will occur way before the exhaustion of the available IPv4 address pool. The unexpected growth of the IPv4 Internet and the hesitation and technical difficulties to deploy IPv6 indicates that the transition may take much longer than originally anticipated. It is expected that communication using IPv6 addresses will increase during the next few years to come at the expense of communication using IPv4 addresses. The Internet should reach a safety point in the future, where the number of IPv4 public addresses in use at a given time begins decreasing. It is very likely that the IPv4 public address pool currently available at IANA will be exhausted before the internet reaches this safety point. This creates a need to prolong the lifetime of the available IPv4 addresses. This document defines methods to allocate the same IPv4 address to multiple hosts, with the aim to prolong the availability of public IPv4 addresses, possibly for as long as it takes for IPv6 to take over the demand for IPv4. |
| | | | |
| draft-baker-ietf-core-04.txt |
| | Core Protocols in the Internet Protocol Suite |
| |
|
This note attempts to identify the core of the Internet Protocol Suite. The target audience is NIST, in the Smart Grid discussion, as they have requested guidance on how to profile the Internet Protocol Suite. In general, that would mean selecting what they need from the picture presented here. |
| | | | |
| draft-baker-ipv6-nd-session-hijack-00.txt |
| | Session Hijack in Neighbor Discovery |
| |
|
This memo is to point out a security issue in IPv6 Neighbor Discovery. |
| | | | |
| draft-baker-ipv6-prefix-subdelegation-00.txt |
| | Prefix Sub-delegation in a SOHO/SMB Environment |
| |
|
This memo considers the question of IPv6 prefix sub-delegation. |
| | | | |
| draft-baker-v6ops-greynet-01.txt |
| | IPv4 and IPv6 Greynets |
| |
|
This note discusses a feature to support building Greynets for IPv4 and IPv6. |
| | | | |
| draft-balus-l2vpn-pbb-ldp-ext-01.txt |
| | Extensions to LDP Signaling for PBB-VPLS |
| |
|
Extensions to VPLS PE model to accommodate PBB components where discussed in [PBB-VPLS Model]. This draft discusses optional extensions to the LDP Signaling procedures in [RFC 4762] required to further enhance the PBB-VPLS solution. |
| | | | |
| draft-bao-pce-pre-configured-routing-00.txt |
| | A Path Computation Element (PCE) Application for Pre-configured Routing |
| |
|
Pre-configured routing is a routing scheme that except primary route operator configures one or multiple routes which will be used as recovery route when the primary route fails for a service previously. This document improves this traditional routing shceme, and PCE (Paht Computation Element) is applied for pre-configured routing. Furthermore, this document also presents a detailed set of PCC-PCE (Path Computation Client) communication protocol requirements and defines PCEP (Path Computation Element Communication Protocol) extensions for PCEP. |
| | | | |
| draft-barnes-ecrit-rough-loc-03.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-policy-uri-00.txt |
| | Location Configuration Extensions for Policy Management |
| |
|
Current location configuration protocols are capable of provisioning an Internet host with a location URI that refers to the host's location. However, these protocols lack a mechnism for the htarget host to inspect or set the privacy rules that are applied to the URIs they distribute. This document extends the current location configuration protocols to provide hosts with a reference to the rules that are applied to a URI, so that the host can view or set these rules. |
| | | | |
| draft-barnes-oauth-model-01.txt |
| | The OAuth Security Model for Delegated Authorization |
| |
|
This document describes the security model for the OAuth authorization system, which allows a party that holds some authorization to delegate a subset of that authorization to another party, without requiring either party to disclose its credentials to the other. In this document, we describe a set of design constraints, a high-level work flow for establishing authorizations subject to those constraints, and set of security requirements for protocols that implement this model. |
| | | | |
| draft-barnes-sipcore-rfc4244bis-03.txt |
| | An Extension to the Session Initiation Protocol (SIP) for Request History Information |
| |
|
This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines an optional SIP header, History-Info, for capturing the history information in requests. |
| | | | |
| draft-barre-shim6-impl-03.txt,.ps |
| | Shim6 Implementation Report : LinShim6 |
| |
|
LinShim6 is an implementation of the Shim6 and REAP protocols, on the Linux platform. This draft provides a description of the architecture and describes the current state of our implementation. The level of support of each protocol feature is detailed. Protocol conformance is evaluated against the main drafts. |
| | | | |
| draft-barwood-dnsext-dns-transport-14.txt |
| | DNS Transport |
| |
|
This documnent describes an experimental transport protocol for DNS. IP fragmentation is avoided, blind spoofing, amplification attacks and other denial of service attacks are prevented. Latency for a typical DNS query is a single round trip, after a setup hadnshake. No per-client server state is required between transactions. The protocol may have other applications. |
| | | | |
| draft-barwood-dnsext-dns-transport-signal-02.txt |
| | DNS Transport Signal |
| |
|
Describes a DNS resource record that is used to signal support for DNS transport protocols. |
| | | | |
| draft-barwood-dnsext-edns-page-option-04.txt |
| | EDNS Page Option |
| |
|
Describes an EDNS option to allow large DNS responses to be sent using small UDP packets. |
| | | | |
| draft-baset-tsvwg-tcp-over-udp-01.txt |
| | 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. |
| | | | |
| draft-bauer-mext-aero-solspace-00.txt |
| | Solution Space for Aeronautical NEMO RO |
| |
|
Many potential solutions have been proposed for NEMO Route Optimization, although none has been adopted up to now. This draft aims on evaluating the different approaches for the aeronautical use case. At the end, a recommendation for the next steps is given. |
| | | | |
| draft-bauer-mext-aero-topology-01.txt |
| | ATN Topology Considerations for Aeronautical NEMO RO |
| |
|
The aviation industry is in the process of moving from legacy and ISO-based protocols to an IP-based environment. This task will require adoption, modification and/or creation of IETF related protocols. The intention of this draft is therefore to provide an overview of the operational environment and the topology of the Aeronautical Telecommunications Network to the IETF. |
| | | | |
| 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-bcx-behave-learn-address-00.txt |
| | 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. |
| | | | |
| draft-beck-oauth-sip-eval-00.txt |
| | Evaluating OAUTH's suitability for SIP authentication |
| |
|
The Open Authentication Protocol (OAUTH) provides a method for clients to access server resources on behalf of another party. This document evaluates OAUTH's suitability as an authentication mechanism for the Session Initiation Protocol (SIP) for use cases where web applications want to interact with SIP servers without sharing user credentials. |
| | | | |
| draft-begen-avt-ports-for-ucast-mcast-rtp-01.txt |
| | Port Mapping Between Unicast and Multicast RTP Sessions |
| |
|
This document presents the details of a port mapping proposal that will allow RTP receivers to choose their own ports for the unicast sessions in RTP applications using both multicast and unicast services. |
| | | | |
| draft-begen-avt-rams-scenarios-00.txt |
| | Considerations for RAMS Scenarios |
| |
|
The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a method based on RTP and RTCP protocol family that enables an RTP receiver to rapidly acquire and start usefully consuming the RTP multicast data. Upon a request from the RTP receiver, an auxiliary unicast RTP retransmission session is set up between a retransmission server and the RTP receiver, over which the reference information about the new multicast stream the RTP receiver is about to join is transmitted at an accelerated pace. This often precedes, but may also accompany, the multicast stream itself. When there is only one multicast stream to be acquired, the RAMS solution works in a straightforward manner. However, when there are two or more multicast streams to be acquired from the same or different multicast RTP sessions, care should be taken to configure each RAMS appropriately. This document provides example scenarios and make practical recommendations. |
| | | | |
| draft-begen-avt-rapid-sync-rtcp-xr-03.txt |
| | Multicast Acquisition Report Block Type for RTCP XR |
| |
|
In most RTP-based multicast applications, the RTP source sends inter- related data. Due to this interdependency, randomly joining RTP receivers usually cannot start consuming the multicast data right after they join the session. Thus, they often experience a random acquisition delay. One approach to reduce this delay is to use an auxiliary unicast RTP session with a retransmission server to receive a burst stream that facilitates rapid acquisition of the multicast stream. An RTP receiver may use this approach (or any other approach) to achieve rapid acquisition. Yet, due to various factors, performance of the rapid acquisition methods usually varies. Furthermore, in some cases the RTP receiver may (or may have to) do a simple multicast join. For quality reporting, monitoring and diagnostics purposes, it is important to collect detailed information from the RTP receivers about their acquisition and presentation experiences. This document addresses this issue by defining a new report block type, called Multicast Acquisition (MA) Report Block, within the framework of RTP Control Protocol (RTCP) Extended Reports (XR). This document also defines the necessary signaling of the new MA report block type in the Session Description Protocol (SDP). |
| | | | |
| draft-begen-avt-rtp-mpeg2ts-preamble-03.txt |
| | RTP Payload Format for MPEG2-TS Preamble |
| |
|
Demultiplexing and decoding an MPEG2 Transport Stream (MPEG2-TS) requires the knowledge of specific information about the transport stream, which we refer to as the MPEG2-TS Preamble. While this information is spread over different locations throughout the transport stream and can be eventually assembled after some time a receiver started receiving the MPEG2-TS, the time it takes to retrieve all this information (especially in multicast environments) may be long. Instead, having this information readily available as a Preamble and sending the Preamble to a receiver that will shortly start receiving the transport stream will virtually eliminate the waiting time and let the receiver start processing/decoding the MPEG2-TS sooner. In this document, we give an overview of the MPEG2-TS and the delay components in video systems, and motivate the need for constructing and using the MPEG2-TS Preamble for rapidly acquiring the source stream in RTP multicast sessions. We also define and register the RTP payload format for the MPEG2-TS Preamble. |
| | | | |
| draft-behera-ldap-password-policy-10.txt |
| | Password Policy for LDAP Directories |
| |
|
Password policy as described in this document is a set of rules that controls how passwords are used and administered in Lightweight Directory Access Protocol (LDAP) based directories. In order to improve the security of LDAP directories and make it difficult for password cracking programs to break into directories, it is desirable to enforce a set of rules on password usage. These rules are made to ensure that users change their passwords periodically, passwords meet construction requirements, the re-use of old password is restricted, and to deter password guessing attacks. |
| | | | |
| draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03.txt |
| | RSVP-TE Extensions for MPLS-TP OAM Configuration |
| |
|
This document defines a method for the configuration of MPLS Transport Profile (MPLS-TP) Operations, Administration and Maintenance (OAM) functionalities through extensions to RSVP-TE. |
| | | | |
| draft-bellis-dns-recursive-discovery-00.txt |
| | DNS Proxy Bypass by Recursive DNS Discovery and LOCAL.ARPA |
| |
|
This document describes a method for a DNS client resolver to discover the IP addresses of the upstream recursive DNS resolvers and hence bypass the local DNS proxy. It also directs IANA to reserve the "LOCAL.ARPA" domain name and to create a registry for well known sub-domains of that domain name, such sub-domains being reserved for use within any network's administrative boundary. |
| | | | |
| draft-benjamin-extendedcallbackinfo-00.txt |
| | AFS Callback Extensions draft-benjamin-extendedcallbackinfo-00 |
| |
|
AFS cache-control strategy is callback (invalidate) based. The AFS callback design allows a client to know when an object it has cached is no longer consistent, but the callback notification message itself provides no specific information about the triggering event. This is a protocol inefficiency, as in several scenarios it results in unnecessary round-trips to file servers to verify file status information, file access information, or to fetch file data which has not changed. We propose an extension of the callback mechanism to provide information about the event(s) triggering a callback, in the payload of the callback notification message itself. The proposed mechanism eliminates most or all unnecessary round-trips imposed by the current callback mechanism, and simultaneously allows AFS implementations to (efficiently) provide correct semantics in several scenarios involving multiple writers (ie, where AFS currently provides incorrect semantics).Editorial Note To provide feedback on this Internet-Draft, join the afs3-standardisation mailing list (afs3-standardization@openafs.org). |
| | | | |
| draft-berger-ccamp-assoc-info-00.txt |
| | On the association of GMPLS Recovery LSPs |
| |
|
End-to-End and Segment Recovery are defined for GMPLS (Generalized Multi-Protocol Label Switching) controlled label switched paths (LSPs) in RFC 4872 and RFC 4873 respectively. Both definitions use the ASSOCIATION object to associate recovery LSPs with the LSP they are protecting. This document provides additional narrative on how such associations are to be identified. This document does not define any new procedures or mechanisms and is strictly informative in nature. It may not be obvious to the informed reader why this document is necessary. |
| | | | |
| draft-bernardos-autoconf-addressing-model-01.txt |
| | Addressing Model for Router Interfaces in Ad Hoc Networks |
| |
|
This document describes a practical IP addressing model for interfaces that take part in router-to-router communications in ad hoc networks. |
| | | | |
| draft-bernardos-mif-pmip-01.txt |
| | Multihoming extensions for Proxy Mobile IPv6 |
| |
| | draft-bernardos-mif-pmip-01.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Carlos Bernardos, Telemaco Melia, Pierrick Seite, Jouni Korhonen |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
The IETF standardized Proxy Mobile IPv6 (PMIPv6). PMIPv6 enables mobile devices to connect to a PMIPv6 domain and roam across gateways without changing the IP address. PMIPv6 also provides limited multi- homing support to multi-mode mobile devices. The IETF is working on optimizations for PMIPv6. While multi-homing item has been proposed to be part of the approved work, discussions showed there are still many controversial issues to be addressed (i.e. the no-host modification theorem). This document explores solutions for the multi-homing use case aiming at helping PMIPv6 development where possible. |
| | | | |
| draft-bernardos-netext-pmipv6-mih-01.txt |
| | PMIPv6 operation with IEEE 802.21 |
| |
|
The NETLMM WG standardized Proxy Mobile IPv6 (PMIPv6). PMIPv6 enables mobile devices to connect to a PMIPv6 domain and roam across gateways without changing the IP address. PMIPv6 also provides limited multi-homing support to multi-mode mobile devices. While the basic scenario addressed by PMIPv6 considers MNs with just one interface, PMIPv6 also allows an MN to connect to the same PMIPv6 domain through different interfaces. This limited support of multi- interfaced MNs is not fully specified, since the MAG needs to obtain/ guess additional information from the MN, in order to decide whether to treat an MN's interface attachment as a handover or as new interface attachment (i.e. meaning the creation of a new mobility session and, therefore, the allocation of new home network prefixes to the MN). The use of the Media Independent Handover (MIH) Services as defined in the IEEE 802.21-2008 specification [IEEE80221] may help in obtaining this additional information. This I-D describes how PMIPv6 would work in an 802.21-enabled scenario, and in particular, analyzes how MIH primitives can be used to help the MAG deal with multi-technology scenarios. The main objective of the IEEE 802.21- 2008 standard is to provide link layer intelligence to upper layers. Hence, a more intelligent decision making capability leading to more reliable and efficient handovers between heterogeneous networks can be enabled. |
| | | | |
| draft-bernardos-netext-pmipv6-nemo-ps-01.txt |
| | PMIPv6 and Network Mobility Problem Statement |
| |
|
The NETLMM WG standardized Proxy Mobile IPv6 (PMIPv6). PMIPv6 enables mobile devices to connect to a PMIPv6 domain and roam across gateways without changing the IP address. Current PMIPv6 specification does only support the movement of hosts within the localized mobility domain. A mobile network (commonly referred to as a NEMO, NEtwork that MOves) can also benefit from the network-based localized mobility support provided by PMIPv6, but in a limited way. This I-D describes what can be done with current standardized protocols, and describes the problem statement of fully supporting network mobility in Proxy Mobile IPv6. The goal of this document is to present the problem -- and the use cases where this problem is relevant to be solved -- to collect feedback from the community about the interest in working on this problem. |
| | | | |
| draft-bernstein-ccamp-wson-compatibility-01.txt |
| | WSON Signal Characteristics and Network Element Compatibility Constraints for GMPLS |
| |
|
While the current GMPLS WSON framework can deal with many types of wavelength switching systems there is a desire to extend the control plane to networks that include a combination of transparent optical and hybrid electro optical systems such as OEO switches, regenerators, and wavelength converters. Such networks are frequently referred to as translucent optical networks in the literature. Some of the systems use in such networks can be limited to processing WSON signals with specific characteristics or attributes. In addition, some of the network elements may be able to perform important optional processing functions such as regeneration on a signal and would need to be provisioned as part of optical path establishment. This document provides a WSON signal definition and attributes characterization based on ITU-T interface and signal class standards and describes the signal compatibility constraints of this extended set of network elements. The signal characterization, network element compatibility constraints and enhanced provisioning support enable GMPLS routing and signaling to control these devices and PCE to compute optical light-paths subject to signal compatibility attributes. |
| | | | |
| draft-bernstein-ccamp-wson-signal-00.txt |
| | WSON Signal Characteristics and Network Element Compatibility Constraints for GMPLS |
| |
|
While the current GMPLS WSON formalism can deal with many types of wavelength switching systems there is a desire to extend this control plane to include other common optical or hybrid electro optical systems such as OEO switches, regenerators, and wavelength converters. This document provides a WSON signal definition and characterization based on ITU-T interface and signal class standards and describes the signal compatibility constraints of this extended set of network elements. The signal characterization and network element compatibility constraints enable GMPLS routing and signaling to control these devices and PCE to compute optical light-paths subject to signal compatibility attributes. |
| | | | |
| draft-bernstein-ccamp-wson-signaling-05.txt |
| | Signaling Extensions for Wavelength Switched Optical Networks |
| |
|
This memo provides extensions to Generalized Multi-Protocol Label Switching (GMPLS) signaling for control of wavelength switched optical networks (WSON). Such extensions are necessary in WSONs under a number of conditions including: (a) when optional processing, such as regeneration, must be indicated to occur at specific nodes along a path, (b) where equipment must be configured to accept an optical signal with specific attributes, or (c) where equipment must be configured to output an optical signal with specific attributes. In addition this memo provides mechanisms to support distributed wavelength assignment in bidirectional LSP, and choice in distributed wavelength assignment algorithms. These extensions build on previous work for the control of lambda and G.709 based networks. |
| | | | |
| draft-bernstein-wson-impairment-encode-01.txt |
| | Information Encoding for Impaired Optical Path Validation |
| |
|
This document provides an information encoding for the optical impairment characteristics of optical network elements for use in path computation and optical path impairment validation. This encoding is based on ITU-T defined optical network element characteristics as given in ITU-T recommendation G.680 and related specifications. This encoding is intentionally compatible with a previous impairment free optical information encoding used in optical path computations and wavelength assignment. |
| | | | |
| draft-bernstein-wson-impairment-info-02.txt |
| | Information Model for Impaired Optical Path Validation |
| |
|
This document provides an information model for the optical impairment characteristics of optical network elements for use in GMPLS/PCE control plane protocols and mechanisms. This information model supports Impairment Aware Routing and Wavelength Assignment (IA-RWA) in optical networks in which path computation and optical path validation are essential components. This is not a general network management information model. This model is based on ITU-T defined optical network element characteristics as given in ITU-T recommendation G.680 and related specifications. This model is intentionally compatible with a previous impairment free optical information model used in optical path computations and wavelength assignment. |
| | | | |
| draft-bhatia-bfd-crypto-auth-01.txt |
| | 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 National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms (SHS) 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. |
| | | | |
| draft-bhatia-manral-igp-crypto-requirements-04.txt |
| | Cryptographic Algorithm Implementation Requirements for Routing Protocols |
| |
|
The interior gateway routing protocols Open Shortest Path First version 2 (OSPFv2) [RFC2328], Intermediate System to Intermediate System (IS-IS) [ISO] [RFC1195] and Routing Information Protocol (RIP) [RFC2453] currently define Clear Text and Message Digest 5 (MD5) [RFC1321] algorithms for authenticating their protocol packets. There have recently been documents adding support of the Secure Hash Algorithm (SHA) family of hash functions for authenticating routing protocol packets for RIP [RFC4822], IS-IS [ISIS-HMAC] and OSPF [OSPF- HMAC]. To ensure interoperability between disparate implementations, it is imperative that we specify a set of mandatory-to-implement algorithms thereby ensuring that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms to be used for the cryptographic authentication of these routing protocols as well as specifying the algorithms that should be implemented because they may be promoted to mandatory at some future time. |
| | | | |
| draft-bhh-mpls-tp-oam-y1731-03.txt |
| | MPLS-TP OAM based on Y.1731 |
| |
|
This document specifies how to leverage Y.1731 [2] Protocol Data Units (PDU) and procedures (state machines) to provide a set of Operation, Administration, and Maintenance (OAM) mechanisms that meets the MPLS Transport Profile (MPLS-TP) OAM requirements as defined in [6]. In particular, this document specifies the MPLS-TP technology specific encapsulation mechanisms to carry these OAM PDUs within MPLS-TP packets to provide MPLS-TP OAM capabilities in MPLS-TP networks. |
| | | | |
| draft-bi-savi-cps-02.txt |
| | SAVI Solution for DHCPv4/v6 |
| |
| | draft-bi-savi-cps-02.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Jun Bi, Guang Yao, Jianping Wu, Fred Baker |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document specifies the procedure of setting up bindings between DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and anchor (refer to [SAVI-framework]) on SAVI (Source Address Validation Improvements) device. The bindings can be used to filter packets with forged IP addresses. |
| | | | |
| draft-bi-savi-dhcp-00.txt |
| | SAVI Solution for DHCPv4/v6 |
| |
| | draft-bi-savi-dhcp-00.txt |
| | Date: |
08/11/2009 |
| | Authors: |
Jun Bi, Jianping Wu, Guang Yao, Fred Baker |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document specifies the procedure for creating bindings between a DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and an anchor (refer to [SAVI-framework]) on SAVI (Source Address Validation Improvements) device. The bindings can be used to filter packets with forged IP addresses generated on the local link. |
| | | | |
| draft-bipi-mboned-ip-multicast-pm-requirement-00.txt |
| | Requirements for IP multicast performance monitoring |
| |
|
With increasing deployment of IP multicast in service provider (SP) network, SPs need a carrier-grade IP multicast performance monitoring solution. This document describes the requirements for such a system for a SP network. This system enables efficient performance monitoring in SPs' production network and provides diagnostic information in case of performance degradation or failure. |
| | | | |
| draft-bishnoi-mpls-ldp-node-group-00.txt |
| | LDP Node and FEC group |
| |
|
[RFC5036] and [MLDP] describes the Label Distribution Protocol (LDP) for setup of point-to-point (P2P), point to multi-point (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths (LSPs). Upstream node selection for P2MP/MP2MP LSP and label map propagation for P2P is based on route availability and local policy. If multiple paths are available then there is no method for selection of certain preferred nodes. A new method is defined in this document that can optionally be used as a tiebreaker among multiple available paths in upstream node selection. This method provides a mechanism to guide traffic via specific set of nodes in a network. |
| | | | |
| draft-bishnoi-mpls-mldp-opaque-types-01.txt |
| | LDP Multipoint Opaque Value Element Types |
| |
|
[MLDP] describes extensions to the Label Distribution Protocol (LDP) for setup of point to multi-point (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths (LSPs). LDP forwarding equivalence class (FEC) elements used to establish P2MP and MP2MP LSPs include type- length-value (TLV) fields that carry information meaningful to Ingress LSRs and Leaf LSRs and are termed as Opaque Value Elements in [MLDP]. This document defines Opaque Value Element structure to be used for provisioning P2MP and MP2MP Provider tunnels (P-Tunnels) for Multicast Virtual Private Network (MVPN). It is envisioned that this would be useful for security and manageability of P-Tunnels used for MVPN from the ones provisioned for other applications and vice-versa. |
| | | | |
| draft-bitar-wadhwa-ancp-pon-02.txt |
| | Applicability of Access Node Control Mechanism to PON based Broadband Networks |
| |
|
The purpose of this document is to provide applicability of Access Node Control Mechanism, as described in [ANCP-FRAMEWORK], to PON based broadband access. The need for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node Complex (a combination of Optical Line Termination (OLT) and Optical Network Termination (ONT) elements), is described in a multi-service reference architecture in order to perform QoS-related, service- related and Subscriber-related operations. The Access Node Control Mechanism is also extended for interaction between components of the Access Node Complex (OLT and ONT). The Access Node Control mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather uses a direct device- device communication. This allows for performing access link related operations within those network elements to meet performance objectives. |
| | | | |
| draft-blake-ipv6-flow-label-nonce-02.txt |
| | Use of the IPv6 Flow Label as a Transport-Layer Nonce to Defend Against Off-Path Spoofing Attacks |
| |
|
TCP and other transport-layer protocols are vulnerable to spoofing attacks from off-path hosts. These attacks can be prevented through the use of cryptographic authentication. However, it is difficult to use cryptographic authentication in all circumstances. A variety of obfuscation techniques -- such as initial sequence number randomization and source port randomization -- increase the effort required of an attacker to successfully guess the packet header fields which uniquely identify a transport connection. This memo proposes the use of the IPv6 Flow Label field as a random, per- connection nonce value, to add entropy to the set of packet header fields used to identify a transport connection. This mechanism is easily implementable, allows for incremental deployment, and is fully compliant with the rules for Flow Label use defined in RFC 3697. |
| | | | |
| draft-blanchet-v6ops-tunnelbroker-tsp-04.txt |
| | IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP) |
| |
|
A tunnel broker with the Tunnel Setup Protocol (TSP) enables the establishment of tunnels of various inner protocols, such as IPv6 or IPv4, inside various outer protocols packets, such as IPv4, IPv6 or UDP over IPv4 for IPv4 NAT traversal. The control protocol (TSP) is used by the tunnel client to negotiate the tunnel with the broker. A mobile node implementing TSP can be connected to both IPv4 and IPv6 networks whether it is on IPv4 only, IPv4 behind a NAT or on IPv6 only. A tunnel broker may terminate the tunnels on remote tunnel servers or on itself. This document describes the TSP protocol within the model of the tunnel broker model. |
| | | | |
| draft-bo-behave-ref-req-01.txt |
| | Requirements for Referral in Mobile Network,input to GROBJ BoF |
| |
|
This document lays out the requirements that need to be met by the potential referral modifications for the mobile network. |
| | | | |
| draft-bonaventure-lisp-preserve-00.txt |
| | Preserving the reachability of LISP ETRs in case of failures |
| |
|
Maintaining reachability of an EID prefix despite the failures of ETRs is a key concern in the LISP architecture. In this document, we first analyse this problem in comparison with traditional routing protocols. Then, we explain how Internet Service Providers could offer a service that preserves the reachability of the LISP ETRs of their customers in case of failures. |
| | | | |
| draft-boot-autoconf-brdp-02.txt |
| | Border Router Discovery Protocol (BRDP) based Address Autoconfiguration |
| |
|
Mobile Ad hoc Networks (MANET) may be attached to a fixed infrastructure network, like the Internet. This document specifies a mechanism for Border Router discovery and utilization in such a subordinate, possibly multi-homed, MANET. It provides facilities for choosing preferred Border Router(s) and configuring IP address(es) needed for communication between MANET nodes and nodes on the Internet via the selected Border Router. Autonomous MANETs do not have Border Routers; a self-sufficient Address Autoconfiguration mechanism for Autonomous MANETs is defined as well. |
| | | | |
| draft-bormann-6lowpan-6lowapp-problem-01.txt |
| | 6LowApp: Problem Statement for 6LoWPAN and LLN Application Protocols |
| |
|
The 6LoWPAN and ROLL WGs are laying the groundwork to make the Wireless Embedded Internet a reality, but what application protocols will we use? Request-response protocols like HTTP are a poor fit to a communication model with battery-operated, mostly sleeping nodes. In addition, the usual data formats (both headers and body) are perceived to be too chatty for the 50-60 byte payloads possible in LoWPANs and to require too much code for the 8-bit and 16-bit processors dominating the Internet of Things. Still, it would be a mistake to start a new silo of application protocols that do not benefit from existing application area Internet experience. This document provides a problem statement for possible work on of application protocols in 6LoWPAN networks or, more generally, in low- power, lossy networks, as well as some considerations for required related work. |
| | | | |
| draft-bormann-rohc-over-802-02.txt |
| | Robust Header Compression (ROHC) over 802 networks |
| |
|
Various proposals have been submitted to the ROHC working group for enabling the use of ROHC [RFC3095] header compression over Ethernet, 802.11 and other 802-based links. Previous proposals generally suffered from a lack of systems perspective on 802 networks. The present document attempts to supply some systems perspective and provides a rough outline for a solution. This is a submission to the IETF ROHC WG. Please direct discussion to its mailing list, rohc@ietf.org $Revision: 1.9 $ |
| | | | |
| draft-boschi-ipfix-anon-04.txt |
| | IP Flow Anonymisation Support |
| |
|
This document describes anonymisation techniques for IP flow data and the export of anonymised data using the IPFIX protocol. It provides a categorization of common anonymisation schemes and defines the parameters needed to describe them. It provides guidelines for the implementation of anonymised data export and storage over IPFIX, and describes an Options-based method for anonymization metadata export within the IPFIX protocol, providing the basis for the definition of information models for configuring anonymisation techniques within an IPFIX Metering or Exporting Process, and for reporting the technique in use to an IPFIX Collecting Process. |
| | | | |
| draft-boucadair-behave-dns-a64-01.txt |
| | A64: DNS Resource Record for IPv4-mapped IPv6 Address |
| |
|
In the context of IPv4-IPv6 interconnection (or interworking), several solutions have been proposed within IETF. Some of these solutions require the definition of a new IPv4-mapped IPv6 address [I-D.ietf-behave-address-format] which is used to represent an IPv4- only host in an IPv6 realms and the definition of a new mechanism called DNS64 for synthesizing a AAAA record, representing an IPv4- mapped IPv6 address in the DNS system, from the A record representing the IPv4 address of the IPv4-only host [I-D.ietf-behave-dns64]. This IPv4-mapped IPv6 address, when managed by a translator, is to be considered as "fake" address in a DNS system since it is not necessarily assigned to any host's interface qualified by the associated name. This document defines a new DNS record type and query type to identify IPv4-mapped IPv6 address [I-D.ietf-behave-address-format] from native IPv6 ones. The new record type and query type aim at helping the requesting party to enforce its policies and avoid crossing NAT64 boxes when possible. Native addresses are to be preferred. |
| | | | |
| draft-boucadair-behave-dns64-discovery-00.txt |
| | DNS64 Service Location and Discovery |
| |
|
This memo proposes a set of solutions for the discovery of DNS64 [I-D.ietf-behave-dns64] service. Three solution candidates are proposed: SRV RR, DHCP and RA-based. |
| | | | |
| draft-boucadair-behave-ipv6-portrange-04.txt |
| | Flexible IPv6 Migration Scenarios in the Context of IPv4 Address Shortage |
| |
| | draft-boucadair-behave-ipv6-portrange-04.txt |
| | Date: |
20/10/2009 |
| | Authors: |
Mohammed Boucadair, Pierre Levis, Jean-Luc Grimault, Alain Villefranque, Mohamed Kassi-Lahlou, Gabor Bajko, Yiu Lee, Telemaco Melia, Olivier Vautrin |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This memo presents a solution to solve IPv4 address shortage and ease IPv4-IPv6 interconnection. The document presents a set of incremental steps for the deployment of IPv6 as a means to solve IPv4 address exhaustion. Stateless IPv4/IPv6 address mapping functions are introduced and IPv4-IPv6 interconnection scenarios presented. This memo advocates for a more proactive approach for the deployment of IPv6 into operational networks. This memo specifies the IPv6 variant of the A+P. Both encapsulation and translation scheme are covered. Moreover, two modes are elaborated: the binding mode (compatible mode with DS-lite) and the stateless mode. |
| | | | |
| draft-boucadair-dispatch-ipv6-atypes-00.txt |
| | The atypes media feature tag for Session Initiation Protocol (SIP) |
| |
|
This specification defines a new media feature tag called atypes. This new media feature tag indicates the IP address type capabilities of the UA (User Agent) and can aid the routing process and ease the invocation of required functions when heterogeneous (i.e. IPv4 and IPv6) parties are involved in a given SIP session. |
| | | | |
| draft-boucadair-dslite-interco-v4v6-02.txt |
| | Deploying Dual-Stack lite in IPv6-only Network |
| |
| | draft-boucadair-dslite-interco-v4v6-02.txt |
| | Date: |
05/10/2009 |
| | Authors: |
Mohammed Boucadair, Christian Jacquenet, Jean-Luc Grimault, Mohamed Kassi-Lahlou, Pierre Levis, Dean Cheng, Yiu Lee |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This memo describes a proposal to enhance Dual-Stack lite (DS-lite) [I-D.ietf-softwire-dual-stack-lite] solution with an additional feature to ease interconnection between IPv4 and IPv6 realms. When deployed, no dual-stack-enabled network is required for the delivery of both IPv4 and IPv6 connectivity to customers. IPv6 transfer capabilities are used for the transfer of IPv4-addressed datagrams in a completely stateless scheme between the interconnection segment and the DS-lite CGN node(s). The proposed DS-lite extension is meant to encourage (if not accelerate) IPv6 deployment in networks. |
| | | | |
| draft-boucadair-isis-v4v6-mi-01.txt |
| | IPv4-mapped IPv6 Instance IDs in IS-IS |
| |
|
This memo defines two new Instance Identifiers (Instance IDs) in IS-IS [RFC1195]). These new Instance IDs [I-D.ietf-isis-mi] are meant to instantiate distinct IS-IS instances to convey routing information which is restricted to IPv4-mapped IPv6 addresses [I-D.ietf-behave-address-format]. The ultimate goal of running separate instances for IPv4-mapped IPv6 routes is to isolate the IPv6 routing table from the IPv4 routing table, and to avoid any overload due to the population of the table by IPv4-mapped IPv6 routes. This isolation is motivated also from an operational perspective to allow the enforcement of specific routing policies for each topology. |
| | | | |
| draft-boucadair-isis-v4v6-mt-01.txt |
| | Multi-Topology IS-IS for IPv4-mapped IPv6 |
| |
|
This memo defines two new Multi Topology Routing Identifiers (MT IDs) to be used by the Intermediate System to Intermediate System (M-ISIS, [RFC5120]) routing protocol within a Multi-Topology (MT) context. These new M-ISIS topologies are meant to convey routing information which is specific to IPv4-mapped IPv6 addresses [I-D.ietf-behave-address-format]. The goal of running separate instances for IPv4-mapped IPv6 routes is to isolate the IPv6 routing table from the IPv4 routing table, and to avoid any overload due to the population of the table by IPv4-mapped IPv6 routes. This isolation is motivated also from an operational perspective to enforce specific routing policies for each topology. |
| | | | |
| draft-boucadair-mmusic-ccap-00.txt |
| | Session Description Protocol (SDP) Connectivity Capability (CCAP) Attribute |
| |
|
This memo proposes a mechanism which allows to carry multiple IP addresses, of different address families (e.g., IPv4, IPv6), in the same SDP offer/answer. The proposed attribute solves the backward compatibility problem which plagued ANAT, due to its syntax. |
| | | | |
| draft-boucadair-ospf-v4v6-ospfv3-mi-01.txt |
| | IPv4-mapped IPv6 Instance IDs in OSPFv3 |
| |
|
This memo defines two new Instance Identifiers (Instance IDs) in OSPFv3 [RFC2740]). These new Instance IDs [I-D.ietf-ospf-af-alt] are meant to instantiate distinct OSPFv3 instances to convey routing information which is specific to IPv4-mapped IPv6 address Address Family [I-D.ietf-behave-address-format]. The goal of running separate instances for IPv4-mapped IPv6 is to distinguish the native IPv6 routing topology from the IPv4 routing topology. Separate instances are also meant to prevent any overload of the native IPv6 routing tables by IPv4-mapped IPv6 routes. This isolation is motivated also from an operational perspective to enforce specific routing policies for each topology. |
| | | | |
| draft-boucadair-ospf-v4v6-ospfv3-mt-01.txt |
| | Multi-Topology OSPFv3 for IPv4-mapped IPv6 |
| |
|
This memo defines two new Multi Topology Routing Identifiers (MT IDs) in OSPFv3 [RFC2740]). These new MT-OSPFv3 [I-D.ietf-ospf-mt-ospfv3] topologies are meant to convey routing information which is restricted to IPv4-mapped IPv6 addresses [I-D.ietf-behave-address-format]. The goal of running separate instances for IPv4-mapped IPv6 routes is to isolate the IPv6 routing table from the IPv4 routing table, and to avoid any overload due to the population of the table by IPv4-inferred routes. This isolation is motivated also from an operational perspective to enforce specific routing policies for each topology. |
| | | | |
| draft-boucadair-port-range-02.txt |
| | IPv4 Connectivity Access in the Context of IPv4 Address Exhaustion: Port Range based IP Architecture |
| |
| | draft-boucadair-port-range-02.txt |
| | Date: |
03/07/2009 |
| | Authors: |
Mohammed Boucadair, Pierre Levis, Gabor Bajko, Teemu Savolainen |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This memo proposes a solution, based on fractional addresses, to face the IPv4 public address exhaustion. It details the solution and presents a mock-up implementation, with the results of tests that validate the concept. It also describes architectures and how fractional addresses are used to overcome the IPv4 address shortage. A comparison with the alternative Carrier-Grade NAT (CG-NAT) solutions is also elaborated in the document. The IPv6 variant of this solution is described in a companion draft. |
| | | | |
| draft-boucadair-pppext-portrange-option-01.txt |
| | Port Range Configuration Options for PPP IPCP |
| |
|
This memo defines two IPCP (IP Configuration Protocol, [RFC1332]) Options to be used in the context of Port Range solutions. IPCP is the configuration protocol used when PPP (Point-to-Point Protocol, [RFC1661]) is deployed. |
| | | | |
| draft-boucadair-sipping-ipv6-atypes-02.txt |
| | The atypes media feature tag for Session Initiation Protocol (SIP) |
| |
|
This specification defines a new media feature tag called atypes. This new media feature tag indicates the IP address type capabilities of the UA (User Agent) and can aid the routing process and ease the invocation of required functions when heterogeneous (i.e. IPv4 and IPv6) parties are involved in a given SIP session. |
| | | | |
| draft-boulton-xcon-session-chat-04.txt |
| | Chatrooms within a Centralized Conferencing (XCON) System |
| |
|
The document "A Framework for Centralized Conferencing" defines a centralized conference as both signaling and protocol agnostic. The primary examples within this framework focus on audio and video as the media types for the session. This document provides an overview of the mechanisms defined in the centralized conferencing framework that can be used to support multi-user chat. In addition, the document describes additional functionality and requirements necessary to provide feature rich functionality. |
| | | | |
| draft-boutros-mpls-tp-cv-cc-00.txt |
| | Connection Verification and Continuity Check for MPLS Transport Profile Label Switched Path |
| |
| | draft-boutros-mpls-tp-cv-cc-00.txt |
| | Date: |
06/07/2009 |
| | Authors: |
Sami Boutros, Siva Sivabalan, George Swallow, David Ward, Stewart Bryant |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
Connection Verification (CV) and Continuity Check (CC) are important Operations, Administration, and Management (OAM)functions of MPLS Transport Profile (MPLS-TP). This document specifies methods for CV and CC for MPLS-TP Label Switched Path (LSP) using Bidirectional Forwarding Detection (BFD). |
| | | | |
| draft-boutros-mpls-tp-fault-02.txt |
| | MPLS-TP Fault OAM |
| |
| | draft-boutros-mpls-tp-fault-02.txt |
| | Date: |
13/07/2009 |
| | Authors: |
Sami Boutros, Siva Sivabalan, George Swallow, David Ward, Stewart Bryant |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This draft specifies a fault management indications for MPLS Transport Profile(MPLS-TP) Label Switched Paths (LSPs). The notification mechanism employs a generic method for a Maintenance End Point (MEP) or Maintenance Intermediate Point (MIP) to indicate a fault on an MPLS-TP LSP. A new MPLS Operation, Administration, and Maintenance (OAM) message is defined. |
| | | | |
| draft-boutros-mpls-tp-path-trace-00.txt |
| | Connection verification for MPLS Transport Profile LSP |
| |
|
This document specifies method for verifying the connection of an MPLS Transport Profile(MPLS-TP) Label Switched Path (LSP) for management purpose. The proposed extension is based on MPLS Operation, Administration, and Maintenance (OAM). The goal is to verify that an MPLS-TP LSP is properly setup in both control and data planes, as well as to record the identities of all the LSRs along the path of MPLS-TP LSP. |
| | | | |
| draft-braden-independent-submission-02.txt |
| | Procedures for Rights Handling in the RFC Independent Stream |
| |
|
This document specifies the procedures by which authors of RFC Independent Stream documents grant the community "incoming" rights for copying and using the text. It also specifies the "outgoing" rights the community grants to readers and users of those documents, and it requests that the IETF Trust manage the outgoing rights to effect this result. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. |
| | | | |
| draft-brashear-afs3-pts-extended-names-00.txt |
| | Authentication Name Mapping extension for AFS-3 Protection Service |
| |
|
This document describes the extension of the format, use and communication of authentication names in the AFS-3 protocol to allow for additional authentication mechanisms to be represented and mapped to AFS IDs, independent of the AFS usernames currently used for management of PRDB entries. The new interface provides mechanisms for adding, removing, and listing mappings, and to allow the fileserver to map an authentication name to a PTS identity. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 22, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. |
| | | | |
| draft-brasher-diap-09.txt |
| | Distributed Internet Archive Protocol (DIAP) |
| |
|
A de-centralised, self-contained and managed storage protocol. A system to provide strong storage fail over by using existing resources over networks distributing vital data evenly. Rapid deployment and high redundancy for small to medium organisations as well as individuals. Designed to reduce dependency on tape backup systems. The protocol also has implications for long term archiving. By classifying data vitality values the limitations in physical space due to bandwidth constrictions can be overcome and the usefulness of DIAP maximised. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 25, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. |
| | | | |
| draft-briscoe-re-pcn-border-cheat-03.txt |
| | Emulating Border Flow Policing using Re-PCN on Bulk Data |
| |
|
Scaling per flow admission control to the Internet is a hard problem. The approach of combining Diffserv and pre-congestion notification (PCN) provides a service slightly better than Intserv controlled load that scales to networks of any size without needing Diffserv's usual overprovisioning, but only if domains trust each other to comply with admission control and rate policing. This memo claims to solve this trust problem without losing scalability. It provides a sufficient emulation of per-flow policing at borders but with only passive bulk metering rather than per-flow processing. Measurements are sufficient to apply penalties against cheating neighbour networks. |
| | | | |
| draft-briscoe-tsvwg-re-ecn-tcp-08.txt |
| | Re-ECN: Adding Accountability for Causing Congestion to TCP/IP |
| |
|
This document introduces a new protocol for explicit congestion notification (ECN), termed re-ECN, which can be deployed incrementally around unmodified routers. The protocol works by arranging an extended ECN field in each packet so that, as it crosses any interface in an internetwork, it will carry a truthful prediction of congestion on the remainder of its path. The purpose of this document is to specify the re-ECN protocol at the IP layer and to give guidelines on any consequent changes required to transport protocols. It includes the changes required to TCP both as an example and as a specification. It briefly gives examples of mechanisms that can use the protocol to ensure data sources respond correctly to congestion,and these are described more fully in a companion document [I-D.briscoe-tsvwg-re-ecn-tcp-motivation]. Authors' Statement: Status (to be removed by the RFC Editor) Although the re-ECN protocol is intended to make a simple but far- reaching change to the Internet architecture, the most immediate priority for the authors is to delay any move of the ECN nonce to Proposed Standard status. The argument for this position is developed in Appendix E. Changes from previous drafts (to be removed by the RFC Editor) Full diffs from all previous verisons (created using the rfcdiff tool) are available at From -07 to -08 (current version): Minor changes and consistency checks. References updated. From -06 to -07: Major changes made following splitting this protocol document from the related motivations document [I-D.briscoe-tsvwg-re-ecn-tcp-motivation]. Significant re-ordering of remaining text. New terminology introduced for clarity. Minor editorial changes throughout. |
| | | | |
| draft-briscoe-tsvwg-re-ecn-tcp-motivation-01.txt |
| | Re-ECN: A Framework for adding Congestion Accountability to TCP/IP |
| |
|
This document describes the framework to support a new protocol for explicit congestion notification (ECN), termed re-ECN, which can be deployed incrementally around unmodified routers. Re-ECN allows accurate congestion monitoring throughout the network thus enabling the upstream party at any trust boundary in the internetwork to be held responsible for the congestion they cause, or allow to be caused. So, networks can introduce straightforward accountability for congestion and policing mechanisms for incoming traffic from end- customers or from neighbouring network domains. As well as giving the motivation for re-ECN this document also gives examples of mechanisms that can use the protocol to ensure data sources respond correctly to congestion. And it describes example mechanisms that ensure the dominant selfish strategy of both network domains and end- points will be to use the protocol honestly. Authors' Statement: Status (to be removed by the RFC Editor) Although the re-ECN protocol is intended to make a simple but far- reaching change to the Internet architecture, the most immediate priority for the authors is to delay any move of the ECN nonce to Proposed Standard status. The argument for this position is developed in Appendix E. |
| | | | |
| draft-brockners-nat-control-protocols-review-00.txt |
| | Review of NAT Control Protocols |
| |
|
This document reviews NAT control capabilities of a set of protocols and evaluates their applicability to per endpoint control of a Large Scale NAT device. |
| | | | |
| draft-brown-versioning-link-relations-03.txt |
| | Link Relations for Simple Version Navigation |
| |
|
This specification defines Atom link relations for navigation between a resource and its versions. |
| | | | |
| draft-brusilovsky-pak-10.txt |
| | Password-Authenticated Diffie-Hellman Exchange (PAK) |
| |
| | draft-brusilovsky-pak-10.txt |
| | Date: |
10/04/2009 |
| | Authors: |
Igor Faynberg, Sarvar Patel, Zachary Zeltsan, Alec Brusilovsky |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document proposes to add mutual authentication, based on human-memorizable password, to the basic unauthenticated Diffie-Hellman key exchange. The proposed algorithm is called Password-authenticated Key exchange (PAK). PAK allows two parties to authenticate themselves while performing the Diffie-Hellman exchange. The protocol is secure against all passive and active attacks. In particular, it does not allow either type of attackers to obtain any information that would enable an off-line dictionary attack on the password. PAK provides Forward Secrecy. |
| | | | |
| draft-bryan-http-digest-algorithm-values-update-03.txt |
| | Additional Hash Algorithms for HTTP Instance Digests |
| |
|
[RFC3230] created the IANA registry named "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" which defines values for digest algorithms used in HTTP. This draft adds new values to the registry and updates previous values. |
| | | | |
| draft-bryan-metalink-22.txt |
| | The Metalink Download Description Format |
| |
| | draft-bryan-metalink-22.txt |
| | Date: |
08/11/2009 |
| | Authors: |
Anthony Bryan, Metalinker Project, Neil McNab, Peter Poeml |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document specifies Metalink, an XML-based download description format. Metalink describes multiple download locations (mirrors), checksums, and other information. Clients can transparently use this information to reliably transfer files. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 11, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. |
| | | | |
| draft-bryan-metalinkhttp-12.txt |
| | Metalink/HTTP: Mirrors and Checksums in HTTP Headers |
| |
| | draft-bryan-metalinkhttp-12.txt |
| | Date: |
11/11/2009 |
| | Authors: |
Anthony Bryan, Neil McNab, Henrik Nordstrom, Alan Ford |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document specifies Metalink/HTTP: Mirrors and Checksums in HTTP Headers, an alternative to the Metalink XML-based download description format. Metalink/HTTP describes multiple download locations (mirrors), Peer-to-Peer, checksums, digital signatures, and other information using existing standards for HTTP headers. Clients can transparently use this information to make file transfers more robust and reliable. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 15, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. |
| | | | |
| draft-bryant-ipfrr-tunnels-03.txt |
| | IP Fast Reroute using tunnels |
| |
|
This draft describes an IP fast re-route mechanism that provides backup connectivity in the event of a link or router failure. In the absence of single points of failure and asymmetric costs, the mechanism provides complete protection against any single failure. If perfect repair is not possible, the identity of all the unprotected links and routers is known in advance. This IP Fast Reroute advanced method was invented in 2002 and draft (draft-bryant-ipfrr-tunnels-00.txt) describing it was submitted to the IETF in May 2004. It was one of the first methods of achieving full repair coverage in an IP Network, and as such the draft has been widely referenced in the academic literature. The authors DO NOT propose that this IPFRR method be implemented since better IPFRR advanced method capable of achieving full repair coverage have subsequently been invented. |
| | | | |
| draft-bryant-mpls-tp-ach-tlv-02.txt |
| | Definition of ACH TLV Structure |
| |
|
In some application of the associated channel header (ACH), it is necessary to have the ability to include a set of TLVs to provide additional context information for the ACH payload. This document defines a number of TLV types. NOTE the family of Address Types is known to be incomplete. The authors request that members of the MPLS-TP community provide details of their required address formats in the form of text for the creation of an additional sections similar to Section 3.1. NOTE other TLV types will be added in further revisions of this document. The authors request that members if the MPLS-TP community requiring new TLVs to complete there MPLS-TP specifications provide details of their required TLV in the form of text for the creation of additional sections similar to Section 2.2. |
| | | | |
| draft-bryant-pwe3-packet-pw-02.txt |
| | Packet Pseudowire Encapsulation over an MPLS PSN |
| |
|
This document describes a pseudowire that is used to transport a packet service over an MPLS PSN is the case where the client LSR and the server PE are co-resident in the same equipment. For correct operation these clients require a multi-protocol interface with fate sharing between the client protocol suite. The packet pseudowire may be used to carry all of the required layer 2 and layer 3 protocols between the pair of client LSRs. |
| | | | |
| draft-c1222-transport-over-ip-02.txt |
| | ANSI C12.22,IEEE 1703 and MC1222 Transport Over IP |
| |
|
This RFC provides a framework for transporting ANSI C12.22/IEEE 1703/ MC1222 Advanced Metering Infrastructure (AMI) Application-Layer Messages on an IP network. |
| | | | |
| draft-cain-post-inch-phishingextns-06.txt |
| | Extensions to the IODEF-Document Class for Reporting Phishing,Fraud,and Other Crimeware |
| |
|
This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC5070 to support the reporting of phishing, fraud, other types of electronic crime. The extensions also support the exchange on information about widespread spam incidents. These extensions are flexible enough to support information gleaned from activities throughout the entire electronic fraud or spam cycle. Both simple reporting and complete forensic reporting are possible, as is consolidating multiple incidents . The extensions defined in this document are used to generate two different types of reports: a fraud report and a wide-spread spam report. Although similar in structure, each report has different required objects and intentions.RFC 2129 Keywords |
| | | | |
| draft-cakulev-ibake-00.txt |
| | IBAKE: Identity-Based Authenticated Key Agreement |
| |
|
Cryptographic protocols based on public key methods are based on certificates and large scale public key infrastructure (PKI) to support certificate management. The emerging field of Identity Based Encryption protocols allows to simplify the infrastructure requirements via a Key Generation Function (KGF) while providing the same flexibility. However one significant limitation of Identity Based Encryption methods is that the KGF can end up being a de-facto key escrow server with undesirable consequences. Another observed deficiency is a lack of mutual authentication of communicating parties. Here, Identity Based Authenticated Key Exchange (IBAKE) Protocol is specified which does not suffer from the key escrow problem and in addition provides mutual authentication and a perfect forward and backwards secrecy. |
| | | | |
| draft-cakulev-ikev2-psk-diameter-00.txt |
| | Diameter IKEv2: Support for Interaction between IKEv2 Server and Diameter Server |
| |
|
Internet Key Exchange is a component of IPsec used for performing mutual authentication as well as establishing and maintaining security associations (SAs) between two parties such as a user and a network entity. Internet Key Exchange v2 (IKEv2) protocol allows several different mechanisms for authenticating a user, namely the Extensible Authentication Protocol, certificates, and pre-shared secrets. To authenticate and/or authorize the user, the network element such as the Access Gateway may need to dynamically bootstrap a security association based on interaction with the Diameter server. This document specifies the interaction between the Access Gateway and Diameter server for the IKEv2 based on pre-shared secrets. |
| | | | |
| draft-cakulev-mikey-ibake-00.txt |
| | MIKEY-IBAKE: Identity-Based Mode of Key Distribution in Multimedia Internet KEYing (MIKEY) |
| |
|
This document describes a key management protocol variant for the multimedia Internet keying (MIKEY) protocol which relies on trusted key management service. In particular, this variant utilizes Identity Based Authenticated Key Exchange framework which allows the participating clients to perform mutual authentication and derive a session key in an 'asymmetric identity based encryption' framework. This framework, in addition to providing mutual authentication, eliminates the key escrow problem that is common in standard Identity Based Encryption while simultaneously providing perfect forward and backwards secrecy. |
| | | | |
| draft-camarillo-hip-via-00.txt |
| | Host Identity Protocol (HIP) Multi-hop Routing Extension |
| |
|
This document specifies two extensions to HIP to implement multi-hop routing. The first extension allows a HIP packet to carry the list of hosts that forwarded it. The second extension allows implementing source routing in HIP. That is, a host sending a HIP packet can define a set of hosts that the HIP packet should traverse. |
| | | | |
| draft-camarillo-sipcore-reinvite-01.txt |
| | Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP) |
| |
|
In this document, we clarify the handling of re-INVITEs in SIP. We clarify in which situations a UAS (User Agent Server) should generate a success response and in which situations a UAS should generate an error response to a re-INVITE. Additionally, we clarify issues related to target-refresh requests. |
| | | | |
| draft-campagna-tls-ecmqv-ecqv-00.txt |
| | ECMQV_ECQV Cipher Suites for Transport Layer Security (TLS) |
| |
|
This document specifies a set of cipher suites for the Transport Layer Security (TLS) protocol that use Elliptic Curve Qu-Vanstone (ECQV) certificates to authenticate an Elliptic Curve Menezes-Qu- Vanstone (ECMQV) exchange. These cipher suites provide forward secrecy. |
| | | | |
| draft-cao-behave-hbt-req-00.txt |
| | Requirements for host based translation solution |
| |
|
This document describes the motivation for pursuing host-based translation schemes for allowing co-existence of legacy IPv4 applications in IPv6 only networks. It lays out the requirements that need to be met by the proposed solutions. |
| | | | |
| draft-cardona-cablelabs-urn-03.txt |
| | A Uniform Resource Name (URN) Namespace for CableLabs |
| |
|
This document describes the Namespace Identifier (NID) 'cablelabs' for Uniform Resource Names (URNs) used to identify resources published by Cable Television Laboratories, Inc. (CableLabs). CableLabs specifies and manages resources that utilize this URN identification model. Management activities for these and other resource types are handled by the manager of the CableLabs' Assigned Names and Numbers registry. |
| | | | |
| draft-carlberg-avt-rtcp-xr-ecn-01.txt |
| | 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. |
| | | | |
| draft-carlberg-avt-rtp-ecn-02.txt |
| | Explicit Notification Extension (ECN) Support for RTP Sessions |
| |
|
This document describes a design to support Explicit Congestion Notification (ECN) for the RTP layer. The design defines a means of end-to-end negotiated support of ECN using the Session Description Protocol (SDP) and a new RTCP Extended Report. |
| | | | |
| draft-carlberg-dime-priority-avps-00.txt |
| | Diameter Priority Attribute Value Pairs |
| |
|
This document defines various priority parameters for use with Diameter and the AAA framework. These parameters are defined in several different protocols that operate at either the network or application layer. |
| | | | |
| draft-carpenter-behave-referral-object-01.txt |
| | A Generic Referral Object for Internet Entities |
| |
|
The purpose of a referral is to enable a given entity in a multiparty application to pass information to another party. This memo specifies a Generic Referral Object (GRO) to be used in the context of referrals. The proposed object is compact and is application- independent. Both IPv4 and IPv6 schemes are supported, as well as upper layer identifiers. Additional information to characterise an enclosed reference is also described. To allow proper interpretation of referrals, a new notion of scope identifiers is introduced. |
| | | | |
| draft-carpenter-renum-needs-work-04.txt |
| | Renumbering still needs work |
| |
|
This document reviews the existing mechanisms for site renumbering for both IPv4 and IPv6, and identifies operational issues with those mechanisms. It also summarises current technical proposals for additional mechanisms. Finally there is a gap analysis identifying possible areas for future work. |
| | | | |
| draft-carpenter-v6ops-isp-scenarios-00.txt |
| | Emerging Service Provider Scenarios for IPv6 Deployment |
| |
|
This document describes scenarios that are emerging among Internet Service Providers for the deployment of IPv6. They are based on practical experience so far, as well as current plans and requirements, but they are not intended as binding recommendations. [[ NOTE: This a preliminary version with incomplete content. ]] |
| | | | |
| draft-cassen-access-right-distribution-protocol-06.txt |
| | 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. |
| | | | |
| draft-cavuto-dtcp-03.txt |
| | 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. |
| | | | |
| draft-ceccarelli-ccamp-gmpls-g709-am3-00.txt |
| | 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. |
| | | | |
| draft-ceccarelli-ccamp-gmpls-g709-lmp-test-01.txt |
| | Link Management Protocol (LMP) Test Messages Extensions for Evolutive Optical Transport Networks (OTN) |
| |
|
This document specifies Link Management Protocol (LMP) extensions for the support of enhanced Optical Transport Networks (OTN). In particular it updates LMP test messages detailing the ITU-T G.709 OTN technology specific information and extends them in order to cover also recently introduced signal types and containers defined by the ITU-T. |
| | | | |
| draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt |
| | Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolutive G.709 OTN Networks |
| |
|
This document describes OSPF routing protocol extensions to support the evolutive Optical Transport Networks (OTN) under the control of Generalized MPLS (GMPLS). zhang Expires April 2010 [page 1] draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt October 2009 |
| | | | |
| draft-ceccarelli-mpls-tp-p2mp-ring-01.txt |
| | P2MP traffic protection in MPLS-TP ring topology |
| |
|
Purpose of this ID is to describe requirements and possible solutions for point to multipoint (P2MP) traffic distribution over interconnected MPLS-TP rings. The rationale for an ID on such a specific application is illustrated in the rest of the document. |
| | | | |
| draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-01.txt |
| | Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for evolutive OTNs 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. References also to G.sup43 are provided. |
| | | | |
| draft-chakrabarti-mip4-mcbc-04.txt |
| | IPv4 Mobility Extension for Multicast and Broadcast Packets |
| |
| | draft-chakrabarti-mip4-mcbc-04.txt |
| | Date: |
08/07/2009 |
| | Authors: |
Ahmad Muhanna, Samita Chakrabarti, Gabriel Montenegro, Yingzhe Wu, Basavaraj Patil |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This specification defines a new Mobile IPv4 extension which is used to negotiate the Multicast-Broadcast Encapsulation Delivery style in the case of Mobile IPv4 Foreign Agent Care-of Address mode registration. This mechanism allows the mobile node to negotiate which type of traffic to be delivered encapsulated to the foreign agent while delivering other types of IP packets using direct delivery style. In particular, this mechanism gives the flexibility to eliminate tunnel overhead in the (typically) wireless medium between the mobile node and the foreign agent. In addition to the reduced overhead, the new mechanism makes many multicast and broadcast services available to the mobile node in a much more deterministic and efficient way. |
| | | | |
| draft-chan-netext-distributed-lma-00.txt |
| | Distributed Local Mobility Anchors |
| |
|
The full functions of a local mobility anchor may be separated into different logical functions: (1) allocation of home network prefixes or home addresses to mobile nodes, (2) location management function which includes managing the IP addresses and locations of the mobile nodes and (3) mobility routing function which includes intercepting and forwarding packets. Distributed local mobility anchors provides visiting local mobility anchors in different networks with mobility routing function to avoid triangle routing problem in Proxy mobile IP or Mobile IP, but keeps the internetwork location management function at the home local mobility anchors at registered networks. The needed location information of a mobile node is acquired only when a packet is first sent to the mobile node and are then cached at the visiting local mobility anchor to enable subsequent optimized mobility routing. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 16, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. |
| | | | |
| draft-chan-torvi-jacquenet-mpls-rd-p2mp-te-00.txt |
| | Receiver Driven Point-To-Multi-Point Traffic Engineered Label Switched Paths |
| |
|
For content delivery services that rely upon the IP multicast transmission scheme, the distribution trees are receiver initiated. The delivery of such services over MPLS networking infrastructures may rely upon P2MP LSP tree structures that are sender initiated, with the root of the P2MP tree being at the LSR router directly connected to the sender. This document describes a mechanism that aims at establishing MPLS P2MP tree structures that are receiver initiated. This mechanism builds on the works of Point-to-MultiPoint Traffic Engineered Lable Swithched Paths (P2MP-TE LSPs). This mechanism can also be used to establish receiver driven BiDirectional P2MP TE LSPs. |
| | | | |
| draft-chen-behave-olnat-01.txt |
| | A Optimal Load-balance mechanism for NAT64 (OL-NAT) |
| |
|
In NAT64 scenaires,sigle-point failure is a critical issue to restrict large-scale deployment. In order to overcome this hurdle, this memo proposed a optimal load-balance mechanism for NAT64. Through the new-defined evaluation metrics, several extended ICMP messages combining with anycast are performed to achieve optimal NAT64 selection. Meanwihle, the synchroniztion process of IP address mapping information is also designed to guarantee the service continuity. |
| | | | |
| draft-chen-behave-rsnat-02.txt |
| | Reliable and Scalable NAT mechanism (RS-NAT) based on BGP for IPv4/IPv6 Transition |
| |
| | draft-chen-behave-rsnat-02.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Gang Chen, Hui Deng, Bo Zhou, Mingwei Xu, Linjian Song, Yong Cui |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
For the rapid exhaustion of IPv4 address pool against the slow development of IPv6, IPv4/IPv6 co-existence/transition would be a long period. In the IPv4/IPv6 transition process, there are many NAT- like technologies active in the internet. However, the NAT boxes such as IPv4 NAT, IPv4/IPv6 NAT are so poor in their reliability and scalability, which put a severe threat on the development of IPv4/IPv6 transition. This document defines a reliable and scalable NAT (RS- NAT) mechanism to solve the problem. |
| | | | |
| draft-chen-bgp-ext-opt-param-01.txt |
| | 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. |
| | | | |
| draft-chen-host-ipv6-ps-00.txt |
| | Host-based Translation Problem Statement |
| |
|
When operators start to customize user terminals, host-based IPv6 translation will be feasible. Host-based translation should overcome single-point failure problems and support various connections between two IP families networks simultaneously. In addition, legacy IPv4 applications should not be modified. This document will discuss host-based translation applicable scenarios and corresponding issues. |
| | | | |
| draft-chen-lisp-er-mo-01.txt |
| | An Incremental Deployable Mapping Service for Scalable Routing Architecture |
| |
| | draft-chen-lisp-er-mo-01.txt |
| | Date: |
12/07/2009 |
| | Authors: |
Gang Chen, Hui Deng, Bo Zhou, Mingwei Xu, Dong Huo, Yu Cao |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document describes a mechanism of providing mapping service for LISP-like architecture. The mapping service comprises of EID Router (ER) mechanism and supplementary DHT Mapping Overlay (MO), in which ER mechanism is for reducing forwarding entries in routers while driving the packets to the destination through tunnels, and the DHT MO serves as a supplement that provides specific mappings to reduce the number of tunnels. The mechanism is flexibly deployable for ISPs since it costs little and is easy to progress. |
| | | | |
| draft-chen-mpls-bfd-enhancement-00.txt |
| | BFD for MPLS LSPs Enhancement |
| |
|
This document defines an enhancement to Bi-directional Forwarding Detection (BFD) for MPLS LSPs [MPLS-BFD] that can be used to specify the return path of BFD control packets for a specific BFD session. Specifying return co-routed or protected return path increases robustness of BFD failure detection and reduces false positives. This document also defines a way to avoid duplicate BFD sessions currently encountered with Co-routed Bidirectional LSPs and Associated Bidirectional LSP. The enhancement halves the BFD sessions over those LSPs, and allows a Co-routed Bidirectional LSPs or Associated Bidirectional LSPs to be protected and switched as a single entity. |
| | | | |
| draft-chen-mpls-return-path-specified-lsp-ping-01.txt |
| | Return Path Specified LSP Ping |
| |
|
This document defines extensions to the failure-detection protocol for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) known as "LSP Ping" that allow selection of the LSP to use for the echo reply return path. Enforcing a specific return path can be used to verify bidirectional connectivity and also increase LSP ping robustness. It may also be used by Bidirectional Forwarding Detection (BFD) for MPLS bootstrap signaling thereby making BFD for MPLS more robust. |
| | | | |
| draft-chen-mpls-tp-nm-discovery-req-00.txt |
| | Multiprotocol Label Switching Transport NM Auto discovery requirement |
| |
|
Layer network topology display on NMS (Network Management System), and can refresh quickly on any change happen on managed network, this function is very useful and important in current and future TMN (Telecom Management Network). It implies equipment should provide some mechanism to support, such as auto discovery. These also apply to TMN of MPLS-TP network. |
| | | | |
| draft-chen-ppsp-dht-chunk-discovery-evaluation-00.txt |
| | Evaluation of DHT-based Chunk Discovery for P2P Streaming |
| |
|
Recently, some researchers have suggested that DHT should be applied to the P2P streaming system to do the media block search. This draft evaluates this proposal by simulation and modeling analysis, and discloses that it is inappropriate for P2P live streaming system. Chen Expires April 18, 2010 [page 2] Internet-Draft Evaluation of DHT-based Chunk Discovery for P2P Streaming October 2009 |
| | | | |
| draft-cheneau-cga-pk-agility-01.txt |
| | 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. |
| | | | |
| draft-cheneau-csi-cga-pk-agility-00.txt |
| | 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. |
| | | | |
| draft-cheneau-csi-ecc-sig-agility-00.txt |
| | ECC public key and signature support in Cryptographically Generated Addresses (CGA) and in the Secure Neighbor Discovery (SEND) |
| |
|
This draft describes a mechanism to deploy Elliptic Curve Cryptography (ECC) alongside with Cryptographically Generated Addresses (CGA) and the Secure Neighbor Discovery (SEND). This document provides basic skeleton to integrate new signature algorithms in CGA and SEND. |
| | | | |
| draft-cheneau-csi-send-sig-agility-00.txt |
| | 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). |
| | | | |
| draft-cheneau-send-sig-agility-01.txt |
| | 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. |
| | | | |
| draft-cheney-safe-04.txt |
| | SAFE (Server-side Asynchronous Framework Execution) Scripting Method |
| |
|
SAFE Scripting Method is a model for allowing application interactivity in email while simultaneously elminating security vulnerabilities associated with client-side scripting. |
| | | | |
| draft-cheshire-dnsext-multicastdns-08.txt |
| | Multicast DNS |
| |
|
As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server, is becoming essential. Multicast DNS (mDNS) provides the ability to do DNS-like operations on the local link in the absence of any conventional unicast DNS server. In addition, mDNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. The primary benefits of mDNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures. |
| | | | |
| draft-cheshire-dnsext-nbp-07.txt |
| | Requirements for Replacing AppleTalk |
| |
|
One of the goals of the authors of Multicast DNS (mDNS) and DNS-Based Service Discovery (DNS-SD) was the desire to retire AppleTalk and the AppleTalk Name Binding Protocol, and to replace them with an IP-based solution. This document presents a brief overview of the capabilities of AppleTalk NBP, and outlines the properties required of an IP-based replacement. |
| | | | |
| draft-cheshire-edns0-owner-option-00.txt |
| | EDNS0 OWNER Option |
| |
|
The DNS-SD Sleep Proxy Service uses a message format identical to that used by standard DNS Update, with two additional pieces of information: the identity of the sleeping server to which the records belong, and the Wake-on-LAN Magic Packet bit pattern which should be used to wake the sleeping server. This document specifies the EDNS0 option used to carry that additional information. |
| | | | |
| draft-chown-addr-select-considerations-03.txt |
| | Considerations for IPv6 Address Selection Policy Changes |
| |
|
Where the source and/or destination node of an IPv6 communication is multi-addressed, a mechanism is required for the initiating node to select the most appropriate address pair for the communication. RFC 3484 (IPv6 Default Address Selection) [RFC3484] defines such a mechanism for nodes to perform source and destination address selection. While RFC3484 recognised the need for implementations to be able to change the policy table, it did not define how this could be achieved. Requirements have now emerged for administrators to be able to dynamically change the RFC 3484 policy tables from a central control point, and for nomadic hosts to be able to obtain the policy for the network that they are currently attached to without manual user intervention. This text discusses considerations for such policy changes, including examples of cases where a change of policy is required, and the likely frequency of such policy changes. This text also includes some discussion on the need to also update RFC 3484, where default policies are currently defined. |
| | | | |
| draft-chroboczek-babel-routing-protocol-01.txt |
| | The Babel routing protocol |
| |
|
Babel is a loop-free distance vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. |
| | | | |
| draft-chu-ldap-kdc-schema-00.txt |
| | An LDAP Schema for Kerberos KDC Information |
| |
|
This document describes an LDAP [RFC4511] schema for implementing the Kerberos 5 [RFC4120] KDC Information Model [I-D.ietf-krb-wg-kdc-model]. It also defines additional elements which are not covered by the Information Model, but are already in common use.1. Background and Motivation Both Kerberos and LDAP are frequently used separately for distributed authentication. They can also be used in combination, but typically their user databases remained separate. This distinction in databases causes unnecessary duplication of data and administration overhead. As such it is desirable for both systems to share a single database. Since the LDAP data model is more general it is most appropriate to store the Kerberos data in LDAP. A number of Kerberos implementations already have support for using LDAP as their KDC backing store. However, each implementation uses its own schema, and the multiple schemas are mutually incompatible. For the sake of interoperability and administrative ease, it is important to define a single standard schema that can be used uniformly by all Kerberos KDC implementations and interoperates with existing LDAP specifications.2. General Issues |
| | | | |
| draft-claise-ipfix-mediation-protocol-00.txt |
| | Specification of the Protocol for IPFIX Mediations |
| |
|
This document specifies the IP Flow Information Export (IPFIX) protocol specific to the Mediation. |
| | | | |
| draft-claise-structured-data-in-ipfix-02.txt |
| | Export of Structured Data in IPFIX |
| |
|
This document specifies an extension to IP Flow Information eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX information model specified in [RFC5102] to support hierarchical structured data and lists (sequences) of Information Elements in data records. This extension allows definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between Templates. |
| | | | |
| draft-clancy-emu-aaapay-03.txt |
| | EAP Method Support for Transporting AAA Payloads |
| |
|
This document defines bindings for existing EAP methods to transport Diameter AVPs, called "AAA payloads". The primary application is to support EAP channel bindings, but this could be used for other applications as well. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 16, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. |
| | | | |
| draft-coene-rserpool-applic-ipfix-08.txt |
| | Reliable Server Pooling Applicability for IP Flow Information Exchange |
| |
|
This document describes the applicability of the Reliable Server Pooling architecture to the IP Flow Information Exchange using the Aggregate Server Access Protocol (ASAP) functionality of RSerPool only. Data exchange in IPFIX between the router and the data collector can be provided by a limited retransmission protocol. |
| | | | |
| draft-cole-manet-report-mib-01.txt |
| | Definition of Managed Objects for Performance Reporting |
| |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring autonomous report generation on any device that supports MIBs containing counter and gauge objects for performance monitoring. This allows a management station to instruct a device to build off-line reports to be collected asynchronously by the management station. |
| | | | |
| draft-cole-netconf-robust-config-01.txt |
| | 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. |
| | | | |
| draft-combes-ipdvb-mib-rcs-08.txt |
| | The SatLabs Group DVB-RCS MIB |
| |
| | draft-combes-ipdvb-mib-rcs-08.txt |
| | Date: |
22/10/2009 |
| | Authors: |
Petter Amundsen, Micheline Lambert, Hans-Peter Lexow, Stephane Combes |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document describes the MIB module for the Digital Video Broadcasting Return Channel via Satellite system (DVB-RCS), as defined by the SatLabs Group. It defines a set of MIB entities to characterize the behavior and performance of network layer entities deploying DVB-RCS. |
| | | | |
| draft-constantine-ippm-tcp-throughput-tm-00.txt |
| | TCP Throughput Testing Methodology |
| |
|
This memo describes a methodology for measuring TCP throughput performance in an end-end managed network environment. This memo is intended to provide a practical approach to help users validate the TCP layer performance of a managed network, which should provide a better indication of end-user application level experience. In the methodology, various TCP and network parameters are identified that should be tested as part of the network verification at the TCP layer. |
| | | | |
| draft-contreras-multimob-msd-00.txt |
| | Multicast service delivery in PMIPv6 domains |
| |
|
A new working group, Multimob, has been chartered for providing an implementation of multicast service distribution to multicast listeners as they move in currently defined Proxy Mobile IPv6 (PMIPv6) domains according to RFC 5213 [1]. No protocol modifications or extensions are considered at this stage. Several proposals [2, 3, 4] have been already presented to face this issue. This contribution sums up some of the previous ideas extending them when necessary to overcome some limitations existing on such solutions. |
| | | | |
| draft-cooper-pkix-rfc5280-clarifications-00.txt |
| | Clarifications to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile |
| |
|
This document updates the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, which is published in RFC 5280. This document changes the set of acceptable encoding methods for the explicitText field of the user notice policy qualifier and clarifies the rules for converting internationalized domain name labels to ASCII. |
| | | | |
| draft-cooper-pkix-rfc5280-impl-report-00.txt |
| | Implementation Report for the Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile RFC 5280 |
| |
|
This is an implementation report of RFC 5280 for the purpose of advancing the document to Draft Standard. |
| | | | |
| draft-cordell-lumas-05.txt |
| | Lumas - Language for Universal Message Abstraction and Specification |
| |
|
A number of methods and tools are available for defining the format of messages used for application protocols. However, many of these methods and tools have been designed for purposes other than message definition, and have been adopted on the basis that they are available rather than being ideally suited to the task. This often means that the methods make it difficult to get definitions correct, or result in unnecessary complexity and verbosity both in the definition and on the wire. Lumas - Language for Universal Message Abstraction and Specification - has been custom designed for the purpose of message definition. It is thus easy to specify messages in a compact, extensible format that is readily machine manipulated to produce a compact encoding on the wire. |
| | | | |
| draft-cridland-acap-vendor-registry-00.txt |
| | The Internet Assigned Number Authority (IANA) Application Configurations Access Protocol (ACAP) Vendor Subtrees Registry |
| |
|
The original ACAP specification included a vendor registry now used in other protocols. This document updates the description of this registry, removing the need for a direct normative reference to ACAP, and removing ambiguity. |
| | | | |
| draft-crocker-dnssec-algo-signal-05.txt |
| | Signaling Cryptographic Algorithm Understanding in DNSSEC |
| |
|
The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. This draft sets out to specify a way for validating end-system resolvers to signal to a server which cryptographic algorithms they support. |
| | | | |
| draft-cui-mext-cn-binding-revocation-00.txt |
| | Binding Revocation from correspondent node in Route Optimization Mode |
| |
|
This document specifies an extension to Binding Revocation mechanism; the correspondent node may also initiate the binding revocation in Route Optimization mode. This extension provides a method to change the Route Optimization mode to the Bidirectional Tunneling mode. |
| | | | |
| draft-cui-mipshop-map-reliability-01.txt |
| | Mobility Anchor Point (MAP) Reliability Extension |
| |
|
This document introduces an extension to allow an adapted multiple binding in hierarchical mobile network. Mobile node registers its RCoA and LCoA in the home agent at same time to get two separate connections between the mobile node and the home agent, or between the mobile node and the correspondent node in Route Optimization scenario. These connections provide robust communication between the mobile node and correspondent nodes and mobile node can overcome the failure on MAP. |
| | | | |
| draft-cui-netext-lma-redirection-solution-00.txt |
| | LMA Redirection Solution |
| |
|
In network-based mobility management domain, LMA is used to manage the mobility of IP node attached to MAG. LMA discovery and LMA redirection mechanism are used to improve the network flexibility. This document is used to introduce a recommended solution for this purpose. In this solution Redirect Agent function is adopted to accomplish the requirement. |
| | | | |
| draft-cui-netext-route-optimization-agent-ext-01.txt |
| | Reflector Extension for Route Optimization Agent |
| |
|
Route Optimization is a very useful feature in Mobile IPv6. Mobile node can communicate with correspondent node without the involvement of the home agent by Route Optimization. But there are some limitations to this feature. One problem is that the mobile node and the correspondent node must be capable for Route Optimization. This document introduces a Route Optimization Agent function used for Route Optimization and this extension mechanism can enable Route Optimization to be used between mobile node and simple IP node. In the extension solution, the Route Optimization Agent function may be implemented in LMA or MAG and the Agent entity can reflect the RO- related signal messages and fulfill the Route Optimization procedure on behalf of the simple IP node. |
| | | | |
| draft-cui-netext-sma-pmipv6-00.txt |
| | Simultaneous Multi-Access for PMIPv6 based on Single HNP Model |
| |
|
Simultaneous Multi-Access (SMA), originally designed for MIPv6, expects to be ported to PMIPv6 to achieve flow binding. However, there are a lot of problems to adapt SMA to PMIPv6 due to different mechanisms of two mobility management protocol. This document analyzes issues of SMA and different multihoming scenarios in PMIPv6. A PMIPv6 system which allows a MN to share HNP across its interfaces is proposed and a SMA solution is designed for the modified PMIPv6 system. The solution supports flow-based routing and address-based routing simultaneously. |
| | | | |
| draft-cui-pet-00.txt |
| | PET-based solution for IPv4/IPv6 coexistence |
| |
| | draft-cui-pet-00.txt |
| | Date: |
06/07/2009 |
| | Authors: |
Yong Cui, Mingwei Xu, Shengling Wang, Xing Li, Jianping Wu |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
IPv6 offers significant advantages over IPv4, however it will take long time to replace IPv4 with IPv6. Therefore, these two protocols are expected to coexist during the transition period. Currently, there are many transition devices deployed to solve transition problems. Most of them only use one technology (either translation or tunneling). However, any transition technology has limitation and application scope. In transition scenarios, besides IP version of source, middle and destination network, the network characteristic (a regular edge network or a backbone) has key impact on system performance of transition methods. Therefore, we need to decide which transition method should be used in some typical transition scenarios and how the transition and tunneling devices collaborate for solving transition problems. This draft introduces a smart toolbox named PET (shortfor Prefixing, encapsulation and translation) which includes all fundamental elements needed in all transition scenarios, such as the control and data plane operations of tunneling and translation. Based on PET, we propose a network side transition solution. In this framework, there deploys only one kind of transition device, i.e. PET. Through the collaboration of PETs, the transition problems can be solved. In this draft, we give the advantages and disadvantages of all transition methods PET may adopt according to IP version of source, middle and destination network, and the network characteristic. |
| | | | |
| draft-cui-softwire-pet-01.txt |
| | IPv4/IPv6 Coexistence Framework (PET) |
| |
| | draft-cui-softwire-pet-01.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Yong Cui, Mingwei Xu, Shengling Wang, Jianping Wu, Xing Li, Chris Metz |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
IPv4 and IPv6 are expected to coexist for a long period. Currently, there are many IPv4/IPv6 transition/coexistence technologies, which can be generally divided into two categories: translation and tunneling. Both translation and tunneling have limitations and application scopes. In some typical transition scenarios, tunneling and translation are needed at the same time. In addition, there may be multiple network devices capable of doing translation or tunneling along the end-to-end path. It's important to choose particular device(devices) for doing translation or tunneling. This draft presents an IPv4-IPv6 transition/coexistence framework named PET (short for Prefixing, Encapsulation and Translation). PET is a network side solution which includes fundamental elements needed in various transition scenarios. In PET framework, signaling is required for transition devices to exchange necessary information and negotiate how to do combine transition and tunneling cooperatively. This draft also addresses how to deploy PETs and analyze the advantages and disadvantages of typical transition technologies that PET may adopt. |
| | | | |
| draft-cui-softwire-pet-framework-00.txt |
| | PET-based framework for IPv4/IPv6 coexistence |
| |
|
IPv6 offers significant advantages over IPv4, however it will take a long time to replace IPv4 with IPv6. Therefore, these two protocols are expected to coexist during the transition period. Currently, there are many transition technologies, such as translation and tunneling. In some typical transition scenarios, both tunneling and translation are needed. However, either translation or tunneling has limitation and application scope. In addition, besides IP version of source, middle and destination network, the network property (a regular edge network or a backbone) has key impact on system performance. Therefore, we need to decide which transition method should be used in some typical transition scenarios and how transition and tunneling collaborate for solving transition problems. This draft presents an IPv4-IPv6 transition framework, which is a network side transition solution. It introduces a toolbox named PET (short for Prefixing, encapsulation and translation) to solve IPv4- IPv6 transition. PET includes fundamental elements needed in transition scenarios, which provides the flexibility for network to decide the proper transition methods. In addition, this draft also addresses how to deploy PETs and analyze the advantages and disadvantages of all transition methods that PET may adopt. |
| | | | |
| draft-cui-softwire-pet64-00.txt |
| | PET for IPv6 to IPv4 communication |
| |
| | draft-cui-softwire-pet64-00.txt |
| | Date: |
19/10/2009 |
| | Authors: |
Yong Cui, Mingwei Xu, Shengling Wang, Xing Li, Jianping Wu |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This draft offers a solution using PET for the scenario that an IPv6- only client initiates a communication to an IPv4-only server through IPv6 backbone. In this communication scenario,translation is needed. However, translation work has requirements on the performance (hardware or software) of PET and the size of network that the PET is charge for. This draft introduces the concept of translation preference to express the PET's willing of performing translation according to some policies the network administrators constitute. Through exchanging the Translation preference among PETs, PET framework can decide which PET should act as a translator. In addition, this draft also gives how the PET collaborates with DNS to solve the IPv6-to-IPv4 communication problem. |
| | | | |
| draft-cui-softwire-va-based-softwire-00.txt |
| | VA-Based Softwire |
| |
|
The increasing deployment of IPv6 networks in both customer networks and ISP networks leads to two common traversing transition scenarios: in the first scenario, an IPv6-only backbone network needs to provide IP connectivity between IPv4 networks, we call it IPv4-over-IPv6 scenario; In the second scenario, IPv6 networks need to be interconnected over an IPv4 transit network, we call it IPv6-over- IPv4 scenario. In both scenarios, the ISP operating the transit network of one address family must offer transit services for attached client networks of the other address family. The Softwire WG has defined softwire mesh mechanism [RFC5565] for the two traversing scenarios. Softwire mesh uses automatic softwire tunnels employing multi-protocol BGP extensions for distributing E-IP routes, where both BGP peers and tunnels between PEs forms a full-mesh architecture. Inspired by the Virtual Aggregation approach [I-D.ietf-grow-va] to IPv4 routing scalability, in this draft we proposed a scalable mechanism for distributing E-IP routes over the transit network. Our solution can significantly reduce the forwarding information base (FIB) size at Address Family Border Routers (AFBRs) as well as the total amount of routing updates, and offers the ISP an easy way to manage the transit service. |
| | | | |
| draft-cui-softwire-va-based-transition-00.txt |
| | VA-Based IPv6 Transition |
| |
|
With the increasing deployment of IPv6 networks, IPv6 transition has become one of the key problems in developing IPv6 networks. Among various transition scenarios, one is common where connectivity between IPv4 networks is desired across IPv6-only backbone network. In such case, ISP operating the IPv6 backbone will accommodate connectivity and offer transit services for attached IPv4 networks. Softwire WG defined softwire mesh mechanism for both of the IPv4- over-IPv6 scenario and the opposite scenario of IPv6-over-IPv4. Softwire mesh uses automatic softwire tunnels employing multi- protocol BGP extensions for distributing IPv4 routes, where BGP and tunnuls should be configured or setup as a full-mesh architecture. This draft, however, proposed an aggregated, centralized mechanism similar to Virtual Aggregation (VA) mechanism, which can significantly shrink the forwarding information base (FIB) size of Address Family Border Routers (AFBRs), reduce the total amount of routing activity, and provide the IPv6 ISP with an easy way to manage the transit service. |
| | | | |
| draft-d-sec-udt-00.txt |
| | Security Requirements for UDT |
| |
| | draft-d-sec-udt-00.txt |
| | Date: |
29/09/2009 |
| | Authors: |
Danilo Valeros Bernardo, Doan Hoang |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
UDT does not have its specific security mechanism. It depends on the application to provide authentication and lower layer to provide security mechanisms[GG07]. However, UDT implementations should check each arrived packets are from the expected source, since UDP is connectionless. This document proposes evaluation of security requirements for UDT, or UDP based Data Transfer considered as an alternative data transfer protocol for the situation when TCP does not work well.The objective is to achieve a wide class of security methods used on existing mature protocols such as UDP and TCP. |
| | | | |
| draft-daboo-et-al-icalendar-in-xml-00.txt |
| | iCalendar XML Representation |
| |
|
This specification defines a format for representing iCalendar data in XML. |
| | | | |
| draft-daboo-srv-caldav-01.txt |
| | Use of SRV records for locating CalDAV and CardDAV services |
| |
|
This specification describes how SRV records and well-known URIs can be used to locate Calendaring Extensions to WebDAV (CalDAV) or vCard Extensions to WebDAV (CardDAV) services. |
| | | | |
| draft-daboo-srv-email-02.txt |
| | Use of SRV records for locating email services |
| |
|
This specification describes how SRV records can be used to locate email services. |
| | | | |
| draft-daboo-valarm-extensions-00.txt |
| | VALARM Extensions for iCalendar |
| |
|
This document defines a set of extensions to the iCalendar VALARM component to enhance use of alarms and improve interoperability between clients and servers. |
| | | | |
| draft-daboo-webdav-sync-02.txt |
| | Collection Synchronization for WebDAV |
| |
|
This specification defines an extension to WebDAV that allows efficient synchronization of the contents of a WebDAV collection. |
| | | | |
| draft-dai-mpls-tp-lock-instruct-00.txt |
| | MPLS-TP Lock Instruction |
| |
|
The aim of this document is to define an MPLS-TP OAM mechanism to meet the requirements for Lock Instruction functionality as required in MPLS-TP OAM Requirements document[MPLS-TP OAM Requirements]. The protocol solutions developed to performe this function apply to P2P bidirectional paths, P2P unidirectional paths and P2MP paths. |
| | | | |
| draft-dai-mpls-tp-p2mp-ring-protection-00.txt |
| | Protection for P2MP Ring in MPLS-TP Networks |
| |
|
This document provides two possible solutions for protecting point to multipoint (P2MP) traffic distribution over a ring topology in MPLS-TP networks. These two methods can protect any link or node(except the root node)failure once a failure is detected through MPLS-TP OAM mechanism. |
| | | | |
| draft-daley-ipv6-nonat6-01.txt |
| | Achieving Addressing Functions in IPv6 without using NAT |
| |
|
Proposals have been made to include Network Address Translation (NAT) in IPv6. Network Address Translation substitutes a source address in the outbound Packet headers at the Internet Egress point for one present at the network edge. It then matches the responding packets by destination address, and restores the original headers. NAT itself is not a feature. It is a mechanism which provides features at an application cost. This document identifies features which are supplied by NAT in IPv4 and how these features may be provisioned in IPv6. Both NAT and application-friendly alternatives are presented. |
| | | | |
| draft-daley-mpsec-label-ts-00.txt |
| | MPLS Label Traffic Selectors for Internet Key Exchange Version 2 |
| |
|
Existing mechanisms for encapsulating MPLS labels in ESP or AH payloads lack the ability to specify which Labels are to be transported. This document provides new traffic selector format for IKEv2 in which MPLS label fields and parameters can be selected. |
| | | | |
| draft-daley-mpsec-secure-lsp-ps-01.txt |
| | Secured Label Switch Path Problem Statement |
| |
|
Delivering cryptographic security over MPLS networks currently requires insertion of extra IP Packet headers in the label stack. This document discusses encryption and authentication of datagrams by carriage of Encapsulating Security Payload directly inside a label header. |
| | | | |
| draft-daley-mpsec-traffic-sel-ps-01.txt |
| | Guidelines for Multiprotocol Traffic Selector Bindings in IPsec |
| |
|
In IPsec, secure connectivity is provided for network layer entities. Traffic Selectors which specify interesting traffic for security association encapsulation are identified only by network and transport layer addressing. This document discusses extending traffic selectors to allow more generic definitions of interesting traffic. |
| | | | |
| draft-daniel-6lowpan-mib-01.txt |
| | 6LoWPAN Management Information Base |
| |
| | draft-daniel-6lowpan-mib-01.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Ki-Hyung Kim, Hamid Mukhtar, Seong-Soon Joo, Seung Yoo, Soohong Daniel Park |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
xml txt |
|
This draft defines a portion of the Management Information Base (MIB), the lowpan MIB for use with network management protocols. In particular it defines objects for managing functions related to a 6LoWPAN entity. |
| | | | |
| draft-daniel-6lowpan-security-analysis-03.txt |
| | IPv6 over Low Power WPAN Security Analysis |
| |
|
This document discusses possible threats and security options for IPv6-over-IEEE802.15.4 networks. Its goal is to raise awareness about security issues in IPv6 lowPan networks. |
| | | | |
| draft-daniel-6lowpan-sslp-02.txt |
| | Simple Service Location Protocol (SSLP) for 6LoWPAN |
| |
| | draft-daniel-6lowpan-sslp-02.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Ki-Hyung Kim, Waleed Baig, Seung Yoo, Soohong Daniel Park, Hamid Mukhtar |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt xml |
|
The Simple Service Location Protocol (SSLP) provides a framework for the discovery and selection of the services working on 6LoWPAN. The protocol has a simple structure that is easy to be implemented on 6LoWPAN devices that are characterized by short range, low bit rate and low power. The protocol also offers a mechanism for interoperability with the IP networks under SLP. It enables communication between 6LoWPAN and other IP networks. |
| | | | |
| draft-das-mipshop-andsf-dhcp-options-01.txt |
| | Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for Access Network Discovery and Selection Function(ANDSF) Discovery |
| |
|
This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options that contain a list IP addresses and a list of domain names that can be mapped to ANDSF (Access Network Discovery and Selection Function) entities in an IP network. ANDSF is being developed in 3GPP (Release-8) and provides inter-system mobility policies and access network specific information to the mobile nodes(MNs) [3GPPTS23.402]. |
| | | | |
| draft-davies-dtnrg-uri-find-01.txt |
| | Adding the "find" Operation to the dtn: URI Scheme |
| |
|
This document discusses the addition of a new operation to the proposed dtn: URI (Uniform Resource Identifier) scheme. The new "find" operation would provide support for DTN (Delay- and Disruption-Tolerant Network) anycast services. |
| | | | |
| draft-davies-reusable-ipv4-address-block-00.txt |
| | Transitional non-conflicting reusable IPv4 address block |
| |
|
Although IPv6 is being introduced globally, the entire IP ecosystem will not have transitioned to IPv6 before the forecast exhaustion of the global IPv4 address pools. This document describes a new transitional non-conflicting reusable IPv4 address block which will facilitate a smooth IPv4 to IPv6 transition for customers and transit providers. The address block would be assigned by IANA and have a limited time horizon to match its transitional purpose. |
| | | | |
| draft-dawes-sipping-debug-01.txt |
| | Private Extension to the Session Initiation Protocol (SIP) for Debugging |
| |
|
Networks that use SIP to start and stop sessions between their users will frequently be upgraded with software and hardware changes. Users will similarly frequently change their client software and the way they use the network. In order to allow troubleshooting and regression testing, it is useful to provide debugging as part of the network fabric. This draft describes an event package that provides debugging configuration to SIP entities and a SIP private header that triggers logging of SIP signalling and identifies logs at mulitiple SIP entities as belonging to a single end-to-end session. |
| | | | |
| draft-dawkins-ldapext-subnot-01.txt |
| | Subscription/Notification for Lightweight Directory Access Protocol (LDAP) |
| |
|
This document extends Lightweight Directory Access Protocol (LDAP) to support subscription and notification mechanism. An LDAP client can subscribe to data of interest available from an LDAP server and receive notifications from the LDAP server when this data is updated. By this means, an LDAP client can become aware of changes to data of interest in a timely manner. |
| | | | |
| draft-dearlove-olsrv2-metrics-04.txt |
| | Link Metrics for OLSRv2 |
| |
|
This document describes how link metrics may be added, in a relatively straightforward manner, to the specification of OLSRv2, in order to allow routing by other than minimum hop count routes. In addition to metric signaling and use, the most significant change is a separation of the routing and flooding functions of MPRs. |
| | | | |
| draft-dec-dhcpv6-route-option-02.txt |
| | DHCPv6 Route Option |
| |
|
This document describes the DHCPv6 Route Option for provisioning IPv6 routes on a DHCPv6 client. This improves the ability of an operator to configure and influence the client to pick an appropriate route to a destination when this client is multi-homed to routers and where other means of route configuration may be impractical. The option is primarily envisaged for configuring a broadband Residential Gateway (RG) node, but is generic enough to be used by other types of DHCPv6 clients. |
| | | | |
| draft-decraene-idr-rfc4360-clarification-00.txt |
| | RFC 4360 Clarification Request |
| |
|
This draft describes a request for clarification of the Operations Section of [RFC4360], regarding the handling of non transitive extended communities. |
| | | | |
| draft-defeche-ipv6-traffic-in-p2p-networks-00.txt |
| | Measuring IPv6 Traffic in BitTorrent Networks |
| |
|
This document summarizes a University thesis which aims to measure the evolution over time of IPv6 traffic, to analyze the geographical distribution of IPv6 nodes and to compare the two Internet Protocol versions on many different criteria (RTT, latency, MTU). The measurements were done during the Summer 2009 using a specific- purpose program which connects to the BitTorrent peer-to-peer network. The study was made in Peer-to-Peer (P2P) networks because they are responsible for most Internet traffic and because their structure and functioning permit a rapid discovery of a large number of nodes from all over the world. In addition, the P2P users are more likely to be interested by IPv6 as IPv6 does not have the same NAT problems as IPv4. |
| | | | |
| draft-dekok-radext-dtls-01.txt |
| | 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. |
| | | | |
| draft-dekok-radext-nai-00.txt |
| | The Network Access Identifier |
| |
|
In order to provide roaming services, it is necessary to have a standardized method for identifying users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client during network authentication. "Roaming" may be loosely defined as the ability to use any one of multiple Internet Service Providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. Examples of where roaming capabilities might be required include ISP "confederations" and ISP-provided corporate network access support. This document is a revised version of RFC 4282, which addresses issues with international character sets, as well as a number of other corrections to the previous RFC. |
| | | | |
| draft-delord-pwe3-cw-bit-etree-01.txt |
| | Control Word Reserved bit for use in E-Tree |
| |
|
The extension described in this document allows a pair of PEs connected via an Ethernet Pseudowire (PW) to signal via the use of the Control Word (CW) whether the Ethernet frame encapsulated is coming from a Root AC or a Leaf AC. This allows a PE receiving this frame to decide whether it can be forwarded to a Leaf AC or not. Such forward or drop decision is an additional filtering action after the MAC-based forwarding decision. This applies to both P2P PW and P2MP PW. |
| | | | |
| draft-dempsky-dnscurve-00.txt |
| | DNSCurve: Link-level security for the Domain Name System |
| |
|
This document describes DNSCurve, a protocol extension that adds link-level security to the Domain Name System (DNS). |
| | | | |
| draft-deng-multimob-pmip6-requirement-02.txt |
| | Multicast Support Requirements for Proxy Mobile IPv6 |
| |
|
This document summarizes requirements for multicast listener support in Proxy Mobile IPv6 (PMIPv6) scenarios. In correspondance to PMIPv6, multicast mobility management requirements do not request any active participation of the mobile node. |
| | | | |
| draft-denis-icmpv6-generation-for-teredo-01.txt |
| | Generation of ICMPv6 Echo Replies for Teredo Clients |
| |
|
Teredo uses return routing to discover the closest Teredo relay corresponding to any given peer. Discovery is achieved by sending an ICMPv6 Echo Request and waiting for the appropriate relay to forward the ICMPv6 Echo Reply back. Unanswered ICMPv6 Echo Requests make Teredo clients assume that the peer is unreachable. This document identifies two scenarios where a stateful middlebox can detect the lack of ICMPv6 Echo Reply and craft one for the Teredo client in order to avoid possibly erroneous peer unreachability assumptions. |
| | | | |
| draft-despotovic-alto-feedback-cp-00.txt |
| | ALTO-FCP: Application Layer Traffic Optimization Feedback-Based Client Protocol |
| |
| | draft-despotovic-alto-feedback-cp-00.txt |
| | Date: |
06/07/2009 |
| | Authors: |
Zoran Despotovic, Wolfgang Kellerer, Spiros Spirou, Dirk Staehle, Maria Rodriguez, Ioanna Papafili |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
In some networked applications, such as peer-to-peer file sharing, the same resource (e.g., a file or a server process) is available at several potential resource providers. Resource consumers typically try to select providers so that application performance is improved, establishing an overlay topology of direct logical links in the process. However, lack of reliable information about the underlying network can lead to poor choices and suboptimal application performance. In addition, resulting application traffic is largely oblivious to technical, economical, and political constraints at the network level, causing problems for network operators. This document describes a protocol that facilitates the exchange of information between an overlay and the underlying network. Such information can be used at each layer to make decisions that are not detrimental to the other layer or, ideally, are beneficial to both. |
| | | | |
| draft-despres-6rd-03.txt |
| | IPv6 Rapid Deployment on IPv4 infrastructures (6rd) |
| |
|
IPv6 rapid deployment (6rd) builds upon mechanisms of 6to4 (RFC3056) to enable a service provider to rapidly deploy IPv6 unicast service to IPv4 sites to which it provides customer premise equipment. Like 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to transit IPv4-only network infrastructure. Unlike 6to4, a 6rd service provider uses an IPv6 prefix of its own in place of the fixed 6to4 prefix. A service provider has used this mechanism for its own IPv6 "rapid deployment": five weeks from first exposure to 6rd principles to more than 1,500,000 residential sites being provided native IPv6, under the only condition that they activate it. |
| | | | |
| draft-despres-sam-03.txt |
| | Scalable Multihoming across IPv6 Local-Address Routing Zones Global-Prefix/Local-Address Stateless Address Mapping (SAM) |
| |
|
The continuous growth of routing tables in the core of Internet is a challenge. It would become overwhelming if each multihomed customer site would need a provider independent prefix to take full advantage of its multihoming. IPv6 has the potential to solve this problem, but a complete specification is still missing. This draft proposes an approach for a solution. The Stateless Address Mapping (SAM) model, introduced for this, is applicable to a hierarchy of routing zones with multihoming permitted at each level, and with each zone using local addresses for its internal routing plan. End-to-end transparency of the Internet is maintains across these local-address zones, thanks to a systematic encapsulation of global-address packets into local-address packets. Local addresses are statelessly derived from prefixes found in global addresses, and from static parameters of traversed zones. Global prefixes delegated by a zone to its child interfaces can be obtained by autoconfiguration, thanks to to a bidirectional correspondence between SAM local addresses and SAM global prefixes. Deployment can be incremental. |
| | | | |
| draft-despres-softwire-mesh-sam-01.txt |
| | Stateless Address Mapping (SAM) - Mesh Softwires without e-BGP |
| |
|
SAM is a generic and simple mechanism for packets having addresses in a family IPvX to traverse routing domains where this address family is not directly routed. SAM topological scenarios are those of Mesh Softwire, i.e. with point to multipoint tunnels between border nodes of interior routing domains. In the mesh-softwire context, SAM differs from RFC 5565 in that SAM uses no protocol between border nodes of the domain, and in that customer border nodes don't need to maintain states for all other border nodes. (RFC 5565 is based on an Exterior Border-Gateway Protocol e-BGP between border nodes, with dynamic routing tables to be maintained in all of them). SAM's address mappings are stateless, based on only a few domain parameters. SAM is thus suitable to small to medium enterprises, and small to medium ISPs, that cannot afford e-BGP in all their border nodes. All combinations of IPv4 and IPv6, global or private, are supported. Also, to mitigate consequences of the IPv4 address shortage, SAM supports port-extended IPv4 addresses (A+P). |
| | | | |
| draft-desruisseaux-caldav-sched-08.txt |
| | CalDAV Scheduling Extensions to WebDAV |
| |
|
This document defines extensions to the CalDAV "calendar-access" feature to specify a standard way of performing scheduling transactions with iCalendar-based calendar components. This document defines the "calendar-auto-schedule" feature of CalDAV. |
| | | | |
| draft-desruisseaux-ischedule-00.txt |
| | Internet Calendar Scheduling Protocol (iSchedule) |
| |
|
This document defines the Internet Calendar Scheduling Protocol (iSchedule), which is a binding from the iCalendar Transport- independent Interoperability Protocol (iTIP) to the Hypertext Transfer Protocol (HTTP) to enable interoperability between calendaring and scheduling systems over the Internet. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 19, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. |
| | | | |
| draft-detienne-ikev2-recovery-03.txt |
| | Safe IKE Recovery |
| |
|
The Internet Key Exchange protocol version 2 (IKEv2) suffers from the limitation of not having a means to quickly recover from a stale state known as dangling Security Associations (SA's) where one side has SA's that the corresponding party does not have anymore. This Draft proposes to address the limitation by offering an immediate, DoS-free recovery mechanism for IKE that can be used in all failover or post-crash situations. |
| | | | |
| draft-dhankins-softwire-tunnel-option-05.txt |
| | Dynamic Host Configuration Protocol (DHCPv6) Option for Dual-Stack Lite |
| |
|
This document describes how Dual-Stack Lite configuration (the Softwire Concentrator (SC)'s address) can be obtained by a Softwire Initiator (SI) via DHCPv6. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 16, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. |
| | | | |
| draft-divilly-atom-hierarchy-03.txt |
| | Hierarchy Relations for Atom |
| |
|
This specification defines link relations for hierarchical navigation among Atom feeds and entries.Editorial Note To provide feedback on this Internet-Draft, join the atom-syntax mailing list (http://www.imc.org/atom-syntax/) [1]. |
| | | | |
| draft-dnsop-transport-for-dns-00.txt |
| | Transport Considerations for DNS |
| |
|
DNS queries and responses are available over a variety of transports (UDP/TCP) and may be ported to use other transports in the future. Current use profiles show that most user generated DNS traffic prefers one transport over another. This historical usage pattern has or may lead to the presumption that any DNS traffic, regardless of transport, should be considered on equal footing. |
| | | | |
| draft-dolmatov-cryptocom-gost2814789-04.txt |
| | GOST 28147-89 encryption,decryption and MAC algorithms |
| |
|
This document is intended to be a source of information about the Russian Federal standard for electronic encryption, decryption, and MAC algorithms (GOST 28147-89) [GOST28147], which is one of the official standards in the cryptography used in Russian algorithms (GOST algorithms). Recently, Russian cryptography started to be used in applications intended to work with the OpenSSL cryptographic library. Therefore, this document has been created as information for users of Russian cryptography. V.Dolmatov Expires May 10, 2010 [page 1] |
| | | | |
| draft-dolmatov-cryptocom-gost34102001-06.txt |
| | GOST R 34.10-2001 digital signature algorithm |
| |
|
This document is intended to be a source of information about the Russian Federal standard for for electronic digital signature generation and verification processes GOST R 34.10-2001 [GOST3410], which is one of the official standards in the cryptography used in Russian algorithms (GOST algorithms). Recently, Russian cryptography started to be used in applications intended to work with the OpenSSL cryptographic library. Therefore, this document has been created as information for users of Russian cryptography. |
| | | | |
| draft-dolmatov-cryptocom-gost341194-04.txt |
| | GOST R 34.11-94 Hash function algorithm |
| |
|
This document is intended to be a source of information about the Russian Federal standard for hash function GOST R 34.11-94 [GOST3411] which is one of the official standards in the cryptography, used in Russian algorithms (GOST algorithms). Recently, Russian cryptography started to be used in applications intended to work with the OpenSSL cryptographic library. Therefore, this document has been created as information for users of Russian cryptography. V.Dolmatov Expires May 10, 2010 [page 1] |
| | | | |
| draft-dolmatov-dnsext-dnssec-gost-01.txt |
| | Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records for DNSSEC |
| |
|
This document describes how to produce GOST signature and hash algorithms DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). V.Dolmatov Expires February 05, 2010 [page 1] |
| | | | |
| draft-dong-idr-vpn-route-constrain-00.txt |
| | Constrained Route Distribution for BGP based Virtual Private Networks(VPNs) |
| |
|
This document defines generalized procedures that allow BGP speakers to exchange Route Target reachability information. This information can be used to precisely control the propagation of different kinds of Virtual Private Network (VPN) routing information. This method avoids unnecessary advertising of VPN routes when more than one kind of VPN is deployed in the network. |
| | | | |
| draft-dong-savi-cga-header-02.txt |
| | 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. |
| | | | |
| draft-donley-ipv6-cpe-rtr-use-cases-and-reqs-00.txt |
| | Use Cases and Requirements for an IPv6 CPE Router |
| |
|
This document captures use cases and associated requirements for an IPv6 Customer Premises Equipment (CPE) router. Specifically, the current version of this document focuses on the provisioning of an IPv6 CPE router and the provisioning of IPv6 Home Devices attached to it. It also addresses IPv6 traffic forwarding and IPv6 CPE Router security. This document also identifies areas for future consideration. These areas include prefix sub-delegation, IPv6 multicast, transition and tunneling mechanisms, provisioning consistency between DHCPv4 and DHCPv6, and DNS support. This document does not address IPv4 use cases or requirements, as they are widely understood; however, it is expected that IPv6 CPE Routers will also support IPv4. |
| | | | |
| draft-drage-sipping-service-identification-03.txt |
| | A Session Initiation Protocol (SIP) Extension for the Identification of Services |
| |
|
This document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to assert the service of authenticated users. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport and usage of such information. This document does NOT offer a general service identification model suitable for use between different trust domains, or use in the Internet at large. The document also defines a URN to identify both services and UA applications. This URN can be used within the SIP header fields defined in this document to identify services, and also within the framework defined for caller preferences and callee capabilities to identify usage of both services and applications between end UAs. |
| | | | |
| draft-dreibholz-ipv4-flowlabel-10.txt |
| | An IPv4 Flowlabel Option |
| |
|
This draft defines an IPv4 option containing a flowlabel that is compatible to IPv6. It is required for simplified usage of IntServ and interoperability with IPv6. |
| | | | |
| draft-dreibholz-rserpool-applic-distcomp-07.txt |
| | Applicability of Reliable Server Pooling for Real-Time Distributed Computing |
| |
|
This document describes the applicability of the Reliable Server Pooling architecture to manage real-time distributed computing pools and access the resources of such pools. |
| | | | |
| draft-dreibholz-rserpool-applic-mobility-06.txt |
| | Applicability of Reliable Server Pooling for SCTP-Based Endpoint Mobility |
| |
|
This document describes a novel mobility concept based on a combination of SCTP with Dynamic Address Reconfiguration extension and Reliable Server Pooling (RSerPool). |
| | | | |
| draft-dreibholz-rserpool-asap-hropt-05.txt |
| | Handle Resolution Option for ASAP |
| |
|
This document describes the Handle Resolution option for the ASAP protocol. |
| | | | |
| draft-dreibholz-rserpool-delay-04.txt |
| | Definition of a Delay Measurement Infrastructure and Delay-Sensitive Least-Used Policy for Reliable Server Pooling |
| |
|
This document contains the definition of a delay measurement infrastructure and a delay-sensitive Least-Used policy for Reliable Server Pooling. |
| | | | |
| draft-dreibholz-rserpool-enrp-takeover-02.txt |
| | Takeover Suggestion Flag for the ENRP Handle Update Message |
| |
|
This document describes the Takeover Suggestion Flag for the ENRP_HANDLE_UPDATE message of the ENRP protocol. |
| | | | |
| draft-dreibholz-rserpool-score-05.txt |
| | Reliable Server Pooling (RSerPool) Bakeoff Scoring |
| |
|
This memo describes some of the scoring to be used in the testing of Reliable Server Pooling protocols ASAP and ENRP at upcoming bakeoffs. |
| | | | |
| draft-dt-roll-rpl-01.txt |
| | RPL: Routing Protocol for Low Power and Lossy Networks |
| |
|
This document specifies the Routing Protocol for Low Power and Lossy Networks (RPL), in accordance with the requirements described in [I-D.ietf-roll-building-routing-reqs], [I-D.ietf-roll-home-routing-reqs], [I-D.ietf-roll-indus-routing-reqs], and [RFC5548]. |
| | | | |
| draft-duerst-iri-bis-07.txt |
| | Internationalized Resource Identifiers (IRIs) |
| |
| | draft-duerst-iri-bis-07.txt |
| | Date: |
26/10/2009 |
| | Authors: |
Martin Duerst, Michel Suignard, Larry Masinter |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document defines the Internationalized Resource Identifier (IRI) protocol element, as an extension of the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). Grammar and processing rules are given for IRIs and related syntactic forms. In addition, this document provides named additional rule sets for processing otherwise invalid IRIs, in a way that supports other specifications that wish to mandate common behavior for 'error' handling. In particular, rules used in some XML languages (LEIRI) and web applications are given. Defining IRI as new protocol element (rather than updating or extending the definition of URI) allows independent orderly transitions: other protocols and languages that use URIs must explicitly choose to allow IRIs. Guidelines are provided for the use and deployment of IRIs and related protocol elements when revising protocols, formats, and software components that currently deal only with URIs. [RFC Editor: Please remove this paragraph before publication.] This document is intended to update RFC 3987 and move towards IETF Draft Standard. This is an interim version in preparation for the IRI BOF at IETF 76 in Hiroshima. For discussion and comments on this draft, please use the public-iri@w3.org mailing list. |
| | | | |
| draft-duerst-mailto-bis-07.txt |
| | The 'mailto' URI Scheme |
| |
|
This document defines the format of Uniform Resource Identifiers (URI) to identify resources that are reached using Internet mail. It adds better internationalization and compatibility with IRIs (RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368). |
| | | | |
| draft-duffield-ippm-burst-loss-metrics-01.txt |
| | Burst Loss Metrics for IPPM |
| |
|
The IPPM Working Group has developed a one way packet loss metric that measures the loss rate on a Poisson probe stream between two hosts. However, the burst properties of packet loss are required to understand the impact of packet loss on applications. This draft defines one-way burst packet loss metrics that express the frequency and duration of loss episode, i.e., maximal sets of consecutively lost probe packets. The draft also defines a probing methodology under which the burst loss metrics are to be measured. |
| | | | |
| draft-duker-as2-reliability-06.txt |
| | Operational Reliability for EDIINT AS2 |
| |
|
The goal of this document is to define approaches to achieve a "once and only once" delivery of messages. The EDIINT AS2 protocol [AS2] is implemented by a number of software tools on a variety of platforms with varying capabilities and with varying network service quality. Although the AS2 protocol defines a unique "Message-ID", current implementations of AS2 do not provide a standard method to prevent the same message (re-transmitted by the initial sender) from reaching back-end business applications at the initial receiver. TCP underpinnings of HTTP over which AS2 operates generally provide a good quality of network connectivity, but experience indicates a need to be able to compensate for both transient server and socket exceptions, including "Connection refused" as well as "Server busy." In addition, difficulties with server availability, stability, and loads can result in reduced operational reliability. This document describes some ways to compensate for exceptions and enhance the reliability of AS2 protocol operation. Implementation of these reliability features is indicated by presence of the "AS2- Reliability" value in the EDIINT-Features header. |
| | | | |
| draft-dusseault-http-patch-15.txt |
| | PATCH Method for HTTP |
| |
|
Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existing HTTP PUT method only allows a complete replacement of a document. This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource. |
| | | | |
| draft-dutta-netext-pmipro-00.txt |
| | ProxyMIP Extension for Inter-MAG Route Optimization |
| |
| | draft-dutta-netext-pmipro-00.txt |
| | Date: |
19/10/2009 |
| | Authors: |
Ashutosh Dutta, Subir Das, Hidetoshi Yokota, Tsunehiko Chiba, Henning Schulzrinne |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This draft describes a light weight route optimization technique that helps to optimize the media path between two communicating nodes when Proxy MIP is used as the mobility protocol. This routing optimization technique is most useful when the two communicating hosts are away from home and need to communicate with each other using an optimized path. It takes advantage of the data packet between LMA and MAG to set up the optimized data path between the communicating hosts. This route optimization technique is applicable to both the intra-LMA and inter-LMA scenarios. |
| | | | |
| draft-dykim-mmcp-00.txt |
| | Mobile Multicast Control Protocol in Wireless/Mobile Networks |
| |
| | draft-dykim-mmcp-00.txt |
| | Date: |
19/08/2009 |
| | Authors: |
Dae Young Kim, Seok Koh |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document is a part of the ITU-T Recommendation and ISO/IEC International Standard, named the Mobile Multicast Communications Protocol (MMCP). The MMCP is a protocol that can be used to support a variety of multimedia multicasting services in the IP-based wireless mobile networks. The MMCP is targeted at the real-time one-to-many multicast services and applications over mobile communications networks. |
| | | | |
| draft-dzis-nwg-nttdm-01.txt |
| | The Network Trouble Ticket Data Model |
| |
| | draft-dzis-nwg-nttdm-01.txt |
| | Date: |
23/09/2009 |
| | Authors: |
Dimitris Zisiadis, Spyros Kopsidas, Matina Tsavli, Leandros Tassiulas, Chrysostomos Tziouvaras, Guillaume Cessieux, Xavier Jeannin |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
Handling multiple sets of network trouble tickets (TTs) originating from different participants inter-connected network environments poses a series of challenges for the involved institutions, Grid is a good example of such multi-domain project. Each of the participants follows different procedures for handling trouble in its domain, according to the local technical and linguistic profile. The TT systems of the participants collect, represent and disseminate TT information in different formats. As a result, management of the daily workload by a central Network Operations Centre (NOC) is a challenge on its own. Normalization of TTs to a common format for presentation and storing at the central NOC is mandatory. In the present document we provide a model for automating the collection and normalization of the TT received by multiple networks forming the Grid. Each of the participants is using its home TT system within its domain for handling trouble incidents, whereas the central NOC is gathering the tickets in the normalized format for repository and handling. XML is used as the common representation language. The model was defined and used as part of the networking support activity of the EGEE project (Enabling Grids for E-sciencE). |
| | | | |
| draft-eastlake-nlpid-iana-considerations-03.txt |
| | IANA Considerations for NLPIDs |
| |
|
Some protocols being developed or extended by the IETF make use of the ISO/IEC (International Organization for Standardization / International Electrotechnical Commission) Network Layer Protocol Identifier (NLPID). This document provides NLPID IANA Considerations. |
| | | | |
| draft-eastlake-trill-rbridge-options-04.txt |
| | Rbridges: TRILL Header Options |
| |
|
The TRILL base protocol specification, draft-ietf-trill-rbridge- protocol-13.txt, specifies minimal hooks for options. This draft specifies the format for options and an initial set of options. |
| | | | |
| draft-eb-ccamp-ospf-wson-impairments-00.txt |
| | OSPF Extensions for Wavelength Switched Optical Networks (WSON) with Impairments |
| |
|
This document specifies OSPF extensions to carry information about physical impairments. This information set is required for the feasibility assessment of the lightpath to be established across an optical switched network controlled by GMPLS. The document intent is both disseminating experimental results carried out within Ericsson Research and provide an initial input for further OSPF extensions in CCAMP IETF group. |
| | | | |
| draft-ebalard-mext-ipsec-ro-01.txt |
| | Mobile IPv6 IPsec Route Optimization (IRO) |
| |
|
This memo specifies an improved alternate route optimization procedure for Mobile IPv6 designed specifically for environments where IPsec is used between peers (most probably with IKE). The replacement of the complex Return Routability procedure for a simple mechanism and the removal of HAO and RH2 extensions from exchanged packets result in performance and security improvements. |
| | | | |
| draft-einarsson-mmusic-rtsp-macuri-02.txt |
| | Multiple aggregated control URIs for RTSP |
| |
|
RTSP defines the setup and control for on demand and live streaming media sessions, which are delivered via an external media transport protocol such as RTP/UDP. RTSP does not define a mechanism to change the content during an on-going streaming session. Such a mechanism improves the streaming experience when a user browses through multiple offerings on a single streaming site. This document describes several methods to improve content switching. The basic principle is to re-use already established transport sessions (e.g. RTP/UDP sessions) and negotiate new content to be delivered on the existing sessions. If additional transport sessions are necessary, those sessions are established separately. This principle of re-using the RTSP control and transport sessions decreases the content switch delay to a large extent and improves the end-user experience. The present document defines a mechanism for switching to new content, both when the client already has the content description available and when it does not. This document additionally considers switching of a single media stream in a session, when several alternative media components are available. For instance, the content may provide several alternate audio tracks in different languages to be played with a single video stream. The principle of Fast Content Switching and Start-up is also defined in 3GPP TS 26.234 [3GPP.26.234] for RTSP 1.0 [RFC2326]. |
| | | | |
| draft-eisler-nfsv4-minorversion-2-requirements-02.txt |
| | Requirements for NFSv4.2 |
| |
|
This document proposes requirements for NFSv4.2. |
| | | | |
| draft-elie-nntp-list-additions-00.txt |
| | Network News Transfer Protocol (NNTP) Additions to LIST Command |
| |
|
This document defines a set of enhancements to the Network News Transfer Protocol (NNTP) that allows a client to request extended information maintained by NNTP servers as for local use and distribution policy. These enhancements are made as new keywords to the existing LIST capability described in RFC 3977. This memo updates and formalizes the LIST DISTRIBUTIONS and LIST SUBSCRIPTIONS commands defined in RFC 2980. It also adds the LIST MODERATORS and LIST MOTD commands, and specifies additional values returned by the existing LIST ACTIVE command for the status of a newsgroup. |
| | | | |
| draft-ellermann-news-nntp-uri-11.txt |
| | The 'news' and 'nntp' URI Schemes |
| |
|
This memo specifies the 'news' and 'nntp' Uniform Resource Identifier (URI) schemes that were originally defined in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about these schemes on standards track. |
| | | | |
| draft-elwell-dispatch-identity-reqs-01.txt |
| | Requirements for secure caller identification in the Session Initiation Protocol (SIP) |
| |
|
This document examines requirements for secure caller identification in SIP. Although existing mechanisms exist to achieve this, there are some known shortcomings or deployment difficulties. This work is being discussed on the dispatch@ietf.org mailing list. |
| | | | |
| draft-eronen-ipsec-ikev2-eap-auth-07.txt |
| | An Extension for EAP-Only Authentication in IKEv2 |
| |
|
IKEv2 specifies that EAP authentication must be used together with public key signature based responder authentication. This is necessary with old EAP methods that provide only unilateral authentication using, e.g., one-time passwords or token cards. This document specifies how EAP methods that provide mutual authentication and key agreement can be used to provide extensible responder authentication for IKEv2 based on methods other than public key signatures. |
| | | | |
| draft-faibish-nfsv4-pnfs-access-permissions-check-01.txt |
| | pNFS Access Permissions Check |
| |
|
This document describes an extension to the pNFS protocol addressing a gap related to the access permission checks to data servers used by the MDS in layouts sent to the clients. The draft addresses both the client access permission checks as well as the MDS access permissions to the data servers. The draft will address new errors related to access permission denial to devices included in valid pNFS layouts. The draft will also address the case when clients request direct NFS access to the MDS and the MDS has no permission to access some of the data servers included in valid layouts. |
| | | | |
| draft-fairhurst-6man-tsvwg-udptt-02.txt |
| | The UDP Tunnel Transport mode |
| |
|
This document proposes a standards track protocol called the UDP Tunnel Transport. This protocol updates the UDP processing of RFC 2460 for IPv6 hosts and routers. The update enables a sender to generate a UDP datagram where the UDP checksum is replaced by a header check determined only by the protocol header information. For this use, the document also updates the way the IPv6 UDP length field is interpreted. This mode is intended to minimise the processing cost for the transport of tunnel packets using UDP. |
| | | | |
| draft-fairhurst-tsvwg-6man-udpzero-00.txt |
| | The IPv6 UDP Checksum Considerations |
| |
|
This document examines the role of the transport checksum when used with IPv6, as defined in RFC2460. It presents a summary of the trade-offs for evaluating the safety of updating RFC 2460 to permit an IPv6 UDP endpoint to use a zero value in the checksum field to indicate that no checksum is present. |
| | | | |
| draft-fajardo-dime-base-test-suite-02.txt |
| | Diameter Base Protocol Interoperability Test Suite |
| |
|
This document describes a collection of test cases to be used for Diameter base protocol interoperability testing. |
| | | | |
| draft-fajardo-dime-dcc-test-suite-02.txt |
| | Diameter Credit Control Interoperability Test Suite |
| |
| |