Current Internet-Drafts This summary sheet provides a short synopsis of each Internet-Draft available within the "internet-drafts" directory at the shadow sites directory. These drafts are listed alphabetically by working group acronym and start date. IP over IEEE 802.16 Networks (16ng) ----------------------------------- "Analysis of IPv6 Link Models for 802.16 based Networks", Syam Madanapalli, 10-Oct-06, This document provides different IPv6 link models that are suitable for 802.16 based networks and provides analysis of various considerations for each link model and the applicability of each link model under different deployment scenarios. This document is result of a Design Team that was formed to analyze the IPv6 link models for 802.16 based networks. "IP over 802.16 Problem Statement and Goals", Junghoon Jee, 16-Oct-06, This draft provides overview of 802.16 Network characteristics and Convergence Sublayers, and specifies the problems in running the IETF IP (both IPv4 and IPv6) protocols over 802.16 Networks. This document also presents the goals that point at relevant work to be at IETF. "IPv6 Over IPv6 Convergence sublayer in 802.16 Networks", Basavaraj Patil, 25-Oct-06, The IEEE 802.16d/e has specified several convergence sublayers which are a part of the MAC that can be used for carrying IPv6 packets. The IPv6 convergence sublayer enables transport of IPv6 packets directly over the MAC. Between the 802.16d/e host and the base station IPv6 packets are carried over a MAC layer transport connection which is a virtual point-to-point link. This document specifies the addressing and operation of IPv6 hosts served by a network that utilizes the 802.16d/e air interface. It recommends the assignment of a unique prefix to each host and allow the host to use multiple identifiers within that prefix, including support for randomly generated identifiers. IPv6 over Low power WPAN (6lowpan) ---------------------------------- "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", Gabriel Montenegro, Nandakishore Kushalnagar, 8-Nov-06, This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. "6LoWPAN: Overview, Assumptions, Problem Statement and Goals", Nandakishore Kushalnagar, Gabriel Montenegro, 4-Aug-06, This document describes the assumptions, problem statement and goals for transmitting IP over IEEE 802.15.4 networks. The set of goals enumerated in this document form an initial set only. Additional goals may be found necessary over time and may be added to this document. Authentication, Authorization and Accounting (aaa) -------------------------------------------------- "Diameter Session Initiation Protocol (SIP) Application", Miguel Garcia-Martin, 28-Apr-06, This document specifies the Diameter Session Initiation Protocol (SIP) Application. This is a Diameter application that allows a Diameter client to request authentication and authorization information. This application is designed to be used in conjunction with the Session Initiation Protocol (SIP), and provides a Diameter client co-located with a SIP server, with the ability to request the authentication of users and authorization of SIP resources usage from a Diameter server. ADSL MIB (adslmib) ------------------ "Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2)", Moti Morgenstern, 12-Jun-06, This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing parameters of the "Asymmetric Digital Subscriber Line" family of interface types, especially including ADSL, ADSL2, and ADSL2+. "Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2)", Moti Morgenstern, 1-Aug-06, This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing parameters of the "Very High Speed Digital Subscriber Line 2 (VDSL2)" interface type, which are also applicable for managing ADSL, ADSL2, and ADSL2+ interfaces. Access Node Control Protocol (ancp) ----------------------------------- "Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks", Sven Ooghe, 16-Oct-06, The purpose of this document is to define a framework for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform QoS-related, service-related and Subscriber-related operations. The Access Node Control Mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather using a direct device-device communication. This allows for performing access link related operations within those network elements, while avoiding impact on the existing OSS systems. Atom Publishing Format and Protocol (atompub) --------------------------------------------- "The Atom Publishing Protocol", Bill de Hora, Joe Gregorio, 5-Oct-06, The Atom Publishing Protocol (APP) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transport of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format [RFC4287]. Audio/Video Transport (avt) --------------------------- "RTP Payload Format for Generic Forward Error Correction", Adam Li, 25-Oct-06, This document specifies a payload format for generic Forward Error Correction (FEC) for media data encapsulated in RTP. It is based on the exclusive-or (parity) operation. The payload format described in this draft allows end systems to apply protection using various protection lengths and levels, in addition to using various protection group sizes to adapt to different media and channel characteristic. It enables complete recovery of the protected packets or partial recovery of the critical parts of the payload depending on the packet loss situation. This scheme is completely compatible with non-FEC capable hosts, so the receivers in a multicast group that do not implement FEC can still work by simply ignoring the protection data. This specification obsoletes RFC 2733 and RFC 3009. The FEC specified in this document is not backward compatible with RFC 2733 and RFC 3009. "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback", Julian Chesterfield, 26-Oct-06, This document specifies an extension to the Real-time Transport Control Protocol (RTCP) to use unicast feedback to a multicast sender. The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism. "RTP Payload Format for JPEG 2000 Video Streams", Satoshi Futemma, 15-Nov-06, This memo describes an RTP payload format for the ISO/IEC International Standard 15444-1 | ITU-T Rec. T.800, otherwise better known as: JPEG 2000. JPEG 2000 features are considered in the design of this payload format. JPEG 2000 is a truly scalable compression technology allowing applications to encode once and decode many different ways. JPEG 2000 video stream is formed by extending from a single image to a series of JPEG 2000 images. "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", Henning Schulzrinne, Tom Taylor, 16-Jun-06, This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets. It obsoletes RFC 2833. This memo captures and expands upon the basic framework defined in RFC 2833, but retains only the most basic event codes. It sets up an IANA registry to which other event code assignments may be added. Companion documents add event codes to this registry relating to modem, fax, text telephony, and channel-associated signalling events. The remainder of the event codes defined in RFC 2833 are conditionally reserved in case other documents revive their use. See Section 7 and Appendix A for details. [RFC Editor: please change the Informative reference following RFC 4103 to the RFC number assigned to draft-ietf-avt-rfc2833bisdata-08.txt, one of the "companion documents" referred to above.] In terms of procedure, this document provides a number of clarifications to the original document. However, it specifically differs from RFC 2833 by removing the requirement that all compliant implementations support the DTMF events. Instead, compliant implementations taking part in out-of-band negotiations of media stream content indicate what events they support. As well, this memo adds three new procedures to the RFC 2833 framework: subdivision of long events into segments, reporting of multiple events in a single packet, and the concept and reporting of state events. "Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF)", Joerg Ott, Elisabetta Carrara, 25-Oct-06, An RTP profile (SAVP) is defined for secure real-time communications, and another profile (AVPF) is specified to provide timely feedback from the receivers to a sender. This memo defines the combination of both profiles to enable secure RTP communications with feedback. "RTP Payload Format for ITU-T Rec. H.263 Video", Joerg Ott, 20-Apr-06, This document describes a scheme to packetize an H.263 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP. The document also describes the syntax and semantics of the SDP parameters needed to support the H.263 video codec. The document obsoletes RFC 2429 and updates the H263-1998 and H263- 2000 MIME media type in RFC 3555 "RTP Profile for TCP Friendly Rate Control", Ladan Gharai, 8-Sep-06, This memo specifies a profile called "RTP/AVPFCC" for the use of the real-time transport protocol (RTP) and its associated control protocol, RTCP, with TCP Friendly Rate Control (TFRC). This profile extends the RTP/AVPF profile with RTP data header additions and new AVPF feedback packets, in order to support TFRCs integration with RTP. TFRC is an equation based congestion control scheme for unicast flows operating in a best effort Internet environment. This profile provides RTP flows with the mechanism to use congestion control in best effort IP networks. "RTP Payload Format for ATRAC Family", Matthew Romaine, Jun Matsumoto, 5-Jun-06, This document describes an RTP payload format for efficient and flexible transporting of audio data encoded with the Adaptive TRansform Audio Codec (ATRAC) family of codecs. Recent enhancements to the ATRAC family of codecs support high quality audio coding with multiple channels. The RTP payload format as presented in this document also includes support for data fragmentation, elementary redundancy measures, and a variation on scalable streaming. "RTP Payload Format for H.263 using RFC2190 to Historic status", Roni Even, 11-May-06, The first RFC that describes RTP payload format for H.263 is RFC2190. This specification discusses why to move this RFC to historic status. "RTP Control Protocol Extended Reports (RTCP XR) VoIP Metrics Management Information Base", Alan Clark, Amy Pendleton, 28-Jun-06, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing Real-Time Transport Control Protocol Extended Reports (RTCP XR) VoIP Metrics (RFC3611). "RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", Johan Sjoberg, 20-Sep-06, This document specifies a real-time transport protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate media type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format. This document obsoletes RFC 3267. "Definition of Events For Modem, FAX, and Text Telephony Signals", Tom Taylor, Henning Schulzrinne, 16-Jun-06, This memo updates RFC xxxx to add event codes for modem, FAX, and text telephony signals when carried in the telephony event RTP payload. It supersedes the assignment of event codes for this purpose in RFC 2833, and therefore obsoletes that part of RFC 2833. [Note to RFC Editor: please replace "RFC xxxx" in the header above and throughout this document with the RFC number assigned to draft-ietf-avt-rfc2833bis-15. Please also make the appropriate change to the fifth normative reference.] "Definition of Events For Channel-Oriented Telephony Signalling", Tom Taylor, Henning Schulzrinne, 22-Jun-06, This memo updates RFC xxxx to add event codes for telephony signals used for channel-associated signalling when carried in the telephony event RTP payload. It supersedes the assignment of event codes for this purpose in RFC 2833, and therefore obsoletes that part of RFC 2833. [Note to RFC Editor: please replace "RFC xxxx" in the header above and throughout this document with the RFC number assigned to draft-ietf-avt-rfc2833bis-15. Please also make the appropriate change to the fourth normative reference.] "Media Type Registration of RTP Payload Formats", Stephen Casner, 17-Oct-06, This document specifies the procedure to register RTP payload formats as audio, video or other media subtype names. This is useful in a text-based format description or control protocol to identify the type of an RTP transmission. "Protocol Extensions for Header Compression over MPLS", Jerry Ash, 31-May-06, This specification defines how to use Multi-Protocol Label Switching (MPLS) to route Header-Compressed (HC) packets over an MPLS label switched path. HC can significantly reduce packet-header overhead and, in combination with MPLS, can also increases bandwidth efficiency and processing scalability in terms of the maximum number of simultaneous compressed flows that use HC at each router). Here we define how MPLS pseudowires are used to transport the HC context and control messages between the ingress and egress MPLS label switching routers. This is defined for a specific set of existing HC mechanisms that might be used, for example, to support voice over IP. This specification also describes extension mechanisms to allow support for future, as yet to be defined, HC protocols. In this specification, each HC protocol operates independently over a single pseudowire instance very much as it would over a single point-to-point link. "A general mechanism for RTP Header Extensions", David Singer, 19-Oct-06, 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 unregistered. The actual extensions in use in a session are signaled in the setup information for that session. "Associating Time-codes with RTP streams", David Singer, 19-Oct-06, This document describes a mechanism for associating time-codes, as defined by the Society of Motion Picture and Television Engineers (SMPTE), with media streams, in a way that is independent of the RTP payload format of the media stream itself. "RTP Payload Format for ITU-T Recommendation G.722.1", Patrick Luthi, Roni Even, 23-Aug-06, International Telecommunication Union (ITU-T) Recommendation G.722.1 is a wide-band audio codec. This document describes the payload format for including G.722.1 generated bit streams within an RTP packet. The document also describe the syntax and semantics of the SDP parameters needed to support G.722.1 audio codec. "Enhancements to RTP Payload Formats for EVRC Family Codecs", Qiaobing Xie, Rohit Kapoor, 19-Oct-06, This document updates the Enhanced Variable Rate Codec (EVRC) RTP payload formats defined in RFC 3558 with several enhancements and extensions. In particular, it defines support for the header-free and interleaved/bundled packet formats for the EVRC-B codec, a new compact bundled format for the EVRC and EVRC-B codecs, as well as discontinuous transmission (DTX) support for EVRC and EVRC-B encoded speech transported via RTP. VoIP applications operating over low bandwidth dial-up and wireless networks require such enhancements for efficient use of the bandwidth. "RTP Payload Format for Vorbis Encoded Audio", Luca Barbato, 27-Jun-06, This document describes an RTP payload format for transporting Vorbis encoded audio. It details the RTP encapsulation mechanism for raw Vorbis data and details the delivery mechanisms for the decoder probability model, referred to as a codebook and other setup information. Also included within the document are the necessary details for the use of Vorbis with MIME and Session Description Protocol (SDP). "Real-time Transport Protocol (RTP) MIB Version 2", Alan Clark, Amy Pendleton, 28-Jun-06, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing Real-Time Transport Protocol (RTP) systems (RFC3550) and is a proposed replacement for RFC 2959 - the RTP MIB. "Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences", Stephen Casner, 17-Oct-06, This document specifies media type registrations for the RTP payload formats defined in the RTP Profile for Audio and Video Conferences. Some of these may also be used for transfer modes other than RTP. "Transmission Time offsets in RTP streams", HariKishan Desineni, David Singer, 19-Oct-06, 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. "The use of AES-192 and AES-256 in Secure RTP", David McGrew, 25-Aug-06, This memo describes the use of the Advanced Encryption Standard (AES) with 192 and 256 bit keys within the Secure RTP protocol. It defines Counter Mode encryption for SRTP and SRTCP and a new SRTP Key Derivation Function (KDF) for AES-192 and AES-256. "Codec Control Messages in the Audio-Visual Profile with Feedback (AVPF)", Stephan Wenger, 23-Oct-06, This document specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However some are also usable in smaller multicast environments and point-to-point calls. The extensions discussed are H.271 video back channel, Full Intra Request, Temporary Maximum Media Bit-rate and Temporal Spatial Trade- off. "RTP Topologies", Magnus Westerlund, Stephan Wenger, 23-Oct-06, This document disucsses multi-endpoint topologies commonly used in RTP based environments. In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology. "Multiplexing RTP Data and Control Packets on a Single Port", Colin Perkins, Magnus Westerlund, 20-Nov-06, This memo discusses issues that arise when multiplexing RTP data packets and RTP control protocol (RTCP) packets on a single UDP port. It updates RFC 3550 to describe when such multiplexing is, and is not, appropriate, and explains how the Session Description Protocol (SDP) can be used to signal multiplexed sessions. Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- "Simple Traversal Underneath Network Address Translators (NAT) (STUN)", Jonathan Rosenberg, 26-Oct-06, Simple Traversal Underneath NATs (STUN) is a lightweight protocol that serves as a tool for application protocols in dealing with NAT traversal. It allows a client to determine the IP address and port allocated to them by a NAT and to keep NAT bindings open. It can also serve as a check for connectivity between a client and a server in the presence of NAT, and for the client to detect failure of the server. STUN works with many existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure. "NAT Behavioral Requirements for Unicast UDP", Francois Audet, Cullen Jennings, 11-Oct-06, This document defines basic terminology for describing different types of NAT behavior when handling Unicast UDP and also defines a set of requirements that would allow many applications, such as multimedia communications or on-line gaming, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. "Network Address Port Translator (NAPT) Any-Source Multicast Requirement", Dan Wing, 26-Oct-06, This document places a requirement on a Network Address Translator (NAT) and Network Address and Port Translator (NAPT) that supports any-source multicast. "NAT Behavioral Requirements for TCP", Saikat Guha, 6-Nov-06, This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and on-line games, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. "Obtaining Relay Addresses from Simple Traversal Underneath NAT (STUN)", Jonathan Rosenberg, 9-Oct-06, This specification defines a usage of the Simple Traversal of UDP Through NAT (STUN) Protocol for asking the STUN server to relay packets towards a client. This usage is useful for elements behind NATs whose mapping behavior is address and port dependent. The extension purposefully restricts the ways in which the relayed address can be used. In particular, it prevents users from running general purpose servers from ports obtained from the STUN server. "Extension to the Simple Traversal Underneath NAT (STUN) Relay Usage for IPv4/IPv6 Transition", Gonzalo Camarillo, Oscar Novo, 21-Nov-06, This document defines the REQUESTED-ADDRESS-TYPE attribute for the Simple Traversal Underneath NAT (STUN) Relay Usage, which allows a client to explicitly request the address type the STUN relay server will allocate (e.g., an IPv4-only node may request the STUN relay server to allocate an IPv6 address). Additionally, this document also defines a new error response code with the value 440 (Address Family not Supported). "NAT Behavioral Requirements for ICMP protocol", Pyda Srisuresh, 5-Oct-06, This document identifies the behavioral properties required of the Network Address Translator (NAT) devices in conjunction with the ICMP protocol. The objective of this memo is to make NAT devices more predictable and compatible with diverse application protocols that traverse the devices. Companion documents provide behavioral recommendations specific to TCP, UDP and other protocols. "State of Peer-to-Peer(P2P) Communication Across Network Address Translators(NATs)", Pyda Srisuresh, 18-Oct-06, This memo documents the various methods known to be in use by peer-to-peer (P2P) applications for communication in the presence of Network Address Translators (NATs) at the current time. This memo covers NAT traversal approaches used by both TCP and UDP based applications. This memo is not an endorsement of the methods described, but merely an attempt to capture them in a document. Bidirectional Forwarding Detection (bfd) ---------------------------------------- "Bidirectional Forwarding Detection Management Information Base", Thomas Nadeau, Zafar Ali, 22-Oct-06, This draft 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 modeling Bidirectional Forwarding Detection (BFD) protocol [BFD]. "BFD For MPLS LSPs", Rahul Aggarwal, 27-Jun-06, One desirable application of Bi-directional Forwarding Detection (BFD) is to detect a MPLS LSP data plane failure. LSP-Ping is an existing mechanism for detecting MPLS data plane failures and for verifying the MPLS LSP data plane against the control plane. BFD can be used for the former, but not for the latter. However the control plane processing required for BFD control packets is relatively smaller than the processing required for LSP-Ping messages. A combination of LSP-Ping and BFD can be used to provide faster data plane failure detection and/or make it possible to provide such detection on a greater number of LSPs. This document describes the applicability of BFD in relation to LSP-Ping for this application. It also describes procedures for using BFD in this environment. "Bidirectional Forwarding Detection", Dave Katz, David Ward, 14-Jun-06, 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 Multihop Paths", Dave Katz, David Ward, 14-Jun-06, This document describes the use of the Bidirectional Forwarding Detection protocol (BFD) over multihop paths, including unidirectional links. "BFD for IPv4 and IPv6 (Single Hop)", Dave Katz, David Ward, 14-Jun-06, 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. "Generic Application of BFD", Dave Katz, David Ward, 14-Jun-06, This document describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol. Comments on this draft should be directed to rtg-bfd@ietf.org. Benchmarking Methodology (bmwg) ------------------------------- "Benchmarking Terminology for Resource Reservation Capable Routers", Krisztian Nemeth, 7-Feb-06, The primary purpose of this document is to define terminology specific to the benchmarking of resource reservation signaling of Integrated Services IP routers. These terms can be used in additional documents that define benchmarking methodologies for routers that support resource reservation or reporting formats for the benchmarking measurements. "Benchmarking Methodology for IGP Data Plane Route Convergence", Scott Poretsky, Brent Imhoff, 5-Jun-06, This dpcument describes the methodology for benchmarking IGP Route Convergence as described in Applicability document [1] and Terminology document [2]. The methodology and terminology are to be used for benchmarking route convergence and can be applied to any link-state IGP such as ISIS [3] and OSPF [4]. The terms used in the procedures provided within this document are defined in [2]. "Terminology for Benchmarking IGP Data Plane Route Convergence", Brent Imhoff, Scott Poretsky, 5-Jun-06, This document describes the terminology for benchmarking IGP Route Convergence as described in Applicability document [Po061] and Methodology document [Po062]. The methodology and terminology are to be used for benchmarking Convergence Time and can be applied to any link-state IGP such as ISIS [Ca90] and OSPF [Mo98]. The data plane is measured to obtain the convergence benchmarking metrics described in [Po062]. "Considerations for Benchmarking IGP Data Plane Route Convergence", Scott Poretsky, 5-Jun-06, This document provides considerations for IGP Route Convergence benchmarking methodology [1] and IGP Route Convergence benchmarking terminology [2]. The methodology and terminology are to be used for benchmarking route convergence and can be applied to any link-state IGP such as ISIS [3] and OSPF [4]. The data plane is measured to obtain the convergence benchmarking metrics described in [1]. "Terminology for Accelerated Stress Benchmarking", Scott Poretsky, Shankar Rao, 25-Oct-06, This document provides the Terminology for performing Accelerated Stress Benchmarking of networking devices. The three phases of the Stress Test: Startup, Instability and Recovery are defined along with the benchmarks and configuration terms associated with the each phase. Also defined are the Benchmark Planes fundamental to stress testing configuration, setup and measurement. The terminology is to be used with the companion framework and methodology documents. "Methodology Guidelines for Accelerated Stress Benchmarking", Shankar Rao, Scott Poretsky, 25-Oct-06, Routers in an operational network are configured with multiple protocols and security policies while simultaneously forwarding traffic and being managed. To accurately benchmark a router for deployment it is necessary to test the router under accelerated operational conditions, which is known as Stress Testing. This document provides the Methodology Guidelines for performing Accelerated Stress Benchmarking of networking devices. Descriptions of Test Topology, Benchmarks and Reporting Format are provided in addition to procedures for conducting various test cases. The methodology is to be used with the companion terminology document [4]. These guidelines can be used as the basis for additional methodology documents that benchmark stress conditions for specific network technologies. "Hash and Stuffing: Overlooked Factors in Network Device Benchmarking", David Newman, Timmons Player, 22-Nov-06, Test engineers take pains to declare all factors that affect a given measurement, including intended load, packet length, test duration, and traffic orientation. However, current benchmarking practice overlooks two factors that have a profound impact on test results. First, existing methodologies do not require the reporting of addresses or other test traffic contents, even though these fields can affect test results. Second, "stuff" bits and bytes inserted in test traffic by some link-layer technologies add significant and variable overhead, which in turn affects test results. This document describes the effects of these factors; recommends guidelines for test traffic contents; and offers formulas for determining the probability of bit- and byte-stuffing in test traffic. "Methodology for Benchmarking Network-layer Traffic Control Mechanisms", Richard Watts, Scott Poretsky, 27-Jun-06, This document describes the methodology for the benchmarking of devices that implement traffic control based on classification such as diff-serv code point (DSCP) criteria. The methodology is to be applied to measurements made on the data plane to evaluate the performance of the traffic control mechanisms. The methodology permits the specific traffic control mechanisms and configuration commands to vary between DUTs. The methodology provides procedures using existing Terminology to benchmark DUT performance traffic control mechanisms applied to physical and logical interfaces using DSCP as the classification criteria. This includes scenarios where Forwarding Congestion occurs due to interface congestion. "Benchmarking Terminology for Protection Performance", Scott Poretsky, 16-Oct-06, This document provides common terminology and metrics for benchmarking the performance of sub-IP layer protection mechanisms. The performance benchmarks are measured at the IP-Layer, so avoid dependence on specific sub-IP protections mechanisms. The benchmarks and terminology can be applied in methodology documents for different sub-IP layer protection mechanisms such as Automatic Protection Switching (APS), Virtual Router Redundancy Protocol (VRRP), and Multi-Protocol Label Switching Fast Reroute (MPLS-FRR). "Methodology for benchmarking MPLS Protection mechanisms", Rajiv Papneja, 18-Oct-06, This draft provides the methodology for benchmarking MPLS Protection mechanisms especially the failover time of local protection (MPLS Fast Reroute as defined in RFC-4090). The failover to a backup tunnel could happen at the headend of the primary tunnel or a midpoint and the backup could offer link or node protection. It becomes vital to benchmark the failover time for all the cases and combinations. The failover time could also greatly differ based on the design and implementation and by factors like the number of prefixes carried by the tunnel, the routing protocols that installed these prefixes (IGP, BGP...), the number of primary tunnels affected by the event that caused the failover, number of primary tunnels the backup protects and type of failure, the physical media type on which the failover occurs etc. All the required benchmarking criteria and benchmarking topology required for measuring failover time of local protection is described Conventions used in this document Better-Than-Nothing Security (btns) ----------------------------------- "Problem and Applicability Statement for Better Than Nothing Security (BTNS)", Joseph Touch, 27-Sep-06, The Internet network security protocol suite, IPsec, consisting of IKE, ESP, and AH, generally requires authentication via IKE of network layer entities to bootstrap security. This authentication can be based on mechanisms such as pre-shared symmetric keys, certificates and associated asymmetric keys, or the use of Kerberos. The need to deploy authentication information and its associated identities to network layer entities can be a significant obstacle to use of network security. This document explains the rationale for extending the Internet network security suite to enable use of IPsec security mechanisms without full IKE authentication. These extensions are intended to protect communication in a "better than nothing" (BTNS) fashion. The extensions may be used on their own (Stand Alone BTNS, or SAB), or may be useful in providing network layer security that can be authenticated by higher layers in the protocol stack, called Channel Bound BTNS (CBB). This document also explains situations in which use of SAB and CBB extensions are appropriate. "Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec", Michael Richardson, Nicolas Williams, 28-Jun-06, This document specifies how to use the Internet Key Exchange (IKE) protocols, such as IKEv1 and IKEv2, to setup "unauthenticated" security associations (SAs) for use with the IPsec Encapsulating Security Payload (ESP) and the IPsec Authentication Header (AH). No IKE extensions are needed, but Peer Authorization Database (PAD) and Security Policy Database (SPD) extensions are specified. Unauthenticated IPsec is herein referred to by its popular acronym, "BTNS" (Better Than Nothing Security). Calendaring and Scheduling Standards Simplification (calsify) ------------------------------------------------------------- "iCalendar Message-Based Interoperability Protocol(iMIP)", Alexey Melnikov, 12-Jun-06, This document, iCalendar Message-Based Interoperability Protocol (iMIP), specifies a binding from the iCalendar Transport-independent Interoperability Protocol (iTIP) to Internet email-based transports. Calendaring entries defined by the iCalendar Object Model (iCAL) are composed using constructs from RFC 2822, RFC 2045, RFC 2046, RFC 2047, RFC 2048 and RFC 2049. This document is a product of Calendaring and Scheduling Standards Simplification (calsify) working group. More information about the IETF CALSIFY working group activities can be found on the IETF web site at . "iCalendar Transport-Independent Interoperability Protocol (iTIP)", Cyrus Daboo, 28-Jun-06, This document specifies a protocol using the iCalendar object specification to provide scheduling interoperability between different calendar systems. This is done without reference to a specific transport protocol so as to allow multiple methods of communication between systems. Subsequent documents will define profiles of this protocol using specific interoperable methods of communications between systems. iTIP complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendar systems. These scheduling methods permit two or more calendar systems to perform transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel. "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", Bernard Desruisseaux, 25-Oct-06, There is a clear need to provide and deploy interoperable calendaring and scheduling services for the Internet. Current group scheduling and Personal Information Management (PIM) products are being extended for use across the Internet, today, in proprietary ways. This memo has been defined to provide the definition of a common format for openly exchanging calendaring and scheduling information across the Internet. Control And Provisioning of Wireless Access Points (capwap) ----------------------------------------------------------- "SLAPP : Secure Light Access Point Protocol", Partha Narasimhan, 27-Mar-06, The CAPWAP problem statement [3] describes a problem that needs to be addressed before a wireless LAN (WLAN) network designer can construct a solution composed of Wireless Termination Points (WTP) and Access Controllers (AC) from multiple, different vendors. One of the primary goals is to find a solution that solves the interoperability between the two classes of devices (WTPs and ACs) which then enables an AC from one vendor to control and manage a WTP from another. "CAPWAP Protocol Specification", Pat Calhoun, 16-Oct-06, 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 [11]. Extensions are expected to be defined to enable use of the CAPWAP protocol with additional wireless technologies. "CAPWAP Protocol Binding for IEEE 802.11", Pat Calhoun, 16-Oct-06, Wireless LAN product architectures have evolved from single autonomous access points to systems consisting of a centralized Access Controller (AC) and Wireless Termination Points (WTPs). The general goal of centralized control architectures is to move access control, including user authentication and authorization, mobility management and radio management from the single access point to a centralized controller. This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Binding Specification for use with the IEEE 802.11 Wireless Local Area Network (WLAN) protocol. The CAPWAP Protocol Specification is defined separately [1]. Common Control and Measurement Plane (ccamp) -------------------------------------------- "Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management", Thomas Nadeau, Adrian Farrel, 8-Sep-06, This document defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Generalized Multiprotocol Label Switching (GMPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in GMPLS related MIB modules that would otherwise define their own representations. "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", Thomas Nadeau, Adrian Farrel, 8-Sep-06, 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 Generalized Multiprotocol Label Switching (GMPLS) based traffic engineering. "Generalized Multiprotocol Label Switching (GMPLS)Label Switching Router (LSR) Management Information Base", Thomas Nadeau, Adrian Farrel, 8-Sep-06, 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 to configure and/or monitor a Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR). "Exclude Routes - Extension to RSVP-TE", Adrian Farrel, 21-Nov-06, The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow abstract nodes and resources to be explicitly included in a path setup, but not to be explicitly excluded. In some networks where precise explicit paths are not computed at the head end it may be useful to specify and signal abstract nodes and resources that are to be explicitly excluded from routes. These exclusions may apply to the whole path, or to parts of a path between two abstract nodes specified in an explicit path. How Shared Risk Link Groups (SLRGs) can be excluded is also specified in this document. This document specifies ways to communicate route exclusions during path setup using RSVP-TE. "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE", Adrian Farrel, 24-May-05, In a distributed, constraint-based routing environment, the information used to compute a path may be out of date. This means that Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup requests may be blocked by links or nodes without sufficient resources. Crankback is a scheme whereby setup failure information is returned from the point of failure to allow new setup attempts to be made avoiding the blocked resources. Crankback can also be applied to LSP recovery to indicate the location of the failed link or node. This document specifies crankback signaling extensions for use in MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC3209, and GMPLS signaling as defined in "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC3473. These extensions mean that the LSP setup request can be retried on an alternate path that detours around blocked links or nodes. This offers significant improvements in the successful setup and recovery ratios for LSPs, especially in situations where a large number of setup requests are triggered at the same time. "GMPLS - Communication of Alarm Information", Lou Berger, 15-Sep-06, This document describes an extension to Generalized MPLS (Multi- Protocol Label Switching) signaling to support communication of alarm information. GMPLS signaling already supports the control of alarm reporting, but not the communication of alarm information. This document presents both a functional description and GMPLS-RSVP specifics of such an extension. This document also proposes modification of the RSVP ERROR_SPEC object. This document updates RFC 3473 "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" through the addition of new, optional protocol elements. It does not change, and is fully backward compatible with the procedures specified in RFC 3473. "RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", Jonathan Lang, 11-Oct-06, This document describes protocol specific procedures and extensions for Generalized Multi-Protocol Label Switching (GMPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Switched Path (LSP) recovery that denotes protection and restoration. A generic functional description of GMPLS recovery can be found in a companion document, RFC 4426. "GMPLS Based Segment Recovery", Lou Berger, 6-Oct-06, This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support label switched path (LSP) segment protection and restoration. These extensions are intended to complement and be consistent with the Extensions for End-to-End GMPLS-based Recovery. Implications and interactions with Fast Reroute are also addressed. This document also updates the handling of Notify_Request objects. "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", Adrian Farrel, 31-Aug-06, This document provides a framework for establishing and controlling Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Paths (LSPs) in multi-domain networks. 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 (ASs). "Extensions to GMPLS RSVP Graceful Restart", Arun Satyanarayana, Reshad Rahman, 25-Oct-05, This document describes extensions to the RSVP Graceful Restart mechanisms defined in RFC 3473. The extensions enable the recovery of RSVP signaling state based on the Path message last sent by the node being restarted. Previously defined Graceful Restart mechanisms, also called recovery from nodal faults, permit recovery of signaling state from adjacent nodes when the data plane has retained the associated forwarding state across a restart. These mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects. The presented extensions use the RSVP Hello extensions defined in RFC 3209, and extensions for state recovery on nodal faults defined in RFC 3473. With the presented extensions the restarting node can recover all previously transmitted Path state including the Explicit Route Object and the downstream (outgoing) interface identifiers. The extensions can also be used to recover signaling state after the restart of an ingress node. The extensions optionally support the use of Summary Refresh, defined in RFC 2961, to reduce the number of messages exchanged during the Recovery Phase when the restarting node has recovered signaling state locally for one or more LSPs. "A Per-domain path computation method for establishing Inter-domain Traffic Engineering (TE) Label Switched Paths (LSPs)", JP Vasseur, 30-Aug-06, This document specifies a per-domain path computation technique for establishing inter-domain Traffic Engineering (TE) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs). In this document a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems. Per-domain computation applies where the full path of an inter-domain TE LSP cannot be or is not determined at the ingress node of the TE LSP, and is not signaled across domain boundaries. This is most likely to arise owing to TE visibility limitations. The signaling message indicates the destination and nodes up to the next domain boundary. It may also indicate further domain boundaries or domain identifiers. The path through each domain, possibly including the choice of exit point from the domain, must be determined within the domain. "Use of Addresses in Generalized Multi-Protocol Label Switching (GMPLS) Networks", Kohei Shiomoto, 25-Oct-06, This document explains and clarifies the use of addresses in Generalized Multi-Protocol Label Switching (GMPLS) networks. The aim of this document is to facilitate and ensure better interworking of GMPLS-capable Label Switching Routers (LSRs) based on experience gained in deployments and interoperability testing and proper interpretation of published RFCs. The document specifies a proper approach for the interpretation and choice of address and identifier fields within GMPLS protocols and references specific control plane usage models. It also examines some common GMPLS Resource Reservation Protocol-Traffic Engineering (RSVP-TE) signaling message processing issues and recommends solutions. Finally, it discusses how to handle IPv6 sources and destinations in the MPLS and GMPLS TE (Traffic Engineering) MIB (Management Information Base) modules. "Routing extensions for discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) mesh membership", JP Vasseur, 5-Sep-06, The set up of a full mesh of Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSP) among a set of Label Switch Routers (LSR) is common deployment scenario of MPLS Traffic Engineering either for bandwidth optimization, bandwidth guarantees or fast rerouting with MPLS Fast Reroute. Such deployment may require the configuration of potentially a large number of TE LSPs (on the order of the square of the number LSRs). This document specifies IGP routing extensions for ISIS and OSPF so as to provide an automatic discovery of the set of LSRs members of a mesh in order to automate the creation of such mesh. "IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities", JP Vasseur, 21-Nov-06, It is highly desired in several cases, to take into account Traffic Engineering (TE) node capabilities during Multi Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered Label Switched Path (TE-LSP) selection, such as for instance the capability to act as a branch Label Switching Router (LSR) of a Point-To-MultiPoint (P2MP) LSP. This requires advertising these capabilities within the Interior Gateway Protocol (IGP). For that purpose, this document specifies Open Shortest Path First (OSPF) and Intermediate System-Intermediate System (IS-IS) traffic engineering extensions for the advertisement of control plane and data plane traffic engineering node capabilities. "Requirements for GMPLS-based multi-region and multi-layer networks (MRN/MLN)", Kohei Shiomoto, 23-Oct-06, Most of the initial efforts on Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability. The complexity raised by the control of such data planes is similar to that seen in classical IP/MPLS networks. By extending MPLS to support multiple switching technologies, GMPLS provides a comprehensive framework for the control of a multi- layered network of either a single switching technology or multiple switching technologies. In GMPLS, a switching technology domain defines a region, and a network of multiple switching types is referenced in this document as a multi-region network (MRN). When referring in general to a layered network, which may consist of either a single or multiple regions, this document uses the term, Multi-layer Network (MLN). This draft defines a framework for GMPLS based multi-region/multi-layer networks and lists a set of functional requirements. "Evaluation of existing GMPLS Protocols against Multi Layer and Multi Region Networks (MLN/MRN)", Jean-Louis Le Roux, 23-Oct-06, This document provides an evaluation of Generalized Multi-Protocol Label Switching (GMPLS) protocols and mechanisms against the requirements for Multi-Layer Networks (MLN) and Multi-Region Networks (MRN). In addition, this document identifies areas where additional protocol extensions or procedures are needed to satisfy these requirements, and provides guidelines for potential extensions. "Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in support of Calls", Dimitri Papadimitriou, Adrian Farrel, 14-Aug-06, In certain networking topologies, it may be advantageous to maintain associations between endpoints and key transit points to support an instance of a service. Such associations are known as Calls. A Call does not provide the actual connectivity for transmitting user traffic, but only builds a relationship by which subsequent Connections may be made. In Generalized MPLS (GMPLS) such Connections are known as Label Switched Paths (LSPs). This document specifies how GMPLS RSVP-TE signaling may be used and extended to support Calls. These mechanisms provide full and logical Call/Connection separation. The mechanisms proposed in this document are applicable to any environment (including multi-area), and for any type of interface: packet, layer-2, time-division multiplexed, lambda or fiber switching. "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", Kohei Shiomoto, 27-Oct-06, This document discusses topics related to hierarchical and stitched Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs). It describes extensions to allow an egress to identify that a bi-directional LSP will be used as a dynamically signaled Forwarding Adjacency LSP (FA-LSP) or Routing Adjacency (RA). In addition, the document also discusses the issue of how to indicate that an LSP should be advertised as a traffic engineering (TE) link into a different instance of the IGP and how to identify the instance that should be used. "Framework for MPLS-TE to GMPLS migration", Kohei Shiomoto, 26-Oct-06, The migration from Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) to Generalized MPLS (GMPLS) is the process of evolving an MPLS-TE control plane to a GMPLS control plane. An appropriate migration strategy can be selected based on various factors including the service provider's network deployment plan, customer demand, and operational policy. This document presents several migration models and strategies for migrating from MPLS-TE to GMPLS and notes that in the course of migration MPLS-TE and GMPLS devices or networks may coexist which may require interworking between MPLS-TE and GMPLS protocols. The applicability? of the interworking that is required is discussed as it appears to influence the choice of a migration strategy. "MEF Ethernet Traffic Parameters", Dimitri Papadimitriou, 25-Oct-06, This document described the Metro Ethernet Forum (MEF) - specific Ethernet Traffic Parameters as described in MEF.10 when using Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. "OSPFv2 Routing Protocols Extensions for ASON Routing", Dimitri Papadimitriou, 5-Oct-06, The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including SONET/SDH and Optical Transport Networks (OTNs). This document provides the extensions of the OSPFv2 Link State Routing Protocol to meet the routing requirements for an Automatically Switched Optical Network (ASON) as defined by ITU-T. "Graceful Shutdown in GMPLS Traffic Engineering Networks", Zafar Ali, 25-Oct-06, GMPLS-TE Graceful shutdown is a method for explicitly notifying the nodes in a Traffic Engineering (TE) enabled network that the TE capability on a link or on an entire Label Switching Router (LSR) is going to be disabled. GMPLS-TE graceful shutdown mechanisms are tailored towards addressing the planned outage in the network. This document provides requirements and protocol mechanisms so as to reduce/eliminate traffic disruption in the event of a planned shutdown of a network resource. These operations are equally applicable for both MPLS and its GMPLS extensions. "Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)", Greg Bernstein, 22-Oct-06, This document describes requirements for, and use of, the Generalized Multi-Protocol Label Switching (GMPLS) control plane in conjunction with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing mechanism and its companion Link Capacity Adjustment Scheme (LCAS) which can be used for hitless dynamic resizing of the inverse multiplex group. These techniques apply to the Optical Transport Network (OTN), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals. "Traffic Engineering Database Management Information Base in support of GMPLS", Thomas Nadeau, 13-Nov-06, This memo defines the Management Information Base (MIB) objects in order to manage traffic engineering database (TED) information with extension in support of Multi-protocol label switching (MPLS) as well as Generalized MPLS (GMPLS) for use with network management protocols. Cross Registry Information Service Protocol (crisp) --------------------------------------------------- "A Domain Availability Check (dchk) Registry Type for the Internet Registry Information Service (IRIS)", Andrew Newton, 5-Jun-06, This document describes a lightweight domain availability service using the IRIS framework and the data model of the IRIS Domain Registry service. "A Lightweight UDP Transfer Protocol for the the Internet Registry Information Service", Andrew Newton, 25-May-06, This document describes a lightweight UDP transfer protocol for the Internet Registry Information Service (IRIS). This transfer protocol uses a single packet for every request and response, and optionally employs compression over the contents of the packet. "A Common Schema for Internet Registry Information Service Transfer Protocols", Andrew Newton, 9-Feb-06, This document describes an XML Schema for use by Internet Registry Information Service (IRIS) application transfer protocols that share common characteristics. It describes common information about the transfer protocol, such as version, supported extensions, and supported security mechanisms. "XML Pipelining with Chunks for the Information Registry Information Service", Andrew Newton, 25-May-06, This document describes a simple TCP transfer protocol for the Internet Registry Information Service (IRIS). Data is transfered between clients and servers using chunks to achieve pipelining. "Domain Registry Version 2 for the Internet Registry Information Service", Andrew Newton, Frederico Neves, 26-May-06, This document describes version 2 of the domain registration information schema for IRIS. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by domain registries and registrars. Datagram Congestion Control Protocol (dccp) ------------------------------------------- "TCP Friendly Rate Control (TFRC): the Small-Packet (SP) Variant", Sally Floyd, Eddie Kohler, 22-Nov-06, This document proposes a mechanism for further experimentation, but not for widespread deployment at this time in the global Internet. TCP-Friendly Rate Control (TFRC) is a congestion control mechanism for unicast flows operating in a best-effort Internet environment [RFC3448]. TFRC was intended for applications that use a fixed packet size, and was designed to be reasonably fair when competing for bandwidth with TCP connections using the same packet size. This document proposes TFRC-SP, a Small-Packet (SP) variant of TFRC, that is designed for applications that send small packets. The design goal for TFRC-SP is to achieve the same bandwidth in bps (bits per second) as a TCP flow using packets of up to 1500 bytes. TFRC-SP enforces a minimum interval of 10 ms between data packets, to prevent a single flow from sending small packets arbitrarily frequently. Flows using TFRC-SP compete reasonably fairly with large-packet TCP and TFRC flows in environments where large-packet flows and small- packet flows experience similar packet drop rates. However, in environments where small-packet flows experience lower packet drop rates than large-packet flows (e.g., with Drop-Tail queues in units of bytes), TFRC-SP can receive considerably more than its share of the bandwidth. "Faster Restart for TCP Friendly Rate Control (TFRC)", Eddie Kohler, Sally Floyd, 27-Jun-06, TCP-Friendly Rate Control (TFRC) is a congestion control mechanism for unicast flows operating in a best-effort Internet environment [RFC3448]. This document introduces Faster Restart, an optional mechanism for safely improving the behavior of interactive flows that use TFRC. Faster Restart is proposed for use with both the default TFRC and with the VoIP variant of TFRC. "RTP and the Datagram Congestion Control Protocol (DCCP)", Colin Perkins, 16-Nov-06, The Real-time Transport Protocol (RTP) is a widely used transport for real-time multimedia on IP networks. The Datagram Congestion Control Protocol (DCCP) is a newly defined transport protocol that provides desirable services for real-time applications. This memo specifies a mapping of RTP onto DCCP, along with associated signalling, such that real-time applications can make use of the services provided by DCCP. "TCP Friendly Rate Control (TFRC): Protocol Specification", Mark Handley, 16-Oct-06, This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best- effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as telephony or streaming media where a relatively smooth sending rate is of importance. Dynamic Host Configuration (dhc) -------------------------------- "DHCP Server Identifier Override Suboption", Richard Johnson, 24-Oct-06, This memo defines a new suboption of the DHCP relay information option which allows the DHCP relay to specify a new value for the Server Identifier option, which is inserted by the DHCP Server. This allows the DHCP relay to act as the actual DHCP server such that RENEW DHCPREQUESTs will come to the relay instead of going to the server directly. This gives the relay the opportunity to include the Relay Agent option with appropriate suboptions even on DHCP RENEW messages. "Subnet Allocation Option", Richard Johnson, 23-Oct-06, This document defines a new DHCP option which is passed between the DHCP Client and the DHCP Server to request dynamic allocation of a subnet, give specifications of subnet(s) allocated, and report usage statistics. This memo documents the current usage of the option in agreement with RFC-3942[7], which declares that any pre-existing usages of option numbers in the range 128 - 223 should be documented and the working group will try to officially assign those numbers to those options. "Implementation Issues with RFC 2131, "Dynamic Host Configuration Protocol (DHCPv4)"", Robert Stevens, Richard Barr Hibbs, 16-Jun-06, This memo identifies implementation issues with RFC 2131, "Dynamic Host Configuration Protocol," reported by a number of implementers, assesses the severity of the problem, then proposes changes to RFC 2131 intended to overcome the issues. This is intended for use as the basis for discussion of RFC 2131 before it is proposed for Internet Standard status. "Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis", Richard Barr Hibbs, 15-Jun-06, DHCPv4 (RFC 2131) is a stable, widely used protocol for configuration of host systems in a TCP/IPv4 network. It did not provide for authentication of clients and servers, nor did it provide for data confidentiality. This is reflected in the original "Security Considerations" section of RFC 2131, which identifies a few threats and leaves development of any defenses against those threats to future work. In about 1995, DHCP security began to attract attention from the Internet community, eventually resulting in the publication of RFC 3118 in 2001. Although RFC 3118 was a mandatory prerequisite for the DHCPv4 Reconfigure Extension, RFC 3203, it has had no known usage by any commercial or private implementation since its adoption. The DHC Working Group adopted a work item for 2003 to review and modify or replace RFC 3118 to afford a workable, easily deployed security mechanism for DHCPv4. This memo provides a threat analysis of the Dynamic Host Configuration Protocol for Ipv4 (DHCPv4) for use both as RFC 2131 advances from Draft Standard to Full Standard and to support our chartered work improving the acceptance and deployment of RFC 3118. "DHCP Option for Proxy Server Configuration", Senthil Balasubramanian, 10-Jul-06, This document defines a new Dynamic Host Configuration Protocol DHCP) option, which can be used to configure the TCP/IP host's Proxy Server configuration for standard protocols like HTTP,FTP, NNTP,SOCKS, Gopher, SLL and etc. Proxy Server provides controlled and efficient access to the Internet by access control mechanism for different types of user requests and caching frequently accessed information (Web pages and possibly files that might have been downloaded using FTP and other protocols). "Clarifications on DHCPv6 Authentication", Tatsuya Jinmei, 27-Jun-06, This document describes issues about the authentication mechanism of the Dynamic Host Configuration Protocol for IP version 6 that were identified from implementation experiences. It also tries to propose resolutions to some of the issues. "DHCP options for PANA Authentication Agents", Lionel Morand, 12-Sep-06, This document defines new DHCPv4 and DHCPv6 options that contain a list of IP addresses to locate one or more of PANA Authentication Agents (PAA). This is one of the many methods that a PANA Client (PaC) can use to locate PANA Authentication Agents (PAA). "Domain Suffix Option for DHCPv6", Renxiang Yan, 9-Jun-06, This document describes a new option for DHCPv6 (DHCP for IPv6) that provides a mechanism for specifying a domain name suffix. "DHCPv6 Relay Agent Assignment Notification (RAAN) Option", Ralph Droms, 10-Aug-06, The DHCP Relay Agent Assignment Notification (RAAN) option is sent from a DHCP server to a DHCP relay agent to inform the relay agent of IPv6 addresses that have been assigned or IPv6 prefixes that have been delegated to DHCP clients. "A Timezone Option for DHCP", Eliot Lear, Paul Eggert, 21-Aug-06, Two common ways to communicate timezone information are POSIX 1003.1 timezone strings and timezone database names. This memo specifies DHCP options each of those methods. The DHCP v4 time offset option is deprecated. "DHCPv4 Relay Agent Flags Suboption", Kim Kinnear, 24-Sep-06, This memo defines a new suboption of the DHCP relay agent information option that allows the DHCP relay to specify flags for the forwarded packet. One flag is defined to indicate whether the DHCP relay received the packet via a unicast or broadcast packet. This information may be used by the DHCP server to better serve clients based on whether their request was originally broadcast or unicast. "PXELINUX Use of 'Site Local' Option Space", David Hankins, 15-Aug-06, This document is in response to RFC3942 [1], and describes the use by PXELINUX of some DHCP Option Codes [2] numbering from 208-211. These codes were designated 'Site Local' [3] prior to this action, and are redefined by RFC3942 as available for allocation as standard DHCP Options. "Rebind Capability in DHCPv6 Reconfigure Messages", D Evans, Ralph Droms, 20-Nov-06, This document updtaes RFC 3315 to allow the Rebind message type to appear in the Reconfigure Message option of a Reconfigure message, which allows DHCPv6 servers to instruct clients to perform a Rebind operation as well as a Renew operation. "DHCPv6 Leasequery", John Jason Brzozowski, 22-Aug-06, This document specifies leasequery for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) which can be used as a means to obtain lease information about DHCPv6 clients from a DHCPv6 server. This document specifies the scope of data that can be retrieved as well as both DHCPv6 leasequery requestor and server behavior. This document extends DHCPv6. "DHCPv6 Relay Agent Echo Request Option", Shengyou Zeng, 25-Oct-06, This memo defines a Relay Agent Echo Request option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The option allows a DHCPv6 relay agent to request a list of relay agent options that the server echoes back to the relay agent. "DHCPv6 Server Reply Sequence Number Option", Bernie Volz, Ralph Droms, 15-Nov-06, This memo defines the Server Reply Sequence Number option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). This option is sent from a DHCPv6 server to a DHCPv6 relay agent to allow a relay agent to detect proper sequencing of Relay-Reply messages that could be delivered out of order. Diameter Maintenance and Extensions (dime) ------------------------------------------ "Diameter Mobile IPv6: HA-to-AAAH support", Julien Bournelle, 25-Oct-06, In a Mobile IPv6 deployment the need for an interaction between the Home Agent, the AAA infrastructure of the Mobile Service Provider (MSP) and the Mobility Service Authorizer (MSA) has been identified. This document describes a new Diameter application, called Mobile IPv6 Authorization Application, used in conjunction with the Diameter EAP Application is used to perform the necessary AAA functions before executing Mobile IPv6 services. This document also specifies the role of the Home Agent as part of the AAA infrastructure supporting the Diameter Mobile IPv6 Authorization Application. "The NAS - HAAA Interface for MIPv6 Bootstrapping", Jouni Korhonen, 25-Oct-06, A Mobile IPv6 node requires a home agent address, a home address, and IPsec security association with its home agent before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these parameters are statically configured. Ongoing Mobile IPv6 bootstrapping work aims to make this information dynamically available to the mobile node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing authentication, authorization and accounting infrastructure. This document describes the usage of Diameter to facilitate Mobile IPv6 bootstrapping for the NAS - HAAA interface. Domain Keys Identified Mail (dkim) ---------------------------------- "DomainKeys Identified Mail (DKIM) Signatures", Eric Allman, 22-Oct-06, DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transfer Agents (MTAs) or Mail User Agents (MUAs). The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus protecting message signer identity and the integrity of the messages they convey while retaining the functionality of Internet email as it is known today. Protection of email identity may assist in the global control of "spam" and "phishing". "DomainKeys Identified Mail (DKIM) Service Overview", Tony Hansen, 25-Oct-06, DomainKeys Identified Mail (DKIM) associates a "responsible" identity with a message and provides a means of verifying that the association is legitimate.[I-D.ietf-dkim-base]. DKIM defines a domain-level authentication framework for email using public-key cryptography and key server technology. This permits verifying the source or intermediary for a message, as well as the contents of messages. The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus proving and protecting the identity associated with the message and the integrity of the messages itself, while retaining the functionality of Internet email as it is known today. Such protection of email identity, may assist in the global control of "spam" and "phishing". This document provides an overview of DKIM and describes how it can fit into a messaging service, how it relates to other IETF message signature technologies. It also includes implementation and migration considerations. "Requirements for a DKIM Signing Practices Protocol", Michael Thomas, 20-Oct-06, DomainKeys Identified Mail [DKIM] [I-D.ietf-dkim-base] provides a cryptographic mechanism for domains to assert responsibility for the messages they handle. A related mechanism would allow an administrator to publish various statements about their DKIM signing practices. This draft defines the requirement for this mechanism. Detecting Network Attachment (dna) ---------------------------------- "Link-layer Event Notifications for Detecting Network Attachments", Alper Yegin, 8-Nov-06, Certain network access technologies are capable of providing various types of link-layer status information to IP. Link-layer event notifications can help IP expeditiously detect configuration changes. This document provides a non-exhaustive catalogue of information available from well-known access technologies. "Fast Router Discovery with L2 support", JinHyeock Choi, 30-Aug-06, For efficient Detecting Network Attachment (DNA), a host should quickly receive a Router Advertisement (RA) message upon a new link- layer connection. This draft presents a quick RA acquisition scheme with the support of a link-layer entity, Point of Attachment (PoA). Upon a new network attachment, the PoA may either trigger an Access Router (AR) to immediately send an unicast RA, "RA Triggering" or send such an RA for itself, "RA Proxying". We may put "RA Triggering" or "RA Proxying" functionality on a PoA to get the optimized result without IPv6 standard change. "Detecting Network Attachment in IPv6 Networks (DNAv6)", James Kempf, 24-Oct-06, Efficient detection of network attachment in IPv6 needs the following three components: a method for hosts to detect link change in the presence of unmodified (non-DNAv6) routers, a method for the host to query routers on the link to identify the link (Link Identification) and a method for the routers on the link to consistently respond to such a query with minimal delay (Fast RA). Solving the link identification based strictly on RFC 2461 is difficult because of the flexibility offered to routers in terms of prefixes advertised in a router advertisement (RA) message. Similarly, the random delay in responding to router solicitation messages imposed by RFC 2461 makes it difficult to receive an RA quickly. In this memo, a mechanism that requires the hosts to monitor all the prefixes advertised on the link and use it for link identification in the presence of non-DNAv6 routers is presented. A more efficient link-identification mechanism requiring the DNAv6 routers to monitor the link for advertised prefixes to assist the hosts in link identification combined with a fast router advertisement mechanism that selects the order of response for the router deterministicly is also presented. "Detecting Network Attachment in IPv6 - Network Deployment Considerations", Sathya Narayanan, 6-Jun-06, Hosts experiencing rapid link-layer changes may require to do configuration change detection procedures more frequently than traditional fixed hosts. This document describes practices available to network deployers in order to support such hosts in Detecting Network Attachment in IPv6 networks. DNS Extensions (dnsext) ----------------------- "Link-local Multicast Name Resolution (LLMNR)", Bernard Aboba, 21-Aug-06, The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. "DNSSEC Opt-In", David Blacka, 22-Jun-06, In the DNS security extensions (DNSSEC), delegations to unsigned subzones are cryptographically secured. Maintaining this cryptography is not always practical or necessary. This document describes an experimental "Opt-In" model that allows administrators to omit this cryptography and manage the cost of adopting DNSSEC with large zones. "DSA Keying and Signature Information in the DNS", Donald Eastlake, 24-Oct-06, The standard method of encoding US Government Digital Signature Algorithm keying and signature information for use in the Domain Name System is specified. "Storage of Diffie-Hellman Keying Information in the DNS", Donald Eastlake, 24-Oct-06, The standard method for encoding Diffie-Hellman keys in the Domain Name System is specified. "Evaluating DNSSEC Transition Mechanisms", Roy Arends, 29-Jun-06, This document collects and summarizes different proposals for alternative and additional strategies for authenticated denial in DNS responses, evaluates these proposals and gives a recommendation for a way forward. It is a snapshot of the DNSEXT working group discussion of June 2004. "Requirements related to DNSSEC Signed Proof of Non-Existence", Rip Loomis, Ben Laurie, 19-Jun-06, DNSSEC-bis uses the NSEC record to provide authenticated denial of existence of RRsets. NSEC also has the side-effect of permitting zone enumeration, even if zone transfers have been forbidden. Because some see this as a problem, this document has been assembled to detail the possible requirements for denial of existence A/K/A signed proof of non-existence. "Automated Updates of DNSSEC Trust Anchors", Michael StJohns, 8-Sep-06, This document describes a means for automated, authenticated and authorized updating of DNSSEC "trust anchors". The method provides protection against single key compromise of a key in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor. This mechanism will require changes to resolver management behavior (but not resolver resolution behavior), and the addition of a single flag bit to the DNSKEY record. "DNSSEC Hashed Authenticated Denial of Existence", Ben Laurie, 25-Oct-06, The Domain Name System Security Extensions (DNSSEC) introduced the NSEC resource record (RR) for authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. "DNSSEC Experiments", David Blacka, 10-Apr-06, This document describes a methodology for deploying alternate, non- backwards-compatible, DNSSEC methodologies in an experimental fashion without disrupting the deployment of standard DNSSEC. "Clarifications and Implementation Notes for DNSSECbis", Rob Austein, Samuel Weiler, 25-Oct-06, This document is a collection of minor technical clarifications to the DNSSECbis document set. It is meant to serve as a resource to implementors as well as an interim repository of DNSSECbis errata. An index sorted by the section of DNSSECbis being clarified. A list of proposed protocol changes being made in other documents, such as [RFC4470] and [I-D.ietf-dnsext-nsec3]. This document would not make those changes, merely provide an index into the documents that are making changes. "Domain Name System (DNS) IANA Considerations", Donald Eastlake 3rd, 29-Jun-06, Internet Assigned Number Authority (IANA) parameter assignment considerations are specified for the allocation of Domain Name System (DNS) Classes, RR Types, operation codes, error codes, RR header bits, and AFSDB subtypes. "DNS Name Server Identifier Option (NSID)", Rob Austein, 22-Jun-06, With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a single IP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query. While existing ad-hoc mechanism allow an operator to send follow-up queries when it is necessary to debug such a configuration, the only completely reliable way to obtain the identity of the name server which responded is to have the name server include this information in the response itself. This note defines a protocol extension to support this functionality. "Requirements related to DNSSEC Trust Anchor Rollover", Steve Crocker, 25-Sep-06, Every DNS security-aware resolver must have at least one Trust Anchor to use as the basis for validating responses from DNS signed zones. For various reasons, most DNS security-aware resolvers are expected to have several Trust Anchors. For some operations, manual monitoring and updating of Trust Anchors may be feasible but many operations will require automated methods for updating Trust Anchors in their security-aware resolvers. This document identifies the requirements that must be met by an automated DNS Trust Anchor rollover solution for security-aware DNS resolvers. "Update to DNAME Redirection", Scott Rose, Wouter Wijngaards, 27-Sep-06, The DNAME record provides redirection for a sub-tree of the domain name tree in the DNS system. That is, all names that end with a particular suffix are redirected to another part of the DNS. Changes to the DNS protocol since DNAME's introduction has lead to a need to clarify several issues in the DNAME specification. These issues are discussed in this document. Domain Name System Operations (dnsop) ------------------------------------- "Requirements for a Mechanism Identifying a Name Server Instance", David Conrad, Suzanne Woolf, 28-Jun-06, With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a single IP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query. A standardized mechanism to determine the identity of a name server responding to a particular query would be useful, particularly as a diagnostic aid for administrators. Existing ad hoc mechanisms for addressing this need have some shortcomings, not the least of which is the lack of prior analysis of exactly how such a mechanism should be designed and deployed. This document describes the existing convention used in some widely deployed implementations of the DNS protocol, including advantages and disadvantages, and discusses some attributes of an improved mechanism. "DNS Referral Response Size Issues", Paul Vixie, Akihiro Kato, 8-Aug-06, With a mandated default minimum maximum message size of 512 octets, the DNS protocol presents some special problems for zones wishing to expose a moderate or high number of authority servers (NS RRs). This document explains the operational issues caused by, or related to this response size limit, and suggests ways to optimize the use of this limited space. Guidance is offered to DNS server implementors and to DNS zone operators. "Preventing Use of Recursive Nameservers in Reflector Attacks", Joao Luis Damas, Frederico Neves, 19-Sep-06, This document describes the use of default configured recursive nameservers as reflectors on DOS attacks. Recommended configuration as measures to mitigate the attack are given. "Locally-served Zones", Mark Andrews, 20-Jun-06, Practice has shown that there are a number of DNS zones all iterative resolvers and recursive nameservers should, unless configured otherwise, automatically serve. RFC 4193 already specifies that this should occur for D.F.IP6.ARPA. This document extends the practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space and other well known zones with similar usage constraints. "Considerations for the use of DNS Reverse Mapping", Daniel Senie, Andrew Sullivan, 12-Sep-06, 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. The goal of this document is to encourage proper deployment of address to name mappings, and provide guidance for their use. Email Address Internationalization (eai) ---------------------------------------- "SMTP extension for internationalized email address", Jiankang Yao, Wei Mao, 25-Oct-06, Internationalized email address includes two parts, the local part and the domain part. The ways email addresses are used by protocols are different from the ways domain names are used. The most critical difference is that emails are delivered through a chain of peering clients and servers while domain names are resolved by name servers by looking up their own tables. In addition to this, email transport protocols SMTP and ESMTP provide a negotiation mechanism through which clients can make decisions for further processing. So internationalized email address is different from the internationalized domain name (IDN). It can be solved by exploiting the negotiation mechanism while IDN can not use the negotiation mechanism. So internationalized email address SHOULD be solved in the mail transport-level using the negotiation mechanism, which is an architecturally desirable approach. This document specifies the use of SMTP extension for internationalized email address delivery. It also mentions the backward compatible mechanism for downgrade procedure, as specified in an associated specification. The protocol proposed here is MTA-level solution which is feasible, architecturally more elegant, and not as difficult to deploy in relevant communities. "UTF-8 Mail: Scenarios", Harald Alvestrand, 29-Jun-06, This document describes some scenarios in which one can imagine internationalized email addresses deployed, and tries to draw some conclusions about what's acceptable and what's not for users in those scenarios. One possible set of extensions that can work in these scenarios is those described in the UTF8MAIL extension documents. "Overview and Framework for Internationalized Email", John Klensin, YangWoo Ko, 10-Nov-06, Full use of electronic mail throughout the world requires that people be able to use their own names, written correctly in their own languages and scripts, as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. "Downgrading mechanism for Email Address Internationalization (EAI)", Yoshiro Yoneya, Kazunori Fujiwara, 18-Aug-06, Traditional mail systems handle only US-ASCII characters in SMTP envelope and mail headers. The Email Address Internationalization (EAI) is implemented by allowing UTF-8 characters in SMTP envelope and mail headers. To deliver Non-ASCII mail address through EAI incompliant environment, some sort of converting mechanism (i.e. downgrading) is required. This document describes requirements for downgrading, SMTP Downgrading, SMTP DATA/Header Downgrading and implementation consideration "IMAP Support for UTF-8", Pete Resnick, Chris Newman, 31-May-06, This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support unencoded international characters in user names, mail addresses and message headers. This is an early draft and intended as a framework for discussion. Please do not deploy implementations of this draft. "Internationalized Email Headers", Jeff Yeh, 6-Nov-06, Full internationalization of electronic mail requires not only the capability to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and information based on them in mail header fields. This document specifies the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field bodies. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. "Mailing Lists and Internationalized Email Addresses", Edmon Chung, 22-Jun-06, This document describes considerations for mailing-lists with the introduction of internationalized email addressing capabilities. Different scenarios involving interaction between mailing-lists and internationalized email addresses are examined. Furthermore, mailing-list header fields will be discussed. "POP3 Support for UTF-8", Chris Newman, 28-Jun-06, This specification extends the Post Office Protocol version 3 (POP3) to support un-encoded international characters in user names, mail addresses, message headers, and protocol-level textual error strings. Extensible Authentication Protocol (eap) ---------------------------------------- "Extensible Authentication Protocol (EAP) Key Management Framework", Bernard Aboba, 25-Oct-06, The Extensible Authentication Protocol (EAP), defined in [RFC3748], enables extensible network access authentication. This document provides a framework for the transport and usage of keying material generated by EAP authentication algorithms, known as "methods". It also specifies the EAP key hierarchy. "Network Discovery and Selection Problem", Jari Arkko, 25-Oct-06, The so called network discovery and selection problem affects network access, particularly in the presence of multiple available wireless accesses and roaming. This problem has been the subject of discussions in various standards bodies. This document summarizes the discussion held about this problem in the Extensible Authentication Protocol (EAP) working group at the IETF. The problem is defined and divided into subproblems, and some constraints for possible solutions are outlined. The document also provides a discussion of the limitations of certain classes of solution, including some that have been previously defined. Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- "Requirements for Emergency Context Resolution with Internet Technologies", Henning Schulzrinne, Roger Marshall, 28-Aug-06, This document defines terminology and enumerates requirements for the context resolution of emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end-to-end. "A Uniform Resource Name (URN) for Services", Henning Schulzrinne, 28-Aug-06, The content of many communication services depends on the context, such as the user's location. We describe a 'service' URN that allows to identify context-dependent services that can be resolved in a distributed manner. "Security Threats and Requirements for Emergency Call Marking and Mapping", Tom Taylor, 12-Jul-06, This document reviews the security threats associated with: o the marking of signalling messages to indicate that they are related to an emergency; and o the process of mapping from locations to Universal Resource Identifiers (URIs) pointing to Public Safety Answering Points (PSAPs). This mapping occurs as part of the process of routing emergency calls through the IP network. Based on the identified threats, this document establishes a set of security requirements for the mapping protocol and for the handling of emergency-marked calls. "LoST: A Location-to-Service Translation Protocol", Ted Hardie, 24-Oct-06, This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate PSAP for emergency services. "Location-to-URL Mapping Architecture and Framework", Henning Schulzrinne, 7-Aug-06, This document describes an architecture for a global, scalable, resilient and administratively distributed system for mapping geographic location information to URLs. The architecture generalizes well-known approaches found in hierarchical lookup systems such as DNS. The architecture does not depend on using a specific protocol, but does require that protocols can summarize the coverage region of a node. "Best Current Practice for Communications Services in support of Emergency Calling", Brian Rosen, James Polk, 18-Oct-06, Requesting help in an emergency using a communications device such as a telephone or mobile is an accepted practice in most of the world. As communications devices increasingly utilize the Internet to interconnect and communicate, users will continue to expect to use such devices to request help, regardless of whether or not they communicate using IP. The emergency response community will have to upgrade their facilities to support the wider range of communications services, but cannot be expected to handle wide variation in device and service capability. The IETF has several efforts targeted at standardizing various aspects of placing emergency calls. This memo describes best current practice on how devices and services should use such standards to reliably make emergency calls "Framework for Emergency Calling in Internet Multimedia", Brian Rosen, 26-Oct-06, Summoning emergency help by the public is a core feature of telephone networks. This document describes a framework of how various IETF protocols and mechanisms are combined to place emergency calls. This includes how these calls are routed to the correct Public Safety Answering Point (PSAP) based on the physical location of the caller, while providing the call taker the necessary information to dispatch a first responder to that location. This document explains how location mapping, call identification and end system behavior are combined to allow multimedia emergency calls. It describes at a high level how the pieces (recognizing a call as an emergency call, marking it as such, determining the location of the caller, routing the call based on location) go together, and references the Internet standards that define the details of these mechanisms. Electronic Data Interchange-Internet Integration (ediint) --------------------------------------------------------- "FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet", Terry Harding, Richard Scott, 24-Jan-06, This Applicability Statement (AS) describes how to exchange structured business data securely using the File Transfer Protocol (FTP) for XML, Binary, Electronic Data Interchange (EDI - ANSI X12 or UN/EDIFACT), or other data used for business-to-business data interchange for which MIME packaging can be accomplished using standard MIME content-types. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax (S/MIME) security body parts. Authenticated acknowledgements employ multipart/signed replies to the original message. EAP Method Update (emu) ----------------------- "The EAP TLS Authentication Protocol", Dan Simon, Bernard Aboba, 9-Nov-06, The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. Transport Level Security (TLS) provides for mutual authentication, integrity- protected ciphersuite negotiation and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation. "EAP Generalized Pre-Shared Key (EAP-GPSK)", Charles Clancy, Hannes Tschofenig, 7-Nov-06, This Internet Draft defines an Extensible Authentication Protocol method called EAP Generalized Pre-Shared Key (EAP-GPSK). This method is a lightweight shared-key authentication protocol supporting mutual authentication and key derivation. Telephone Number Mapping (enum) ------------------------------- "ENUM Implementation Issues and Experiences", Lawrence Conroy, Kazunori Fujiwara, 29-Jun-06, This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it is advisory, and produced as a help to others in reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol. "IANA Registration for Enumservice VOID", Richard Stastny, 21-Oct-05, This document registers the Enumservice 'void' using the URI schemes 'mailto:' and 'http:' as per the IANA registration process defined in the ENUM specification, RFC3761. 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 assigned for communications service. When such an indication is provided, an ENUM client can detect calls that will fail "early". "ENUM Validation Information Mapping for the Extensible Provisioning Protocol", Bernie Hoeneisen, 15-Feb-06, This document describes an Extensible Provisioning Protocol (EPP) extension framework for mapping information about the validation process that has been applied for the E.164 number (or number range), which the E.164 Number Mapping (ENUM) domain name is based on. Specified in the Extensible Markup Language (XML), this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of ENUM domain names. "ENUM Validation Architecture", Alex Mayrhofer, Bernie Hoeneisen, 6-Sep-06, An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes validation requirements and a high level architecture for an ENUM validation infrastructure. "ENUM Validation Token Format Definition", Otmar Lendl, 27-Feb-06, An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes an signed XML data format -- the Validation Token -- with which Validation Entities can convey successful completion of a validation procedure in a secure fashion. "IANA Registration for an Enumservice Containing PSTN Signaling Information", Jason Livingood, Richard Shockey, 7-Aug-06, This document registers the Enumservice type "pstn" and subtype "tel" using the URI scheme 'tel', as well as the subtype " sip" using the URI scheme 'sip' as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice is used to facilitate the routing of telephone calls in those countries where Number Portability exists. "IANA Registration for vCard Enumservice", Alexander Mayrhofer, 15-Nov-06, This memo registers the Enumservice "vCard" with three subtypes (empty subtype, "xml", "rdf") using the URI schemes "http" and "https". This Enumservice is to be used to refer from an ENUM domain name to a vCard instance describing the user of the respective E.164 number. Information gathered from those vCards could be used before, during or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before picking up the call. "IANA Registration for IAX Enumservice", Ed Guy, 25-Oct-06, This document registers the IAX2 (Inter-Asterisk eXchange Version 2) Enumservice using the URI scheme 'iax2:' as per the IANA registration process defined in the ENUM specification RFC3761. "Guide and Template for IANA Registrations of Enumervices", Jason Livingood, 25-Oct-06, This document provides a guide to and template for the creation of new IANA registration of ENUM services. It is also to be used for updates of existing IANA registrations. "Infrastrucure ENUM Requirements", Steven Lind, Penn Pfautz, 8-Aug-06, This document provides requirements for "infrastructure" or "carrier" ENUM (E.164 Number Mapping), defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP (Voice over IP.) "A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services", Rohan Mahy, 22-Jun-06, This document registers a Telephone Number Mapping (ENUM) service for Instant Messaging (IM). Specifically, this document focuses on provisioning 'im:' URIs in ENUM. "A Telephone Number Mapping (ENUM) Service Registration for Internet Calendaring Services", Rohan Mahy, 6-Jul-06, This document registers a Telephone Number Mapping (ENUM) service for Internet Calendaring Services. Specifically, this document focuses on provisioning 'mailto:' (iMIP) and 'http:' (CalDAV) URIs in ENUM. "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM", Jason Livingood, 15-Nov-06, This document defines a use case as well as a proposal for a parallel namespace to “e164.arpa” as defined in RFC3761, to be used for Infrastructure ENUM purposes. "IANA Registration for an Enumservice Calling Name Delivery (CNAM) Information and IANA Registration for Media type 'application/cnam'", Richard Shockey, 27-Sep-06, This document registers the Enumservice 'pstn' and subtype 'cnam' using the URI scheme 'data:' as per the IANA registration process defined in the ENUM specification, RFC 3761 and registers a new media type application/cnam. This data is used to facilitate the transfer of Calling Name Delivery (CNAM) data for calls that originate on the Public Switched Telephone Network (PSTN) that may be displayed on VoIP or other Real-time Client User Agents (CUA). "The ENUM Branch Location Record", Otmar Lendl, 2-Aug-06, This documents defines the ENUM Branch Location record (EBL) which is used to indicate where the ENUM tree for special ENUM application is located. The primary application for the EBL record is to provide a temporary solution for the infrastructure ENUM tree location. "Combined User and Infrastructure ENUM in the e164.arpa tree", Michael Haberler, Richard Stastny, 22-Oct-06, This memo defines an interim solution for Infrastructure ENUM to allow a combined User and Infrastructure ENUM implementation in e164.arpa as a national choice until the long-term solution is approved. This interim solution will be deprecated after deployment of the long-term solution. "ENUM Requirement for EDNS0 Support", Jim Reid, Lawrence Conroy, 6-Sep-06, Support for EDNS0 (Extension Mechanisms for DNS) is mandated in this document for DNS entities querying for or serving NAPTR records. In general those entities will be supporting ENUM resolution. This requirement is needed because DNS responses to ENUM-related queries generally return large RRSets. Without EDNS0 support these lookups would result in truncated responses and repeated queries over TCP transport. That has a severe impact on DNS server load and on the latency of those queries. This document adds an operational requirement to use of the protocol standardised in RFC 3761. "The Uniform Resource Identifier (URI) DNS Resource Record", Patrik Faltstrom, Olaf Kolkman, 28-Sep-06, This document defines a new DNS resource record, called the Uniform Resource Identifier (URI) RR, for publishing mappings from hostnames to URIs. "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", Patrik Faltstrom, 18-Oct-06, This document discusses the use of the Domain Name System (DNS) for storage of E.164 [E164] numbers, and resolving those to URIs that can be used for (for example) call setup. This include how DNS can be used for identifying available services connected to one E.164 number. It obsoletes RFC 3761 [RFC3761]. This version of the document (00) is not more than the start of a discussion for detailed changes. FEC Framework (fecframe) ------------------------ "FECFRAME requirements", Mark Watson, 22-Oct-06, This document defines requirements for a "FEC Framework" to be defined by the IETF FECFRAME working group. The object of this group is primarily to develop specifications for using forward error correction (FEC) codes with applications in the Internet to provide protection against packet loss. Forwarding and Control Element Separation (forces) -------------------------------------------------- "ForCES Applicability Statement", Alan Crouch, 12-Jul-06, The ForCES protocol defines a standard framework and mechanism for the interconnection between Control Elements and Forwarding Elements in IP routers and similar devices. In this document we describe the applicability of the ForCES model and protocol. We provide example deployment scenarios and functionality, as well as document applications that would be inappropriate for ForCES. "ForCES Forwarding Element Model", Joel Halpern, Ellen Deleganes, 5-Oct-06, This document defines the forwarding element (FE) model used in the Forwarding and Control Element Separation (ForCES) protocol. The model represents the capabilities, state and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly. More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected. This FE model is intended to satisfy the model requirements specified in the ForCES requirements draft, RFC 3564 [1]. "ForCES Protocol Specification", Avri Doria, 24-Mar-06, 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. "TCP/IP based TML (Transport Mapping Layer) for ForCES protocol", Jon Maloy, 13-Jul-06, This document defines the IP based TML (Transport Mapping Layer) for the ForCES protocol. It explains the rationale for choosing the transport protocols and also describes how this TML addresses all the requirements described in the Forces [3] requirements and ForCES protocol [5] document. "ForCES MIB", Robert HAAS, 28-Jul-06, 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). The ForCES working group is defining a protocol to allow a Control Element (CE) to control the behavior of a Forwarding Element (FE). Extensions to FTP (ftpext) -------------------------- "Extensions to FTP", Robert Elz, Paul Hethmon, 23-Sep-02, This document specifies new FTP commands to obtain listings of remote directories in a defined format, and to permit restarts of interrupted data transfers in STREAM mode. It allows character sets other than US-ASCII, and also defines an optional virtual file storage structure. Geographic Location/Privacy (geopriv) ------------------------------------- "A Document Format for Expressing Privacy Preferences for Location Information", Henning Schulzrinne, 13-Feb-06, This document defines an authorization policy language for controling access to location information. It extends the authorization framework of the common policy markup language to provide location- specific access control. "Common Policy: A Document Format for Expressing Privacy Preferences", Henning Schulzrinne, 10-Aug-06, This document defines a framework for authorization policies controlling access to application specific data. This framework combines common location- and presence-specific authorization aspects. An XML schema specifies the language in which common policy rules are represented. The common policy framework can be extended to other application domains. "Carrying Location Objects in RADIUS", Hannes Tschofenig, 28-Sep-06, This document describes RADIUS attributes for conveying access network ownership and location information based on a civic and geospatial location format. The distribution of location information is a privacy sensitive task. Dealing with mechanisms to preserve the user's privacy is important and addressed in this document. "GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations", Hannes Tschofenig, 25-Oct-06, The Presence Information Data Format Location Object (PIDF-LO) specification provides a flexible and versatile means to represent location information. There are, however, circumstances that arise when information needs to be constrained in how it is represented so that the number of options that need to be implemented in order to make use of it are reduced. There is growing interest in being able to use location information contained in a PIDF-LO for routing applications. To allow successfully interoperability between applications, location information needs to be normative and more tightly constrained than is currently specified in the PIDF-LO. This document makes recommendations on how to constrain, represent and interpret locations in a PIDF-LO. It further recommends a subset of GML that MUST be implemented by applications involved in location based routing. "Revised Civic Location Format for PIDF-LO", Martin Thomson, James Winterbottom, 25-Sep-06, This document defines an XML format for the representation of civic location. This format is designed for use with PIDF Location Object (PIDF-LO) documents. The format is based on the civic address definition in PIDF-LO, but adds several new elements based on the civic types defined for DHCP, and adds a hierarchy to address complex road identity schemes. The format also includes support for the xml:lang language tag and restricts the types of elements where appropriate. Global Routing Operations (grow) -------------------------------- "Operation of Anycast Services", Joe Abley, Kurt Lindqvist, 10-Jul-06, As the Internet has grown, and as systems and networked services within enterprises have become more pervasive, many services with high availability requirements have emerged. These requirements have increased the demands on the reliability of the infrastructure on which those services rely. Various techniques have been employed to increase the availability of services deployed on the Internet. This document presents commentary and recommendations for distribution of services using anycast. "MRT routing information export format", Larry Blunk, 29-Jun-06, This document describes the MRT format for routing information export. This format was developed in concert with the Multi-threaded Routing Toolkit (MRT) from whence the format takes it name. The MRT format was initially defined in the MRT Programmer's Guide [9]. The format can be used to export routing protocol messages, state changes, and routing information base contents. Host Identity Protocol (hip) ---------------------------- "Host Identity Protocol", Robert Moskowitz, 16-Jun-06, This memo specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Sigma-compliant Diffie- Hellman key exchange, using public-key identifiers from a new Host Identity name space for mutual peer authentication. The protocol is designed to be resistant to Denial-of-Service (DoS) and Man-in-the- middle (MitM) attacks, and when used together with another suitable security protocol, such as Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper layer protocols, suchs as TCP and UDP. Discussion related to this document is going on at the IETF HIP Working Group mailing list. "End-Host Mobility and Multihoming with the Host Identity Protocol", Pekka Nikander, 26-Jun-06, This document defines mobility and multihoming extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general "LOCATOR" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host-- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR parameter can also be used to support end-host multihoming, detailed procedures are left for further study. "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions", Pekka Nikander, Julien Laganier, 19-Oct-06, This document specifies a new resource record (RR) for the Domain Name System (DNS), and how to use it with the Host Identity Protocol (HIP.) This RR allows a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Names of its rendezvous servers (RVS.) "Host Identity Protocol (HIP) Rendezvous Extension", Julien Laganier, Lars Eggert, 7-Jun-06, This document defines a rendezvous extension for the Host Identity Protocol (HIP). The rendezvous extension extends HIP and the HIP registration extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation