|
Internet Drafts - IDs for Mar/2008
Index - Month Index of IDs
All IDs - sorted by date)
31/03/2008
| |
|
| |
| | The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) |
| |
| | draft-ietf-enum-3761bis-03.txt |
| | Date: |
31/03/2008 |
| | Authors: |
Scott Bradner, Lawrence Conroy, Kazunori Fujiwara |
| | Working Group: |
Telephone Number Mapping (enum) |
| | Formats: |
txt |
|
This document discusses the use of the Domain Name System (DNS) for the storage of E.164 numbers, and for resolving them into URIs that can be used for (for example) telephony call setup. This document also describes how the DNS can be used to identify the services associated with an E.164 number. This document obsoletes RFC 3761. |
| | MIPv6 Home Link Detection |
| |
|
The MIPv6 bootstrapping procedure allows the mobile node to dynamically discover its home prefix using an IKEv2 exchange. Since the home prefix is not statically configured on the mobile node, there is a need to specify a mechanism for the mobile node to detect if it is on its home link. This document specifies one such mechanism. |
| | Passwords in LDAP |
| |
|
The Lightweight Directory Access Protocol (LDAP) provides a number of password-based mechanisms for authenticating directory users to the directory service. This document discusses the use of passwords in directory user authentication. The document specifies schema for representing a basic password policy and directory service enforcement of password policy. |
| | Softwire Mesh Framework |
| |
| | draft-ietf-softwire-mesh-framework-04.txt |
| | Date: |
31/03/2008 |
| | Authors: |
Jianping Wu, Yong Cui, Xing Li, Chris Metz, Eric Rosen, Simon Barber, Pradosh Mohapatra, John Scudder, Intellectual Property |
| | Working Group: |
Softwires (softwire) |
| | Formats: |
txt |
|
The Internet needs to be able to handle both IPv4 and IPv6 packets. However, it is expected that some constituent networks of the Internet will be "single protocol" networks. One kind of single protocol network can parse only IPv4 packets and can process only IPv4 routing information; another kind can parse only IPv6 packets and can process only IPv6 routing information. It is nevertheless required that either kind of single protocol network be able to provide transit service for the "other" protocol. This is done by passing the "other kind" of routing information from one edge of the single protocol network to the other, and by tunneling the "other kind" of data packet from one edge to the other. The tunnels are known as "Softwires". This framework document explains how the routing information and the data packets of one protocol are passed through a single protocol network of the other protocol. The document is careful to specify when this can be done with existing technology, and when it requires the development of new or modified technology. |
30/03/2008
| |
|
| |
| | IAX: Inter-Asterisk eXchange Version 2 |
| |
| | draft-guy-iax-04.txt |
| | Date: |
30/03/2008 |
| | Authors: |
Mark Spencer, Brian Capouch, Ed Guy, Frank Miller, Kenneth Shumard |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt xml |
|
This document describes IAX, the Inter-Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for the Asterisk PBX and is targeted primarily at Voice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia. IAX is an "all in one" protocol for handling multimedia in IP networks. It combines both control and media services in the same protocol. In addition, IAX uses a single UDP data stream on a static port greatly simplifying Network Address Translation (NAT) gateway traversal, eliminating the need for other protocols to work around NAT, and simplifying network and firewall management. IAX employs a compact encoding which decreases bandwidth usage and is well suited for Internet telephony service. In addition, its open nature permits new payload types additions needed to support additional services. |
| | Better Approach To Mobile Ad-hoc Networking (B.A.T.M.A.N.) |
| |
| | draft-openmesh-b-a-t-m-a-n-00.txt |
| | Date: |
30/03/2008 |
| | Authors: |
Axel Neumann, Corinna Aichele, Marek Lindner, Simon Wunderlich |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document specifies a simple and robust algorithm for establishing multi-hop routes in mobile ad-hoc networks. It ensures highly adaptive and loop-free routing while causing only low processing and traffic cost. |
| | Recommendations for filtering ICMP messages |
| |
|
This document document provides advice on the filtering of ICMPv4 and ICMPv6 messages. Additionaly, it discusses the operational and interoperability implications of such filtering. |
29/03/2008
| |
|
| |
| | IANA Registration for Enumservice UNUSED |
| |
|
This document registers the Enumservice "unused" using the URI scheme "http:" as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice may be used to indicate that the E.164 number (or E.164 number range) tied to the domain in which the enclosing NAPTR is published is not allocated or assigned for communications service. When such an indication is provided, an ENUM client can detect calls that will fail "early". |
| | EAP Extensions for EAP Re-authentication Protocol (ERP) |
| |
|
The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to not repeat the entire EAP exchange with another authenticator. This document specifies extensions to EAP and EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator. The re-authentication server may be in the home network or in the local network that the peer is connecting to. |
| | Location Hiding: Problem Statement and Requirements |
| |
|
The emergency services architecture developed in the IETF Emergency Context Resolution with Internet Technology (ECRIT) working group describes an architecture where location information is provided by access networks to end points in order to determine the correct dial string and information to route the call to a Public Safety Answering Point (PSAP). For determining the PSAP Uniform Resource Identifier (URI) the usage of the Location-to-Service Translation (LoST) Protocol is envisioned. This document explores the architectural impact for the IETF emergency services architecture for situations where the Internet Access Provider (IAP) and/or the Internet Service Provider (ISP) are only willing to disclose limited or no location information. This document provides a problem statement and lists requirements. |
| | A Taxonomy for New Routing and Addressing Architecture Designs |
| |
|
The Routing Research Group is tasked to design a new routing architecture to meet the challenges of scalability in face of pervasive multi-homing and inter-domain traffic engineering. A number of solutions have been proposed. This draft describes a taxonomy for the design space, and then uses the taxonomy to discuss and compare the proposed solutions. |
28/03/2008
| |
|
| |
| | RSVP-TE Signaling Extension For The Conversion Between Permanent Connections And Soft Permanent Connections In A GMPLS enabled Transport Network |
| |
|
In a transport network scenario, where Data Plane connections controlled either by GMPLS (Soft Permanent Connections - SPC) or by Management System (Permanent Connections - PC) may independently coexist, the ability of transforming an existing PC into a SPC and vice versa - without actually affecting Data Plane traffic being carried over it - is a valuable option. This applies especially when a GMPLS based Control Plane is first introduced into an existing network and there may be the need, from a Carrier point of view, to pass under GMPLS control existing connections already set up over Data Plane. In other terms, such operation could be seen as a way of transferring the ownership and control of an existing and in-use Data Plane connection between the Management Plane and the Control Plane, leaving its Data Plane state untouched. This memo provides a minor extension to RSVP-TE signaling protocol, within GMPLS architecture, to enable such connection ownership transfer and describes the proposed procedures. |
| | Host Identity Protocol based Mobile Router (HIPMR) |
| |
| | draft-melen-hip-mr-00.txt |
| | Date: |
28/03/2008 |
| | Authors: |
Jan Melen, Jukka Ylitalo, Patrik Salmela |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This drafts defines a moving network support for HIP enabled hosts. The protocol uses asymmetric authentication and symmetric authorization. The solution presented in this draft is based on delegation of signalling rights between mobile nodes and mobile routers that results in route optimization between end-hosts. |
| | X.509 Key and Signature Encoding for the KeyNote Trust Management System |
| |
|
This memo describes X.509 key identifiers and signature encoding for version 2 of the KeyNote trust-management system [KEYNOTE]. X.509 certificates [RFC3280] can be directly used in the Authorizer or Licensees field (or in both fields) in a KeyNote assertion, allowing for easy integration with protocols that already use X.509 certificates for authentication. In addition, the document defines additional signature types that use other hash functions (beyond the MD5 and SHA1 hash functions that are defined in [RFC2792]). |
| | Pseudowire (PW) Redundancy |
| |
|
This document describes a framework comprised of few scenarios and associated requirements where PW redundancy is needed. A set of redundant PWs is configured between PE nodes in SS-PW applications, or between T-PE nodes in MS-PW applications. In order for the PE/T-PE nodes to indicate the preferred PW path to forward to one another, a new status is needed to indicate the preferential forwarding status of active or standby for each PW in the redundancy set. |
27/03/2008
| |
|
| |
| | Data Channel Status Confirmation Extensions for the Link Management Protocol |
| |
|
This document defines simple additions to the Link Management Protocol (LMP) to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent LSRs to confirm Li Expires September 2008 [page 1] draft-ietf-ccamp-confirm-data-channel-status-00.txt March 2008 data channel statuses, and provides triggers for notifying the management plane if any discrepancies are found. |
| | Guidelines for Using the Privacy Mechanism for SIP |
| |
|
This is an informational document that provides guidelines for using the privacy mechanism for Session Initiation Protocol (SIP), that is specified in RFC 3323 and subsequently extended in RFCs 3325 and 4244. It is intended to clarify the handling of the target SIP headers/parameters and SDP parameters for each of the privacy header values (priv-values). |
| | TOTP: Time-based One-time Password Algorithm |
| |
|
This document describes an extension of one-time password algorithm HOTP as defined in [RFC4226] to support time based moving factor. |
| | Basic Specification for IP Fast-Reroute: Loop-free Alternates |
| |
|
This document describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS/LDP networks in the event of a single failure, whether link, node or shared risk link group (SRLG). The goal of this technology is to reduce the packet loss that happens while routers converge after a topology change due to a failure. Rapid failure repair is achieved through use of precalculated backup next-hops that are loop-free and safe to use until the distributed network convergence process completes. This simple approach does not require any support from other routers. The extent to which this goal can be met by this specification is dependent on the topology of the network. |
26/03/2008
| |
|
| |
| | LDP Typed Wildcard FEC |
| |
|
The LDP specification [RFC5036] for the Wildcard FEC element has several deficiencies. This document corrects those deficiencies. In addition, it specifies the Typed Wildcard FEC for the Prefix FEC Element Type defined in RFC5036. |
| | LDP Capabilities |
| |
|
A number of enhancements to the Label Distribution Protocol (LDP) have been proposed. Some have been implemented, and some are advancing toward standardization. It is likely that additional enhancements will be proposed in the future. At present LDP has no guidelines for advertising such enhancements at LDP session initialization time. There is also no mechanism to enable and disable enhancements after the session is established. This document provides guidelines for advertising LDP enhancements at session initialization time. It also defines a mechanism to enable and disable enhancements after LDP session establishment. |
| | Traversal With Internet Server Transports (TWIST): Relay Extensions to Session Traversal Utilities for NAT (STUN) |
| |
|
If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers) located behind other NATs. In these situations, it is necessary for the host to use the services of an intermediate node on the Internet that acts as a communication relay. Likewise, if a host of one IP address family wants to communicate with the host of another address family, through one or more NATs, an intermediate node may be necessary. This specification defines a protocol, called TWIST (Traversal With Internet Server Transports), that allows the host to control the operation of a TWIST relay and to exchange packets with its peers using the relay, or directly between each other. This is similar to TURN, but defines an alternative mechanism which is more scalable, cheaper to deploy, and is thus more likely to succeed in achieving wide- spread use. TWIST is not meant to replace TURN, but rather to provide an alternative. This document is a straw-man proposal, to stimulate discussion, not a fully defined draft. |
| | The Transport Layer Security (TLS) Protocol Version 1.2 |
| |
|
This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. |
25/03/2008
| |
|
| |
| | Namespace Considerations and Registries for GSS-API Extensions |
| |
|
This document describes the ways in which the GSS-API may be extended and directs the creation of an IANA registry for various GSS-API namespaces. |
| | Reclassifying 240/4 as usable unicast address space |
| |
|
This memo reclassifies the address block 240.0.0.0/4 as usable address space. While the community has not concluded whether the block should be considered public or private, given the current consumption rate, it is clear that the block should not be left unused. This document also makes several recommendations on ways that current implementations of the IP protocol stack will need to be modified to make this address space usable. |
| | Behavior of Collocated HA/LMA |
| |
|
In discussions about PMIPv6-MIPv6 interactions in NETLMM WG, scenario C describes the case of collocation of LMA and HA function. In this case a PMIP network emulates the "home link" for MNs using MIPv6. This document argues that even when LMA and HA functions are Collocated they MUST be treated as logically separate entities. In particular this draft argues that PMIP BCEs MUST NOT overwrite MIPv6 BCEs and vice versa. |
| | Path Computation Element (PCE) Communication Protocol (PCEP) |
| |
| | draft-ietf-pce-pcep-12.txt |
| | Date: |
25/03/2008 |
| | Authors: |
Arthi Ayyangar, Eiji Oki, Alia Atlas, Andrew Dolganow, Yuichi Ikejiri, Kenji Kumaki, JP Vasseur, Jean-Louis Le Roux |
| | Working Group: |
Path Computation Element (pce) |
| | Formats: |
txt |
|
This document specifies the Path Computation Element Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. |
| | Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions |
| |
|
The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. When a Path Computation Client (PCC) requests a PCE for a route, it may be useful for the PCC to specify, as constraints to the path computation, abstract nodes, resources, and Shared Risk Link Groups (SRLGs) that are to be explicitly excluded from the computed route. Such constraints are termed route exclusions. The PCE Communication Protocol (PCEP) is designed as a communication protocol between PCCs and PCEs. This document presents PCEP extensions for route exclusions. |
24/03/2008
| |
|
| |
| | RTP Payload Format for DV (IEC 61834) Video |
| |
|
This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as "DV" into a payload format for the Real-Time Transport Protocol (RTP). This document Obsoletes RFC 3189. |
| | Bidirectional Forwarding Detection |
| |
|
This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. Comments on this draft should be directed to rtg-bfd@ietf.org. |
| | BFD for IPv4 and IPv6 (Single Hop) |
| |
|
This document describes the use of the Bidirectional Forwarding Detection protocol over IPv4 and IPv6 for single IP hops. Comments on this draft should be directed to rtg-bfd@ietf.org. |
| | Filename Preservation for EDIINT Protocol |
| |
|
The intent of this document is to be placed on the RFC track as an Informational RFC. |
23/03/2008
| |
|
| |
| | IS-IS BFD Enabled TLV |
| |
|
This document describes a TLV for use in the IS-IS routing protocol that allows for the proper use of the Bidirectional Forwarding Detection protocol (BFD). There exist certain scenarios in which IS-IS will not react appropriately to a BFD detected forwarding plane failure without use of either this TLV or some other method. |
| | Humanresolver: an introduction and model of operation |
| |
|
This document introduces "humanresolver": a peer-to-peer contact manager application. |
21/03/2008
| |
|
| |
| | Extended Generic Security Service Mechanism Inquiry APIs |
| |
|
This document introduces new application programming interfaces (APIs) to the Generic Security Services API (GSS-API) for extended mechanism attribute inquiry. These interfaces are primarily intended to reduce instances of hardcoding of mechanism identifiers in GSS applications. These interfaces include: mechanism attributes and attribute sets, a function for inquiring the attributes of a mechanism, a function for indicating mechanisms that posses given attributes, and a function for displaying mechanism attributes. |
| | Requirements for Federated File Systems |
| |
|
This draft describes and lists the functional requirements of a federated file system and defines related terms. Our intent is to use this draft as a starting point and refine it, with input and feedback from the file system community and other interested parties, until we reach general agreement. We will then begin, again with the help of any interested parties, to define standard, open federated file system protocols that satisfy these requirements and are suitable for implementation and deployment. |
| | Sieve Email Filtering: Editheader Extension |
| |
|
This document defines two new actions for the "Sieve" email filtering language that add and delete email header fields. |
20/03/2008
| |
|
| |
| | Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol |
| |
|
RFC 2865 defines a Status-Server code for use in RADIUS, but labels it as "Experimental" without further discussion. This document describes a practical use for the Status-Server packet code, which is to let clients query the status of a RADIUS server. These queries, and responses (if any) enable the client to make more informed decisions. The result is a more stable, and more robust RADIUS architecture. |
| | Network Mobility Basic Support within Proxy Mobile IPv6: scenarios and analysis |
| |
|
As Proxy Mobile IPv6 is deployed, a Mobile Network will be initialized in or move to a Proxy Mobile IPv6 domain. In this document, the scenarios of Network Mobility Basic Support within Proxy Mobile IPv6 that ensure session continuance for all nodes in the Mobile Network are presented. In addition, an analysis of all scenarios that comprise the interactions between Network Mobility Basic Support and Proxy Mobile IPv6 is provided as a guideline to PMIPv6 deployments. |
| | Control Protocol Extensions for Setup of TDM Pseudowires in MPLS Networks |
| |
|
This document defines extension to the PWE3 control protocol [RFC4447] and PWE3 IANA allocations [RFC4446] required for setup of TDM pseudowires in MPLS networks. |
19/03/2008
| |
|
| |
| | Advice to the Trustees of the IETF Trust on Rights to be Granted in IETF Documents |
| |
|
Contributors grant intellectual property rights to the IETF. The IETF Trust holds and manages those rights on behalf of the IETF. The Trustees of the IETF Trust are responsible for that management. This management includes granting the licenses to copy, implement and otherwise use IETF contributions, among them Internet-Drafts and RFCs. The Trustees of the IETF Trust accepts direction from the IETF regarding the rights to be granted. This document describes the desires of the IETF regarding outbound rights to be granted in IETF contributions. |
| | Message Header Field for Indicating Message Authentication Status |
| |
|
This memo defines a new message header field for use with electronic mail messages to indicate the results of message authentication efforts. Mail user agents (MUAs) may use this message header field to relay that information in a convenient way to users or to make sorting and filtering decisions. |
| | EDI-INT Features Header |
| |
|
With the maturity of the EDI-INT standard of AS1, AS2 and AS3, applications and additional features are being built upon the basic secure transport functionality. These features are not necessarily supported by all EDI-INT applications and could cause potential problems with implementations |
| | IPsec Gateway Failover Protocol |
| |
|
The Internet Key Exchange version 2 (IKEv2) protocol has computational and communication overhead with respect to the number of round-trips required and cryptographic operations involved. In remote access situations, the Extensible Authentication Protocol is used for authentication, which adds several more round trips and therefore latency. To re-establish security associations (SA) upon a failure recovery condition is time consuming, especially when an IPsec peer, such as a VPN gateway, needs to re-establish a large number of SAs with various end points. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA re-establishment. In many failure cases it would be useful to provide an efficient way to resume an interrupted IKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA. A client can reconnect to a gateway from which it was disconnected, or alternatively migrate to another gateway that is associated with the previous one. The proposed approach conveys IKEv2 state information, in the form of an encrypted ticket, to a VPN client that is later presented to the VPN gateway for re-authentication. The encrypted ticket can only be decrypted by the VPN gateway in order to restore state for faster session setup. |
| | IKEv2 extensions for combating SPIT on mobile hosts |
| |
|
This document describes IKEv2 extensions for combating SPIT on mobile hosts. |
| | Location-to-Service Translation Protocol (LoST) Extensions |
| |
|
An important class of location-based services answer the question "What instances of this service are closest to me?" Examples include finding restaurants, gas stations, stores, automated teller machines, wireless access points (hot spots) or parking spaces. Currently, the Location-to-Service Translation (LoST) protocol only supports mapping locations to a single service based on service regions. This document describes an extension that allows queries "N nearest" and "within distance X". |
18/03/2008
| |
|
| |
| | MIB for Fibre-Channel Security Protocols (FC-SP) |
| |
| | draft-ietf-imss-fc-fcsp-mib-02.txt |
| | Date: |
18/03/2008 |
| | Authors: |
Claudio DeSanti, Fabio Maino, Keith McCloghrie |
| | Working Group: |
Internet and Management Support for Storage (imss) |
| | Formats: |
txt |
|
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 managed objects for information related to FC-SP, the Security Protocols defined for Fibre Channel. |
| | DKIM Third-Party Authorization for Sender Signer Practices |
| |
|
TPA-label is a DNS-based prefix mechanism for DKIM policy records as a means to authorize Third-Party domains. This mechanism allows first-party domains to autonomously authorize a range of third-party domains in a scalable, individual DNS transaction. This authorization extends the scope of DKIM policy assertions to supplant more difficult to administer mechanisms. Alternatives for facilitating third-party authorizations currently necessitate the coordination between two or more domains by setting up selector/key DNS records, DNS zone delegations, or the regular exchange of public/ private keys. Checking DKIM policies may occur when a From header email-address is not within the domain of a valid DKIM signature. When a Third-Party signature is found, TPA-labels offer an efficient means for email address domains to authorize specific third-party signing domains. The scope of the authorization may separately assert identity authentication for From and Sender and Resent-* headers for email- addresses within the authorizing domain. Identity authentication can be asserted by the scope of the authorization, even when signed by a Third-Party domain. In addition, the RFC2821.MailFrom domain can authorize domains for controlling DSNs. |
| | LoWPAN Backbone Router |
| |
|
ISA100.11a is a Working Group at the ISA SP100 standard committee that covers Wireless Systems for Industrial Automation and Process Control. The WG is mandated to design a scalable, industrial grade LowPAN for devices such as sensors, valves, and actuators. The upcoming standard uses the 6LoWPAN format for the network header. It also introduces the concept of a Backbone Router to merge small LoWPANs via a high speed transit and scale the ISA100.11a network. This paper proposes an IPv6 version of the Backbone Router concept. |
| | Global HA to HA protocol |
| |
|
This HAHA protocol extends MIPv6 [RFC3775] and NEMO [RFC3963] to remove their link layer dependencies on the Home Link and distribute the HAs at IP layer. Global HAHA considers the distribution at the scale of the Internet, and introduces the MIP proxy for Local Mobility Management and Route Optimization in the Infrastructure. |
| | Definition of Managed Objects for the DYMO Manet Routing Protocol |
| |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring aspects of the DYMO routing process. The DYMO MIB also reports state information, performance metrics, and notifications. In addition to configuration, this additional state and performance information is useful to management stations troubleshooting routing problems. |
| | Use of Bit 0x20 in DNS Labels to Improve Transaction Identity |
| |
|
The small (16-bit) size of the DNS transaction ID has made it a frequent target for forgery, with the unhappy result of many cache pollution vulnerabilities demonstrated throughout Internet history. Even with perfectly and unpredictably random transaction ID's, random and birthday attacks are still theoretically feasible. This document describes a method by which an initiator can improve transaction identity using the 0x20 bit in DNS labels. |
| | Sieve Notification Mechanism: mailto |
| |
|
This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent by electronic mail. |
17/03/2008
| |
|
| |
| | Forward-shifted RTP Redundancy Payload Support |
| |
|
This document defines a simple enhancement to RFC 2198 to support RTP sessions with forward-shifted redundant encodings, i.e., redundant data is sent before the corresponding primary data. Forward-shifted redundancy can be used to conceal losses of a large number of consecutive media frames (e.g., consecutive loss of seconds or even tens of seconds of media). |
| | CAPWAP Protocol Specification |
| |
|
This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol. The CAPWAP protocol meets the IETF CAPWAP working group protocol requirements. The CAPWAP protocol is designed to be flexible, allowing it to be used for a variety of wireless technologies. This document describes the base CAPWAP protocol. The CAPWAP protocol binding which defines extensions for use with the IEEE 802.11 wireless LAN protocol is available in [I-D.ietf-capwap-protocol-binding-ieee80211]. Extensions are expected to be defined to enable use of the CAPWAP protocol with additional wireless technologies. |
| | Revised extension mechanisms for DNS (EDNS0) |
| |
|
The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow clients to advertise their capabilities to servers. This document describes backward compatible mechanisms for allowing the protocol to grow.1 - Introduction |
| | SAM Problem Statement |
| |
|
We describe the generally expected behavior of a scalable and adaptive multicast architecture, leaving further details to separate documents on requirements and the SAM design space. This document is a starting point for discussions of feasibility, priority, and deployability. |
| | New Information Elements from the IPFIX Information Model |
| |
|
This document specifies the IPFIX protocol that serves for transmitting IP traffic flow information over the network. In order Aitken, Claise Standard Track [page 1] New Information Elements for the IPFIX Information Model March 2008 to transmit IP traffic flow information from an exporting process to an information collecting process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX data and templates records are carried over a number of transport protocols from an IPFIX exporting process to an IPFIX collecting process. |
| | Sender Policy Framework: Email Address Internationalization |
| |
|
UTF8SMTP is an extension of SMTP (Simple Mail Transfer Protocol) allowing the use of UTF-8 in the SMTP envelope for EAI (Email Address Internationalization) and other purposes. This memo discusses some consequences for SPF (Sender Policy Framework). |
16/03/2008
| |
|
| |
| | A Quick Crash Recovery Method for IKE |
| |
|
This document describes an extension to the IKEv2 protocol that allows for faster crash recovery using a saved token method. When an IPsec tunnel between two IKEv2 implementations is disconnected due to a restart of one peer, it can take as much as several minutes to recover. In this text we propose an extension to the protocol, that allows for recovery within a few seconds of the reboot. |
15/03/2008
| |
|
| |
| | Graceful BGP session shutdown |
| |
|
This draft describes operational procedures aimed at reducing the amount of traffic lost during planned maintenances of routers, involving the shutdown of BGP peering sessions. |
| | Extended Remote Authentication Dial In User Service (RADIUS) Attributes |
| |
|
For the Remote Authentication Dial In User Service (RADIUS) protocol to continue to support new applications the RADIUS attribute type space must be extended beyond the current limit of 255 possible attribute types while maintaining backwards compatibility with the existing protocol. This document defines a mechanism to accomplish that task, along with standard methods to group together related attributes and to encode values that don't fit into 253 octets. |
14/03/2008
| |
|
| |
| | CAPWAP Access Controller DHCP Option |
| |
|
The Control And Provisioning of Wireless Access Points Protocol allows a Wireless Termination Point to use DHCP to discover the Access Controllers it is to connect to. This document describes the DHCP options to be used by the CAPWAP protocol. |
| | Determining When to Discard or Retry a SIP Request During Overload |
| |
|
SIP servers can become overload and unable to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document proposes an architecture for determining when a client should throttle the sending of SIP requests vs. retrying them. |
| | ICMP attacks against TCP |
| |
|
This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP) and other similar protocols. Additionally, describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues. |
13/03/2008
| |
|
| |
| | Considerations for the use of DNS Reverse Mapping |
| |
|
Mapping of addresses to names is a feature of DNS. Many sites implement it, many others do not. Some applications attempt to use it as a part of a security strategy. This document outlines what should be taken into account when deciding whether to implement reverse mappings of addresses to names, suggests that site administrators implement reverse mappings if there are no strong considerations against such mappings, and provides considerations to be taken into account when using reverse mappings. |
| | Downgrading mechanism for Email Address Internationalization |
| |
|
Traditional mail systems handle only ASCII characters in SMTP envelope and mail header fields. The Email Address Internationalization (UTF8SMTP) extension allows UTF-8 characters in SMTP envelope and mail header fields. To avoid bouncing internationalized Email messages when a server in the delivery path does not support the UTF8SMTP extension, some sort of converting mechanism is required. This document describes a downgrading mechanism for Email Address Internationalization. Note that this is a way to downgrade, not tunnel. There is no associated up-conversion mechanism, although internationalized email clients might use original internationalized addresses or other data when displaying or replying to downgraded messages. |
| | Clarifications and Extensions to the GSS-API for the Use of Channel Bindings |
| |
|
This document clarifies and generalizes the Generic Security Services Application Programming Interface (GSS-API) "channel bindings" facility, and imposes requirements on future GSS-API mechanisms and programming language bindings of the GSS-API. |
| | Alarms in SYSLOG |
| |
|
This document describes how to send alarm information in syslog. It includes the mapping of ITU perceived severities onto syslog message fields. |
| | H.248/MEGACO Package Registration Procedures |
| |
|
This document updates the H.248/MEGACO IANA Package Registration procedures in order to better describe the Package registration process and to provide a more formal review and feedback process. |
| | SAM Overlay Protocol |
| |
|
The previously proposed Hybrid Overlay Multicast Framework uses a structured peer-to-peer overlay to connect peers in different types of multicast regions of the Internet. We use AMT (Automatic IP Multicast Without Explicit Tunnels) to connect peers in ALM (Application Layer Multicast) regions with peers in native multicast regions. Here we define the overlay messaging needed to support the multicast tree operations. One goal of this approach is to ensure that the SAM framework is compatible with the P2P-SIP overlay, which is still being defined. Another goal is to be overlay agnostic so that different overlay algorithms can interoperate in a single SAM (Scalable Adaptive Multicast) session. |
| | Subnetwork Encapsulation and Adaptation Layer |
| |
|
SEAL is related to problem spaces currently under investigation in the IRTF Routing Research Group, as well as the IETF INTAREA general area and IETF AUTOCONF and MANET working groups. SEAL addresses packet size issues for IP-in-IP tunnels, with improved duplicate packet detection as an additional benefit. This document is currently under construction as an individual submission, to be followed by determination of an appropriate working group (or remain as individual sub). |
| | SAVI Threat Scope |
| |
|
This memo discusses threats enabled by IP source address spoofing and discusses a number of techniques aimed at mitigating those threats. |
| | Using HTTP for delivery in Delay/Disruption-Tolerant Networks |
| |
|
This document describes how to use the Hypertext Transfer Protocol, HTTP, for communication across delay- and disruption-tolerant networks. HTTP is well-known and straightforward to implement in these networks. |
| | IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespaces |
| |
|
This document creates additional Session Initiation Protocol (SIP) Resource-Priority namespaces to meet the requirements of the US Defense Information Systems Agency, and places these namespaces in the IANA registry. |
12/03/2008
| |
|
| |
| | An Extension to Session Initiation Protocol (SIP) Events for Pausing and Resuming Notifications |
| |
|
The Session Initiation Protocol (SIP) events framework enables a subscriber to receive asynchronous notification of various events from other SIP user agents. It defines mechanisms to create, refresh, terminate subscriptions. This framework also defines mechanism to fetch (poll) an event state of a resource without creating persistent subscriptions. There is no mechanism to temporarily pause the notifications, while still maintaining a subscription on the server. This lack of functionality sometime results in a lot of superfluous notification traffic, and put unnecessary load on the server. This draft defines an extension to SIP events that allows the subscriber to pause, un-pause notifications, and be able to perform fetch (poll) subscriptions within an established (created) subscription dialog. |
| | Common Practices in Routing Protocols Deployment |
| |
|
This document discusses common practices used in deploying routing protocols in both public and private networks. The focus is not to describe how routing protocols should be deployed, but rather how they are generally deployed, to provide those working on specifications which impact the operation of routing protocols with guidance in what will likely be deployed, or what will likely not be deployed. The focus in thie document will be ionterdomain routing, but it will cover aspects of intradomain routing, as well.1. Background When considering new extensions to existing routing protocols, it's useful to consider them in the context of existing usage of these protocols. Various questions come to mind, such as: o Common Underlying Principles of Network Designs o Common Practices in Route Origination o Common Practices in Routing Database Management o Common Practices in Aggregation o Common Practices in Peering o Common Practices in Security o .... Each of these topics will be covered in a separate section below. |
| | Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS) |
| |
|
This memo describes the requirements for a Crypto-Agility solution for Remote Authentication Dial-In User Service (RADIUS). |
11/03/2008
| |
|
| |
| | A general mechanism for RTP Header Extensions |
| |
|
This document provides a general mechanism to use the header- extension feature of RTP (the Real Time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized. The actual extensions in use in a session are signaled in the setup information for that session. |
| | Transmission Time offsets in RTP streams |
| |
|
This document describes a method to inform RTP clients when RTP packets are transmitted at a time other than their 'nominal' transmission time. It also provides a mechanism to provide improved inter-arrival jitter reports from the clients, that take into account the reported transmission times. |
| | ForCES Protocol Specification |
| |
| | draft-ietf-forces-protocol-14.txt |
| | Date: |
11/03/2008 |
| | Authors: |
Ligang Dong, Avri Doria, Ram Gopal, Robert HAAS, Jamal Hadi Salim, Hormuzd Khosravi, Weiming Wang |
| | Working Group: |
Forwarding and Control Element Separation (forces) |
| | Formats: |
txt xml |
|
This document specifies the Forwarding and Control Element Separation (ForCES) protocol. ForCES protocol is used for communications between Control Elements(CEs) and Forwarding Elements (FEs) in a ForCES Network Element (ForCES NE). This specification is intended to meet the ForCES protocol requirements defined in RFC3654. Besides the ForCES protocol messages, the specification also defines the framework, the mechanisms, and the Transport Mapping Layer (TML) requirements for ForCES protocol.Authors The participants in the ForCES Protocol Team, primary co-authors and co-editors, of this protocol specification, are: Ligang Dong (Zhejiang Gongshang University), Avri Doria (Lulea University of Technology), Ram Gopal (Nokia), Robert Haas (IBM), Jamal Hadi Salim (Znyx), Hormuzd M Khosravi (Intel), and Weiming Wang (Zhejiang Gongshang University). Special acknowledgement goes to Joel Halpern who has done extensive editing in support of congruence between the model and this protocol specification. Without his participation and persistence, this specification might never have been completed. |
| | ForCES MIB |
| |
|
This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it defines managed objects for the Forwarding and Control Element Separation (ForCES) Network Element (NE). |
| | IP Mobility Support for IPv4,revised |
| |
| |