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, 21-Feb-07, 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-Feb-07, This document specifies problems in running the IETF IP protocols over IEEE 802.16 networks by identifying specific gaps in the 802.16 MAC for IPv4 and IPv6 support. This document also provides an overview of IEEE 802.16 network characteristics and convergence sublayers. The common terminology to be used for the base guideline while defining the solution frameworks is also presented. "IPv6 Over the IP Specific part of the Packet Convergence sublayer in 802.16 Networks", Basavaraj Patil, 8-Mar-07, IEEE Std 802.16 is an Air Interface for Fixed and Mobile Broadband Wireless Access Systems. The 802.16 specification includes several service specific convergence sublayers (CS) as part of the MAC (Medium Access Control) layer which are used by upper layer protocols. The ATM CS and Packet CS are the two main service specific convergence sublayers and these are a part of the 802.16 MAC to which the upper layers interface. The packet CS is used for transport for all packet-based protocols such as Internet Protocol (IP), IEEE Std. 802.3 (Ethernet) and, IEEE Std 802.1Q (VLAN). The IP specific part of the Packet CS enables transport of IPv4 and IPv6 packets directly over the MAC. This document specifies the addressing and operation of IPv6 over the IP specific part of the packet CS for hosts served by a network that utilizes the IEEE Std 802.16 air interface. It recommends the assignment of a unique prefix (or prefixes) to each host and allows the host to use multiple identifiers within that prefix, including support for randomly generated interface identifiers. "Transmission of IP over Ethernet over IEEE 802.16 Networks", HongSeok Jeon, 7-Mar-07, This document describes the transmission of IPv4 as well as IPv6 over Ethernet in a network deploying the IEEE 802.16 cellular radio transmission technology. The Ethernet on top of IEEE 802.16 is realized by bridging between the point-to-point radio links, which are provided by IEEE 802.16 between the base station and its associated subscriber stations. Due to the resource constraints of radio transmission systems and the limitations of the IEEE 802.16 MAC functionality for the realization of an Ethernet, the transmission of IP over an Ethernet over IEEE 802.16 may considerably benefit by adding IP specific support functions in the Ethernet over IEEE 802.16 while maintaining full compatibility with standard IP over Ethernet behavior. IPv6 over Low power WPAN (6lowpan) ---------------------------------- "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", Gabriel Montenegro, 2-Mar-07, 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, 2-Mar-07, 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. ADSL MIB (adslmib) ------------------ "Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2)", Moti Morgenstern, 27-Feb-07, This document defines a Management Information Base (MIB) module for use with network management protocols in the IfQueueBlockernet community. In particular, it describes objects used for managing parameters of the "Very High Speed Digital Subscriber Line 2 (VDSL2)" inter and ADSL2+ interfaces. face type, which are also applicable for managing ADSL, ADSL2, "xDSL multi-pair bonding (G.Bond) MIB", Edward Beili, 26-Feb-07, This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP based internets. This document proposes an extension to the Interfaces Group MIB with a set of common objects for managing multi-pair bonded Digital Subscriber Line (xDSL) interfaces, defined in ITU-T recommendations G.998.1, G.998.2 and G.998.3. The MIB modules specific to each bonding technology are defined in GBOND-ATM-MIB, GBOND-ETH-MIB and GBOND-TDIM-MIB respectively. Access Node Control Protocol (ancp) ----------------------------------- "Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks", Sven Ooghe, 14-Feb-07, 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. "Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)", Hasnaa Moustafa, 4-Jan-07, The Access Node Control Protocol (ANCP) aims to communicate QoS-, service- and subscriber-related configurations and operations between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)). The main goal of this protocol is to configure and manage access equipments and allow them to report information to the NAS in order to enable and optimize configuration. This document investigates security threats that all ANCP nodes could encounter. This document develops a threat model for ANCP security aiming to decide which security functions are required. Based on this, security requirements regarding the Access Node Control Protocol are defined. "Protocol for Access Node Control Mechanism in Broadband Networks", Sanjay Wadhwa, 6-Mar-07, This document describes proposed extensions to the GSMPv3 protocol to allow its use in a broadband environment, as a control plane between Access Nodes (e.g. DSLAM) and Broadband Network Gateways (e.g. NAS). These proposed extensions are required to realize a protocol for “Access Node Control” mechanism as described in [9]. The resulting protocol with the proposed extensions to GSMPv3 [4] is referred to as “Access Node Control Protocol” (ANCP). This document focuses on specific use cases of access node control mechanism for topology discovery, line configuration, and OAM. It is intended to be augmented by additional protocol specification for future use cases considered in scope by the ANCP charter. Atom Publishing Format and Protocol (atompub) --------------------------------------------- "The Atom Publishing Protocol", Bill de Hora, Joe Gregorio, 6-Mar-07, The Atom Publishing Protocol (APP) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transfer of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format [RFC4287]. "The application/atom+xml Type Parameter", James Snell, 2-Jan-07, The Atom Syndication Format (RFC 4287) defines the 'application/ atom+xml' media type to identify both Atom Feed and Atom Entry Documents. This document defines an optional 'type' parameter used to differentiate the two types of Atom documents. Ad-Hoc Network Autoconfiguration (autoconf) ------------------------------------------- "Mobile Ad hoc Network Architecture", Ian Chakeres, 5-Mar-07, This document discusses Mobile Ad hoc NETworks (MANETs). It introduces basic MANET terms, characteristics, and challenges. This document also defines several MANET entities and architectural concepts. Audio/Video Transport (avt) --------------------------- "RTP Payload Format for Generic Forward Error Correction", Adam Li, 31-Jan-07, 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. "Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF)", Joerg Ott, Elisabetta Carrara, 5-Mar-07, 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 Profile for TCP Friendly Rate Control", Ladan Gharai, 2-Mar-07, This memo specifies how the TCP Friendly Rate Control (TFRC) of RTP flows can be supported using the RTP/AVPF profile and the general RTP header extension mechanism. AVPF feedback packets and RTP header extensions are defined to support the exchange of control information between RTP TFRC senders and receivers. TFRC is an equation based congestion control scheme for unicast flows operating in a best effort Internet environment. "RTP Payload Format for ATRAC Family", Matthew Romaine, Jun Matsumoto, 1-Dec-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 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 Channel-Oriented Telephony Signalling", Tom Taylor, Henning Schulzrinne, 26-Jan-07, This memo updates RFC 4733 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. "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, 16-Feb-07, 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", HariKishan Desineni, David Singer, 1-Mar-07, This document provides a general mechanism to use the header- extension feature of RTP (the Real Time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized. The actual extensions in use in a session are signaled in the setup information for that session. "Associating Time-codes with RTP streams", David Singer, 26-Feb-07, 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-Jan-07, 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 describes the syntax and semantics of the SDP parameters needed to support G.722.1 audio codec. "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. "How to Write an RTP Payload Format", Magnus Westerlund, 15-Dec-06, This document contains information on how to best write an RTP payload format. Reading tips, design practices, and practical tips on how to quickly and with good results produce an RTP payload format specification. A template is also included with instructions that can be used when writing an RTP payload format. "Transmission Time offsets in RTP streams", HariKishan Desineni, David Singer, 14-Feb-07, 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. "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", Stephan Wenger, 8-Mar-07, 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 messages related to the ITU-T H.271 Video Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit- rate and Temporal Spatial Trade-off. "RTP Topologies", Magnus Westerlund, Stephan Wenger, 23-Feb-07, This document discucsses multi-endpoint topologies 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, 8-Mar-07, 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. "RTCP XR - IP Video Metrics Report Blocks", Alan Clark, Amy Pendleton, 4-Dec-06, This document defines extensions to the RTCP XR extended report packet type blocks to support the monitoring of video over IP and the associated audio streams, if present, for IPTV and video conferencing endpoint reporting. "RTP Payload Format for SVC Video", Stephan Wenger, 7-Mar-07, This memo describes an RTP Payload format for the scalable extension of the ITU-T Recommendation H.264 video codec which is technically identical to ISO/IEC International Standard 14496-10 video codec. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NAL units), produced by the video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bit-rate conversational, through Internet video streaming with interleaved transmission, to high bit-rate video-on-demand. "RTP Payload Format for MIDI", John Lazzaro, John Wawrzynek, 1-Mar-07, This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content- delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. "RTP payload format for EVRC-WB codec and MIME updates for EVRC-B codec", HariKishan Desineni, Qiaobing Xie, 24-Jan-07, This document specifies real-time transport protocol (RTP) payload formats to be used for the EVRC wideband codec (EVRC-WB) and updates the MIME registrations for EVRC-B codec. Several media type registrations are included for EVRC-WB RTP payload formats. In addition, a file format is specified for transport of EVRC-WB speech data in storage mode applications such as e-mail. "RTCP HR - High Resolution VoIP Metrics Report Blocks", Alan Clark, 16-Feb-07, This document defines extensions to the RTCP XR extended report packet type blocks to support Voice over IP (VoIP) monitoring for services that require higher resolution or more detailed metrics than those supported by RFC3611 [3]. Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- "Session Traversal Utilities for (NAT) (STUN)", Jonathan Rosenberg, 8-Mar-07, Session Traversal Utilities for NAT (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. "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, 28-Feb-07, 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, 7-Mar-07, This specification defines a usage of the Simple Traversal Underneath 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, 1-Mar-07, This document specifies 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, 20-Feb-07, 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. "NAT Behavior Discovery Using STUN", Derek MacDonald, Bruse Lowekamp, 26-Feb-07, This specification defines a usage of the Simple Traversal Underneath Network Address Translators (NAT) (STUN) Protocol that allows applications to discover the presence and current behaviour of NATs and firewalls between them and the STUN server. 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, 8-Mar-07, 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, 7-Mar-07, 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, 7-Mar-07, 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, 7-Mar-07, 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, 7-Mar-07, 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, 13-Feb-07, 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, 1-Mar-07, This document describes the methodology for benchmarking Interior Gateway Protocol (IGP) Route Convergence. The methodology is to be used for benchmarking IGP convergence time through externally observable (black box) data plane measurements. The methodology can be applied to any link-state IGP, such as ISIS and OSPF. "Terminology for Benchmarking IGP Data Plane Route Convergence", Brent Imhoff, Scott Poretsky, 1-Mar-07, This document describes the terminology for benchmarking Interior Gateway Protocol (IGP) Route Convergence. The terminology is to be used for benchmarking IGP convergence time through externally observable (black box) data plane measurements. The terminology can be applied to any link-state IGP, such as ISIS and OSPF. "Considerations for Benchmarking IGP Data Plane Route Convergence", Scott Poretsky, 1-Mar-07, This document discusses considerations for benchmarking Interior Gateway Protocol (IGP) Route Convergence for any link-state IGP, such as Intermediate System-Intermediate System (ISIS) and Open-Shorted Path first (OSPF). A companion methodology document is to be used for benchmarking IGP convergence time through externally observable (black box) data plane measurements. A companion terminology document is to be referenced to support the benchmarking. "Terminology for Accelerated Stress Benchmarking", Scott Poretsky, Shankar Rao, 8-Mar-07, 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, 8-Mar-07, 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, 2-Jan-07, 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. "Benchmarking Terminology for Protection Performance", Scott Poretsky, 8-Mar-07, 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, 2-Mar-07, This draft describes the methodology for benchmarking MPLS Protection mechanisms for link and node protection as defined in [MPLS-FRR-EXT]. The benchmarking and terminology [TERM-ID] are to be used for benchmarking MPLS based protection mechanisms [MPLS-FRR-EXT]. This document provides test methodologies and test-bed setup for measuring failover times while considering all dependencies that might impact faster recovery of real time services riding on MPLS based primary tunnel. The terms used in the procedures included in this document are defined in [TERM-ID]. "IPv6 Benchmarking Methodology", Chip Popoviciu, 20-Feb-07, The Benchmarking Methodologies defined in RFC2544 [2] are IP version independent however, they do not address some of the specificities of IPv6. This document provides additional benchmarking guidelines which in conjunction with RFC2544 lead to a more complete and realistic evaluation of the IPv6 performance of network elements. Better-Than-Nothing Security (btns) ----------------------------------- "Problem and Applicability Statement for Better Than Nothing Security (BTNS)", Joseph Touch, 14-Feb-07, The Internet network security protocol suite, IPsec, consisting of IKE, ESP, and AH, generally requires authentication 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 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, 1-Mar-07, 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). "IPsec Channels: Connection Latching", Nicolas Williams, 1-Mar-07, This document specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create "channels" by "latching" "connections" (packet flows) to certain IPsec Security Association (SA) parameters for their lifetime. This can be used to protect applications against accidentally exposing live packet flows to unintended peers, whether as the result of a reconfiguration of IPsec or as the result of using weak peer identity to peer address associations. Weak association of peer ID and peer addresses is at the core of Better Than Nothing Security (BTNS), thus connection latching can add a significant measure of protection to BTNS IPsec nodes. Latched connections also represent IPsec channels, a building block for channel binding to IPsec; channel binding adds an additional level of protection to applications using BTNS IPsec, and IPsec in general. Calendaring and Scheduling Standards Simplification (calsify) ------------------------------------------------------------- "iCalendar Message-Based Interoperability Protocol (iMIP)", Alexey Melnikov, 21-Feb-07, 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 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 . The issue tracker for the Calsify WG is located at: "iCalendar Transport-Independent Interoperability Protocol (iTIP)", Cyrus Daboo, 7-Mar-07, 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, 5-Mar-07, This document defines a MIME media type for representing and exchanging calendaring and scheduling information such as events, to- dos, journal entries and free/busy information. The definition of the text/calendar media type, known as iCalendar, is independent of any particular calendar service or protocol. Control And Provisioning of Wireless Access Points (capwap) ----------------------------------------------------------- "Light Weight Access Point Protocol", Pat Calhoun, 2-Mar-07, In the recent years, there has been a shift in wireless LAN product architectures from autonomous access points to centralized control of light weight access points. The general goal has been to move most of the traditional wireless functionality such as access control (user authentication and authorization), mobility and radio management out of the access point into a centralized controller. The IETF's CAPWAP WG has identified that a standards based protocol is necessary between a wireless Access Controller and Wireless Termination Points (the latter are also commonly referred to as Light Weight Access Points). This specification defines the Light Weight Access Point Protocol (LWAPP), which addresses the CAPWAP's protocol requirements. Although the LWAPP protocol is designed to be flexible enough to be used for a variety of wireless technologies, this specific document describes the base protocol, and an extension that allows it to be used with the IEEE's 802.11 wireless LAN protocol. "Wireless LAN Control Protocol (WiCoP)", Satoshi Iino, 7-Feb-07, The popularity of wireless local area networks (WLANs) has led to wide spread deployments across different establishments. It has also translated in to increasing scale of the WLANs. Large-scale deployments made of large numbers of wireless termination points (WTPs) and covering substantial areas are increasingly common. The Wireless LAN Control Protocol (WiCoP) described in this document allows for the control and provisioning of large-scale WLANs. It enables central management of these networks and realizes the objectives set forth for the 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, 7-Mar-07, 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 [13]. 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, 7-Mar-07, 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 protocol. The CAPWAP Protocol Specification is defined separately [1]. "CAPWAP Threat Analysis for 802.11 Deployments", Scott Kelly, Charles Clancy, 13-Feb-07, Early Wireless LAN (WLAN) deployments feature a "fat" Access Point (AP) which serves as a standalone interface between the wired and wireless network segments. However, this model raises scaling, mobility, and manageability issues, and the CAPWAP protocol is being developed in reponse. CAPWAP effectively splits the fat AP functionality into two network elements, and the communication channel between these components may traverse potentially hostile hops. This document analyzes the security exposure resulting from the introduction of CAPWAP, and summarizes the associated security considerations for CAPWAP implementations and deployments. 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, 18-Jan-07, 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. "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. "Extensions to GMPLS RSVP Graceful Restart", Arun Satyanarayana, Reshad Rahman, 29-Jan-07, 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. Those mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects. The extensions defined in this document build on the RSVP Hello extensions defined in RFC 3209, and extensions for state recovery on nodal faults defined in RFC 3473. Using these 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. "Inter domain Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering - RSVP-TE extensions", Arthi Ayyangar, 1-Mar-07, This document describes procedures and protocol extensions for the use of Resource ReserVation Protocol Traffic Engineering (RSVP-TE) signaling in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and non-packet networks to support the establishment and maintenance of Label Switched Paths that cross domain boundaries. For the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space or path computation responsibility. Examples of such domains include Autonomous Systems, IGP routing areas, and GMPLS overlay networks. "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", Arthi Ayyangar, 1-Mar-07, In certain scenarios, there may be a need to combine together several Generalized Multi-Protocol Label Switching (GMPLS) Label Switched Paths (LSPs) such that a single end-to-end (e2e) LSP is realized and all traffic from one constituent LSP is switched onto the next LSP. We will refer to this as "LSP stitching", the key requirement being that a constituent LSP not be allocated to more than one e2e LSP. The constituent LSPs will be referred to as "LSP segments" (S-LSPs). This document describes extensions to the existing GMPLS signaling protocol (RSVP-TE) to establish e2e LSPs created from from S-LSPs, and describes how the LSPs can be managed using the GMPLS signaling and routing protocols. It may be possible to configure a GMPLS node to switch the traffic from an LSP for which it is the egress, to another LSP for which it is the ingress, without requiring any signaling or routing extensions whatsoever, completely transparent to other nodes. This will also result in LSP stitching in the data plane. However, this document does not cover this scenario of LSP stitching. "A Per-domain path computation method for establishing Inter-domain Traffic Engineering (TE) Label Switched Paths (LSPs)", JP Vasseur, 20-Feb-07, 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, 24-Jan-07, 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 a 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 Interior Gateway Protocol (IGP) routing extensions for Intermediate System-to-Intermediate System (IS-IS) and Open Shortest Path First (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 of TE LSPs. "IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities", JP Vasseur, 19-Dec-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, 23-Jan-07, 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, 7-Feb-07, 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 will 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. In the course of migration, MPLS-TE and GMPLS devices, or networks, may coexist which may require interworking between MPLS-TE and GMPLS protocols. Aspects of the interworking required are discussed as it will influence the choice of a migration strategy. This framework document provides a migration toolkit to aid the operator in selection of an appropriate strategy. This framework document also lists a set of solutions that may aid in interworking, and highlights a set of potential issues. "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, 7-Mar-07, 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, 7-Mar-07, 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. "Requirements for the Conversion Between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network", Diego Caviglia, 19-Dec-06, From a Carrier perspective, the possibility of turning a Permanent Connection (PC) into a Soft Permanent Connection (SPC) and vice versa, without actually affecting Data Plane traffic being carried over it, is a valuable option. In other terms, such operation can be seen as a way of transferring the ownership and control of an existing and in-use Data Plane connection between the Management Plane and the Control Plane, leaving its Data Plane state untouched. "Interworking Requirements to Support operation of MPLS-TE over GMPLS networks", Kenji Kumaki, 21-Dec-06, This document describes a framework and Service Provider requirements for operating Multiprotocol Label Switching (MPLS) traffic engineering (TE) networks over Generalized MPLS (GMPLS) networks. Operation of an MPLS-TE network as a client network to a GMPLS network has enhanced operational capabilities than provided by a co- existent protocol model (ships in the night). The GMPLS network may be a packet or a non-packet network, and may itself be a multi-layer network supporting both packet and non-packet technologies. A MPLS-TE Label Switched Path (LSP) originates and terminates on an MPLS Label Switching Router (LSR). The GMPLS network provides transparent transport for the end-to-end MPLS-TE LSP. Specification of solutions is out of scope for this document. "Analysis of Inter-domain Label Switched Path (LSP) Recovery", Tomonori Takeda, 22-Dec-06, This document analyzes various schemes to realize Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Path (LSP) recovery in multi-domain networks based on the existing framework for multi-domain LSPs. The main focus for this document is on establishing end-to-end diverse Traffic Engineering (TE) LSPs in multi-domain networks. It presents various diverse LSP setup schemes based on existing functional elements. Cross Registry Information Service Protocol (crisp) --------------------------------------------------- "A Domain Availability Check (dchk) Registry Type for the Internet Registry Information Service (IRIS)", Andrew Newton, 5-Dec-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, 7-Mar-07, 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, 7-Mar-07, 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, 7-Mar-07, 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. 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, 2-Mar-07, 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 small packet variant of TFRC [TFRCSP]. We present Faster Restart in general terms as a congestion control mechanism, and further describe how to implement Faster Restart in Datagram Congestion Control Protocol (DCCP) Congestion Control IDs 3 and 4 [RFC4342], [CCID4]. "RTP and the Datagram Congestion Control Protocol (DCCP)", Colin Perkins, 5-Mar-07, 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, 7-Mar-07, 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 streaming media where a relatively smooth sending rate is of importance. Dynamic Host Configuration (dhc) -------------------------------- "Virtual Subnet Selection Sub-Option for the Relay Agent Information Option for DHCPv4", Kenneth Kinnear, 1-Mar-07, In some environments, a relay agent resides in a network element which also has access to one or more virtual private networks (VPNs). If one DHCP server wishes to offer service to DHCP clients on those different VPNs the DHCP server needs to know information about the VPN on which each client resides. The virtual-subnet-selection sub- option of the relay-agent-information option is used by the relay agent to tell the DHCP server important information about the VPN (called the Virtual Subnet Selection information, or VSS) for every DHCP request it passes on to the DHCP server, and is also used to properly forward any DHCP reply that the DHCP server sends back to the relay agent. "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. "DHCP options for PANA Authentication Agents", Lionel Morand, 18-Dec-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 methods that a PANA Client (PaC) can use to locate PANA Authentication Agents (PAA). "Domain Suffix Option for DHCPv6", Renxiang Yan, 13-Dec-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, 30-Nov-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, 29-Nov-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, 1-Feb-07, 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. "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 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, 2-Mar-07, 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. "DHCPv6 Leasequery", John Jason Brzozowski, 5-Mar-07, 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. Diameter Maintenance and Extensions (dime) ------------------------------------------ "The Diameter API", Pat Calhoun, 1-Feb-07, The Diameter authentication, authorization, and accounting (AAA) protocol provides support for peering AAA transactions across the Internet. This document describes a standardized API for the Diameter protocol. The API is defined for the C language. The intent of the API is to foster source code portability across multiple programming platforms. "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. "Diameter Mobile IPv6: NAS <-> HAAA Support", Jouni Korhonen, 13-Feb-07, A Mobile IPv6 node requires a Home Agent address, a home address, and a security association with its Home Agent before it can start utilizing Mobile IPv6. RFC 3775 requires that some or all of these parameters are statically configured. 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 MIPv6 bootstrapping using the Diameter Network Access Server (NAS) <-> home Authentication, Authorization and Accounting server (HAAA) interface. "Diameter Base Protocol", Victor Fajardo, John Loughney, 5-Mar-07, The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application needs to be supported by all Diameter implementations. "Diameter Quality of Service Application", Glen Zorn, 28-Feb-07, This document describes a Diameter application that performs Authentication, Authorization, and Accounting for Quality of Service (QoS) reservations. This protocol is used by elements along the path of a given application flow to authenticate a reservation request, ensure that the reservation is authorized, and to account for resources consumed during the lifetime of the application flow. Clients that implement the Diameter QoS application contact an authorizing entity/application server that is located somewhere in the network, allowing for a wide variety of flexible deployment models. Domain Keys Identified Mail (dkim) ---------------------------------- "DomainKeys Identified Mail (DKIM) Signatures", Eric Allman, 20-Feb-07, 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) Message Signing Service Overview", Tony Hansen, 8-Mar-07, 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, 8-Mar-07, DomainKeys Identified Mail (DKIM) provides a cryptographic mechanism for domains to assert responsibility for the messages they handle. A related mechanism will allow an administrator to publish various statements about their DKIM signing practices. This document defines requirements for this mechanism. Detecting Network Attachment (dna) ---------------------------------- "Link-layer Event Notifications for Detecting Network Attachments", Alper Yegin, 16-Feb-07, 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. "Detecting Network Attachment in IPv6 Networks (DNAv6)", James Kempf, 6-Mar-07, 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. DNS Extensions (dnsext) ----------------------- "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. "Elliptic Curve Keys and Signatures in the Domain Name System (DNS)", R Schroeppel, Donald Eastlake, 6-Mar-07, The standard format for storing elliptic curve cryptographic keys and elliptic curve SHA-1 based signatures in the Domain Name System (DNS) is specified. "Automated Updates of DNSSEC Trust Anchors", Michael StJohns, 30-Nov-06, This document describes a means for automated, authenticated and authorized updating of DNSSEC "trust anchors". The method provides protection against N-1 key compromises of N keys 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(s). 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, 8-Mar-07, 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, 7-Mar-07, 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. "Domain Name System (DNS) IANA Considerations", Donald Eastlake 3rd, 8-Dec-06, Internet Assigned Number Authority (IANA) parameter assignment considerations are specified for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record 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, 29-Nov-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 in the DNS", Scott Rose, Wouter Wijngaards, 23-Jan-07, 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. This is an update to the original specification in RFC 2672. "Measures for making DNS more resilient against forged answers", Remco van Mook, Bert Hubert, 12-Jan-07, The current internet climate poses serious threats to the Domain Name System. In the interim period before the DNS protocol can be secured more fully, measures can already be taken to make 'spoofing' a recursing nameserver many orders of magnitude harder. Even a cryptographically secured DNS benefits from having the ability to discard bogus answers quickly, as this potentially saves large amounts of computation. By describing certain behaviour that has previously not been standardised, this document sets out how to make the DNS more resilient against accepting incorrect answers. This document updates RFC1034. Domain Name System Operations (dnsop) ------------------------------------- "Requirements for a Mechanism Identifying a Name Server Instance", David Conrad, Suzanne Woolf, 16-Feb-07, 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, 28-Feb-07, With a mandated default minimum maximum UDP 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, 14-Feb-07, This document describes ways to prevent the use of default configured recursive nameservers as reflectors on DOS attacks. Recommended configuration as measures to mitigate the attack are given. "Locally-served DNS Zones", Mark Andrews, 2-Mar-07, 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, 26-Feb-07, Mapping of addresses to names is a feature of DNS. Many sites implement it, many others do not. Some applications attempt to use it as a part of a security strategy. This document outlines what should be taken into account when deciding whether to implement reverse mappings of addresses to names, and recommends that site administrators implement reverse mappings if there are no strong considerations against such mappings. "I'm Being Attacked by PRISONER.IANA.ORG!", Joe Abley, William Maton, 28-Feb-07, Many sites connected to the Internet make use of IPv4 addresses which are not globally unique. Examples are the addresses designated in RFC1918 for private use within individual sites. Hosts should never normally send reverse DNS queries for those addresses on the public Internet. However, such queries are frequently observed. Authority servers are deployed to provide authoritative answers to such queries as part of a loosely- coordinated effort known as the AS112 project. Since queries sent to AS112 servers are usually not intentional, the replies received back from those servers are typically unexpected. Unexpected inbound traffic can trigger alarms on intrusion detection systems and firewalls, and operators of such systems often mistakenly believe that they are being attacked. This document provides background information and technical advice to those firewall operators. "AS112 Nameserver Operations", Joe Abley, William Maton, 28-Feb-07, Many sites connected to the Internet make use of IPv4 addresses which are not globally unique. Examples are the addresses designated in RFC1918 for private use within individual sites. Devices in such environments may occasionally originate reverse DNS queries corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that they are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site. It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the root and IN-ADDR.ARPA authority servers. This document describes the steps required to install a new AS112 node, and offers advice relating to such a node's operation. Email Address Internationalization (eai) ---------------------------------------- "SMTP extension for internationalized email address", Jiankang Yao, Wei Mao, 6-Mar-07, 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. 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. "UTF-8 Mail: Scenarios", Harald Alvestrand, 26-Feb-07, 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 UTF8SMTP extension documents. "Overview and Framework for Internationalized Email", John Klensin, YangWoo Ko, 7-Feb-07, 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 document set also includes discussion of key assumptions and issues in deploying fully internationalized email. email header syntax to accommodate UTF-8 data. The "Downgrading mechanism for Email Address Internationalization", Yoshiro Yoneya, Kazunori Fujiwara, 8-Mar-07, Traditional mail systems handle only US-ASCII characters in SMTP envelope and mail header fields. The Email Address Internationalization is implemented by allowing UTF-8 characters in SMTP envelope and mail header fields (UTF8SMTP). To deliver Non- ASCII mail address via UTF8SMTP non-compliant environment, some sort of converting mechanism (i.e. downgrading) is required. This document describes requirements for downgrading, SMTP downgrading, Email header downgrading and implementation consideration. "IMAP Support for UTF-8", Pete Resnick, Chris Newman, 7-Mar-07, 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, 7-Mar-07, 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", Randall Gellens, Edmon Chung, 22-Jan-07, 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 are discussed. "POP3 Support for UTF-8", Chris Newman, 26-Jan-07, 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. "International Delivery and Disposition Notifications", Chris Newman, 29-Jan-07, Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing draft standard is presently limited to US-ASCII text in the machine readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type. Extensible Authentication Protocol (eap) ---------------------------------------- "Extensible Authentication Protocol (EAP) Key Management Framework", Bernard Aboba, 8-Feb-07, The Extensible Authentication Protocol (EAP), defined in [RFC3748], enables extensible network access authentication. This document specifies the EAP key hierarchy and provides a framework for the transport and usage of keying material generated by EAP authentication algorithms, known as "methods". It also provides a system-level security analysis. "Network Discovery and Selection Problem", Jari Arkko, 8-Mar-07, When multiple access network are available, users may have difficulty in selecting which network to connect to, and how to authenticate with that network. This document defines the network discovery and selection problem, dividing it into multiple sub-problems. Some constraints on potential solutions are outlined, and the limitations of several solutions (including existing ones) are discussed. Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- "Requirements for Emergency Context Resolution with Internet Technologies", Henning Schulzrinne, Roger Marshall, 5-Mar-07, 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, 6-Mar-07, 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, 7-Mar-07, 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, 18-Dec-06, This document describes an architecture for a global, scalable, resilient and administratively distributed system for mapping geographic location information to URLs, using the Location-to- Service (LoST) protocol. The architecture generalizes well-known approaches found in hierarchical lookup systems such as DNS. "Best Current Practice for Communications Services in support of Emergency Calling", Brian Rosen, James Polk, 8-Mar-07, 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, 8-Mar-07, 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. "A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure", Henning Schulzrinne, 11-Dec-06, The Location-to-Service Translation Protocol (LoST) describes an XML- based protocol for mapping service identifiers and geospatial or civic location information to service contact Uniform Resource Locators (URLs). LoST servers can be located anywhere but a placement closer to the end host, e.g., in the access network, is desireable. Such a LoST server placement provides benefits in disaster situations with intermittent network connectivity regarding the resiliency of emergency service communication. This document describes how a LoST client can discover a LoST server using the Dynamic Host Configuration Protocol (DHCP). Electronic Data Interchange-Internet Integration (ediint) --------------------------------------------------------- "Compressed Data for EDIINT", Terry Harding, 17-Jan-07, The intent of this document is to be placed on the RFC track as an Informational RFC. The EDIINT AS1 and AS2 message formats don't currently contain any transport neutral provisions for compressing data when utilizing S/MIME as the secure packaging standard. Compressing data before transmission provides a number of advantages including 1. reducing data redundancy, and so reducing opportunities for attacks exploiting redundancy, and 2. reducing the amount of data and so speeding up cryptographic processing such as signing, encryption, archiving, and 3. reducing the overall transmitted message size, reducing both time and bandwidth needed for transport. "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, 23-Feb-07, 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-Feb-07, 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, 8-Mar-07, 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 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 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 Enumservices", Jason Livingood, 7-Mar-07, This document provides a guide to and template for the creation of new IANA registration of ENUM (E.164 Number Mapping) services. i 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, 7-Mar-07, 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, 7-Mar-07, 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, 24-Jan-07, 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, 12-Dec-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, 24-Jan-07, 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 approval 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. "IANA Registration for Enumservice 'XMPP'", Alexander Mayrhofer, 3-Jan-07, This document requests IANA registration of an Enumservice for XMPP, the Extensible Messaging and Presence Protocol. This Enumservice specifically allows the use of 'xmpp' Uniform Resource Identifiers (URIs) in the context of E.164 Number Mapping (ENUM). "IANA Registration for Enumservice UNUSED", Richard Stastny, 28-Feb-07, This document registers the Enumservice "unused" using the URI scheme "data:" as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice may be used to indicate that the E.164 number (or E.164 number range) tied to the domain in which the enclosing NAPTR is published is not allocated or assigned for communications service. When such an indication is provided, an ENUM client can detect calls that will fail "early". 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. "Forward Error Correction (FEC) Framework", Mark Watson, 26-Feb-07, This document describes for a framework for using forward error correction (FEC) codes with applications in the Internet to provide protection against packet loss. The framework supports applying Forward Error Correction to arbitrary packet flows and is primarily intended for streaming media. This framework can be used to define Content Delivery Protocols that provide Forward Error Correction for streaming media delivery or other packet flows. Content Delivery Protocols defined using this framework can support any FEC Scheme (and associated FEC codes) which is compliant with various requirements defined in this document. Thus, Content Delivery Protocols can be defined which are not specific to a particular FEC Scheme and FEC Schemes can be defined which are not specific to a particular Content Delivery Protocol. Forwarding and Control Element Separation (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, 5-Mar-07, 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. "ForCES MIB", Robert HAAS, 2-Mar-07, 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). "ForCES Transport Mapping Layer (TML) Service Primitives", Weiming Wang, 15-Feb-07, This document specifies Transport Mapping Layer (TML) Service Primitives for Forwarding and Control Element Separation (ForCES). Based on the service primitives, TML services that are provided by TML to ForCES Protocol Layer (PL) are standardized. To define the primitives, TML properties represented as TML events, TML attributes, and TML capabilities are also specified in the document. 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) ------------------------------------- "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", Henning Schulzrinne, 2-Feb-07, This document defines an authorization policy language for controling access to location information. It extends the Common Policy authorization framework to provide location-specific access control. More specifically, this document defines condition elements specific to location information in order to restrict access based on the current location of the Target. Furthermore, it offers location- specific transformation elements to reduce the granularity of the returned location information. "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, 7-Mar-07, 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, 15-Feb-07, 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. "A Document Format for Filtering and Reporting Location Notications in the Presence Information Document Format Location Object (PIDF-LO)", Rohan Mahy, 7-Mar-07, This document describes filters which limit asynchronous location notifications to compelling events. The resulting location information is conveyed in existing location formats wrapped in GEOPRIV privacy extensions to the Presence Information Document Format (PIDF-LO). Location disclosure is limited to voluntary disclosure by a notifier that possesses credentials for the named resource. "Binary to Decimal Conversion for Location Configuration Information", John Schnizlein, Marc Linsner, 2-Jan-07, This document describes the nature of the data expressed in the geographic LCI defined in RFC 3825, and includes examples of conversion from its binary format to decimal character strings. "GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements", Hannes Tschofenig, Henning Schulzrinne, 8-Jan-07, This document provides a problem statement, lists requirements and captures discussions for a GEOPRIV Layer 7 Location Configuration Protocol (LCP). This protocol aims to allow an end host to obtain location information, by value or by reference, from a Location Information Server (LIS) that is located in the access network. The obtained location information can then be used for a variety of different protocols and purposes. For example, it can be used as input to the Location-to-Service Translation Protocol (LoST) or to convey location within SIP to other entities. Global Routing Operations (grow) -------------------------------- "MRT routing information export format", Larry Blunk, 8-Mar-07, 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 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, 1-Feb-07, 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. "End-Host Mobility and Multihoming with the Host Identity Protocol", Tom Henderson, 5-Mar-07, 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 when HIP nodes are multi-homed or mobile. "Using ESP transport format with HIP", Petri Jokela, 14-Feb-07, This memo specifies an Encapsulated Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP). "Host Identity Protocol (HIP) Registration Extension", Julien Laganier, 7-Jun-06, This document specifies a registration mechanism for the Host Identity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes. "HIP Extensions for the Traversal of Network Address Translators", Vivien Schmitt, 8-Mar-07, This document specifies extensions to Host Identity Protocol (HIP) to support traversal of Network Address Translator (NAT) middleboxes. The traversal mechanism tunnels HIP control and data traffic over UDP and enables HIP initiators which MAY be behind NATs to contact HIP responders which MAY be behind another NAT. "Native Application Programming Interfaces for SHIM Layer Prococols", Miika Komu, 8-Mar-07, This document proposes extensions to the current networking APIs for protocols based on identifier/locator split. Currently, the document focuses on HIP, but the extensions can be used also by other protocols implementing identifier locator split. Using the API extensions, new SHIM aware applications can gain a better control of the SHIM layer and endpoint identifiers. For example, the applications can query and set SHIM related attributes, or specify their own endpoint identifiers for a host. In addition, a new indirection element called endpoint descriptor is defined for SHIM aware applications that can be used for implementing opportunistic mode in a clean way. "Using HIP with Legacy Applications", Tom Henderson, Pekka Nikander, 26-Nov-06, The Host Identity Protocol and architecture (HIP) proposes to add a cryptographic name space for network stack names. From an application viewpoint, HIP-enabled systems support a new address family (e.g., AF_HOST), but it may be a long time until such HIP- aware applications are widely deployed even if host systems are upgraded. This informational document discusses implementation and API issues relating to using HIP in situations in which the system is HIP-aware but the applications are not. Handover Keying (hokey) ----------------------- "Handover Key Management and Re-authentication Problem Statement", Charles Clancy, 25-Jan-07, This document describes the Handover Keying (HOKEY) problem statement. The current EAP keying framework is not designed to support re-authentication and handovers. This often cause unacceptable latency in various mobile wireless environments. HOKEY plans to address these HOKEY plans to address these problems by implementing a generic mechanism to reuse derived EAP keying material for hand-off. "Specification for the Derivation of Usage Specific Root Keys (USRK) from an Extended Master Session Key (EMSK)", Joseph Salowey, 24-Jan-07, An Extended Master Session Key (EMSK) is a cryptographic key generated from an Extensible Authentication Protocol (EAP) exchange reserved solely for the purpose of deriving master keys for one or more purposes identified as usage definitions. This document specifies a mechanism for deriving cryptographically separate root keys from the EMSK, called usage specific root Keys (USRK). The document provides a set of requirements for avoiding conflicts between usage definitions to ensure this cryptographic separation. The USRK is used according to the usage definition defined for a specific purpose. Ethernet Interfaces and Hub MIB (hubmib) ---------------------------------------- "Managed Objects of Ethernet Passive Optical Networks (EPON)", Lior Khermosh, 15-Nov-06, This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based Internets. In particular, it defines objects for managing interfaces that conform to the Ethernet Passive Optical Networks (EPON) standard as defined in the IEEE Std 802.3ah-2004, which are extended capabilities to the Ethernet like interfaces. "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB", Edward Beili, 23-Feb-07, This document defines Management Information Base (MIB) modules for use with network management protocols in TCP/IP based internets. This document describes extensions to the Ethernet-like Interfaces MIB and MAU MIB modules with a set of objects for managing Ethernet in the First Mile Copper (EFMCu) interfaces 10PASS-TS and 2BASE-TL, defined in IEEE Std 802.3ah-2004. In addition a set of objects is defined, describing cross-connect capability of a managed device with multi-layer (stacked) interfaces, extending the stack management objects in the Interfaces Group MIB and the Inverted Stack Table MIB modules. "Definitions and Managed Objects for OAM Functions on Ethernet Like Interfaces", Matt Squire, 23-Feb-07, This document defines objects for managing Operations, Administration, and Maintenance (OAM) capabilities on Ethernet like interfaces conformant to the Ethernet OAM functionality defined in the Ethernet in the First Mile (EFM) clauses of the Ethernet standards. The Ethernet OAM functionality is complementary to SNMP management in that it is focused on a small set of link-specific functions for directly connected Ethernet interfaces. This document defines objects for controlling those link OAM functions, and for providing results and status of the OAM functions to management entities. "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)", Edward Beili, 26-Jul-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 IEEE 802.3 Medium Attachment Units (MAUs). This memo obsoletes RFC 3636. It amends that specification by moving MAU type OBJECT-IDENTITY definitions and relevant textual conventions into a separate Internet Assigned Number Authority (IANA) maintained MIB module. In addition, management information is added to enable support for Ethernet in the First Mile (EFM) and 10GBASE-CX4 MAUs. Internet Architecture Board (iab) --------------------------------- "Architectural Implications of Link Indications", Bernard Aboba, 2-Mar-07, A link indication represents information provided by the link layer to higher layers regarding the state of the link. This document describes the role of link indications within the Internet Architecture. While the judicious use of link indications can provide performance benefits, inappropriate use can degrade both robustness and performance. This document summarizes current proposals, describes the architectural issues and provides examples of appropriate and inappropriate uses of link indications. "Design Choices When Expanding DNS", Patrik Faltstrom, 25-Oct-06, This note discusses how to extend the DNS with new data for a new application. DNS extension discussion too often circulates around reuse of the TXT record. This document lists different mechanisms to accomplish the extension to DNS, and comes to the conclusion that the use of a new RR Type is the best solution. "The RFC Series and RFC Editor", Leslie Daigle, 2-Mar-07, This document describes the framework for an RFC Series and an RFC Editor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFC Series to continue to fulfill its mandate. "Multiple Encapsulation Methods Considered Harmful", Bernard Aboba, 25-Jan-07, This document describes architectural and operational issues that arise from link layer protocols supporting multiple Internet Protocol encapsulation methods. "Multilink Subnet Issues", Dave Thaler, 25-Jan-07, There have been several proposals around the notion that a subnet may span multiple links connected by routers. This memo documents the issues and potential problems that have been raised with such an approach. "Report from the IAB workshop on Unwanted Traffic March 9-10, 2006", Loa Andersson, 13-Feb-07, This document reports the outcome of a workshop held by the Internet Architecture Board (IAB) on Unwanted Internet Traffic. The workshop was held on March 9-10, 2006 at USC/ISI in Marina del Rey, CA, USA. The primary goal of the workshop was to foster interchange between the operator, standards, and research communities on the topic of unwanted traffic, as manifested in, for example, Distributed Denial of Service (DDoS) attacks, spam, and phishing, to gain understandings on the ultimate sources of these unwanted traffic, and to assess their impact and the effectiveness of existing solutions. It was also a goal of the workshop to identify engineering and research topics that could be undertaken by the IAB, the IETF, the IRTF, and the network research and development community at large to develop effective countermeasures against the unwanted traffic. "Report from the IAB Workshop on Routing and Addressing", David Meyers, 1-Mar-07, This document reports the outcome of the Routing and Addressing Workshop which the Internet Architecture Board (IAB) held on October 18-19, 2006 in Amsterdam, Netherlands. The primary goal of the workshop was to develop a shared understanding of the problems that the large backbone operators are facing regarding the scalability of today's Internet routing system. The key workshop findings include an analysis of the major factors that are driving routing table growth, constraints in router technology, and the limitations of today's Internet addressing architecture. It is hoped that these findings will serve as input to the IETF community and help identify next steps towards effective solutions. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and not the IAB. "Process for Publication of IAB RFCs", Leslie Daigle, 22-Dec-06, From time to time, the Internet Architecture Board (IAB) publishes documents as Requests for Comments (RFCs). This document defines the process by which those documents are produced, reviewed, and published in the RFC series. "Independent Submissions to the RFC Editor", John Klensin, Dave Thaler, 8-Mar-07, There is a long-term tradition in the Internet community, predating the IETF by many years, of use of the RFC series to publish materials that are not rooted in the IETF standards process and its review and approval mechanisms. These documents, known as "independent submissions", serve a number of important functions for the Internet community, both inside and outside of the community of active IETF participants. This document discusses the independent submission model and some reasons why it is important. It then describes editorial and processing norms that can be used for independent submissions as the community goes forward into new relationships between the IETF community and its primary technical publisher. Inter-Domain Routing (idr) -------------------------- "Outbound Route Filtering Capability for BGP-4", Enke Chen, Yakov Rekhter, 25-Sep-06, This document defines a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of route filters that the peer would use to constrain/filter its outbound routing updates to the speaker. "BGP Support for Four-octet AS Number Space", Quaizar Vohra, Enke Chen, 7-Feb-07, Currently the Autonomous System number is encoded as a two-octet entity in BGP. This document describes extensions to BGP to carry the Autonomous System number as a four-octet entity. "Aspath Based Outbound Route Filter for BGP-4", Keyur Patel, Susan Hares, 28-Feb-07, This document defines a new Outbound Router Filter type for BGP, termed "Aspath Outbound Route Filter", that can be used to perform aspath based route filtering. This ORF-type supports aspath based route filtering as well as regular expression based matching, for address groups. "Dynamic Capability for BGP-4", Enke Chen, Srihari Sangli, 22-Nov-06, This document defines a new BGP capability termed "Dynamic Capability", which would allow the dynamic update of capabilities over an established BGP session. This capability would facilitate non-disruptive capability changes by BGP speakers. "AS-wide Unique BGP Identifier for BGP-4", Enke Chen, Jenny Yuan, 22-Nov-06, To accommodate situations where the current requirements for the BGP Identifier are not met, this document relaxes the definition of the BGP Identifier to be a 4-octet unsigned, non-zero integer, and relaxes the "uniqueness" requirement so that only AS-wide uniqueness of the BGP Identifiers is required. These revisions to the base BGP specification do not introduce any backward compatibility issue. "Autonomous System Confederations for BGP", Paul Traina, 2-Feb-07, The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for Transmission Control Protocol/Internet Protocol (TCP/IP) networks. BGP requires that all BGP speakers within a single autonomous system (AS) must be fully meshed. This represents a serious scaling problem that has been well documented in a number of proposals. This document describes an extension to BGP which may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system. "Multisession BGP", John Scudder, Chandrashekhar Appanna, 4-Jan-07, This specification augments "Multiprotocol Extensions for BGP-4" [MP- BGP] by proposing a mechanism to allow multiple sessions to be used between a given pair of BGP speakers. Each session is used to transport routes for one or more AFI/SAFI. This provides an alternative to the current [MP-BGP] approach of multiplexing routes for all AFI/SAFI onto a single connection. Use of this approach is expected to increase the robustness of the BGP protocol as it is used to support more and more diverse AFI/SAFI. "Avoid BGP Best Path Transitions from One External to Another", Enke Chen, Srihari Sangli, 27-Dec-05, In this document we propose a revision to the BGP route selection rules that would avoid unnecessary best path transitions between external paths under certain conditions. The proposed revision would help the overall network stability, and more importantly, would eliminate certain BGP route oscillations in which more than one external paths from one BGP speaker contribute to the churn. "Address Prefix Based Outbound Route Filter for BGP-4", Enke Chen, Srihari Sangli, 21-Jul-06, This document defines a new Outbound Router Filter type for BGP, termed "Address Prefix Outbound Route Filter", that can be used to perform address prefix based route filtering. This ORF-type supports prefix length or range based matching, wild-card based address prefix matching, as well as the exact address prefix matching for address families. "The AS_PATHLIMIT Path Attribute", Tony Li, 5-Jan-07, This document describes the 'AS path limit' (AS_PATHLIMIT) path attribute for BGP. This is an optional, transitive path attribute that is designed to help limit the distribution of routing information in the Internet. By default, prefixes advertised into the BGP graph are distributed freely, and if not blocked by policy will propagate globally. This is harmful to the scalability of the routing subsystem since information that only has a local effect on routing will cause state creation throughout the default-free zone. This attribute can be attached to a particular path to limit its scope to a subset of the Internet. Intrusion Detection Exchange Format (idwg) ------------------------------------------ "Intrusion Detection Mesage Exchange Requirements", Mark Wood, Michael Erlinger, 23-Oct-02, The purpose of the Intrusion Detection Exchange Format Working Group (IDWG) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems, and to the management systems which may need to interact with them. This Internet-Draft describes the high-level requirements for such a communication mechanism, including the rationale for those requirements where clarification is needed. Scenarios are used to illustrate some requirements. "The Intrusion Detection Message Exchange Format", Hervé Debar, 22-Mar-06, The purpose of the Intrusion Detection Message Exchange Format (IDMEF) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems, and to the management systems which may need to interact with them. This Internet-Draft describes a data model to represent information exported by intrusion detection systems, and explains the rationale for using this model. An implementation of the data model in the Extensible Markup Language (XML) is presented, an XML Document Type Definition is developed, and examples are provided. "The Intrusion Detection Exchange Protocol (IDXP)", Benjamin Feinstein, Gregory Matthews, John White, 23-Oct-02, This memo describes the Intrusion Detection Exchange Protocol (IDXP), an application-level protocol for exchanging data between intrusion detection entities. IDXP supports mutual-authentication, integrity, and confidentiality over a connection-oriented protocol. The protocol provides for the exchange of IDMEF messages, unstructured text, and binary data. The IDMEF message elements are described in the Intrusion Detection Message Exchange Format (IDMEF) [2], a companion document of the Intrusion Detection Exchange Format (IDWG) working group of the IETF. Internet Emergency Preparedness (ieprep) ---------------------------------------- "A Framework for Supporting Emergency Telecommunications Services (ETS) Within a Single Administrative Domain", Ken Carlberg, 28-Dec-06, This document presents a framework discussing the role of various protocols and mechanisms that could be considered candidates for supporting Emergency Telecommunication Services (ETS) within a single administrative domain. Comments about their potential usage as well as their current deployment are provided to the reader. Specific solutions are not presented. Internet Engineering Steering Group (iesg) ------------------------------------------ "Guidance on Area Director Sponsoring of Documents", Jari Arkko, 7-Mar-07, This note discusses the process related to "individual submissions", publication of RFCs by finding a sponsoring Area Director to take it through IETF and Internet Engineering Steering Group (IESG) review. This note covers both the the processing in the IESG as well as guidance on when such sponsoring is appropriate. Internet Message Access Protocol Extension (imapext) ---------------------------------------------------- "INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS", Mark Crispin, Ken Murchison, 20-Nov-06, This document describes the base-level server-based sorting and threading extensions to the [IMAP] protocol. These extensions provide substantial performance improvements for IMAP clients which offer sorted and threaded views. "IMAP ANNOTATE Extension", Randall Gellens, Cyrus Daboo, 19-Oct-06, The ANNOTATE extension to the Internet Message Access Protocol permits clients and servers to maintain "meta data" for messages, or individual message parts, stored in a mailbox on the server. For example, this can be used to attach comments and other useful information to a message. It is also possible to attach annotations to specific parts of a message, so that, for example, they could be marked as seen or important, or a comment added. "IMAP4 LIST Command Extensions", Barry Leiba, Alexey Melnikov, 26-Sep-06, IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we have added extensions, such as Mailbox Referrals, that have required specialized lists we have had to expand the number of list commands, since each extension must add its function to both LIST and LSUB, and these commands are not, as they are defined, extensible. If we've needed the extensions to work together, we've had to add a set of commands to mix the different options, the set increasing in size with each new extension. This document describes an extension to the base LIST command that will allow these additions to be done with mutually compatible options to the LIST command, avoiding the exponential increase in specialized list commands. "Internet Message Access Protocol Internationalization", Arnt Gulbrandsen, Chris Newman, 7-Mar-07, Internet Message Access Protocol (IMAP) version 4rev1 has basic support for non-ASCII characters in mailbox names and search substrings. It also supports non-ASCII message headers and content encoded as specified by Multipurpose Internet Mail Extensions (MIME). This specification defines a collection of IMAP extensions which improve international support including comparator negotiation for search, sort and thread, language negotiation for international error text, and translations for namespace prefixes. Internet and Management Support for Storage (imss) -------------------------------------------------- "Fibre Channel Registered State Change Notification (RSCN) MIB", Claudio DeSanti, 10-Nov-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 information related to the management of Fibre Channel's Registered State Change Notifications (RSCNs). "Fibre-Channel Fabric Configuration Server MIB", Claudio DeSanti, 9-Jan-07, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fabric Configuration Server function of a Fibre Channel network. "Fibre-Channel Zone Server MIB", Claudio DeSanti, 24-Jan-07, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to a Fibre Channel Zone Server. Extended Incident Handling (inch) --------------------------------- "The Incident Object Description Exchange Format", Jan Meijer, 20-Sep-06, The Incident Object Description Exchange Format (IODEF) defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. This document describes the data model for the IODEF and provides the associated XML Schema. "Requirements for the Format for Incident Information Exchange (FINE)", Yuri Demchenko, 12-Jul-06, This document describes the high-level functional requirements of an abstract format, the Format for Incident information Exchange (FINE), which will facilitate the exchange of incident information among computer security incident response teams (CSIRTs) and involved parties. A common and well-defined format will help in the exchange of incident related information across different administrative domains such as organizations, regions, and countries. Implementations of FINE will also be useful for reactionary analysis of current threats and support the proactive identification of trends that can lead to incident prevention. IP over Cable Data Network (ipcdn) ---------------------------------- "Network-Based Call Signaling (NCS) MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs)", Gordon Beacham, 6-Mar-07, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it provides a common data and format representation for PacketCable and IPCablecom compliant Multimedia Terminal Adapter devices. "Management Event MIB for PacketCable/IPCablecom MTAs", Wim De Ketelaere, 23-Oct-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 provides a common data and format representation for events generated by PacketCable and IPCablecom compliant Multimedia Terminal Adapter devices. IP over DVB (ipdvb) ------------------- "Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks", Gorry Fairhurst, Marie-Jose Montpetit, 2-Mar-07, This document describes the process of binding/associating IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). This procedure is known as Address Resolution (AR), or Neighbour Discovery (ND). Such address resolution complements the higher layer resource discovery tools that are used to advertise IP sessions. In MPEG-2 Networks, an IP address must be associated with a Packet ID (PID) value and a specific Transmission Multiplex. The document reviews current methods appropriate to a range of technologies (DVB, ATSC, DOCSIS, and variants). It also describes the interaction with well-known protocols for address management including DHCP, ARP, and the ND protocol, and provides guidance on usage. "Security requirements for the Unidirectional Lightweight Encapsulation (ULE) protocol", Haitham Cruickshank, 8-Mar-07, The MPEG-2 standard defined by ISO 13818-1 [ISO-MPEG2] supports a range of transmission methods for a range of services. This document provides a threat analysis and derives the security requirements when using the Transport Stream, TS, to support an Internet network-layer using Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. The document also provides the motivation for link-level security for a ULE Stream. A ULE Stream may be used to send IPv4 packets, IPv6 packets, and other Protocol Data Units (PDUs) to an arbitrarily large number of Receivers supporting unicast and/or multicast transmission. "Extension Formats for Unidirectional Link Encapsulation (ULE) and the Generic Stream Encapsulation (GSE)", Gorry Fairhurst, Bernhard Collini-Nocker, 5-Mar-07, This document describes a set of Extension Headers for the Unidirectional Link Encapsulation (ULE) [RFC4236]. The Extension Header formats defined in this document define new extensions that are common extensions to both ULE and the Generic Stream Encapsulation (GSE) [GSE] defined by the second generation framing structure DVB-S2 standard [S2]. IP Flow Information Export (ipfix) ---------------------------------- "Architecture for IP Flow Information Export", Ganesh Sadasivan, 10-Sep-06, This memo defines the IP Flow Information eXport (IPFIX) architecture for the selective monitoring of IP flows, and for the export of measured IP flow information from an IPFIX device to a collector. "Information Model for IP Flow Information Export", Juergen Quittek, 26-Feb-07, This memo defines an information model for the IP Flow Information eXport (IPFIX) protocol. It is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process and the Exporting Process. Although developed for the IPFIX protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications. "Specification of the IPFIX Protocol for the Exchange", Benoit Claise, 9-Nov-06, This document specifies the IPFIX protocol that serves for transmitting IP traffic flow information over the network. In order to transmit IP traffic flow information from an exporting process to an information collecting process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX data and templates records are carried over a number of transport protocols from an IPFIX exporting process to an IPFIX collecting process. "IPFIX Applicability", Tanja Zseby, 7-Feb-07, This document describes the applicability of the IP Flow Information Export (IPFIX) protocol for a variety of applications. It shows how applications can use IPFIX, describes the relevant information elements (IEs) and shows opportunities and limitations of the protocol. The document furthermore describes relations of the IPFIX framework to other architectures and frameworks. "IPFIX Implementation Guidelines", Elisa Boschi, 13-Feb-07, The IP Flow Information eXport (IPFIX) protocol defines how IP Flow information can be exported from routers, measurement probes or other devices. This document provides guidelines for the implementation and use of the IPFIX protocol. Several sets of guidelines address template management, transport-specific issues, implementation of exporting and collecting processes and IPFIX implementation on middleboxes (such as firewalls, network address translators, tunnel endpoints, packet classifiers, etc.). "Reducing Redundancy in IPFIX and PSAMP Reports", Elisa Boschi, 1-Mar-07, This document describes a bandwidth saving method for exporting flow or packet information using the IP Flow Information Export (IPFIX) protocol. As the PSAMP protocol is based on IPFIX, these considerations are valid for PSAMP exports as well. This method works by separating information common to several flow records from information specific to an individual flow record. Common flow information is exported only once in a data record defined by an option template, while the rest of the specific flow information is associated with the common information via a unique identifier. "Bidirectional Flow Export using IPFIX", Brian Trammell, Elisa Boschi, 2-Mar-07, This document describes an efficient method for exporting bidirectional flow (Biflow) information using the IP Flow Information Export (IPFIX) protocol, representing each Biflow using a single Flow Record. "IP Flow Information eXport (IPFIX) Testing", Carsten Schmoll, Paul Aitken, 18-Oct-06, This document presents a list of tests which implementers of IP Flow Information Export (IPFIX) compliant systems are encouraged to perform on their IPFIX system. This document has been created to help implementers test the functionality of their IPFIX Exporter and/or Collector. The goal of these tests is to ensure that all important functions are covered by tests and thereby to gain a level of confidence in the system which allows the implementer to perform interoperability or plug tests with other IPFIX systems. "Definitions of Managed Objects for IP Flow Information Export", Thomas Dietz, 26-Feb-07, This document defines managed objects for IP Flow Information Export (IPFIX). These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors including some minor configuration information. IP over InfiniBand (ipoib) -------------------------- "Definitions of Managed Objects for InfiniBand Channel Adapters (CA)", Sean Harnedy, 22-Oct-06, InfiniBand Architecture (IBA) specifies a high speed, channel based, switched fabric architecture that delivers scalable performance in data centers. 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 InfiniBand Channel Adapters (CA). IP over Resilient Packet Rings (iporpr) --------------------------------------- "Mapping of IP/MPLS packets into IEEE 802.17 (Resilient packet ring) Networks", Marc Holness, Glenn Parsons, 21-Aug-06, This document specifies a basic standard method of encapsulating IPv4, IPv6, and MPLS datagrams into IEEE 802.17 Resilient packet ring (RPR) datagrams. IP Performance Metrics (ippm) ----------------------------- "Defining Network Capacity", Phil Chimento, Joseph Ishac, 30-Nov-06, Measuring capacity is a task that sounds simple, but in reality can be quite complex. In addition, the lack of a unified nomenclature on this subject makes it increasingly difficult to properly build, test, and use techniques and tools built around these constructs. This document provides definitions for the terms 'Capacity' and 'Available Capacity' related to IP traffic traveling between a source and destination in an IP network. By doing so, we hope to provide a common framework for the discussion and analysis of a diverse set of current and future estimation techniques. "A Two-way Active Measurement Protocol (TWAMP)", Jozef Babiarz, 2-Mar-07, The IPPM One-way Active Measurement Protocol [RFC4656] (OWAMP) provides a common protocol for measuring one-way metrics between network devices. OWAMP can be used bi-directionally to measure one-way metrics in both directions between two network elements. However, it does not accommodate round-trip or two-way measurements. This memo specifies a Two-way Active Measurement Protocol (TWAMP), based on the OWAMP, that adds two-way or round-trip measurement capabilities. The TWAMP measurement architecture is usually comprised of two hosts with specific roles, and this allows for some protocol simplifications, making it an attractive alternative in some circumstances. "IP Performance Metrics (IPPM) for spatial and multicast", Emile Stephan, 6-Mar-07, The IETF IP Performance Metrics (IPPM) working group has standardized metrics for measuring end-to-end performance between 2 points. This memo defines 2 sets of metrics to extend these end-to-end ones. It defines spatial metrics for measuring the performance of segments along a path and metrics for measuring the performance of a group of users in multiparty communications. "Spatial Composition of Metrics", Al Morton, Emile Stephan, 24-Oct-06, This memo utilizes IPPM metrics that are applicable to both complete paths and sub-paths, and defines relationships to compose a complete path metric from the sub-path metrics with some accuracy w.r.t. the actual metrics. This is called Spatial Composition in RFC 2330. The memo refers to the Framework for Metric Composition, and provides background and motivation for combining metrics to derive others. The descriptions of several composed metrics and statistics follow. "Framework for Metric Composition", Al Morton, Steven Van den Berghe, 8-Mar-07, This memo describes a framework for composing and aggregating metrics (both in time and in space) defined by RFC 2330 and developed by the IPPM working group. The framework describes the generic composition and aggregation mechanisms. It provides a basis for additional documents that implement this framework for detailed, and practically useful, compositions and aggregations of metrics. "Reporting IP Performance Metrics to Users", Stanislav Shalunov, 25-Oct-06, The aim of this document is to define a small set of metrics that are robust, easy to understand, orthogonal, relevant, and easy to compute. The IPPM WG has defined a large number of richly parameterized metrics because network measurement has many purposes. Often, the ultimate purpose is to report a concise set of metrics describing a network's state to an end user. It is for this purpose that the present set of metrics is defined. "Traceroute Measurements Information Model and XML Data Model", Saverio Niccolini, 23-Feb-07, This memo describes a standard way to store traceroute measurements. To better address the traceroute measurements storing issue, the authors first of all give a definition of the traceroute tool, describe the tool itself as well as its parameters and the default values on the most common operating systems and the output results that can be stored. Afterwards, the common information model with the base elements of the traceroute measurement storing is defined dividing the information elements in two semantically separated groups (configuration elements and results ones). Moreover an additional element is defined to relate configuration elements and results ones by means of a common unique identifier. On the basis of the information model a data model is then proposed in order to actually store the traceroute measurements. Intellectual Property Rights (ipr) ---------------------------------- "Advice to the IAOC on Rights to be Granted in IETF Documents", Joel Halpern, 23-Jan-07, The IASA is resposible for managing intellectual property rights on behalf of the IETF. This includes the license to copy, implement and otherwise use IETF contributions, among them Internet-Drafts and RFCs. The IASA accepts direction from the IETF regarding the rights to be granted. This document describes the desires of the IETF regarding outbound rights to be granted in IETF contributions. "Clarification of the 3rd Party Disclosure procedure in RFC 3979", Thomas Narten, 13-Oct-06, This document clarifies and updates a single sentence in RFC 3979. Specifically, when 3rd party IPR disclosures are made, the intention is that the IETF Executive Director notify the IPR holder that a 3rd party disclosure has been filed, and to ask the IPR holder whether they have any disclosure that needs to be made, per applicable RFC3979 rules. "Rights Contributions provide to the IETF Trust", Scott Bradner, Jorge Contreras, 1-Mar-07, The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo obsoletes RFC 3978 and, with RFC 3979 and RFC xxx (-outgoing), replaces Section 10 of RFC 2026. IP Storage (ips) ---------------- "Definitions of Managed Objects for iSNS (Internet Storage Name Service)", Kevin Gibbons, 20-Oct-06, The iSNS protocol provides storage name service functionality on an IP network that is being used for iSCSI or iFCP storage. This draft provides a mechanism to monitor multiple iSNS Servers, including information about registered objects in an iSNS Server. This memo is a product of the IP Storage (IPS) working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ips@ietf.org and/or the authors. "Datamover Architecture for iSCSI (DA)", Mallikarjun Chadalapaka, 12-Dec-06, iSCSI is a SCSI transport protocol that maps the SCSI family of application protocols onto TCP/IP. Datamover Architecture for iSCSI (DA) defines an abstract model in which the movement of data between iSCSI end nodes is logically separated from the rest of the iSCSI protocol in order to allow iSCSI to adapt to innovations available in new IP transports. While DA defines the architectural functions required of the class of Datamover protocols, it does not define any specific Datamover protocols. Each such Datamover protocol, to be defined in a separate document, provides a reliable transport for all iSCSI PDUs, but actually moves the data required for certain iSCSI PDUs without involving the remote iSCSI layer itself. This document begins with an introduction of a few new abstractions, defines a layered architecture for iSCSI and Datamover protocols, and then models the interactions within an iSCSI end node between the iSCSI layer and the Datamover layer that happen in order to transparently perform remote data movement within an IP fabric. It is intended that this definition would help map iSCSI to generic RDMA-capable IP fabrics in the future comprising TCP, SCTP, and possibly other underlying network transport layers such as InfiniBand. "iSCSI Extensions for RDMA Specification", Mike Ko, 20-Oct-05, iSCSI Extensions for RDMA provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol such as the iWARP protocol suite. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA-Capable Protocol such as the iWARP protocol suite. "iSCSI Corrections and Clarifications", Mallikarjun Chadalapaka, 20-Feb-07, iSCSI is a SCSI transport protocol and maps the SCSI family of application protocols onto TCP/IP. RFC 3720 defines the iSCSI protocol. This document compiles the clarifications to the original protocol definition in RFC 3720 to serve as a companion document for the iSCSI implementers. This document updates RFC 3720 and the text in this document supersedes the text in RFC 3720 when the two differ. "Declarative Public Extension Key for iSCSI Node Architecture", David Wysochanski, 26-Nov-06, The iSCSI protocol, described in RFC 3720 [2], allows for extension items to the protocol in the form of Private or Public Extension Keys. This Internet-Draft describes a Public Extension Key for the purpose of enhancing iSCSI supportability. The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence. The receiving node can then use this information for enhanced logging and support. This document updates RFC 3720 to allow iSCSI extension items to be defined by standards track RFCs and experimental RFCs in addition to informational RFCs. IP Security Policy (ipsp) ------------------------- "IPsec Security Policy IPsec Action MIB", Wesley Hardaker, 10-Nov-06, This document defines an SMIv2 Management Information Base (MIB) module for configuring IPsec actions for the security policy database (SPD) of a device that uses the IPsec Security Policy Database Configuration MIB for configuring the IPSec protocol actions on that device. The IPsec Action MIB integrates directly with the IPsec Security Policy Database Configuration MIB and it is meant to work within the framework of an action referenced by that MIB. "IPsec Security Policy IKE Action MIB", Wesley Hardaker, 10-Nov-06, This document defines a SMIv2 Management Information Base (MIB) module for configuring Internet Key Exchange (IKE) actions for the security policy database (SPD) of a device that uses the IPsec Security Policy Database Configuration MIB for configuring the IKE protocol actions on that device. The IPsec IKE Action MIB integrates directly with the IPsec Security Policy Database Configuration MIB and it is meant to work within the framework of an action referenced by that MIB. IP Telephony (iptel) -------------------- "A Telephony Gateway REgistration Protocol (TGREP)", Manjunath Bangalore, 11-Jan-07, This document describes the Telephony Gateway Registration Protocol (TGREP) for registration of telephony prefixes supported by telephony gateways and soft switches. The registration mechanism can also be used to export resource information. The prefix and resource information can then be passed on to a Telephony Routing over IP (TRIP) Location Server, which in turn can propagate that routing information within and between internet telephony administrative domains (ITAD). TGREP shares a lot of similarities with the TRIP Protocol. It has similar procedures and Finite State Machine for session establishment. It also shares the same format for messages and a subset of attributes with TRIP. "Representing trunk groups in tel/sip Uniform Resource Identifiers (URIs)", Cullen Jennings, Vijay Gurbani, 22-Jan-07, This document describes a standardized mechanism to convey trunk group parameters in sip and tel Uniform Resource Identifiers (URIs). An extension to the tel URI is defined for this purpose. "The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry", Cullen Jennings, Vijay Gurbani, 8-Dec-06, This document creates an Internet Assigned Number Authority (IANA) registry for tel Uniform Resource Identifier (URI) parameters and their values. It populates the registry with the parameters defined in the tel URI specification, along with the parameters in tel URI extensions defined for number portability and trunk groups. IP Version 6 Working Group (ipv6) --------------------------------- "IPv6 Stateless Address Autoconfiguration", Susan Thomson, 12-May-05, This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. "IP Version 6 over PPP", Srihari Varada, 15-Jun-05, The Point-to-Point Protocol (PPP) provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the method for sending IPv6 packets over PPP links, the NCP for establishing and configuring the IPv6 over PPP and the method for forming IPv6 link-local addresses on PPP links. It also specifies the conditions for performing Duplicate Address Detection on IPv6 global unicast addresses configured for PPP links either through stateful or stateless address autoconfiguration. This document is an update to RFC 2472 and, hence, obsoletes it. "Neighbor Discovery for IP version 6 (IPv6)", Thomas Narten, 9-Mar-07, This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", Thomas Narten, 9-Oct-06, Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers. Addresses are formed by combining network prefixes with an interface identifier. On interfaces that contain embedded IEEE Identifiers, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. IS-IS for IP Internets (isis) ----------------------------- "Routing IPv6 with IS-IS", Chris Hopps, 24-Oct-05, This draft specifies a method for exchanging IPv6 routing information using the IS-IS routing protocol. The described method utilizes 2 new TLVs, a reachability TLV and an interface address TLV to distribute the necessary IPv6 information throughout a routing domain. Using this method one can route IPv6 along with IPv4 and OSI using a single intra-domain routing protocol. "M-ISIS: Multi Topology (MT) Routing in IS-IS", Tony Przygienda, 21-Oct-05, This draft describes an optional mechanism within ISIS used today by many ISPs for IGP routing within their clouds. This draft describes how to run within a single ISIS domain a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for variety of purposes such as an in-band management network ``on top'' of the original IGP topology, maintain separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or force a subset of an address space to follow a different topology. "Point-to-point operation over LAN in link-state routing protocols", Naiming Shen, 20-Apr-06, The two predominant circuit types used by link state routing protocols are point-to-point and broadcast. It is important to identify the correct circuit type when forming adjacencies, flooding link state database packets, and representing the circuit topologically. This document describes a simple mechanism to treat the broadcast network as a point-to-point connection from the standpoint of IP routing. "A Policy Control Mechanism is IS-IS Using Administrative Tags", Christian Martin, Brad Neal, Stefano Previdi, 11-Feb-05, This document describes an extension to the IS-IS protocol to add operational capabilities that allow for ease of management and control over IP prefix distribution within an IS-IS domain. This document enhances the IS-IS protocol by extending the information that a Intermediate System (IS) [router] can place in Link State Protocol Data Units (LSPs) for policy use. This extension will provide operators with a mechanism to control IP prefix distribution throughout multi-level IS-IS domains. Additionally, the information can be placed in LSPs that have TLVs as yet undefined, if this information is used to convey the same meaning in these future TLVs as it is used in the currently defined TLVs. "Definition of an IS-IS Link Attribute sub-TLV", JP Vasseur, Stefano Previdi, 7-Feb-07, This document defines a sub-TLV called "Link-attributes" carried within the TLV 22 and used to flood some link characteristics. "IS-IS Extensions for Advertising Router Information", JP Vasseur, 15-Feb-07, This document defines a new optional IS-IS TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. "IS-IS HMAC SHA Cryptographic Authentication", Manav Bhatia, 26-Feb-07, This document proposes an extension to IS-IS to allow the use of any cryptographic authentication algorithm in addition to the already documented authentication schemes, described in the base specification and RFC 3567. Although this document has been written specifically for using MAC construct along with the SHA family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future. "Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", Kireeti Kompella, Yakov Rekhter, 15-Nov-06, This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). Integrated Security Model for SNMP (isms) ----------------------------------------- "Secure Shell Transport Model for SNMP", Joseph Salowey, David Harrington, 11-Oct-06, This memo describes a Transport Model for the Simple Network Management Protocol, using the Secure Shell protocol. "Transport Subsystem for the Simple Network Management Protocol (SNMP)", David Harrington, Juergen Schoenwaelder, 7-Mar-07, This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document defines a subsystem to contain Transport Models, comparable to other subsystems in the RFC3411 architecture. As work is being done to expand the transport to include secure transport such as SSH and TLS, using a subsystem will enable consistent design and modularity of such Transport Models. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. "Transport Security Model for SNMP", David Harrington, 23-Feb-07, This memo describes a Transport Security Model for the Simple Network Management Protocol. Kitten (GSS-API Next Generation) (kitten) ----------------------------------------- "GSS-API Domain-Based Service Names and Name Type", Nicolas Williams, 13-Sep-06, This document describes domainname-based service principal names and the corresponding name type for the Generic Security Service Application Programming Interface (GSS-API). Domain-based service names are similar to host-based service names, but using a domain name (not necessarily an Internet domain name) in addition to a hostname. The primary purpose of domain-based names is to provide a measure of protection to applications that utilize insecure service discovery protocols. This is achieved by providing a way to name clustered services after the "domain" which they service, thereby allowing their clients to authorize the service's servers based on authentication of their service names. "GSS-API Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism", Nicolas Williams, 13-Sep-06, This document describes the mapping of GSS-API domainname-based service principal names onto Kerberos V principal names. "GSS-API Extension for Storing Delegated Credentials", Nicolas Williams, 20-Oct-06, This document defines a new function for the GSS-API which allows applications to store delegated (and other) credentials in the implicit GSS-API credential store. This is needed for GSS-API applications to use delegated credentials as they would use other credentials. Kerberos (krb-wg) ----------------- "Generating KDC Referrals to Locate Kerberos Realms", Larry Zhu, Kenneth Raeburn, 7-Mar-07, The memo documents a method for a Kerberos Key Distribution Center (KDC) to respond to client requests for Kerberos tickets when the client does not have detailed configuration information on the realms of users or services. The KDC will handle requests for principals in other realms by returning either a referral error or a cross-realm TGT to another realm on the referral path. The clients will use this referral information to reach the realm of the target principal and then receive the ticket. "Passwordless Initial Authentication to Kerberos by Hardware Preauthentication", Matt Crawford, 23-Oct-06, This document specifies an extension to the Kerberos protocol for performing initial authentication of a user without using that user's long-lived password. Any "hardware preauthentication" method may be employed instead of the password, and the key of another principal must be nominated to encrypt the returned credential. "Kerberos Set/Change Key/Password Protocol Version 2", Nicolas Williams, 7-Mar-07, This document specifies an extensible protocol for setting keys and changing the passwords of Kerberos V principals. "A Generalized Framework for Kerberos Pre-Authentication", Larry Zhu, Sam Hartman, 7-Mar-07, Kerberos is a protocol for verifying the identity of principals (e.g., a workstation user or a network server) on an open network. The Kerberos protocol provides a mechanism called pre-authentication for proving the identity of a principal and for better protecting the long-term secret of the principal. This document describes a model for Kerberos pre-authentication mechanisms. The model describes what state in the Kerberos request a pre-authentication mechanism is likely to change. It also describes how multiple pre-authentication mechanisms used in the same request will interact. This document also provides common tools needed by multiple pre- authentication mechanisms. One of these tools is a secure channel between the client and the KDC with a reply key delivery mechanism; this secure channel can be used to protect the authentication exchange thus eliminate offline dictionary attacks. With these tools, it is straightforward to chain multiple authentication mechanisms, utilize a different key management system, or support a new key agreement algorithm. "The Kerberos Network Authentication Service (Version 5)", Tom Yu, 7-Mar-07, This document specifies version 5 of the Kerberos network authentication protocol. It obsoletes RFC 4120, and in addition to providing a detailed description of the protocol, it describes a framework to allow for extensions to be made to the protocol without creating interoperability problems. "ECC Support for PKINIT", Larry Zhu, 5-Mar-07, This document describes the use of Elliptic Curve certificates, Elliptic Curve signature schemes and Elliptic Curve Diffie-Hellman (ECDH) key agreement within the framework of PKINIT - the Kerberos Version 5 extension that provides for the use of public key cryptography. "Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges Over TCP", Simon Josefsson, 14-Sep-06, This document describes an extensibility mechanism for the Kerberos V5 protocol when used over TCP transports. The mechanism uses the reserved high-bit in the length field. It can be used to negotiate TCP-specific Kerberos extensions. "Anonymity Support for Kerberos", Larry Zhu, 5-Mar-07, This document defines extensions to the Kerberos protocol for the Kerberos client to authenticate the Kerberos Key Distribution Center and the Kerberos server, without revealing the client's identity. These extensions can be used to secure communication between the anonymous client and the server. "Additional Kerberos Naming Constraints", Larry Zhu, 7-Mar-07, This document defines new naming constraints for well-known Kerberos principal name and well-known Kerberos realm names. "PK-INIT Cryptographic Algorithm Agility", Love Hornquist Astrand, Larry Zhu, 7-Mar-07, The PK-INIT defined in RFC 4556 is examined and updated to remove protocol structures tied to specific cryptographic algorithms. The affinity to SHA as the check-sum algorithm in the authentication request is analyzed. The PK-INIT key derivation function is made negotiable, the digest algorithms for signing the pre-authentication data and the client's X.509 certificates are made discoverable. These changes provide protection preemptively against vulnerabilities discovered in the future against any specific cryptographic algorithm, and allow incremental deployment of newer algorithms. "Kerberos Version 5 GSS-API Channel Binding Hash Agility", Sean Emery, 8-Mar-07, Currently, the Kerberos Version 5 Generic Security Services Application Programming Interface (GSS-API) mechanism [RFC4121] does not have the ability to utilize better hash algorithms used to generate channel binding identities. The current mechanism for doing this is hard coded to use MD5 only. The purpose of this document is to outline changes required to update the protocol so that more secure algorithms can be used to create channel binding identities. The extensibility of this solution also provides an eventual replacement of identities based solely on hash algorithms. Layer 1 Virtual Private Networks (l1vpn) ---------------------------------------- "Framework and Requirements for Layer 1 Virtual Private Networks", Tomonori Takeda, 10-Jan-07, This document provides a framework and service level requirements for Layer 1 Virtual Private Networks (L1VPNs). This framework is intended to aid in developing and standardizing protocols and mechanisms to support interoperable L1VPNs. The document examines motivations for L1VPNs, high level (service level) requirements, and outlines some of the architectural models that might be used to build L1VPNs. "BGP-based Auto-Discovery for L1VPNs", Hamid Ould-Brahim, 24-Oct-06, The purpose of this draft is to define a BGP-based auto- discovery mechanism for layer-1 VPNs. The auto-discovery mechanism for l1vpns allows the provider network devices to dynamically discover the set of PEs having ports attached to CEs member of the same VPN. That information is necessary for completing the signaling phase. One main objective of l1vpn auto-discovery mechanism is to support "single-end provisioning" model, where addition of a new port to a given l1vpn would involve configuration changes only on the PE that has this port and on the CE that is connected to the PE via this port. "Layer 1 VPN Basic Mode", Don Fedyk, 25-Oct-06, This draft describes the basic mode of Layer 1 VPNs (L1VPN BM) that is port based VPNs. In L1VPN BM, the basic unit of service is a Label Switched Path (LSP) between a pair of customer ports within a given VPN port-topology. This draft defines the operational model using either provisioning or a VPN auto-discovery mechanism and the signaling extensions for the L1VPN BM. "OSPF Based L1VPN Auto-Discovery", Igor Bryskin, Lou Berger, 2-Mar-07, This document defines an OSPF based layer-1 VPN auto-discovery mechanism. This mechanism enables PEs using the OSPF IGP to dynamically learn about existence of each other, and attributes of currently configured CE-PE links and their associations with L1VPNs. This document builds on [L1VPN-FRMWK] and provides an auto-discovery mechanism as discussed in [L1VPN-BM]. "Applicability analysis of Generalized Multiprotocol Label Switching (GMPLS) protocols for the Layer 1 Virtual Private Network (L1VPN) Enhanced Mode", Tomonori Takeda, 15-Nov-06, This document provides an applicability analysis on the use of Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms to satisfy the requirements of the Layer 1 Virtual Private Network (L1VPN) Enhanced Mode. L1VPNs provide customer services and connectivity at layer 1 over layer 1 networks. The operation of L1VPNs is divided into the Basic Mode and the Enhanced Mode, where the Enhanced Mode of operation features exchange of routing information between the layer 1 network and the customer domain. In addition, this document identifies areas where additional protocol extensions or procedures are needed to satisfy the requirements of the L1VPN Enhanced Mode, and provides guidelines for potential extensions. "Applicability Statement for Layer 1 Virtual Private Networks (L1VPNs) Basic Mode", Tomonori Takeda, 6-Mar-07, This document provides an applicability statement on the use of Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms to support Basic Mode Layer 1 Virtual Private Networks (L1VPNs). L1VPNs provide customer services and connectivity at layer 1 over layer 1 networks. The operation of L1VPNs is divided into the Basic Mode and the Enhanced Mode where the Basic Mode of operation does not feature any exchange of routing information between the layer 1 network and the customer domain. This document examines how GMPLS protocols can be used to satisfy the requirements of a Basic Mode L1VPN. Layer Two Tunneling Protocol Extensions (l2tpext) ------------------------------------------------- "PPP Tunneling Using Layer Two Tunneling Protocol Version 3 (L2TPv3)", Carlos Pignataro, 20-Nov-06, This document describes the use of "version 3" of Layer Two Tunneling Protocol (L2TPv3) to tunnel Point-to-Point Protocol (PPP) packets. This document defines the control protocol and encapsulation specifics for tunneling PPP over L2TPv3, and is a companion document to the L2TPv3 base specification. "PPP over L2TP Tunnel Switching", Vipin Jain, 2-Mar-07, PPP [7] over L2TP Tunnel Switching, also called L2TP Multihop, is the process of forwarding PPP payload from an L2TP session to another L2TP session over a different tunnel. It facilitates moving the logical termination point of an L2TP session, based on layer 2 characteristics or administrative policies, to different L2tp Endpoint. This document introduces the L2TP tunnel switching nomenclature and defines the behavior of standard AVPs in tunnel switching deployment. The scope of this document is limited to the discussion of switching PPP frames over L2TPv2 or L2TPv3 tunnels. "Fail Over extensions for L2TP "failover"", Vipin Jain, 21-Feb-07, L2TP is a connection-oriented protocol that has shared state between active endpoints. Some of this shared state is vital for operation but may be rather volatile in nature, such as packet sequence numbers used on the L2TP Control Connection. When failure of one side of a control connection occurs, a new control connection is created and associated with the old connection by exchanging information about the old connection. Such a mechanism is not intended as a replacement for an active fail over with some mirrored connection states, but as an aid just for those parameters that are particularly difficult to have immediately available. Protocol extensions to L2TP defined in this document are intended to facilitate state recovery, providing additional resiliency in an L2TP network and improving a remote system's layer 2 connectivity. "Layer Two Tunneling Protocol (Version 3) "L2TPv3" Management Information Base", Evan Caves, 7-Sep-06, This document describes a portion of the Management Information Base (MIB) to manage the Layer Two Tunneling Protocol, Version 3 (L2TPv3). "Layer Two Tunneling Protocol - Setup of TDM Pseudowires", Sharon Galtzur, Alexander Vainshtein, 5-Mar-07, This document defines extensions to the Layer Two Tunneling Protocol (L2TP) for support of structure-agnostic [RFC4553] and structure- aware [PWE3-CESoPSN] pseudowires. "Signaling and Encapsulation for the Transport of IP over L2TPv3", Carlos Pignataro, Wei Luo, 14-Feb-07, The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of data link protocols over IP networks. This document defines the control messaging, signaling procedures and encapsulation specifics of how to tunnel IPv4 and IPv6 packets directly over L2TPv3. "L2TP Proxy Authenticate Extensions for EAP", Manesh Kelkar, 2-Mar-07, L2TP [1] and [6] defines Proxy Authentication AVPs that MAY be exchanged during session establishment, to provide forwarding of PPP authentication information obtained at the LAC to the LNS for validation. This document defines contents of this PPP authenticate information for the Extensible Authentication Protocol (EAP). Layer 2 Virtual Private Networks (l2vpn) ---------------------------------------- "Provisioning, Autodiscovery, and Signaling in L2VPNs", Eric Rosen, 5-May-06, Provider Provisioned Layer 2 Virtual Private Networks (L2VPNs) may have different "provisioning models", i.e., models for what information needs to be configured in what entities. Once configured, the provisioning information is distributed by a "discovery process". When the discovery process is complete, a signaling protocol is automatically invoked to set up the mesh of Pseudowires (PWs) that form the (virtual) backbone of the L2VPN. This document specifies a number of L2VPN provisioning models, and further specifies the semantic structure of the endpoint identifiers required by each model. It discusses the distribution of these identifiers by the discovery process, especially when discovery is based on the Border Gateway Protocol (BGP). It then specifies how the endpoint identifiers are carried in the two signaling protocols that are used to set up PWs, the Label Distribution Protocol (LDP) and the Layer 2 Tunneling Protocol (L2TPv3). "L2VPN OAM Requirements and Framework", Dinesh Mohan, Ali Sajassi, 6-Mar-07, This draft provides framework and requirements for Layer 2 Virtual Private Networks (L2VPN) Operation, Administration and Maintenance (OAM). The OAM framework is intended to provide OAM layering across L2VPN services, Pseudo Wires (PWs) and Packet Switched Network (PSN) tunnels. The requirements are intended to identify OAM requirement for L2VPN services (i.e. VPLS, VPWS, and IPLS). Furthermore, if L2VPN services OAM requirements impose specific requirements on PW OAM and/or PSN OAM, those specific PW and/or PSN OAM requirements are also identified. "Requirements for Multicast Support in Virtual Private LAN Services", Yuji Kamite, 6-Mar-07, This document provides functional requirements for network solutions that support multicast over Virtual Private LAN Service (VPLS). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions will use these requirements as guidelines. "Multicast in VPLS", Rahul Aggarwal, 9-Mar-07, This document describes a solution for overcoming a subset of the limitations of existing VPLS multicast solutions. It describes procedures for VPLS multicast that utilize multicast trees in the sevice provider (SP) network. One such multicast tree can be shared between multiple VPLS instances. Procedures by which a single multicast tree in the backbone can be used to carry traffic belonging only to a specified set of one or more IP multicast streams from one or more VPLSs are also described. "VPLS Interoperability with CE Bridges", Ali Sajassi, 8-Nov-06, One of the main motivations behind VPLS is its ability to provide connectivity not only among customer routers and servers/hosts but also among customer bridges. If only connectivity among customer IP routers/hosts was desired, then IPLS solution [IPLS] could have been used. The strength of the VPLS solution is that it can provide connectivity to both bridge and non-bridge types of CE devices. VPLS is expected to deliver the same level of service that current enterprise users are accustomed to from their own enterprise bridged networks today or the same level of service that they receive from their Ethernet Service Providers using IEEE 802.1ad-based networks [P802.1ad] (or its predecessor – QinQ-based network). When CE devices are IEEE bridges, then there are certain issues and challenges that need to be accounted for in a VPLS network. Majority of these issues have currently been addressed in IEEE 802.1ad standard for provider bridges and they need to be addressed for VPLS networks. This draft discusses these issues and wherever possible, the recommended solutions to these issues. "PIM Snooping over VPLS", Venu Hemige, 7-Mar-07, In Virtual Private LAN Service (VPLS), as also in IEEE Bridged Networks, the switches simply flood multicast traffic on all ports in the LAN by default. IGMP Snooping is commonly deployed to ensure multicast traffic is not forwarded on ports without IGMP receivers. The procedures and recommendations for IGMP Snooping are defined in [IGMP-SNOOP]. But when any protocol other than IGMP is used, the common practice is to simply flood multicast traffic to all ports. PIM-SM, PIM-SSM, PIM-BIDIR are widely deployed routing protocols. PIM Snooping procedures are important to restrict multicast traffic to only the routers interested in receiving such traffic. While most of the PIM Snooping procedures defined here also apply to IEEE Bridged Networks, VPLS demands certain special procedures due to the split-horizon rules that require the Provider Edge (PE) devices to co-operate. This document describes the procedures and recommendations for PIM-Snooping in VPLS to facilitate replication to only those ports behind which there are interested PIM routers and/or IGMP hosts. This document also describes procedures for PIM Proxy. PIM Proxy is required on PEs for VPLS Multicast to work correctly when Join suppression is enabled in the VPLS. PIM Proxy also helps scale VPLS Multicast much better than just PIM Snooping. Layer 3 Virtual Private Networks (l3vpn) ---------------------------------------- "An Architecture for Provider Provisioned CE-based Virtual Private Networks using IPsec", Jeremy De Clercq, 20-Dec-05, This informational document describes procedures for a Service Provider to offer Virtual Private Network Services to its customers by provisioning the CE devices on behalf of the customer. The IPsec technology is used to protect the customer traffic. "Architecture for the Use of PE-PE IPsec Tunnels in BGP/MPLS IP VPNs", Eric Rosen, 8-Aug-05, In BGP/MPLS IP Virtual Private Networks (VPNs), VPN data packets traveling from one Provider Edge (PE) router to another generally carry two MPLS labels, an "inner" label that corresponds to a VPN- specific route, and an "outer" label that corresponds to a Label Switched Path (LSP) between the PE routers. In some circumstances, it is desirable to support the same type of VPN architecture, but using an IPsec Security Association in place of that LSP. The "outer" MPLS label would thus be replaced by an IP/IPsec header. This enables the VPN packets to be carried securely over non-MPLS networks, using standard IPsec authentication and/or encryption functions to protect them. This draft specifies the procedures which are specific to support of BGP/MPLS IP VPNs using the IPsec encapsulation. "Using BGP as an Auto-Discovery Mechanism for VR-based Layer-3 VPNs", Hamid Ould-Brahim, 26-Sep-06, In any provider-based VPN scheme, the Provider Edge (PE) devices attached to a common VPN must exchange certain information as a prerequisite to establish VPN-specific connectivity. The main purpose of an auto-discovery mechanism is to enable a PE to dynamically discover the set of remote PEs having VPN members in common. The auto-discovery mechanism proceeds by having a PE advertises to other PEs, at a minimum, its own IP address and the list of VPN members configured on that PE. Once that information is received the remote PEs will then identify the list of VPN sites members of the same VPN, and use the information carried within the discovery mechanism to establish VPN connectivity. This draft defines a BGP based auto-discovery mechanism for Virtual Router-based layer-3 VPNs. This mechanism is based on the approach used by BGP/MPLS-IP-VPN for distributing VPN routing information within the service provider(s). "Network based IP VPN Architecture Using Virtual Routers", Hamid Ould-Brahim, 6-Mar-06, This document describes a network-based Virtual Private Network (VPN) architecture using the virtual router (VR) concept. Multiple VRs can exist in a single physical device. A VR emulates all the functionality of a physical router, and therefore inherits all existing mechanisms and tools for configuration, operation, accounting, and maintenance. Any routing protocol can be used to distribute VPN reachability information among VRs, and no VPN- related modifications or extensions are needed to the routing protocol for achieving VPN reachability. Direct VR-to-VR connectivity may be configured through layer-2 links or through IP- or MPLS-based tunnels. Traffic from VRs belonging to different VPNs may be aggregated over a "backbone VR" network, which greatly simplifies VPN provisioning. This architecture accommodates various backbone deployment scenarios, both where the VPN service provider owns the backbone, and where the VPN service provider obtains backbone service from one or more other service providers. "Virtual Router Management Information Base Using SMIv2", Elwin Stelzer, 1-Aug-05, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing networks using Virtual Routers (VR). "Applicability Statement for Virtual Router-based Layer 3 PPVPN Approaches", Ananth Nagarajan, 29-Aug-06, This document is an applicability statement for Layer 3 Provider Provisioned VPNs (L3 PPVPNs) that are based on Virtual Router (VR) approaches. This document describes how VR-based approaches meet the key requirements that are outlined in the PPVPN Applicability Statements Guideline document. "Applicability Statement for Provider Provisioned CE-based Virtual Private Networks using IPsec", Jeremy DeClercq, 27-Jan-04, This document is an applicability statement for Provider Provisioned CE-based IPsec VPNs, as discribed in [CEVPN]. This document describes how provider provisioned CE-based approaches meet the key requirements that are outlined in the PPVPN Applicability Statements Guideline document [ASGUIDE] and the key security requirements according to the template in section 8 of the VPN security framework document [SEC-FW]. "Requirements for Multicast in L3 Provider-Provisioned VPNs", Thomas Morin, 13-Nov-06, This document presents a set of functional requirements for network solutions that allow the deployment of IP multicast within L3 Provider Provisioned Virtual Private Networks (PPVPNs). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions specifying the support of IP multicast within such VPNs will use these requirements as guidelines. "Multicast in MPLS/BGP IP VPNs", Eric Rosen, Rahul Aggarwal, 19-Oct-06, In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document. "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", Rahul Aggarwal, 2-Mar-07, This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in [MVPN]. Enhancements to Internet email to Support Diverse Service Environments (lemonade) --------------------------------------------------------------------------------- "IMAP URL Scheme", Alexey Melnikov, 29-Jan-07, IMAP [IMAP4] is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mail- ing list archives as well as private and shared message stores. This document defines a URL scheme for referencing objects on an IMAP server. "CONVERT", Stephane Maes, Ray Cromwell, 26-Oct-06, CONVERT defines IMAP extensions allowing clients to request adaptation and/or transcoding of attachments. Clients can specify the conversion details or allow servers to decide based on knowledge of client capabilities, on user or administrator preferences or its settings. "Support for Sieve in Internet Message Access Protocol (IMAP4)", Barry Leiba, 8-Mar-07, Sieve defines an email filtering language that can, in principle, plug into any point in the processing of an email message. As defined in the base specification, it plugs into mail delivery. This document defines how Sieve can plug into points in the IMAP protocol where messages are created or changed, adding the option of user- defined or installation-defined filtering (or, with Sieve extensions, features such as notifications). "LEMONADE profile bis", Stephane Maes, 20-Oct-06, This document describes the LEMONADE profile. It contains pointers to or descriptions of all the features that are normatively part of this version of the LEMONADE profile. This document describes a profile (a set of required extensions, restrictions and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission and to efficiently resynchronize in case of loss of connectivity with the server. The Lemonade profile relies upon extensions to IMAP and Mail Submission protocols; specifically URLAUTH and CATENATE IMAP protocol extensions and BURL extension to the SUBMIT protocol. "WITHIN Search extension to the IMAP Protocol", Stephane Maes, 9-Mar-07, This document describes the WITHIN extension to IMAP SEARCH. IMAP SEARCH returns messages whose internal date is within or outside a specified interval. The mechanism described here, OLDER and YOUNGER, differs from BEFORE and SINCE in that the client specifies an interval, rather than a date. We expect WITHIN to be most useful for persistent searches from mobile devices. "The IMAP COMPRESS Extension", Arnt Gulbrandsen, 18-Jan-07, The COMPRESS extension allows an IMAP connection to be effectively and efficiently compressed. "Deployment Considerations for lemonade-compliant Mobile Email", Randall Gellens, 8-Mar-07, This document discusses deployment issues and describes requirements for successful deployment of mobile email which are implicit in the IETF lemonade documents. "Internet Message Store Events", Chris Newman, 5-Mar-07, One of the missing features in the existing Internet mail and messaging standards is a facility for server-to-server and server-to- client event notifications related to message store events. As the scope of Internet mail expands to support more diverse media (such as voice mail), devices (such as cell phones) and to provide rich interactions with other services (such as web portals and legal compliance systems), the need for an interoperable notification system increases. This document attempts to enumerate the types of events which interest real-world consumers of such a system. "Streaming Multimedia Messaging Attachments", Neil Cook, 8-Mar-07, This document describes a method for streaming multimedia attachments received by a resource constrained and/or mobile device from an IMAP server. It allows such clients, which often have limits in storage space and bandwidth, to play video and audio e-mail content. The document describes a profile for making use of the IMAP URLAUTH extension (RFC 4467), the Network Announcement SIP Media Service (RFC 4240), and the Media Server Control Markup Language (RFC 4722). The document also defines a new IMAP METADATA entry. "IMAP4 Extensions for Quick Mailbox Resynchronization", Alexey Melnikov, 28-Feb-07, This document defines an IMAP4 extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox as part of the SELECT command, without the need for server-side state or additional client round-trips. This extension also introduces a new response that allows for a more compact representation for a list of expunged messages. Long-Term Archive and Notary Services (ltans) --------------------------------------------- "Long-Term Archive Service Requirements", Carl Wallace, 14-Dec-06, There are many scenarios in which users must be able to prove the existence of data at a specific point in time and be able to demonstrate the integrity of data since that time, even when the duration from time of existence to time of demonstration spans a large period of time. Additionally, users must be able to verify signatures on digitally signed data many years after the generation of the signature. This document describes a class of long-term archive services to support such scenarios and the technical requirements for interacting with such services. "Evidence Record Syntax (ERS)", Ralf Brandner, 8-Mar-07, In many scenarios, users must be able prove the existence and integrity of data, including digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. This document specifies the syntax and processing of an Evidence Record, a structure designed to support long-term non- repudiation of existence of data. "Long-term Archive Protocol (LTAP)", Aleksej Jerman-Blazic, 5-Mar-07, This document describes a service operated as a trusted third party to securely archive electronic document called a long-term archive service (LTA). We describe an architecture framework and a protocol allowing clients to interact with such a service. Bindings to concrete transport and security protocol layers are given. . "Using SCVP to Convey Long-term Evidence Records", Carl Wallace, 13-Feb-07, The Simple Certificate Validation Protocol (SCVP) defines an extensible means of delegating the development and validation of certification paths to a server. It can be used to support the development and validation of certification paths well after the expiration of the certificates in the path by specifying a time of interest in the past. The Evidence Record Syntax (ERS) defines structures, called evidence records, to support non-repudiation of existence of data. Evidence records can be used to preserve materials that comprise a certification path such that trust can be established in the certificates after the expiration of the certificates in the path and after the cryptographic algorithms used to sign the certificates in the path are no longer secure. This document describes an application of SCVP to serve this purpose using the WantBack feature of SCVP to convey evidence records. "Infrastructure Support for Retention of PKI Artifacts", Carl Wallace, 26-Oct-06, In most PKIs, directory servers are used to provide current certificates and revocation information to relying parties. In situations where certificates must be validated relative to a time in the past, relying parties often have no means of obtaining the necessary PKI artifacts. This specification defines several directory attributes to support validation using historical PKI artifacts. "Verification Data", Tobias Gondrom, 29-Jan-07, Digitally signed documents and data in a LTANS service receive the signature renwal procedures and non-repudiation services. As documents can be stored for very long (theoretically inifinite) times, it is very important to understand which data is and will be necessary for the verification of the contained digital signatures and the applied timestamps and the evidence records. This document shall describe various pieces of information which SHOULD and MUST be provided to effectively verify evidence records and their protected data and signatures. "LTANS Architecture", Tobias Gondrom, 18-Oct-06, This documents outlines best practices how to use and integrate components based on the various specifications prepared by the LTANS WG for long term archiving and non-repudiation services can work together in a best practices environment. It especially takes care of the overall architecture and integration of the protocol and the data structures. "Extensible Markup Language Evidence Record Syntax", A. Jerman Blazic, 26-Feb-07, In many scenarios, users must be able to demonstrate the (time) existence, integrity and validity of data including signed data for long or undetermined period of time. This document specifies XML syntax and processing rules for creating evidence for long-term non- repudiation of existence of data. ERS-XML incorporates alternative syntax and processing rules to ASN.1 ERS syntax by using XML language. Language Tag Registry Update (ltru) ----------------------------------- "Tags for Identifying Languages", Addison Phillips, Mark Davis, 19-Dec-06, This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. "Update to the Language Subtag Registry", Doug Ewell, 15-Jan-07, This memo defines the procedure used to update the IANA Language Subtag Registry in conjunction with the publication of RFC 4646bis [RFC EDITOR NOTE: replace with actual RFC number], for use in forming tags for the identification of languages. As an Internet-Draft, it also contained a complete replacement of the contents of the Registry to be used by IANA in updating it. To prevent confusion, this material was removed before publication. Multicast & Anycast Group Membership (magma) -------------------------------------------- "IGMPv3/MLDv2 and Multicast Routing Protocol Interaction", Brian Haberman, Jay Martin, 27-Oct-03, The definitions of IGMPv3 and MLDv2 require new behavior within the multicast routing protocols. The additional source information contained in IGMPv3 and MLDv2 messages necessitates multicast routing protocols to manage and utilize the information. This document will describe how multicast routing protocols will interact with these source-filtering group management protocols. "Multicast Group Membership Discovery MIB", Julian Chesterfield, 8-Mar-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 objects used for managing the Internet Group Management Protocol (IGMP) and the Multicast Listener Discovery (MLD) protocol. Mobile Ad-hoc Networks (manet) ------------------------------ "Dynamic MANET On-demand (DYMO) Routing", Charlie Perkins, Ian Chakeres, 5-Mar-07, The Dynamic MANET On-demand (DYMO) routing protocol is intended for use by mobile nodes in wireless, multihop networks. It offers adaptation to changing network topology and determines unicast routes between nodes within the network in an on-demand fashion. "Simplified Multicast Forwarding for MANET", Joseph Macker, 6-Mar-07, This document describes the Simplified Multicast Forwarding (SMF) protocol that provides a basic IP multicast forwarding capability suitable for mobile ad-hoc networks (MANET). SMF is designed to have limited applicability as a forwarding mechanism for multicast packets within MANET routing areas. In addition, it provides mechanisms to support interoperability with a connected fixed-infrastructure networks. SMF uses a simplified forwarding mechanism that delivers multicast packets to all MANET multicast receivers within a MANET routing area. The core design does not use receiver specific group information in favor of reduced complexity and state maintenance within the mobile topology. Group-specific forwarding can be supported through appropriate forwarding filters and related extensions may follow in later specifications. The design accounts for the unique nature and behavior of MANET interfaces and takes advantage of efficient relay set algorithms previously designed and applied in the MANET routing control plane. This document describes the SMF forwarding mechanisms in detail, its use with the MANET Neighborhood Discovery Protocol (NHDP), and several efficient relay set algorithms specified for use in conjunction with SMF. "The Optimized Link State Routing Protocol version 2", Thomas Clausen, 2-Mar-07, This document describes version 2 of the Optimized Link State Routing (OLSRv2) protocol for mobile ad hoc networks. The protocol embodies an optimization of the classical link state algorithm tailored to the requirements of a mobile ad hoc network (MANET). The key optimization of OLSRv2 is that of multipoint relays, providing an efficient mechanism for network-wide broadcast of link state information (i.e. reducing the cost of performing a network- wide link state broadcast). A secondary optimization is that OLSRv2 employs partial link state information: each node maintains information about all destinations, but only a subset of links. Consequently, only selected nodes diffuse link state advertisements (thus reducing the number of network-wide link state broadcasts) and these advertisements contain only a subset of links (thus reducing the size of network-wide link state broadcasts). The partial link state information thus obtained still allows each OLSRv2 node to at all times maintain optimal (in terms of number of hops) routes to all destinations in the network. OLSRv2 imposes minimum requirements on the network by not requiring sequenced or reliable transmission of control traffic. Furthermore, the only interaction between OLSRv2 and the IP stack is routing table management. OLSRv2 is particularly suitable for large and dense networks as the technique of MPRs works well in this context. "Generalized MANET Packet/Message Format", Thomas Clausen, 2-Mar-07, This document specifies a multi-message packet format that may be used by mobile ad hoc network routing and other protocols. "MANET Neighborhood Discovery Protocol (NHDP)", Thomas Clausen, 2-Mar-07, This document describes a 1-hop and symmetric 2-hop neighborhood discovery protocol (NHDP) for mobile ad hoc networks (MANETs). "MANET IANA Needs", Ian Chakeres, 26-Feb-07, This document enumerates IANA assignments for immediate use in MANET. Specifically, a UDP port, two link-local multicast group addresses (IPv4 & IPv6), and two site-local multicast group addresses (IPv4 & IPv6). MBONE Deployment (mboned) ------------------------- "Automatic IP Multicast Without Explicit Tunnels (AMT)", Dave Thaler, 20-Nov-06, Automatic Multicast Tunneling (AMT) allows multicast communication amongst isolated multicast-enabled sites or hosts, attached to a network which has no native multicast support. It also enables them to exchange multicast traffic with the native multicast infrastructure and does not require any manual configuration. AMT uses an encapsulation interface so that no changes to a host stack or applications are required, all protocols (not just UDP) are handled, and there is no additional overhead in core routers. "Unicast-Prefix-based IPv4 Multicast Addresses", Dave Thaler, 7-Mar-07, This specification defines an extension to the multicast addressing architecture of the IP Version 4 protocol. The extension presented in this document allows for unicast-prefix-based allocation of multicast addresses. By delegating multicast addresses at the same time as unicast prefixes, network operators will be able to identify their multicast addresses without needing to run an inter-domain allocation protocol. "Overview of the Internet Multicast Addressing Architecture", Pekka Savola, 19-Oct-06, The lack of up-to-date documentation on IP multicast address allocation and assignment procedures has caused a great deal of confusion. To clarify the situation, this memo describes the allocation and assignment techniques and mechanisms currently (as of this writing) in use. "Requirements for Accounting, Authentication and Authorization in Well Managed IP Multicasting Services", Haixiang He, 10-Feb-06, This memo presents requirements in the area of accounting and access control for multicasting. General requirements for accounting capabilities including quality-of-service (QoS) related issues are listed. Finally, cases for Content Delivery Services (CDS) are described as application examples which could benefit from multicasting accounting and access control capabilities as described in the I-D. It is proposed that this I-D be used as a starting point for further discussion on these issues. "Overview of the Internet Multicast Routing Architecture", Pekka Savola, 26-Nov-06, The lack of up-to-date documentation on IP multicast routing protocols and procedures has caused a great deal of confusion. To clarify the situation, this memo describes the routing protocols and techniques currently (as of this writing) in use. This memo also Obsoletes and reclassifies to Historic a number of older multicast protocols. "IP Multicast MIB", David McWalter, 2-Mar-07, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing multicast function, independent of the specific multicast protocol(s) in use. This document obsoletes RFC 2932. "AAA Framework for Multicasting", Hiroaki Satou, 25-Oct-06, IP multicast-based services, such as TV broadcasting or videoconferencing raise the issue of making sure that potential customers are fully entitled to access the corresponding contents. There is indeed a need for service and content providers to identify (if not authenticate, especially within the context of enforcing electronic payment schemes) and to invoice such customers in a reliable and efficient manner. This memo describes the framework for specifying the Authorization, Authentication and Accounting (AAA) capabilities that could be activated within the context of the deployment and the operation of IP multicast-based services. This framework addresses the requirements presented in draft-ietf-mboned- maccnt-req-04.txt, "Requirements for Accounting, Authentication and Authorization in Well Managed IP Multicasting Services". "Lightweight IGMPv3 and MLDv2 Protocols", Hui Liu, 20-Dec-06, This document describes lightweight IGMPv3 and MLDv2 protocols (LW- IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of IGMPv3 and MLDv2. The interoperability with the full versions and the previous versions of IGMP and MLD is also taken into account. "Moving MCAST.NET into the ARPA infrastructure top level domain", Peter Koch, 28-Feb-07, This document proposes to migrate the MCAST.NET domain into the ARPA top level domain that is dedicated to infrastructure support. It also provides for a maintenance policy and covers migration issues and caveats. Middlebox Communication (midcom) -------------------------------- "Definitions of Managed Objects for Middlebox Communication", Juergen Quittek, 9-Oct-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 a set of managed objects that allow configuring middleboxes, such as firewalls and network address translators, in order to enable communication across these devices. The definitions of managed objects in this documents follow closely the MIDCOM semantics defined in RFC 3989. Mobility for IPv4 (mip4) ------------------------ "Low Latency Handoffs in Mobile IPv4", Karim Malki, 4-Oct-05, Mobile IPv4 describes how a Mobile Node can perform IPv4-layer handoffs between subnets served by different Foreign Agents. In certain cases, the latency involved in these handoffs can be above the threshold required for the support of delay-sensitive or real- time services. The aim of this document is to present two methods to achieve low-latency Mobile IPv4 handoffs. In addition, a combination of these two methods is described. The described techniques allow greater support for real-time services on a Mobile IPv4 network by minimising the period of time when a Mobile Node is unable to send or receive IPv4 packets due to the delay in the Mobile IPv4 Registration process. "The Definitions of Managed Objects for IP Mobility Support using SMIv2, revised", Ravindra Rathi, 19-Jan-07, 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 used for managing the Mobile Node, Foreign Agent and Home Agent of the Mobile IP Protocol. "IP Mobility Support for IPv4, revised", Charles Perkins, 8-Mar-07, This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. "Mobile IPv4 Regional Registration", Eva Fogelström, 26-Oct-06, Using Mobile IP, a mobile node registers with its home agent each time it changes care-of address. This document describes a new kind of "regional registrations", i.e. registrations local to the visited domain. The regional registrations are performed via a new network entity called a Gateway Foreign Agent (GFA) and introduce a layer of hierarchy in the visited domain. Regional registrations reduce the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another within the same visited domain. This document is an optional extension to the Mobile IPv4 protocol. "Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE", Vijay Devarapalli, Pasi Eronen, 5-Mar-07, Enterprise users require mobility and secure connectivity when they roam and connect to the services offered in the enterprise. Secure connectivity is required when the user connects to the enterprise from an untrusted network. Mobility is beneficial when the user moves, either inside or outside the enterprise network, and acquires a new IP address. This document describes a solution using Mobile IPv4 and mobility extensions to IKEv2 (MOBIKE) to provide secure connectivity and mobility. "Mobile IPv4 Message String Extension", Venkateshwara Sastry, 2-Mar-07, This document specifies a new extension for use in Mobile IPv4. This extension can be added by the Home Agent and the Foreign Agent to Registration Reply messages. This extension carries a text string that is intended for the user of the Mobile Node. "Mobile IPv4 RADIUS requirements", Madjid Nakhjiri, 1-Feb-07, This document provides an applicability statement as well as a scope definition for the specification provided in the document "RADIUS Mobile IPv4 extension" and its future revisions hereby collectively referred to as [I-D.nakhjiri-radius-mip4]. The goal is to justify qualification of [I-D.nakhjiri-radius-mip4] as a IETF work item. "Mobile IPv4 Fast Handovers", Rajeev Koodli, Charles Perkins, 1-Mar-07, This document adapts the Mobile IPv6 Fast Handovers to improve delay and packet loss resulting from Mobile IPv4 handover operations. Specifically, this document addresses movement detection, IP address configuration and location update latencies during a handover. For reducing the IP address configuration latency, the document proposes that the new Care-of Address is always made to be the new access router's IP address. Additional mechanisms may be defined in the future versions of this document. "Mobile IPv4 Extension for Configuration Options Exchange", Jayshree Bharatia, 26-Feb-07, This document describes the mechanism for providing the host configuration information during Mobile IP registration. One or more Configuration Options Exchange Extensions may be included in the registration message to provide the Mobile Node the configuration parameters needed for network service (e.g. DNS). "Dual Stack Mobile IPv4", George Tsirtsis, 29-Dec-06, This specification provides IPv6 extensions to the Mobile IPv4 protocol. The extensions allow a dual stack node to use IPv4 and IPv6 home addresses as well as to move between IPv4 and dual stack network infrastructures. "IPv4 Network Mobility (NEMO) Protocol", Kent Leung, 1-Mar-07, This document describes a protocol for supporting Mobile Networks between a Mobile Router and a Home Agent by extending the Mobile IPv4 protocol. A Mobile Router is responsible for the mobility of one or more network segments or subnets moving together. The Mobile Router hides its mobility from the nodes on the mobile network. The nodes on the Mobile Network may be fixed in relationship to the Mobile Router and may not have any mobility function. Extensions to Mobile IPv4 are introduced to support Mobile Networks. "Generic Notification Message for Mobile IPv4", Hui Deng, 2-Mar-07, This document specifies protocol enhancements that allow Mobile IPv4 entities to send and receive explicit notification messages using a new Mobile IPv4 message type designed for this purpose. Mobility for IPv6 (mip6) ------------------------ "Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture", Francis Dupont, Vijay Devarapalli, 18-Dec-06, This document describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2. "Using IPsec between Mobile and Correspondent IPv6 Nodes", Francis Dupont, Jean-Michel Combes, 1-Mar-07, Mobile IPv6 uses IPsec to protect signaling between the Mobile Node and the Home Agent. This document defines how IPsec can be used between the Mobile Node and Correspondent Nodes for Home Address Option validation (aka. triangular routing) and protection of mobility signaling for Route Optimization. The configuration details for IPsec and IKE are also provided. "AAA Goals for Mobile IPv6", Gerardo Giaretta, 12-Sep-06, In commercial deployments Mobile IPv6 can be a service offered by a Mobility Services Provider (MSP). In this case all protocol operations may need to be explicitly authorized and traced, requiring the interaction between Mobile IPv6 and the AAA infrastructure. Integrating the AAA infrastructure offers also a solution component for Mobile IPv6 bootstrapping in integrated and split scenarios. This document describes various scenarios where a AAA interface for Mobile IPv6 is actually required. Additionally, it lists design goals and requirements for such an interface. "Mobile IPv6 bootstrapping in split scenario", Gerardo Giaretta, 19-Dec-06, A Mobile IPv6 node requires a Home Agent address, a home address, and IPsec security associations with its Home Agent before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these are statically configured. This document defines how a Mobile IPv6 node can bootstrap this information from non- topological information and security credentials preconfigured on the Mobile Node. The solution defined in this document solves the bootstrapping problem from draft-ietf-mip6-bootstrapping-ps-02 when the Mobile Node's mobility service is authorized by a different service provider than basic network access, and is therefore generically applicable to any bootstrapping case. "Problem Statement: Dual Stack Mobility", Hesham Soliman, George Tsirtsis, 22-Jan-07, This draft discusses the issues associated with mobility management for dual stack mobile nodes. Currently, two mobility management protocols are defined for IPv4 and IPv6. Deploying both in a dual stack mobile node introduces a number of problems. Deployment and operational issues motivate the use of a single mobility management protocol. This draft discusses such motivations. The draft also discusses requirements for the Mobile IPv4 and Mobile IPv6 protocol so that they can support mobility management for a dual stack node. "IP Address Location Privacy and Mobile IPv6: Problem Statement", Rajeev Koodli, 21-Feb-07, In this document, we discuss Location Privacy as applicable to Mobile IPv6. We document the concerns arising from revealing Home Address to an on-looker and from disclosing Care of Address to a correspondent. "Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6)", Hesham Soliman, 8-Mar-07, The current Mobile IPv6 and NEMO specification support only IPv6. Hence, this specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the HA. This specification allows also the Mobile Node to roam over both IPv6 and IPv4, including the case where Network Address Translation is present on the path. "MIP6-bootstrapping for the Integrated Scenario", Kuntal Chowdhury, Alper Yegin, 8-Feb-07, The Mobile IPv6 bootstrapping problem statement describes two main scenarios. In the first scenario (i.e. the split scenario), the mobile node's mobility service is authorized by a different service authorizer than the basic network access authorizer. In the second scenario (i.e. the integrated scenario), the mobile node's mobility service is authorized by the same service authorizer as the basic network access service authorizer. This document defines a method for home agent information discovery for the integrated scenario. "Mobility Header Home Agent Switch Message", Brian Haley, 2-Mar-07, This document specifies a new Mobility Header message type that can be used between a home agent and mobile node to signal a mobile node that it should acquire a new home agent. "Home Agent Reliability Protocol", Ryuji Wakikawa, 6-Mar-07, The home agent can be a single point of failure when Mobile IPv6 is used in a system. It is critical to provide home agent reliability in the event of a home agent crashing or becoming unavailable. This would allow another home agent to take over and continue providing service to the mobile nodes. This document describes the problem scope briefly and provides a mechanism of home agent failure detection, home agent state transfer, and home agent switching for home agent redundancy and reliability. "DHCP Option for Home Information Discovery in MIPv6", Hee-Jin Jang, 16-Feb-07, This draft defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home agent address, home address, and home subnet. New DHCP options are defined to carry the information from a DHCP server to the DHCP client running on the mobile node. "RADIUS Mobile IPv6 Support", Kuntal Chowdhury, 8-Mar-07, A Mobile IPv6 node requires a home agent(HA) address, a home address(HOA), and IPsec security association with its HA before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these parameters are statically configured. Ongoing 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 (AAA) infrastructure. This document defines new attributes to facilitate Mobile IPv6 bootstrapping via a RADIUS infrastructure. This information exchange may take place as part of the initial network access authentication procedure or as part of a separate protocol exchange between the mobile node, the HA and the AAA infrastructure. "Mobile IPv6 Experimental Messages", Vijay Devarapalli, 23-Feb-07, This document defines a new experimental Mobility header message and a mobility option that can be used for experimental extensions to the Mobile IPv6 protocol. "Mobile IPv6 Vendor Specific Option", Vijay Devarapalli, 23-Feb-07, There is a need for vendor specific extensions to Mobility Header messages so that Mobile IPv6 vendors are able to extend the protocol for research or deployment purposes. This document defines a new vendor specific mobility option. "Authentication Protocol for Mobile IPv6", Alpesh Patel, 2-Mar-07, IPsec is specified as the means of securing signaling messages between the Mobile Node and Home agent for Mobile IPv6 (MIPv6). MIPv6 signalling messages that are secured include the Binding Updates and Acknowledgement messages used for managing the bindings between a Mobile Node and its Home Agent. This document proposes an alternate method for securing MIPv6 signaling messages between a Mobile Nodes and Home Agents. The alternate method defined here conists of a MIPv6-specific authentication option that can be added to MIPv6 signalling messages. Mobility for IP: Performance, Signaling and Handoff Optimization (mipshop) -------------------------------------------------------------------------- "Mobile IPv6 Fast Handovers over IEEE 802.16e Networks", Hee-Jin Jang, 3-Jan-07, This document describes how a Mobile IPv6 Fast Handover could be implemented on link layers conforming to the 802.16e suite of specifications. "Mobile IPv6 Fast Handovers for 3G CDMA Networks", Hidetoshi Yokota, Gopal Dommety, 8-Mar-07, Mobile IPv6 is designed to maintain its connectivity while moving from one network to another. It is adopted in 3G CDMA networks as a way to maintain connectivity when the mobile node moves between access routers. However, this handover procedure requires not only movement detection, but also the acquisition of a new care-of address and the sending of a binding update message to the home agent before the traffic begins to direct to the new location. During this period, packets destined for the mobile node will be lost, which may not be acceptable for real-time application such as Voice over IP (VoIP) or video telephony. This document specifies fast handover methods and selective bi-casting methods in the 3G context in order to reduce latency and packet loss during handover. "Fast Handovers for Mobile IPv6", Rajeev Koodli, 5-Mar-07, Mobile IPv6 enables a Mobile Node to maintain its connectivity to the Internet when moving from an Access Router to another, a process referred to as handover. During this time, the Mobile Node is unable to send or receive packets due to both link switching delay and IP protocol operations. The "handover latency" resulting from standard Mobile IPv6 procedures, namely, movement detection, new Care of Address configuration and Binding Update, is often unacceptable to real-time traffic such as Voice over IP. Reducing the handover latency could be beneficial to non real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link switching latency. "Enhanced Route Optimization for Mobile IPv6", Jari Arkko, 9-Feb-07, This document specifies an enhanced version of Mobile IPv6 route optimization, providing lower handoff delays, increased security, and reduced signaling overhead. "Mobility Independent Services: Problem Statement", Telemaco Melia, 10-Jan-07, There are on-going activities in the networking community to develop solutions that aid in IP handover mechanisms between heterogeneous wired and wireless access systems including, but not limited to, IEEE 802.21. Intelligent access selection, taking into account link layer attributes, requires the delivery of a variety of different information types to the terminal from different sources within the network and vice-versa. The protocol requirements for this signalling have both transport and security issues that must be considered. The signalling must not be constrained to specific link types, so there is at least a common component to the signalling problem which is within the scope of the IETF. This draft presents a problem statement for this core problem. "Distributing a Symmetric FMIPv6 Handover Key using SEND", James Kempf, 2-Mar-07, Fast Mobile IPv6 requires that a Fast Binding Update is secured using a security association shared between an Access Router and a Mobile Node in order to avoid certain attacks. In this document, a method for distributing a shared key to secure this signaling is defined. The method utilizes the RSA public key that the Mobile Node used to generate its Cryptographically Generated Address in SEND. The RSA public key is used to encrypt a shared key sent from the Access Router to the Mobile Node prior to handover. The ability of the Mobile Node to decrypt the shared key verifies its possession of the private key corresponding to the CGA public key used to generate the address. This allows the Mobile Node to use the shared key to sign and authorize the routing changes triggered by the Fast Binding Update. Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- "SDPng Transition", Joerg Ott, Charles Perkins, 15-May-03, The Session Description Protocol (SDP) is today widely used in the Internet to announce as well as negotiate multimedia sessions and exchange capabilities. Having originally been designed for session announcements only, as opposed to announcements and capabilities negotiation announcements, native SDP lacks numerous features to be applicable in many session scenarios. Numerous extensions have been developed to circumvent SDP's shortcomings -- but they have also repeatedly shown its inherent limitations. A successor protocol -- termed 'SDPng' for the time being -- is developed to address the aforementioned needs of Internet applications in a more structured manner. With the huge installed base of SDP-based applications, a migration path needs to be developed to move from SDP to SDPng over time. This document outlines how this migration can be achieved: in general as well as for the various IETF control protocols that potentially make use of SDP and SDPng. "Real Time Streaming Protocol 2.0 (RTSP)", Henning Schulzrinne, 27-Dec-06, This memorandum defines RTSP version 2.0 which is a revision of the Proposed Standard RTSP version 1.0 which is defined in RFC 2326. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550). "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Jonathan Rosenberg, 7-Mar-07, This document describes a protocol for Network Address Translator (NAT) traversal for multimedia sessions established with the offer/ answer model. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol, applying its binding discovery and relay usages, in addition to defining a new usage for checking connectivity between peers. ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP). "An Extension to the Session Description Protocol (SDP) for Media Loopback", Kaynam Hedayat, 25-Sep-06, The wide deployment of Voice over IP (VoIP), Real-time Text and Video over IP services has introduced new challenges in managing and maintaining voice/real-time Text/video quality, reliability, and overall performance. In particular, media delivery is an area that needs attention. One method of meeting these challenges is monitoring the media delivery performance by looping media back to the transmitter. This is typically referred to as "active monitoring" of services. Media loopback is especially popular in ensuring the quality of transport to the edge of a given VoIP, Real-time Text or Video over IP service. Today in networks that deliver real-time media, short of running 'ping' and 'traceroute' to the edge, service providers are left without the necessary tools to actively monitor, manage, and diagnose quality issues with their service. The extension defined herein adds new SDP media attributes which enables establishment of media sessions where the media is looped back to the transmitter. Such media sessions will serve as monitoring and troubleshooting tools by providing the means for measurement of more advanced VoIP, Real-time Text and Video Over IP performance metrics. "Security Preconditions for Session Description Protocol (SDP) Media Streams", Flemming Andreasen, Dan Wing, 20-Oct-06, This document defines a new security precondition for the Session Description Protocol (SDP) precondition framework described in RFCs 3312 and 4032. A security precondition can be used to delay session establishment or modification until media stream security for a secure media stream has been negotiated successfully. "TCP Candidates with Interactive Connectivity Establishment (ICE", Jonathan Rosenberg, 8-Mar-07, Interactive Connectivity Establishment (ICE) defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Simple Traversal of UDP over NAT (STUN). ICE provides a general framework for describing alternates, but only defines UDP-based transport protocols. This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream. "SDP Capability Negotiation: Requirements and Review of Existing Work", Flemming Andreasen, 6-Mar-07, The Session Description Protocol (SDP) was intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability indication or capability negotiation, however over the years, SDP has seen widespread adoption and as a result it has been gradually extended to provide limited support for these. SDP and its current extensions however do not have, for example, the ability to negotiate one or more alternative transport protocols (e.g. RTP profiles) which makes it particularly difficult to deploy new RTP profiles such as secure RTP and RTP with RTCP-based feedback. The purpose of this document is to identify a set of requirements for SDP Capability Negotiation and evaluate existing work in this area. The document does not provide any solutions to SDP Capability Negotiation "A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer", Miguel Garcia-Martin, 18-Dec-06, This document provides a mechanism to negotiate the transfer of one or more files between two endpoints by using the Session Description Protocol (SDP) offer/answer model specified in RFC 3264. SDP is extended to describe the attributes of the files to be transferred. The offerer can either describe the files it wants to send, or the files it would like to receive. The answerer can either accept or reject the offer separately for each individual file . The transfer of one or more files is initiated after a successful negotiation. The Message Session Relay Protocol (MSRP) is defined as the default mechanism to actually carry the files between the endpoints. The conventions on how to use MSRP for file transfer are also provided in this document. "SDP Capability Negotiation", Flemming Andreasen, 6-Mar-07, The Session Description Protocol (SDP) was intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability indication or capability negotiation, however over the years, SDP has seen widespread adoption and as a result it has been gradually extended to provide limited support for these. SDP and its current extensions however do not have the ability to negotiate one or more alternative transport protocols (e.g. RTP profiles) which makes it particularly difficult to deploy new RTP profiles such as secure RTP or RTP with RTCP-based feedback. The purpose of this document is to address that and other real-life limitations by extending SDP with capability negotiation parameters and associated offer/answer procedures to use those parameters in a backwards compatible manner. The solution provided in this document provides a general SDP capability negotiation framework. It also defines specifically how to provide attributes and transport protocols as capabilities and negotiate them using the framework. Extensions for other types of capabilities (e.g. media types and formats) may be provided in other documents. "SDP media capabilities Negotiation", Flemming Andreasen, 21-Feb-07, Session Description Protocol (SDP) capability negotiation provides a general framework for negotiating capabilities in SDP. The base framework defines only capabilities for negotiating transport protocols and attributes. In this document, we extend the framework by defining media capabilities that can be used to negotiate media types and their associated parameters. Mobile Nodes and Multiple Interfaces in IPv6 (monami6) ------------------------------------------------------ "Analysis of Multihoming in Mobile IPv6", Nicolas Montavont, 27-Feb-07, Mobile IPv6 as specified in RFC3775 [1] allows a mobile node to maintain its IPv6 communications while moving between subnets. This document investigates configurations where a mobile node running Mobile IPv6 is multihomed. The use of multiple addresses is foreseen to provide ubiquitous, permanent and fault-tolerant access to the Internet, particularly on mobile nodes which are more prone to failure or sudden lack of connectivity. However, Mobile IPv6 currently lacks support for such multihomed nodes. The purpose of this document is to detail all the issues arising through the operation of Mobile IPv6 on multihomed mobile nodes. "Motivations and Scenarios for Using Multiple Interfaces and Global Addresses", Thierry Ernst, 26-Oct-06, In this document, multihoming is investigated from a node point of view, and not from a site point of view as the term "multihoming" is commonly understood so far. The purpose of this document is to explain the motivations for fixed and mobile nodes (hosts and routers) using multiple interfaces and the scenarios where this may end up using multiple global addresses on their interfaces. Such multihoming configurations can bring a number of benefits once appropriate support mechanisms are put in place. Interestingly, this analysis is generic, i.e. motivations and benefits of node multihoming apply to both fixed end nodes and mobile end nodes. "Multiple Care-of Addresses Registration", Ryuji Wakikawa, 5-Mar-07, According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses, but only one, termed the primary care-of address, can be registered with its home agent and the correspondent nodes. However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple access media simultaneously, in which case multiple active IPv6 care-of addresses would be assigned to the mobile node. We thus propose Mobile IPv6 extensions designed to register multiple care-of addresses bound to a single Home Address instead of the sole primary care-of address. For doing so, a new identification number must be carried in each binding for the receiver to distinguish between the bindings corresponding to the same Home Address. Those extensions are targeted to NEMO (Network Mobility) Basic Support as well as to Mobile IPv6. Multiprotocol Label Switching (mpls) ------------------------------------ "ICMP Extensions for MultiProtocol Label Switching", Ronald Bonica, 1-Feb-07, This memo defines an extension object that can be appended to selected multi-part ICMP messages. This extension permits Label Switching Routers to append MPLS information to ICMP messages, and has already been widely deployed. "Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute", Riza Cetin, Thomas Nadeau, 5-Mar-07, This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for Multiprotocol Label Switching fast rerouting. "MPLS Traffic Engineering Soft Preemption", Matthew Meyer, 26-Oct-06, This document details MPLS Traffic Engineering Soft Preemption, a suite of protocol modifications extending the concept of preemption with the goal of reducing/eliminating traffic disruption of preempted Traffic Engineering Label Switched Paths (TE LSPs). Initially MPLS RSVP-TE was defined supporting only immediate TE LSP displacement upon preemption. The utilization of a preemption pending flag helps more gracefully mitigate the re-route process of preempted TE LSP. For the brief period soft preemption is activated, reservations (though not necessarily traffic levels) are in effect under- provisioned until the TE LSP(s) can be re-routed. For this reason, the feature is primarily but not exclusively interesting in MPLS enabled IP networks with Differentiated Services and Traffic Engineering capabilities. "Label Switching Router Self-Test", George Swallow, 26-Oct-05, This document defines a means for a Label-Switching Router (LSR) to verify that its data plane is functioning for certain key Multi-Protocol Label Switching (MPLS) applications, including unicast forwarding and traffic engineering tunnels. A new Loopback FEC type is defined to allow an upstream neighbor to assist in the testing at very low cost. MPLS Verification Request and MPLS Verification Reply messages are defined to do the actual probing. "LDP Specification", Loa Andersson, 25-Sep-06, The architecture for Multi Protocol Label Switching (MPLS) is described in RFC 3031 [RFC3031]. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. "Avoiding Equal Cost Multipath Treatment in MPLS Networks", George Swallow, 15-Feb-07, This document describes the Equal Cost Multipath (ECMP) behavior of currently deployed MPLS networks. This document makes best practice recommendations for anyone defining an application to run over an MPLS network that wishes to avoid the reordering that can result from transmission of different packets from the same flow over multiple different equal cost paths. "Extensions to RSVP-TE for Point-to-Multipoint TE LSPs", Rahul Aggarwal, 23-Jan-07, This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described. There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. "Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3", Mark Townsley, 9-Nov-06, The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of payload types over IP networks. This document defines how to carry an MPLS label stack and its payload over the L2TPv3 data encapsulation. This enables an application which traditionally requires an MPLS-enabled core network to utilize an L2TPv3 encapsulation over an IP network instead. "Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping", Adrian Farrel, Seisho Yasukawa, 5-Mar-07, Recent proposals have extended the scope of Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) to encompass point-to-multipoint (P2MP) LSPs. The requirement for a simple and efficient mechanism that can be used to detect data plane failures in point-to-point (P2P) MPLS LSPs has been recognised and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP Ping". The scope of this document is fault detection and isolation for P2MP MPLS LSPs. This documents does not replace any of the mechanism of LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and extends the techniques and mechanisms of LSP Ping to the MPLS P2MP environment. "Component Link Recording and Resource Control for GMPLS Link Bundles", Anca Zamfir, 23-Oct-06, Record Route is a useful administrative tool that has been used extensively by the service providers. However, when TE links are bundled, identification of label resource in RRO is not enough for the administrative purpose. Network service providers would like to know the component link within a TE link that is being used by a given LSP. In other words, when link bundling is used, resource recording requires mechanisms to specify the component link identifier, along with the TE link identifier and Label. As , it is not possible to record component link in the RRO, this draft defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to specify component link identifiers for resource recording purposes. This draft also defines the ERO counterpart of the RRO extension. The ERO extensions are needed to perform explicit label/ resource control over bundled TE link. Hence, this draft defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to specify component link identifiers for explicit resource control and recording over GMPLS link bundles. "Experience with the LDP protocol", Loa Andersson, 20-Sep-05, The purpose of this memo is to document how some of the requirements specified in RFC 1264 for advancing protocols developed by working groups within the IETF Routing Area to Draft Standard have been satisfied by LDP (Label Distribution Protocol). Specifically, this report documents operational experience with LDP, requirement 5 of section 5.0 in RFC 1264. "LDP Implementation Survey Results", Loa Andersson, Bob Thomas, 4-Oct-05, Multiprotocol Label Switching (MPLS) is a method for forwarding packets that uses short, fixed-length values carried by packets, called labels, to determine packet nexthops [RFC3031]). A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. One such protocol called LDP [RFC3036] is used by LSRs to distribute labels to support MPLS forwarding along normally routed paths. This document reports on a survey of LDP implementations conducted in August 2002 as part of the process of advancing LDP from proposed to draft standard. "MPLS Multicast Encapsulations", Toerless Eckert, 1-Mar-07, RFC 3032 established two data link layer codepoints for MPLS: one to indicate that the data link layer frame is carrying an MPLS unicast packet, and the other to indicate that the data link layer frame is carrying an MPLS multicast packet. This specification updates RFC3032 by redefining the meaning of these two codepoints. The former "multicast codepoint" is now to be used only on multiaccess media, and it is to mean "the top label of the following label stack is an upstream-assigned label". The former "unicast codepoint" is to be used in all other cases. Whether the data link layer payload is a unicast MPLS packet or a multicast MPLS packet is now to be determined by looking up the top label, rather than by the codepoint. RFC3032 does not specify the destination address to be placed in the "MAC DA" field of an ethernet frame which carries an MPLS multicast packet. This document provides that specification. This document updates RFC 3032 and RFC 4023. "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Ina Minei, 20-Oct-06, This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point to multi-point (P2MP) and multipoint-to- multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) networks. The solution relies on LDP without requiring a multicast routing protocol in the network. Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner. There can be various applications for P2MP/MP2MP LSPs, for example IP multicast or support for multicast in BGP/MPLS L3VPNs. Specification of how such applications can use a LDP signaled P2MP/MP2MP LSP is outside the scope of this document. "MPLS Upstream Label Assignment and Context Specific Label Space", Rahul Aggarwal, 8-Mar-07, RFC 3031 limits the MPLS architecture to downstream assigned MPLS labels. This document introduces the notion of upstream assigned MPLS labels. It describes the procedures for upstream MPLS label assignment and introduces the concept of a "Context-Specific Label Space". "MPLS Upstream Label Assignment for RSVP-TE", Rahul Aggarwal, Jean-Louis Le Roux, 8-Mar-07, This document describes procedures for distributing upstream-assigned labels for Resource Reservation Protocol - Traffic Engineering (RSVP- TE). It also describes how these procedures can be used for avoiding branch LSR traffic replication on a LAN for RSVP-TE point-to- multipoint (P2MP)LSPs. "MPLS Upstream Label Assignment for LDP", Rahul Aggarwal, Jean-Louis Le Roux, 8-Mar-07, This document describes procedures for distributing upstream-assigned labels for Label Distribution Protocol (LDP). It also describes how these procedures can be used for avoiding branch LSR traffic replication on a LAN for LDP point-to-multipoint (P2MP)LSPs. "Requirements for Point-To-Multipoint Extensions to the Label Distribution Protocol", Jean-Louis Le Roux, 2-Mar-07, This document lists a set of functional requirements for Label Distribution Protocol (LDP) extensions for setting up point-to- multipoint (P2MP) Label Switched Paths (LSP), in order to deliver point-to-multipoint applications over a Multi Protocol Label Switching (MPLS) infrastructure. It is intended that solutions that specify LDP procedures for setting up P2MP LSP satisfy these requirements. "A Link-Type sub-TLV to convey the number of Traffic Engineering Label Switched Paths signalled with zero reserved bandwidth across a link", JP Vasseur, 12-Dec-06, Several Link-type sub-TLVs have been defined for OSPF and IS-IS in the context of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) in order to advertise some link characteristics such as the available bandwidth, traffic engineering metric, administrative group and so on. By making statistical assumption on the aggregated traffic carried onto a set of TE Label Switched Paths (LSPs) signalled with zero bandwith (referred to as unconstrained TE LSP in this document), and with the knowledge of the number of unconstrained TE LSPs signalled across a link, algorithms can be designed to load balance (existing or newly configured) unconstrained TE LSP across a set of equal cost paths. This requires the knowledge of the number of unconstrained TE LSPs signalled across a link. This document specifies a new Link-type Traffic Engineering sub-TLV used to advertise the number of unconstrained TE LSP(s) signalled across a link. "Codepoint Registry for The Flags Field in the Resource Reservation Protocol Traffic Engineering (RSVP-TE) Session Attribute Object", Adrian Farrel, 26-Feb-07, This document provides instructions to IANA for the creation of a new codepoint registry for the flags field in the Session Attribute object of the Resource Reservation Protocol Traffic Engineeging (RSVP-TE) signaling messages used in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) signaling. "Point-to-Multipoint Multiprotocol Label Switching (MPLS)Traffic Engineering (TE) Management Information Base (MIB) module", Adrian Farrel, 26-Feb-07, This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for point-to-multipoint Multiprotocol Label Switching-based traffic engineering. "LDP Typed Wildcard FEC", Bob Thomas, Ina Minei, 23-Jan-07, The LDP specification [RFC3036] for the Wildcard FEC element has several deficiencies. This document corrects those deficiencies. In addition, it specifies the Typed Wildcard FEC for the Prefix FEC Element Type defined in RFC3036. "Detecting MPLS Data Plane Failures in Inter-AS and inter-provider Scenarios", Thomas Nadeau, George Swallow, 8-Mar-07, This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching Label Switched Paths that extend beyond a single Autonomous System and/or across multiple Service Provider network boundaries. This document describes extensions to the existing MPLS LSP Ping protocol to achieve these goals. Multicast Security (msec) ------------------------- "ECC Algorithms for MIKEY", Andrew Milne, 22-Oct-06, This document proposes extensions to the authentication, encryption and digital signature methods described for use in MIKEY, employing elliptic-curve cryptography (ECC). These extensions are defined to align MIKEY with other ECC implementations and standards. It should be noted that this document is not self-contained; it uses the notations and definitions of [RFC3830]. "Multicast Extensions to the Security Architecture for the Internet Protocol", Brian Weis, 8-Feb-07, The Security Architecture for the Internet Protocol [RFC4301] describes security services for traffic at the IP layer. That architecture primarily defines services for Internet Protocol (IP) unicast packets, as well as manually configured IP multicast packets. This document further defines the security services for manually and dynamically keyed IP multicast packets within that Security Architecture. "GKDP: Group Key Distribution Protocol", Lakshminath Dondeti, 20-Feb-07, This document specifies a group key distribution protocol (GKDP) based on IKEv2, the IPsec key management protocol; the new protocol is similar to IKEv2 in message and payload formats, and message semantics to a large extent. The protocol in conformance with MSEC key management architecture contains two components: member registration and group rekeying, and downloads a group security association from the GCKS to a member. This protocol is independent of IKEv2 except in its likeness. "On the applicability of various MIKEY modes and extensions", Steffen Fries, Dragan Ignjatic, 4-Dec-06, Multimedia Internet Keying - MIKEY - is a key management protocol that can be used for real-time applications. In particular, it has been defined focusing on the support of the Secure Real-time Transport Protocol. MIKEY itself defines four key distribution methods. Moreover, it is defined to allow extensions of the protocol. As MIKEY becomes more and more accepted, extensions to the base protocol arose, especially in terms of additional key distribution methods, but also in terms of payload enhancements. This document provides an overview about MIKEY in general as well as the existing extensions in MIKEY, which have been defined or are in the process of definition. It is intended as additional source of information for developers or architects to provide more insight in use case scenarios and motivations as well as advantages and disadvantages for the different key distribution schemes. The use cases discussed in this document are strongly related to dedicated SIP call scenarios providing challenges for key management in general beyond them media before SDP answer, forking, and shared key conferencing. "Updates to the Group Domain of Interpretation (GDOI)", Brian Weis, Sheela Rowles, 5-Mar-07, This memo describes updates to the Group Domain of Interpretation (GDOI) [RFC3547]. It provides clarification where the original text is unclear. It also includes a discussion of algorithm agility within GDOI, and proposes several new algorithm attribute values. "Use of TESLA in the ALC and NORM Protocols", Vincent Roca, 2-Mar-07, This document explains how to integrate the TESLA source authentication and packet integrity protocol to the ALC and NORM content delivery protocols. This document only considers the authentication/integrity of the packets generated by the session's sender. "Multicast IP Security Composite Cryptographic Groups", George Gross, Haitham Cruickshank, 7-Feb-07, The Multicast IP Security extension architecture [Weis] implicitly assumes a basic group endpoint population that shares homogeneous cryptographic capabilities and security policies. In practice, large- scale cryptographic groups may contain a heterogeneous endpoint population that can not be accommodated by that basic multicast IPsec architecture. For example, some endpoints may not have been upgraded to handle the successor algorithm for one that is being retired (e.g. SHA1 transition to SHA-ng). Group deployments that span multiple legal jurisdictions may have a different security policy in each jurisdiction (e.g. key strength). This document defines the "composite cryptographic group" IP security architecture capability. A composite cryptographic group allows multicast IPsec applications to transparently interact with the single logical group that is formed by the union of one or more basic cryptographic groups. "GDOI Key Establishment for the SRTP Data Security Protocol", Mark Baugher, 21-Feb-07, The Secure Real-time Transport Protocol (SRTP) protects unicast and multicast RTP packets. Multicast receivers of SRTP session data therefore share an SRTP master key for message authentication and decryption. This document describes how to establish a shared, "group key" for an SRTP session using RFC 3547, the Group Domain of Interpretation (GDOI) and RFC 2408, the Internet Security Association and Key Management Protocol. This document extends GDOI for SRTP group key establishment. "Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic", David McGrew, Brian Weis, 26-Feb-07, This memo describes the use of Advanced Encryption Standard (AES) counter modes when applied to the Encapsulating Security Payload (ESP) and Authentication Header (AH) in multiple-sender group applications. Network Endpoint Assessment (nea) --------------------------------- "Requirements for Network Endpoint Assessment (NEA)", Paul Sangster, 5-Mar-07, This document defines the problem statement, scope and interface (protocol) requirements between the components of the NEA (Network Endpoint Assessment) reference model. NEA provides owners of networks (e.g. an enterprise offering remote access) a mechanism to evaluate the posture of a system. This may take place during the request for network access and/or subsequently at any time while connected to the network. The learned posture information can then be applied to a variety of compliance oriented decisions. The posture information is frequently useful for detecting systems that are lacking (or have out of date) security protective mechanisms (e.g. anti-virus, firewall). In order to provide context for the requirements, a reference model and terminology are introduced. This model is provided for informational purposes but is based on the models used by NAC [CNAC], NAP[NAP] and TNC[TNC]. Network Mobility (nemo) ----------------------- "Network Mobility Support Goals and Requirements", Thierry Ernst, 9-Nov-06, Network mobility arises when a router connecting a network to the Internet dynamically changes its point of attachment to the Internet thereby causing the reachability of the said network to be changed in relation to the fixed Internet topology. Such kind of network is referred to as a mobile network. With appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet can be maintained after the mobile router changes its point of attachment. This document outlines the goals expected from network mobility support and defines the requirements that must be met by the NEMO Basic Support solution. "Network Mobility Support Terminology", Thierry Ernst, Hong Lach, 9-Nov-06, This document defines a terminology for discussing network mobility (NEMO) issues and solution requirements. "NEMO Home Network models", Pascal Thubert, 21-Feb-06, This paper documents some usage patterns and the associated issues when deploying a Home Network for NEMO-enabled Mobile Routers, conforming the NEMO Basic Support. The aim here is specifically to provide some examples of organization of the Home Network, as they were discussed in NEMO related mailing lists. "Analysis of Multihoming in Network Mobility Support", Chan-Wah Ng, 7-Feb-07, This document is an analysis of multihoming in the context of network mobility (NEMO) in IPv6. As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations. The possible deployment scenarios of multihomed mobile networks are described together with the associated issues when network mobility is supported by RFC 3963 (NEMO Basic Support). Recommendations are offered on how to address these issues. "NEMO Management Information Base", Sri Gundavelli, 25-Oct-06, This memo defines a portion of the Management Information Base (MIB), the network mobility support (NEMO) MIB, for use with network management protocols in the Internet community. In particular, the NEMO MIB will be used to monitor and control a mobile ipv6 node with NEMO functionality. "Network Mobility Route Optimization Problem Statement", Chan-Wah Ng, 18-Sep-06, With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the bi-directional tunnel established between the Mobile Router and Home Agent when the mobile network is away. This sub-optimal routing results in various inefficiencies associated with packet delivery, such as increased delay and bottleneck links leading to traffic congestion, which can ultimately disrupt all communications to and from the Mobile Network Nodes. Additionally, with nesting of Mobile Networks, these inefficiencies get compounded, and stalemate conditions may occur in specific dispositions. This document investigates such problems, and provides for the motivation behind Route Optimization (RO) for NEMO. "DHCPv6 Prefix Delegation for NEMO", Ralph Droms, Pascal Thubert, 29-Sep-06, One aspect of network mobility support is the assignment of a prefix or prefixes to a Mobile Router (MR) for use on the links in the Mobile Network. DHCPv6 prefix delegation can be used for this configuration task. "Mobile Network Prefix Delegation", TJ Kniveton, Pascal Thubert, 6-Dec-06, This paper extends the Nemo Basic Support [9] for a Mobile Router to synchronize its Mobile Network Prefixes with its Home Agents and obtain new ones dynamically. The proposed prefix delegation mechanism is agnostic to the way the back end is implemented; it enables bootstrapping, resynchronization at binding creation or after a loss of states (eg MR reboot), MNP Renumbering, and configuration checking for loop avoidance. "Network Mobility Route Optimization Solution Space Analysis", Chan-Wah Ng, 18-Sep-06, With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the MRHA tunnel when the mobile network is away. This results in increased length of packet route and increased packet delay in most cases. To overcome these limitations, one might have to turn to Route Optimization (RO) for NEMO. This memo documents various types of Route Optimization in NEMO, and explores the benefits and tradeoffs in different aspects of NEMO Route Optimization. Network Configuration (netconf) ------------------------------- "NETCONF Event Notifications", Hector Trevino, Sharon Chisholm, 21-Feb-07, This document defines mechanisms which provide an asynchronous message notification delivery service for the NETCONF protocol. This is an optional capability built on top of the base NETCONF definition. This document defines the capabilities and operations necessary to support this service. Network-based Localized Mobility Management (netlmm) ---------------------------------------------------- "Goals for Network-based Localized Mobility Management (NETLMM)", James Kempf, 9-Oct-06, In this document, design goals for a network-based localized mobility management (NETLMM) protocol are discussed. "Problem Statement for Network-based Localized Mobility Management", James Kempf, 24-Sep-06, Localized mobility management is a well understood concept in the IETF with a number of solutions already available. This document looks at the principal shortcomings of the existing solutions, all of which involve the host in mobility management, and makes a case for network-based local mobility management. "Security Threats to Network-Based Localized Mobility Management", James Kempf, Christian Vogt, 13-Sep-06, This document discusses security threats to network-based localized mobility management. Threats may occur on two interfaces: the interface between a localized mobility anchor and a mobile access gateway, as well as the interface between a mobile access gateway and a mobile node. Threats to the former interface impact the localized mobility management protocol itself. Network File System Version 4 (nfsv4) ------------------------------------- "RPC: Remote Procedure Call Protocol Specification Version 2", Robert Thurlow, 27-Dec-06, This document describes the ONC (Open Network Computing) Remote Procedure Call (ONC RPC Version 2) protocol as it is currently deployed and accepted. It is meant to supersede [RFC1831]. "NFS RDMA Problem Statement", Thomas Talpey, Chet Juszczak, 23-Oct-06, This draft addresses applying Remote Direct Memory Access to the NFS protocols. NFS implementations historically incur significant overhead due to data copies on end-host systems, as well as other sources. The potential benefits of RDMA to these implementations are explored, and the reasons why RDMA is especially well-suited to NFS and network file protocols in general are evaluated. "RDMA Transport for ONC RPC", Brent Callaghan, Thomas Talpey, 23-Oct-06, A protocol is described providing RDMA as a new transport for ONC RPC. The RDMA transport binding conveys the benefits of efficient, bulk data transport over high speed networks, while providing for minimal change to RPC applications and with no required revision of the application RPC protocol, or the RPC protocol itself. "NFS Direct Data Placement", Brent Callaghan, Thomas Talpey, 23-Oct-06, The RDMA transport for ONC RPC provides direct data placement for NFS data. Direct data placement not only reduces the amount of data that needs to be copied in an NFS call, but allows much of the data movement over the network to be implemented in RDMA hardware. This draft describes the use of direct data placement by means of server- initiated RDMA operations into client-supplied buffers in a Chunk list for implementations of NFS versions 2, 3, and 4 over an RDMA transport. "NFSv4 Minor Version 1", Spencer Shepler, 6-Mar-07, This Internet-Draft describes NFSv4 minor version one, including features retained from the base protocol and protocol extensions made subsequently. The current draft includes description of the major extensions, Sessions, Directory Delegations, and parallel NFS (pNFS). This Internet-Draft is an active work item of the NFSv4 working group. Active and resolved issues may be found in the issue tracker at: http://www.nfsv4-editor.org/cgi-bin/roundup/nfsv4. New issues related to this document should be raised with the NFSv4 Working Group nfsv4@ietf.org and logged in the issue tracker. "pNFS Block/Volume Layout", David Black, 6-Mar-07, Parallel NFS (pNFS) extends NFSv4 to allow clients to directly access file data on the storage used by the NFSv4 server. This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used. The main pNFS operations draft specifies storage-class-independent extensions to NFS; this draft specifies the additional extensions (primarily data structures) for use of pNFS with block and volume based storage. "Object-based pNFS Operations", Benny Halevy, 7-Mar-07, This Internet-Draft provides a description of the object-based pNFS extension for NFSv4. This is a companion to the main pnfs specification in the NFSv4 Minor Version 1 Internet Draft, which is currently draft-ietf-nfsv4-minorversion1-10.txt. Individual Submissions (none) ----------------------------- "Distance Vector Multicast Routing Protocol", Tom Pusateri, 3-Dec-03, DVMRP is an Internet routing protocol that provides an efficient mechanism for connection-less datagram delivery to a group of hosts across an internetwork. It is a distributed protocol that dynamically generates IP Multicast delivery trees using a technique called Reverse Path Multicasting (RPM) [Deer90]. This document is an update to Version 1 of the protocol specified in RFC 1075 [Wait88]. "Salted Challenge Response Authentication Mechanism (SCRAM)", Chris Newman, 8-Mar-07, The secure authentication mechanism most widely deployed and used by Internet application protocols, is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS). There are some significant security concerns with that mechanism which could be addressed by the use of a challenge response authentication mechanism protected by TLS. Unfortunately, the challenge response mechanisms presently on the standards track all fail to meet requirements necessary for widespread deployment and have had success only in limited use. This specification describes the Salted Challenge Response Authentication Mechanism (SCRAM) which addresses the deployability requirements. When used in combination with Transport Layer Security or an equivalent security layer, this mechanism could improve the status-quo for application protocol authentication and provide a suitable choice for a mandatory-to-implement mechanism for future application protocol standards. "Additional ECC Groups For IKE and IKEv2", Daniel R. L. Brown, 10-Oct-06, This document describes additional elliptic curve groups for use in IKE (as defined in RFC 2409) and IKEv2 (as defined in RFC 3406). These groups are defined to align IKE and IKEv2 with other ECC implementations and standards, and in addition, many of them provide higher strength than the previousley defined Oakley groups. "SMTP Language Extension", Alexey Melnikov, 20-Feb-07, The Simple Mail Transfer Protocol (RFC 2821) allows server responses to include human-readable text that in many cases needs to be presented to the user. This document specifies a way for a client to negotiate which language the server should use when sending human-readable text. It also extends the UTF-8 Delivery Status Notifications format to include language field for the human-readable text. "IP over MIME", Donald Eastlake 3rd, 2-Dec-05, The MIME encoding of IP packets is specified so they can conveniently be sent via MAIL, HTTP, etc. This may be convenient for transmitting packets for analysis, debugging, monitoring, or creating application level tunnels. "Transport of Layer 2 Frames Over MPLS", Luca Martini, 8-Sep-06, This document describes methods for transporting the Protocol Data Units (PDUs) of layer 2 protocols such as Frame Relay, ATM AAL5, Ethernet, and providing a SONET circuit emulation service across an MPLS network. "Cisco Systems' Simple Certificate Enrollment Protocol(SCEP)", Xiaoyi Liu, 23-Jan-07, This document specifies the Simple Certificate Enrollment Protocol, a PKI communication protocol which leverages existing technology by using PKCS#7 and PKCS#10. SCEP is the evolution of the enrollment protocol developed by Verisign, Inc. for Cisco Systems, Inc. It now enjoys wide support in both client and CA implementations. "A Protocol for Remotely Managing Sieve Scripts", Tim Martin, Alexey Melnikov, 22-Nov-06, Sieve scripts allow users to filter incoming email. Message stores are commonly sealed servers so users cannot log into them, yet users must be able to update their scripts on them. This document describes a protocol "sieve" for securely managing Sieve scripts on a remote server. This protocol allows a user to have multiple scripts, and also alerts a user to syntactically flawed scripts. "LDAP Administrator Address Attribute", Mark Wahl, 20-Nov-06, Organizations with multiple or outsourced directory servers need the ability for administrators to determine who is responsible for a particular directory server. This document defines an attribute with contact information for a directory server's responsible party, conceptually similar to the 'sysContact' object of SNMP, which can be retrieved from the directory server using the Lightweight Directory Access Protocol. "Secure Internet Live Conferencing (SILC), Protocol Specification", Pekka Riikonen, 23-Jan-07, This memo describes a Secure Internet Live Conferencing (SILC) protocol which provides secure conferencing services over insecure network channel. SILC provides advanced and feature rich conferencing services with security as main design principal. Strong cryptographic methods are used to protect SILC packets inside the SILC network. Three other specifications relates very closely to this memo; SILC Packet Protocol [SILC2], SILC Key Exchange and Authentication Protocols [SILC3] and SILC Commands [SILC4]. "SILC Packet Protocol", Pekka Riikonen, 19-Jan-07, This memo describes a Packet Protocol used in the Secure Internet Live Conferencing (SILC) protocol, specified in the Secure Internet Live Conferencing, Protocol Specification [SILC1]. This protocol describes the packet types and packet payloads which defines the contents of the packets. The protocol provides secure binary packet protocol that assures that the contents of the packets are secured and authenticated. "SILC Key Exchange and Authentication Protocols", Pekka Riikonen, 19-Jan-07, This memo describes two protocols used in the Secure Internet Live Conferencing (SILC) protocol, specified in the Secure Internet Live Conferencing, Protocol Specification [SILC1]. The SILC Key Exchange (SKE) protocol provides secure key exchange between two parties resulting into shared secret key material. The protocol is based on Diffie-Hellman key exchange algorithm and its functionality is derived from several key exchange protocols. The second protocol, SILC Connection Authentication protocol provides user level authentication used when creating connections in SILC network. The protocol supports passphrase (pre-shared secret) authentication and public key (and certificate) authentication based on digital signatures. "Distance Vector Multicast Routing Protocol Applicability Statement", Tom Pusateri, 12-May-04, This document provides a framework for the use of Distance Vector Multicast Routing Protocol (DVMRP) Version 3 within a multicast routing domain. It is an interior gateway protocol designed to be used within an autonomous system. "LDAP Transactions", Kurt Zeilenga, 24-Oct-06, Lightweight Directory Access Protocol (LDAP) update operations, such as Add, Delete, and Modify operations, have atomic, consistency, isolation, durability (ACID) properties. Each of these update operations act upon an entry. However, It is often desirable to update two or more entries in a single unit of interaction, a transaction. Transactions are necessary to support a number of applications including resource provisioning. This document extends LDAP to support transactions. "Encapsulation Methods for Transport of Layer 2 Frames Over MPLS Networks", Luca Martini, 10-Sep-06, This document describes methods for encapsulating the Protocol Data Units (PDUs) of layer 2 protocols such as Frame Relay, ATM, or Ethernet for transport across an MPLS network. "A Configuration Profile Schema for LDAP-based agents", Bob Joslin, 11-Oct-06, This document consists of two primary components, a schema for agents that make use of the Lightweight Directory Access protocol (LDAP) and a proposed use case of that schema, for distributed configuration of similar directory user agents. A set of attribute types and an objectclass are proposed. In the proposed use case, directory user agents (DUAs) can use this schema to determine directory data location and access parameters for specific services they support. In addition, in the proposed use case, attribute and objectclass mapping allows DUAs to re-configure their expected (default) schema to match that of the end user's environment. This document is intended to be a skeleton for future documents that describe configuration of specific DUA services. "Explicit Multicast (Xcast) Concepts and Options", Richard Boivie, 31-Jan-07, While traditional IP multicast schemes [1112] are scalable for very large multicast groups, they have scalability issues with a very large number of distinct multicast groups. This document describes Xcast (Explicit Multi-unicast (Xcast)), a new multicast scheme with complementary scaling properties: Xcast supports a very large number of small multicast sessions. Xcast achieves this by explicitly encoding the list of destinations in the data packets, instead of using a multicast group address. This document discusses Xcast concepts and options in several areas; it does not provide a complete technical specification. "The ARK Persistent Identifier Scheme", John Kunze, Richard Rodgers, 28-Feb-07, The ARK (Archival Resource Key) naming scheme is designed to facilitate the high-quality and persistent identification of information objects. A founding principle of the ARK is that persistence is purely a matter of service and is neither inherent in an object nor conferred on it by a particular naming syntax. The best that an identifier can do is to lead users to the services that support persistence. The term ARK itself refers both to the scheme and to any single identifier that conforms to it. An ARK has five components: [http://NMAH/]ark:/NAAN/Name[Qualifier] an optional and mutable Name Mapping Authority Hostport, the "ark:" label, the Name Assigning Authority Number (NAAN), the assigned Name, and an optional and possibly mutable Qualifier supported by the NMA. The NAAN and Name together form the immutable persistent identifier for the object. An ARK is a special kind of URL that connects users to three things: the named object, its metadata, and the provider's promise about its persistence. When entered into the location field of a Web browser, the ARK leads the user to the named object. That same ARK, followed by a single question mark ('?'), returns a brief metadata record that is both human- and machine-readable. When the ARK is followed by dual question marks ('??'), the returned metadata contains a commitment statement from the current provider. Tools exist for minting, binding, and resolving ARKs. "SMB File Sharing URI Scheme", Christopher Hertel, 16-Jan-07, The Server Message Block (SMB) protocol is one of the most widely used network file system protocols in existence. This document describes a scheme for an SMB Uniform Resource Identifier (SMB URI) which can be used to identify SMB workgroups, servers, server shares, directories, files, inter-process communications ports (named pipes), and devices--the objects in the SMB network file system space. "SILC Commands", Pekka Riikonen, 19-Jan-07, This memo describes the commands used in the Secure Internet Live Conferencing (SILC) protocol, specified in the Secure Internet Live Conferencing, Protocol Specification [SILC1]. The SILC Commands are very important part of the SILC protocol. Usually the commands are used by SILC clients to manage the SILC session, but also SILC servers may use the commands. This memo specifies detailed command messages and command reply messages. "OSPF-xTE: An experimental extension to OSPF for Traffic Engineering", Pyda Srisuresh, Paul Joseph, 3-Jan-05, This document defines OSPF-xTE, an experimental traffic engineering (TE) extension to the link-state routing protocol OSPF. OSPF-xTE defines new TE LSAs to disseminate TE metrics within an autonomous System (AS), which may consist of multiple areas. Further, When an AS consists of TE and non-TE nodes, OSPF-xTE ensures that Non-TE nodes in the AS are uneffected by the TE LSAs. OSPF-xTE generates a stand-alone TE Link State Database (TE-LSDB), distinct from the native OSPF LSDB, for computation of TE circuit paths. OSPF-xTE is versatile and extendible to non-packet networks such as SONET/TDM and optical networks. "An IPv6 Provider-Independent Global Unicast Address Format", Tony Hain, 5-Sep-06, This document defines an IPv6 Provider-Independent global unicast address format for use in the Internet. The address format defined in this document is consistent with the IPv6 Protocol [1] and the "IPv6 Addressing Architecture" [2]. It is designed to facilitate scalable Internet routing when sites attach to multiple service providers, by using a prefix based on a geographic reference to the site. A natural byproduct of this address allocation mechanism is that all addresses are fixed allowing sites to change providers at will without requiring their network to renumber. "Application and Use of the IPv6 Provider Independent Global Unicast Address Format", Tony Hain, 5-Sep-06, This document discusses the expected use of the Provider Independent address format discussed in the companion document GEO [1] in the Internet. Several parties have expressed interest in using this approach as a good fit for managing their networks. With the long timeframe that the shim6 effort will take, this approach provides a scalable multi-homing approach for use in the interim. In addition to covering implementations where it adds value in managing the growth of the Internet routing tables, the document will discuss implementations that should be avoided due to the negative impact on the routing tables. "The Dublin Core Metadata Element Set", John Kunze, Thomas Baker, 1-Mar-07, Defines fifteen metadata elements for resource description in a cross-disciplinary information environment. "IPv4 Address Conflict Detection", Stuart Cheshire, 6-Nov-06, When two hosts on the same link attempt to use the same IPv4 address at the same time (except in rare special cases where this has been arranged by prior coordination) problems ensue for one or both hosts. This document describes (i) a simple precaution that a host can take in advance to help prevent this misconfiguration from happening, and (ii) if this misconfiguration does occur, a simple mechanism by which a host can passively detect after-the-fact that it has happened, so that the host or administrator may respond to rectify the problem. "LDAP: Dynamic Groups for LDAPv3", S Haripriya, 8-Jan-07, This document describes the requirements, semantics, schema elements, and operations needed for a dynamic group feature in LDAP. A dynamic group is defined here as a group object with a membership list of distinguished names that is dynamically generated using LDAP search criteria. The dynamic membership list may then be interrogated by LDAP search and compare operations, and may also be used to find the groups that an object is a member of. This feature eliminates a huge amount of the administrative effort required today for maintaining group memberships and role-based operations in large enterprises. "SS7 MTP2-User Peer-to-Peer Adaptation Layer Test Specifications M2PA-TEST", Brian Bidulock, 7-Feb-07, This Internet Draft provides information for the Internet community on test cases for testing the SS7 MTP2-User Peer-to-Peer Adaptation Layer [M2PA] based on the conformance test specifications for SS7 MTP Level 2 [Q.781]. This memo describes the test environment and a detailed description of test cases for validation, compatibility and interoperability testing of the M2PA protocol implemented on the foundation of ITU SS7 MTP Signalling Links [Q.703]. "Application Server Process (ASP) Extension (ASPEXT) Framework for Signalling User Adaptation Layers", Brian Bidulock, 7-Feb-07, This Internet-Draft describes ASP Extensions (ASPEXT) for Signalling User Adaptation Protocols [M2UA], [M3UA], [SUA], [IUA], [DUA], [V5UA], [GR303UA], [ISUA], [TUA], which permits cooperating Signalling Peer Processes (SPPs) to indicate to each other the specific protocol extensions that each supports. "Signalling Gateway (SG) Information (SGINFO) Support for Signalling User Adaptation Layers", Brian Bidulock, 7-Feb-07, This Internet-Draft describes Signalling Gateway (SG) Information (SGINFO) for Signalling User Adaptation Protocols [M2UA], [M3UA], [SUA], [ISUA], [TUA], which permits supporting Signalling Gateways (SG) to convey additional Application Server (AS) support information to Application Server Processes (ASPs) activating for AS on the SG. This additional AS support information consists of information pertaining to the underlying SS7 Signalling Provider that otherwise would have to be statically configured at the Application Server Process (ASP) or exchanged between SG and ASP using a non-IETF defined protocol. "Load Selection (LOADSEL) for Signalling User Adaptation Layers", Brian Bidulock, 7-Feb-07, This Internet-Draft describes Load Selection (LOADSEL) for Signalling User Adaptation Protocols [IUA], [DUA], [V5UA], [M2UA], [M3UA], [SUA], [GR303UA], [ISUA], [TUA], which permits an Application Server Processes (ASP) to indicate its placement within an Application Server and permits an Signalling Gateway (SG) to distribute traffic over ASPs in Application Servers under Application Server Process (ASP) control. "Load Grouping Extension for Signalling User Adaptation Layers", Brian Bidulock, 7-Feb-07, This Internet-Draft describes an extension parameter and procedure to the Signalling User Adaptation Protocols [IUA], [M2UA], [M3UA], [SUA], [DUA], [V5UA], [GR303UA], [ISUA], [TUA], based on the Stream Transmission Control Protocol (SCTP) [SCTP] which permits an Application Server Processes (ASP) to indicate its placement within a Load Group and permits an Signalling Gateway (SG) to distribute traffic over Load Groups under Application Server Process (ASP) control. The described procedure provides for Override, Load-share and Broadcast traffic mode operation within a Load Group consisting of one or more Application Server Processes (ASPs) resulting in a mixture of traffic modes within an Application Server (AS). The parameters and procedures described here supplement the UA Load Selection [LOADSEL] extension parameters and procedures for improved distribution of traffic over ASPs and Signalling Gateway Processes (SGPs). "Correlation Id and Hearbeat Procedures (CORID) Supporting Lossless Fail-Over between SCTP Associations for Signalling User Adaptation Layers", Brian Bidulock, 7-Feb-07, This Internet-Draft describes Correlation Id and Heartbeat procedures to support lossless fail-over between SCTP [SCTP] associations for SS7 [Q.700] Signalling User Adaptation Protocols [M2UA], [M3UA], [SUA], [ISUA], [TUA] supporting the concept of a Routing Context or Interface Identifier. These procedures permit lossless fail-over between Application Server Processes (ASPs) at a Signalling Gateway (SG) and fail-over between Signalling Gateway Processes (SGPs) and Signalling Gateways (SGs) at an Application Server Process (ASP). Lossless fail-over permits these fail-overs to occur without loss or duplication of UA-User messages. "SS7 TCAP-User Adaptation Layer (TUA)", Brian Bidulock, 7-Feb-07, This document defines a protocol for the transport of any SS7 TCAP- User signalling (e.g, INAP, MAP, etc.) over IP using the Stream Control Transport Protocol [SCTP]. The protocol should be modular and symmetric, to allow it to work in diverse architectures, such as a Signalling Gateway and IP Signalling End-point architecture. Protocol elements are added to allow seamless operation between peers in the SS7 and IP domains. "Media Gateway Control Protocol Fax Package", Flemming Andreasen, David Hancock, 6-Mar-07, This document defines a Media Gateway Control Protocol (MGCP) package to support fax calls. The package allows for fax calls to be supported in two different ways. The first one utilizes ITU-T Recommendation T.38 for fax relay under the control of the Call Agent. The second one lets the gateway decide upon a method for fax transmission as well as handle the details of the fax call without Call Agent involvement. "Analysis of IDR requirements and History", Avri Doria, Elwyn Davies, 20-Feb-07, This document analyses the current state of IDR routing with respect to RFC1126 and other IDR requirements and design efforts. It is the companion document to "Requirements for Inter-Domain Routing" [I-D.irtf-routing-reqs], which is a discussion of requirements for the future routing architecture and future routing protocols. Publication of this document is in accordance with the consensus of the active contributors the IRTF's Routing Research Group. "Instructions to Request for Comments (RFC) Authors", Joyce Reynolds, Robert Braden, 20-Jul-04, This memo provides information for authors of Request for Comments (RFC) documents. It summarizes RFC editorial policies and formatting requirements, addresses frequently-asked questions, and serves as a model for constructing a properly formatted RFC. "Mobile SCTP", Maximilian Riegel, Michael Tuexen, 23-Oct-06, Transport layer mobility management is presented in addition to Mobile IP for providing seamless mobility in the Internet. By use of SCTP (Stream Control Transmission Protocol) and some of its currently proposed extensions a seamless handover can be fully accomplished in the mobile client without any provisions in the network, only assisted by functions embedded in Mobile SCTP enabled servers. Client mobility management based on Mobile SCTP seems not to require any new protocol development. It is a particular application of SCTP eventually solving the requirements of transport layer mobility in the Internet. "IMAP METADATA Extension", Cyrus Daboo, 27-Feb-07, The METADATA extension to the Internet Message Access Protocol permits clients and servers to maintain "annotations" or "meta data" on IMAP servers. It is possible to have annotations on a per-mailbox basis or on the server as a whole. For example, this would allow comments about the purpose of a particular mailbox to be "attached" to that mailbox, or a "message of the day" containing server status information to be made available to anyone logging in to the server. "OSPF Link-local Signaling", Alex Zinin, 27-Oct-06, OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF routers exchange information on a link using packets that follow a well-defined format. The format of OSPF packets is not flexible enough to enable applications exchange arbitrary data, which may be necessary in certain situations. This memo describes a vendor specific, backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. "OSPF Out-of-band LSDB resynchronization", Alex Zinin, 27-Oct-06, OSPF is a link-state intra-domain routing protocol used in IP networks. LSDB synchronization in OSPF is achieved via two methods-- initial LSDB synchronization when an OSPF router has just been connected to the network and asynchronous flooding that ensures continuous LSDB synchronization in the presence of topology changes after the initial procedure was completed. It may sometime be necessary for OSPF routers to resynchronize their LSDBs. OSPF standard, however, does not allow routers to do so without actually changing the topology view of the network. This memo describes a vendor specific mechanism to perform such form of out-of-band LSDB synchronization. The mechanism described in this document was proposed before Graceful OSPF Restart [RFC3623] came into existence. It is implemented/supported by at least one major vendor and is currently deployed in the field. The purpose of this document is to capture the details of this mechanism for public use. This mechanism is not an IETF standard. "OSPF Restart Signaling", Alex Zinin, 27-Oct-06, Abstract OSPF is a link-state intra-domain routing protocol used in IP networks. Routers find new and detect unreachable neighbors via Hello subprotocol. Hello OSPF packets are also used to ensure two- way connectivity within time. When a router restarts its OSPF software, it may not know its neighbors. If such a router sends a hello packet on an interface, its neighbors are going to reset the adjacency, which may not be desirable in certain conditions. This memo describes a vendor specific mechanism that allows OSPF routers to inform their neighbors about the restart process. Note that this mechanism requires support from neighboring routers. The mechanism described in this document was proposed before Graceful OSPF Restart [RFC3623] came into existence. It is implemented/ supported by at least one major vendor and is currently deployed in the field. The purpose of this document is to capture the details of this mechanism for public use. This mechanism is not an IETF standard. "Web Distributed Authoring and Versioning (WebDAV) SEARCH", Julian Reschke, 13-Feb-07, This document specifies a set of methods, headers, properties and content-types composing WebDAV SEARCH, an application of the HTTP/1.1 protocol to efficiently search for DAV resources based upon a set of client-supplied criteria. "SMTP Submission Service Extension for Future Message Release", Gregory White, Gregory Vaudreuil, 10-Aug-06, This memo defines an extension to the SMTP submission protocol for a client to indicate a future time for the message to be released for delivery. This extension permits a client to use server-based storage for a message that should be held in queue until an appointed time in the future. This is useful for clients which do not have local storage or are otherwise unable to release a message for delivery at an appointed time. "SILC Message Flag Payloads", Pekka Riikonen, 26-May-05, This memo describes the data payloads associated with the SILC Message Flags, as defined in the SILC Packet Protocol specification [SILC2]. The purpose of the Message Flags is to augment the function of the Message Payload used to send both private and channel messages, by allowing the sender to tell the receiver what type of data the payload includes, and how the data should be processed. Some of the Message Flags may define additional payloads to be associated with the flag, and this memo describes these payloads. "User Online Presence and Information Attributes", Pekka Riikonen, 19-Jan-07, This document defines set of attributes that can represent the online user's presence in a network, and to provide general information about the user. The purpose is to provide a generic mechanism to share online presence and status, and general information about the user to be used in several kind of network protocols and applications. These attributes could be used by for example chat and conferencing protocols (such as Instant Message protocols), network games, and other similar network protocols and applications that has online users in a network. "IPv6 Reverse Routing Header and its application to Mobile Networks", Pascal Thubert, Marco Molteni, 14-Feb-07, NEMO basic support enables Mobile Networks by extending Mobile IP to Mobile Routers. In the case of nested Mobile Networks, this involves the overhead of nested tunnels between the Mobile Routers and their Home Agents, and causes a number of security issues. This proposal alleviates those problems as well as other minor ones, by using a source routing within the mobile nested structure, introducing a new routing header, called the reverse routing header. "URI Fragment Identifiers for the text/plain Media Type", Erik Wilde, Martin Duerst, 17-Jan-07, This memo defines URI fragment identifiers for text/plain MIME entities. These fragment identifiers make it possible to refer to parts of a text/plain MIME entity, identified by character count or range, line count or range, or a regular expression. These identification methods can be combined to identify more than one sub- resource of a text/plain MIME entity. Fragment identifiers may also contain hash information to make them more robust. "Using PPP-over-Ethernet (PPPoE) in Wireless LANs", Giuseppe Paterno, 26-May-05, This document explores the use of Point-To-Point Protocol over Ethernet (PPPoE) to provide wireless access to the Internet and suggests how the infrastructure can be deployed. The document targets consumers, corporations, Internet Service Providers, and mobile phone operators that provide user access through Wireless LANs technologies such as IEEE 802.11. "XML Schema for Media Control", Orit Levin, 15-Jan-07, This document defines an XML Schema for video fast update in a tightly controlled environment, developed by Microsoft, Polycom, Radvision and used by multiple vendors. This document describes a method that has been deployed in SIP based systems for over the last three years and being used across real-time interactive applications from different vendors in interoperable manner. New implementations are discouraged from using the described method described except for backward compatibility purposes. New Implementations are required to use the new full intra request command in the RTCP channel. "Secure Ad hoc On-Demand Distance Vector (SAODV) Routing", Manel Guerrero Zapata, 6-Sep-06, The Secure Ad hoc On-Demand Distance Vector (SAODV) is an extension of the AODV routing protocol that can be used to protect the route discovery mechanism providing security features like integrity and authentication. "EAP-Support in Smartcard", Guy Pujolle, Pascal Urien, 21-Feb-07, This document describes the functional interface, based on the ISO7816 standard, for EAP methods fully and securely executed in smartcards. These tamper resistant devices may deliver client or server services. "Guidelines for Mandating the Use of IPsec", Steven Bellovin, 8-Feb-07, The Security Considerations sections of many Internet Drafts say, in effect, "just use IPsec". While this is sometimes correct, more often it will leave users without real, interoperable security mechanisms. This memo offers some guidance on when IPsec Version 2 should and should not be specified. "Split Multi-link Trunking (SMLT)", Roger Lapuh, 19-Jan-06, This document describes Split Multi-link Trunking (SMLT) for bridged and routed networks. SMLT enables topologies with upstream node redundancy for increased reliability of Layer 2 link aggregation subnetworks based on [IEEE 802.3ad] and router redundancy based on VRRP [RFC 2338]. SMLT is an improvement over Multi-Link Trunking (MLT), a method of link aggregation that allows multiple Ethernet links to be aggregated together, and handled as a single logical trunk. MLT can be realized via many different link aggregation mechanisms. Several methods of MLT are in use today; one example is [IEEE 802.3ad]. SMLT is MLT with links of a link-aggregation group connected to ports on two different devices (e.g. SMLT client and aggregation device). Unlike MLT, at least one end of a link-aggregated group is dual-homed to two different SMLT aggregation devices. In many cases those devices act as bridges (switches) as well as L3 routers (Routing Switches). These two redundant SMLT aggregation devices can share one or more VRRP routing instances; for that SMLT-VRRP extends the VRRP functionality to an active-active router concept, where both SMLT aggregation device route traffic for a common VRRP-ID, thus load balancing traffic not only for L2 but also for L3. "SS7 ISUP-User Adaptation Layer (ISUA)", Brian Bidulock, 7-Feb-07, This document defines a protocol for the transport of any SS7 ISUP- User signalling (e.g, Call Control) over IP using the Stream Control Transport Protocol [SCTP]. The protocol should be modular and symmetric, to allow it to work in diverse architectures, such as a Signalling Gateway and IP Signalling End-point architecture. Protocol elements are added to allow seamless operation between peers in the SS7 and IP domains. "Registration Extensions (REGEXT) for Signalling User Adaptation Layers", Brian Bidulock, 7-Feb-07, This memo describes Registration Extensions (REGEXT) that provides the ability for an Application Server Process (ASP) to modify existing Routing (Link) Keys with a Signalling Gateway (SG). Current procedures in the SS7 Signalling User Adaptation Layers (UAs) [M2UA], [M3UA], [SUA], [ISUA], [TUA] do not provide for the modification of Routing (Link) Keys without deactivation of the Application Server (AS). This causes problems in making changes to live systems. The extensions described in this memo permit modification of Signalling Link membership in Application Servers for SS7 MTP2-User Adaptation Layer [M2UA], modification of Circuit Identification Code (CIC) ranges for the SS7 MTP3-User Adaptation Layer [M3UA], modification of Circuit Identification Code (CIC) ranges for the SS7 ISUP-User Adaptation Layer [ISUA], modificiation of Destination Local Reference (DLR) ranges for SS7 SCCP-User Adaptation Layer [SUA], and modification of Transaction Identifier (TID) ranges for SS7 TCAP-User Adaptation Layer [TUA]. "IPv6 Socket API for Address Selection", Erik Nordmark, 7-Mar-07, The IPv6 default address selection document [RFC3484] describes the rules for selecting source and destination IPv6 addresses, and indicates that applications should be able to reverse the sense of some of the address selection rules through some unspecified API. However, no such socket API exists in the basic [RFC3493] or advanced [RFC3542] IPv6 socket API documents. This document fills that gap by specifying new socket level options and flags for the getaddrinfo() API to specify preferences for address selection that modify the default address selection algorithm. The socket API described in this document will be particularly useful for IPv6 applications that want to choose between temporary and public addresses, and for Mobile IPv6 aware applications that want to use the care-of address for communication. "LSP Preemption Policies for MPLS Traffic Engineering", Jaudelice de Oliveira, 28-Nov-06, When the establishment of a higher priority (Traffic Engineering Label Switched Path) TE LSP requires the preemption of a set of lower priority TE LSPs, a node has to make a local decision to select which TE LSPs will be preempted. The preempted LSPs are then rerouted by their respective Head-end Label Switch Router (LSR). This document presents a flexible policy that can be used to achieve different objectives: preempt the lowest priority LSPs; preempt the minimum number of LSPs; preempt the set of TE LSPs that provide the closest amount of bandwidth to the required bandwidth for the preempting TE LSPs (to minimize bandwidth wastage); preempt the LSPs that will have the maximum chance to get rerouted. Simulation results are given and a comparison among several different policies, with respect to preemption cascading, number of preempted LSPs, priority, wasted bandwidth and blocking probability is also included. "Early Retransmit for TCP and SCTP", Mark Allman, 26-Nov-06, This document proposes a new mechanism for TCP and SCTP that can be used to recover lost segments when a connection's congestion window is small. The "Early Retransmit" mechanism allows the transport to reduce, in certain special circumstances, the number of duplicate acknowledgments required to trigger a fast retransmission. This allows the transport to use fast retransmit to recover packet losses that would otherwise require a lengthy retransmission timeout. "The LDAP No-Op Control", Kurt Zeilenga, 14-Feb-07, This document defines the Lightweight Directory Access Protocol (LDAP) No-Op control which can be used to disable the normal effect of an operation. The control can be used to discover how a server might react to a particular update request without updating the directory. "Bundle Protocol Specification", Keith Scott, Scott Burleigh, 8-Dec-06, This document describes the end-to-end protocol, block formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN). "Delay-Tolerant Networking Architecture", Vinton Cerf, 15-Dec-06, This document describes an architecture for delay-tolerant and disruption-tolerant networks, and is an evolution of the architecture originally designed for the Interplanetary Internet, a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration. This document describes an architecture that addresses a variety of problems with internetworks having operational and performance characteristics that make conventional (Internet-like) networking approaches either unworkable or impractical. We define a message- oriented overlay that exists above the transport (or other) layers of the networks it interconnects. The document presents a motivation for the architecture, an architectural overview, review of state management required for its operation, and a discussion of application design issues. "Lumas - Language for Universal Message Abstraction and Specification", Peter Cordell, 2-Feb-07, A number of methods and tools are available for defining the format of messages used for application protocols. However, many of these methods and tools have been designed for purposes other than message definition, and have been adopted on the basis that they are available rather than being ideally suited to the task. This often means that the methods make it difficult to get definitions correct, or result in unnecessary complexity and verbosity both in the definition and on the wire. Lumas - Language for Universal Message Abstraction and Specification - has been custom designed for the purpose of message definition. It is thus easy to specify messages in a compact, extensible format that is readily machine manipulated to produce a compact encoding on the wire. "EAP IKEv2 Method", Hannes Tschofenig, 7-Mar-07, This document specifies EAP-IKEv2, an EAP authentication method that is based on the Internet Key Exchange (IKEv2) protocol. EAP-IKEv2 provides mutual authentication and session key establishment between an EAP peer and an EAP server. It supports authentication techniques that are based on passwords, high-entropy shared keys, and public key certificates. These techniques can be combined in a number of ways. EAP-IKEv2 further provides support for cryptographic ciphersuite negotiation, hash function agility, identity confidentiality (in certain modes of operation), fragmentation, and an optional "fast reconnect" mode. EAP-IKEv2 has sucessfully passed Designated Expert Review as mandated by RFC 3748. "Internet Application Protocol Collation Registry", Chris Newman, 15-Sep-06, Many Internet application protocols include string-based lookup, searching, or sorting operations. However the problem space for searching and sorting international strings is large, not fully explored, and is outside the area of expertise for the Internet Engineering Task Force (IETF). Rather than attempt to solve such a large problem, this specification creates an abstraction framework so that application protocols can precisely identify a comparison function and the repertoire of comparison functions can be extended in the future. "Verizon Wireless Dynamic Mobile IP Key Update for cdma2000(R) Networks", Christopher Carroll, Frank Quick, 28-Mar-05, The Verizon Wireless Dynamic Mobile IP Key Update procedure is a mechanism for distributing and updating Mobile IP (MIP) cryptographic keys in cdma2000(R) networks (including High Rate Packet Data which is often referred to as 1xEV-DO). The Dynamic Mobile IP Key Update (DMU) procedure occurs between the MIP Mobile Node (MN) and RADIUS AAA Server via a CDMA2000(R) Packet Data Serving Node (PDSN) that is acting as a Mobile IP Foreign Agent (FA). "Implementing Multiple Line Appearances using the Session Initiation Protocol (SIP)", Anil Kumar, 6-Mar-07, This document describes the implementation of a group telephony feature commonly known as Bridged Line Appearance (BLA), Multiple Line Appearance (MLA), or Shared Call/Line Appearance (SCA). When implemented using the Session Initiation Protocol (SIP), it is referred to as Multiple Appearances. This feature is commonly offered in the IP Centrex services and IP-PBX offerings and is likely to be implemented on SIP IP telephones and SIP feature servers used in a business environment. This specification defines a new SIP dialog event package tag "appearance" and a method for a group of SIP user agents to coordinate the identification of appearances between them using SIP dialog package subscriptions. "The Calling Party's Category tel URI Parameter", Rohan Mahy, 7-Mar-07, This document specifies a new parameter for the tel URI that represents the Calling Party's Category, a parameter used in SS7 ISUP and other telephony signaling protocols. "Memorandum for multi-domain Public Key Infrastructure Interoperability", Masaki SHIMAOKA, 14-Feb-07, This document desires to establish a standard terminology and actual language for interoperability of multi-domain PKI that consists of several PKI domains which are operated under each distinct policy. This document describes the relationships between Certification Authorities (CAs), the definition and requirements for PKI domains, and typical models of multi-domain PKI. "GOST 28147-89 Cipher Suites for Transport Layer Security (TLS)", Grigorij Chudov, Serguei Leontiev, 10-Sep-06, This document is intended to register new cipher suites for the Transport Layer Security (TLS) protocol, according to the procedure specified in TLS Protocol standards. These cipher suites are based on Russian national cryptographic standards - GOST R 34.10-94 and GOST R 34.10-2001 public keys, GOST 28147-89 encryption algorithm and GOST R 34.11-94 digest algorithm. "IPv6 Router Advertisement Option for DNS Configuration", Jae-Hoon Jeong, 20-Feb-07, This document specifies a new IPv6 Router Advertisement option to allow IPv6 routers to advertise DNS recursive server addresses to IPv6 hosts. "SS7 MTP2-User Adaptation Layer (M2UA) SS7 Test Specifications M2UA-SS7TEST", Brian Bidulock, 7-Feb-07, This Internet-Draft provides information for the Internet community on the implementation of test cases for testing the SS7 MTP2-User Adaptation Layer [M2UA] Signalling Gateway (SG) based on the conformance test specifications for SS7 MTP Level 2 [Q.780], [Q.781], [M2PATEST07]. "The XML Enabled Directory", Steven Legg, Daniel Prager, 20-Oct-06, The XML Enabled Directory (XED) leverages existing Lightweight Directory Access Protocol (LDAP) and X.500 directory technology to create a directory service that stores, manages and transmits Extensible Markup Language (XML) format data, while maintaining interoperability with LDAP clients and X.500 agents. This document introduces the various XED specifications. "The XML Enabled Directory: Schema Operational Attributes", Steven Legg, Daniel Prager, 16-Nov-06, This document defines additional subschema operational attributes for the XML Enabled Directory (XED) that allow user-defined directory attribute syntaxes to be imported into a directory server. User defined syntaxes specified in XML Schema, RELAX NG or Abstract Syntax Notation One (ASN.1), or specified as XML document type definition (DTD) element type declarations, are supported. "Abstract Syntax Notation X (ASN.X)", Steven Legg, 22-Dec-06, Abstract Syntax Notation X (ASN.X) is a semantically equivalent Extensible Markup Language (XML) representation for Abstract Syntax Notation One (ASN.1) specifications. ASN.X completely avoids the numerous ambiguities inherent in the ASN.1 language, therefore specifications written in ASN.X are much easier to parse and manage than original ASN.1 specifications. ASN.X, together with the Robust XML Encoding Rules (RXER), constitutes a schema language for XML documents that offers, through other ASN.1 encoding rules, alternative compact binary encodings for XML instance documents. "Requirements for Inter-Domain Routing", Avri Doria, 25-Jan-07, These requirements for routing architectures are the product of two sub-groups with the IRTF Routing Research Group. They represent two individual and separate views of the problem and of what is required to fix the problem. While speaking of requirements, the document is actually a recommendation to anyone who would create a routing architecture for the Internet in the coming years. Publication of this document is in accordance with the consensus of the active contributors the IRTF's Routing Research Group. "The XML Enabled Directory: Protocols", Steven Legg, Daniel Prager, 16-Nov-06, This document defines semantically equivalent Extensible Markup Language (XML) renditions of the Lightweight Directory Access Protocol (LDAP) and X.500 directory protocols for use by the XML Enabled Directory (XED). "Private VLANs: Addressing VLAN scalability and security issues in a multi-client environment", Sanjib HomChaudhuri, Marco Foschiano, 16-Feb-07, This document describes the concept of Layer 2 isolation among devices that are members of the same Layer 2 domain. A vlan is a broadcast domain in which all devices can establish direct communication with one another at Layer 2. As a consequence, devices that are connected to the same vlan have an implicit trust relationship with each other. If 'untrusted' devices are introduced into a vlan, security issues may arise because trusted and untrusted devices end up sharing the same broadcast domain. The traditional solution to this kind of problem is to assign a separate vlan to each device that is concerned about Layer 2 security issues. That however is not a scalable solution. The mechanism proposed in this document can offer total Layer 2 isolation between devices connected to the same vlan. What that means is that, on the one hand, each customer will enjoy the benefits that come with a separate dedicated vlan, while on the other hand the service provider will enjoy the benefit of consuming as few as two vlan identifiers. Moreover, the scheme described in this document allows end devices to be Layer 2 isolated while sharing the same IP subnet, which in turn allows the network designer to employ larger subnets and reduce the address allocation and management overhead. "A Bound End-to-End Tunnel (BEET) mode for ESP", Jan Melen, Pekka Nikander, 23-Feb-07, This document specifies a new mode, called Bound End-to-End Tunnel (BEET) mode, for IPsec ESP. The new mode augments the existing ESP tunnel and transport modes. For end-to-end tunnels, the new mode provides limited tunnel mode semantics without the regular tunnel mode overhead. The mode is intended to support new uses of ESP, including mobility and multi-address multi-homing. "IMAP Extension for SASL Initial Client Response", Arnt Gulbrandsen, Robert Siemborski, 26-Nov-06, To date, the Internet Message Access Protocol (IMAP) has used a Simple Authentication and Security Layer (SASL) profile which always required at least one complete round trip for an authentication, as it did not support an initial client response argument. This additional round trip at the beginning of the session is undesirable, especially when round trip costs are high. This document defines an extension to IMAP which allows clients and servers to avoid this round trip by allowing an initial client response argument to the IMAP AUTHENTICATE command. This document defines an extension to IMAP which allows clients and servers to avoid this round trip by allowing an initial client response argument to the IMAP AUTHENTICATE command. "SMTP Service Extension for Authentication", Robert Siemborski, Alexey Melnikov, 23-Feb-07, This document defines a Simple Mail Transport Protocol (SMTP) extension whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session. This extension includes a profile of the Simple Authentication and Security Layer (SASL) for SMTP. This document obsoletes RFC 2554 and replaces it as a Proposed Standard. "POP3 SASL Authentication Mechanism", Abhijit Menon-Sen, Robert Siemborski, 23-Feb-07, This document defines a profile of the Simple Authentication and Security Layer (SASL) for the Post Office Protocol (POP3). This extension allows a POP3 client to indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session. This document seeks to consolidate the information related to POP3 AUTH into a single document. To this end, this document obsoletes RFC 1734, replacing it as a Proposed Standard, and updates information contained in Section 6.3 of RFC 2449. "Pseudowire Congestion Control Framework", Eric Rosen, 19-Oct-06, Given that pseudowires may be used to carry non-TCP data flows, it is necessary to provide pseudowire-specific congestion control procedures. These procedures should ensure that pseudowire traffic is "TCP-compatible", as defined in RFC 2914. This document attempts to lay out the issues which must be considered when defining such procedures. "Stream Control Transmission Protocol (SCTP) Packet Drop Reporting", Randall Stewart, 12-Jan-07, This document describes a new chunk type for SCTP. This new chunk type can be used by both endhosts and routers to report the loss of SCTP datagrams due to errors in transmission or other drops not due to congestion. "Remote Call Control in the Session Initiation Protocol (SIP) using the REFER method and the session-oriented dialog package", Cullen Jennings, Rohan Mahy, 7-Mar-07, This document describes how to use the SIP REFER method and the dialog package to manipulate conversations, dialogs, and sessions on remote User Agents. Specifically it extends the REFER mechanism to allow the specification of a response that a UA should send in a dialog. This functionality is most useful for collections of loosely coupled User Agents that wish to present a coordinated user experience. It does not require a Third-Party Call Control controller to be involved in any of the manipulated dialogs. "Session Initiation Protocol (SIP) Event Notification Extension for Notification Throttling", Aki Niemi, 8-Mar-07, This memo specifies a throttle mechanism for limiting the rate of Session Initiation Protocol (SIP) event notifications. This mechanism can be applied in subscriptions to all SIP event packages, but the mechanism is especially designed to be used in combination with a subscription to a Resource List Server (RLS). "FLUTE Interoperability Testing Guidelines", Harsh Mehta, 2-Feb-07, This document describes a possible testing strategy for interoperability among implementations of the File Delivery over Unidirectional Transport (FLUTE) protocol. "MANET Extension of OSPF using CDS Flooding", Phil Spagnolo, Richard Ogier, 5-Mar-07, This document specifies an extension of OSPF for IPv6 to support mobile ad hoc networks (MANETs). The extension, called OSPF-MDR, is designed as a new OSPF interface type for MANETs. OSPF-MDR is based on the selection of a subset of MANET routers, consisting of MANET Designated Routers (MDRs) and Backup MDRs. The MDRs form a connected dominating set (CDS), and the MDRs and Backup MDRs together form a biconnected CDS for robustness. This CDS is exploited in two ways. First, to reduce flooding overhead, an optimized flooding procedure is used in which only (Backup) MDRs flood new LSAs back out the receiving interface; reliable flooding is ensured by retransmitting LSAs along adjacencies. Second, adjacencies are formed only between (Backup) MDRs and a subset of their neighbors, allowing for much better scaling in dense networks. The CDS is constructed using 2-hop neighbor information provided in a Hello protocol extension. The Hello protocol is further optimized by allowing differential Hellos that report only changes in neighbor states. Options are specified for originating router-LSAs that provide full or partial topology information, allowing overhead to be reduced by advertising less topology information. "Remote Authentication Dial In User Service (RADIUS) Attribute Type Extension", Avi Lior, 20-Oct-06, In order for the Remote Authentication Dial In User Service protocol to continue to support new applications, the RADIUS attribute space must be extended beyond the current limit of 255 possible attribute types. This document defines a mechanism to extend the base RADIUS attribute types while maintaining backwards compatibility as well as compatibility with Diameter. "Calendaring Extensions to WebDAV (CalDAV)", Lisa Dusseault, 15-Sep-06, This document specifies a set of methods, headers, message bodies, properties, and reports that define calendar access extensions to the WebDAV protocol. The new protocol elements are intended to make WebDAV-based calendaring and scheduling an interoperable standard that supports calendar access, calendar management, calendar sharing, and calendar publishing. "Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One (ASN.1)", Daniel Prager, Steven Legg, 22-Dec-06, This document defines a set of Abstract Syntax Notation One (ASN.1) encoding rules, called the Robust XML Encoding Rules or RXER, that produce an Extensible Markup Language (XML) representation for values of any given ASN.1 data type. Rules for producing a canonical RXER encoding are also defined. "DHCP Proxy Server Micro-block Allocation Scheme For IP Address Pool Management", Naiming Shen, 21-Dec-06, A new DHCP address allocation mechanism called Micro-blocking is proposed in this document. It is used for DHCP proxy servers or routers working with DHCP servers to maximize the IP address allocation efficiency while improve dynamic routing scalability in provider's networks. A DHCP sub-option within the relay agent information option 82 is defined in this document. This simple DHCP extension can be applied as a simple IP address-pool management among multiple IP devices. "SixXS Heartbeat Protocol", Jeroen Massar, 6-Jun-05, This document proposes a heartbeat protocol for signalling availability of hosts with a specific emphasis on providing a signalling protocol for allowing dynamic non-24/7 endnodes to use tunnel's of the various IPv6 Tunnel Brokers. "IPsec Security Policy Database Configuration MIB", Wesley Hardaker, 19-Oct-06, This document defines an SMIv2 Management Information Base (MIB) module for configuring the security policy database of a device implementing the IPsec protocol. The policy-based packet filtering and the corresponding execution of actions described in this document are of a more general nature than for IPsec configuration alone, such as for configuration of a firewall. This MIB module is designed to be extensible with other enterprise or standards based defined packet filters and actions. "6to4 Reverse DNS Delegation Specification", Geoff Huston, 23-Oct-06, This memo describes the service mechanism for entering a delegation of DNS servers which provide reverse lookup of 6to4 IPv6 addresses into the 6to4 reverse zone file. The mechanism is based on a conventional DNS delegation service interface, allowing the service client to enter the details of a number of DNS servers for the delegated domain. In the context of a 6to4 reverse delegation, the client is primarily authenticated by its source address used in the delegation request, and is authorised to use the function if its IPv6 address prefix corresponds to an address from within the requested 6to4 delegation address block. "Considerations in Validating the Path in BGP", Russ White, 16-Aug-06, A good deal of thought has gone into, and is currently being given to, validating the path to a destination advertised by BGP. The purpose of this work is to explain the issues in validating a BGP AS Path, in the expectation that it will help in the evaluation of schemes seeking to improve path validation. The first section defines at least some of the types of questions a BGP speaker receiving an update from a peer not in the local autonomous system (AS) could ask about the information within the routing update. The sections following examine the answers to these questions in consideration of specific deployments of BGP. The examples given in this draft are intended to distill deployments down to their most critical components, making the examples easier to understand and consider. In many situations, the specific path taken in the example may not be relevant, but that does not nullify the principles considered in each example. It has been suggested that these examples are "red herrings," because they do not illustrate actual problems with specific policies. On the contrary, these examples are powerful because they are simple. Any topology in which one of these example topologies is a subtopology will exhibit the characteristics explained in this draft. Rather than focusing on a specific topology, then dismissing that single topology as a "corner case," this draft shows the basic issues with assertions about the AS Path attribute within BGP. These generalized issues can then be applied to more specific cases. "Mixmaster Protocol Version 2", U Moeller, 30-Dec-04, Most e-mail security protocols only protect the message body, leaving useful information such as the identities of the conversing parties, sizes of messages and frequency of message exchange open to adversaries. This document describes Mixmaster version 2, a mail transfer protocol designed to protect electronic mail against traffic analysis. "ECN Nonces for Stream Control Transmission Protocol (SCTP)", Sourabh Ladha, 12-Jan-07, This document describes the addition of the ECN-nonce RFC 3540 [4] to the Stream Control Transmission Protocol (SCTP) RFC 2960 [3]. The ECN-nonce reduces the vulnerability of ECN senders to misbehaving receivers that conceal congestion signals like ECN marks and packet losses. The ECN-nonce approach is different in SCTP because SCTP uses chunks for extensible protocol features and is selective acknowlegement (SACK)-based; this document describes those differences. In particular this document describes (1) protocol extensions in the form of a single new parameter for the INIT/ INIT-ACK chunks, and a single bit flag in the SACK chunk, and (2) rules governing the sender and receiver side implementation. This document outlines a minimum response that an SCTP sender should apply after detecting a misbehaving receiver. "Basic Messaging and Presence Interworking between the Extensible Messaging and Presence Protocol (XMPP) and Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE)", Peter Saint-Andre, 1-Mar-07, This document defines a bi-directional protocol mapping for use by gateways that enable the exchange of presence information and single instant messages between systems that implement the Extensible Messaging and Presence Protocol (XMPP) and those that implement the basic extensions to the Session Initiation Protocol (SIP) for instant messaging and presence. "The Archived-At Message Header Field", Martin Duerst, 26-Oct-06, This memo defines a new email header field, Archived-At:, to provide a direct link to the archived form of an individual email message. "Multi-party Instant Message (IM) Sessions Using the Message Session Relay Protocol (MSRP)", Aki Niemi, Miguel Garcia-Martin, 7-Mar-07, The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP). This document defines the necessary tools for establishing multi-party instant messaging (IM) sessions, or chat rooms, with MSRP. "IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)", Florent Parent, Marc Blanchet, 2-Sep-05, A tunnel broker with the Tunnel Setup Protocol (TSP) enables the establishment of tunnels of various inner protocols, such as IPv6 or IPv4, inside various outer protocols packets, such as IPv4, IPv6 or UDP over IPv4 for IPv4 NAT traversal. The control protocol (TSP) is used by the tunnel client to negotiate the tunnel with the broker. A mobile node implementing TSP can be connected to both IPv4 and IPv6 networks whether it is on IPv4 only, IPv4 behind a NAT or on IPv6 only. A tunnel broker may terminate the tunnels on remote tunnel servers or on itself. This document describes the TSP protocol within the model of the tunnel broker model. "The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)", Joseph Salowey, 15-Jan-07, This document defines the Extensible Authentication Protocol (EAP) based Flexible Authentication via Secure Tunneling (EAP-FAST) protocol. EAP-FAST is an EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the peer and the EAP server. "MIPv6 Authorization and Configuration based on EAP", Gerardo Giaretta, 22-Oct-06, This draft defines an architecture, and related protocols, for performing dynamic Mobile IPv6 authorization and configuration relying on a AAA infrastructure. The necessary interaction between the AAA server of the home provider and the mobile node is realized using EAP, exploiting the capability of some EAP methods to convey generic information items together with authentication data. This approach has the advantage that the access equipment acts as a simple pass-through for EAP messages and therefore does not play any active role in the Mobile IPv6 negotiation procedure, which makes the solution easier to deploy and maintain. "Problem Statement for MIPv6 Interactions with GPRS/UMTS Packet Filtering", Xiaobao Chen, 1-Feb-07, This document provides an analysis of certain inter-working problems between IPv6 nodes running Mobile IPv6, at least one of which is connected to a Third Generation Partnership Project (3GPP) specified General Packet Radio Service/Universal Mobile Tele- communications System (GPRS/UMTS) network. The inter-working problems are caused by some specific packet filtering operations at the edge of the GPRS/UMTS network which are applied to control access to the GPRS/UMTS services and network resources. However, we believe that other scenarios may exist in which similar packet filtering operations may be applied and that similar problems would arise in these more general scenarios. The GPRS Gateway Support Node (GGSN) checks the source address or the destination address in the basic IPv6 header of incoming or outgoing IP datagrams against a set of packet filtering information established during the GPRS/UMTS session set-up. The packet filtering information remains stable during the sessions and independent of Mobile IP. When MIPv6 is activated by either end of the IPv6 mobile nodes, the packet filtering will fail to perform properly and subsequently block the traffic due to the mismatch between the packet filters and the current source address or destination address in the basic IPv6 header of the IP datagrams to and from the IPv6 mobile nodes. "A note about 3rd party bombing in Mobile IPv6", Francis Dupont, 23-Jan-07, Mobile IPv6 introduces some new kinds of reflection attacks, as known as 3rd party bombing. This memo analyses these attacks and makes some recommendations: the goal is to avoid anything, including in new optimized mechanisms, which can make the life of bad guys easier. "Terminology for Benchmarking LDP Data Plane Convergence", Thomas Eriksson, 28-Feb-07, This document defines new terms for benchmarking of LDP convergence. These terms are to be used in future methodology documents for benchmarking LDP Convergence. Existing BMWG terminology documents such as IGP Convergence Benchmarking [3] provide useful terms for LDP Convergence benchmarking. These terms are discussed in this document. Applicable terminology for MPLS and LDP defined in MPLS WG RFCs [1] and [2] is also discussed. "Iowa Internet Annoyance Logging Protocol (IIALP) pronounced E'-alp", George Davey, 10-Jan-07, This draft describes a system by which Internet Annoyances can be logged quickly and automatically using IIALP (Iowa Internet Annoyance Logging Protocol). The annoyance logs on a particular IIALP Server are condensed and forwarded up the IIALP hierarchy to central Root IIALP Servers for central annoyance queries. Serial numbers and TTL values keep the individual reports organized and dated. One unique complaint per IP per epoch period prevents flooding. Differences in detail and propagation parameters exist between Root and Subordinate IIALP Servers to allow for more detail to be kept at the originating IIALP Server. Standard XML and TCP security techniques, and Hierarchy Structure eliminate erroneous reporting. Routers and software running IIALP can use IIALP to create dynamic QOS lists for abusing Internet assets exceeding a set limits. IIALP allows for an infinite number of different types of annoyances to exist but has concise templates for common annoyances such as SPAM. IIALP is a centralized logging system for Internet annoyance event reporting. "Multi-homing for small scale fixed network Using Mobile IP and NEMO", Kenichi Nagami, 4-Mar-05, Multi-homing technology improves the availability of host and network connectivity. Since the node and network behavior of mobile networking and fixed networking are different, the different architecture has been discussed and proposed. This document proposes the common architecture both for mobile and fixed networking environment, using the mobile IP and NEMO. The proposed architecture only requires a modification of the mobile IP and NEMO so that multiple-CoA can be used. In addition, multiple HAs which are located in different place, are required for redundancy. "PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics", Bo Berry, Howard Holgate, 14-Nov-06, This document extends the Point-to-Point Over Ethernet (PPPoE) Protocol [2] with a credit-based flow control mechanism and Link Quality Metric report. This optional extension should improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile radio links. "IMAP4 POSTADDRESS extension", Alexey Melnikov, 8-Nov-06, The POSTADDRESS extension of the Internet Message Access Protocol [IMAP4] permits a client to discover an email address that can be used to send messages to an IMAP mailbox. "Extensions to OSPF to Support Mobile Ad Hoc Networking", Abhay Roy, M Chandra, 22-Jan-07, This document describes extensions to OSPF to support mobile ad hoc networking. Specifically, the document specifies a mechanism for link-local signaling, a OSPF-MANET interface, a simple technique to reduce the size of Hello packets by only transmitting incremental state changes, and a method for optimized flooding of routing updates. "Mobile IPv4 NAI-based Home Address Assignment", Naveen PaulKandasamy, Kent Leung, 8-Mar-07, AAA servers are in use within the Internet today to provide authentication and authorization services for dial-up computers. Such services are likely to be equally valuable for mobile nodes using Mobile IP when the nodes are attempting to connect to foreign domains with AAA servers. AAA servers today identify clients by using the Network Access Identifier (NAI). Our proposal defines a way for the mobile node to identify itself, by including the NAI along with the Mobile IP Registration Request. This memo also updates RFC 2290 which specifies the Mobile-IPv4 Configuration option for IPCP, by allowing the Mobile Node's Home Address field of this option to be zero and specifying a comprehensive procedure for achieving a NAI-based home address assignment and more particularly, the Home Agent and Mobile Node behaviors including the error recovery mechanisms for various scenarios related to NAI-based home address assignment. "Email Submission: Access and Accountability", Carl Hutzler, 27-Oct-05, Email has become a popular distribution service for a variety of socially unacceptable, mass-effect purposes. The most obvious ones include spam and worms. This note recommends conventions for the operation of email submission and transport services between independent operators, such as enterprises and Internet Service Providers. Its goal is to improve lines of accountability for controlling abusive uses of the Internet mail service. Consequently the document offers recommendations for constructive operational policies between independent operators of email transmission services. With the recent advent of email authentication technologies aimed at providing assurances and traceability between internetworked networks, the authors recognized that the initial submission of a message became the weakest link. Consequently, the document offers recommendations for constructive operational policies for the first step of email sending, the submission (or posting) of email into the transmission network. Relaying and delivery entail policies that occur subsequent to submission and are outside the scope of this document. The document seeks BCP status. Comments and discussion of this document should be addressed to the ietf-smtp@imc.org mailing list. "User Session Tracking in RADIUS", Avi Lior, Glen Zorn, 19-Oct-06, This document defines a set of new messages and attributes designed to allow RADIUS servers to cleanly track user sessions. "Nested Nemo Tree Discovery", Pascal Thubert, 20-Nov-06, The purpose of this paper is to describe a minimum set of features that extends the Nemo basic support [4] in order to avoid loops in the nested Nemo case. As a result, Mobile Routers assemble into a tree that can be optimized based on various metrics. "Licklider Transmission Protocol - Specification", Scott Burleigh, 6-Sep-06, This document describes the Licklider Transmission Protocol (LTP) designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long- haul" reliable transmission in interplanetary space, but has applications in other environments as well. In an Interplanetary Internet setting deploying the Bundling protocol being developed by the Delay Tolerant Networking Research Group, LTP is intended to serve as a reliable convergence layer over single hop deep-space RF links. LTP does ARQ of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful, and has no negotiation or handshakes. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. "Internet Mail Architecture", David Crocker, 8-Mar-07, Over its thirty-five year history Internet Mail has undergone significant changes in scale and complexity, as it has become a global infrastructure service. The first standardized architecture for networked email specified little more than a simple split between the user world and the transmission world. Core aspects of the service, such as the styles of mailbox address and basic message format, have remained remarkably constant. However today's Internet Mail is marked by many independent operators, many different components for providing users service and many others for performing message transfer. Public discussion of the architecture has not kept pace with the real-world technical and operational refinements. This document offers an enhanced Internet Mail architecture that targets description of the existing service. "Additional authorization identity syntax for Kerberos-aware Directories", Alexey Melnikov, 21-Nov-06, This document defines new LDAP authorization identity syntax for Kerberos-aware Directories. "Domain-based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)", Mark Delany, 26-Jul-06, "DomainKeys" creates a domain-level authentication framework for email by using public key technology and the DNS to prove the provenance and contents of an email. This document defines a framework for digitally signing email on a per-domain basis. The ultimate goal of this framework is to unequivocally prove and protect identity while retaining the semantics of Internet email as it is known today. Proof and protection of email identity may assist in the global control of "spam" and "phishing". "DISCOVER: Supporting Multicast DNS Queries", Bill Manning, Paul Vixie, 17-Nov-05, This document describes the DISCOVER opcode, an experimental extension to the Domain Name System (DNS) to use multicast queries for resource discovery. A client multicasts a DNS query using the DISCOVER opcode and processes the multiple responses that may result. "Dialstring parameter for the Session Initiation Protocol Uniform Resource Identifier", Brian Rosen, 2-Mar-07, RFC3966 explicitly states that 'tel' URIs may not represent a dial string. That leaves no way specify a dial string in a standardized way. Great confusion exists with the SIP URI parameter "user=phone", and specifically, if it can represent a dial string. This memo creates a new value for the user parameter "dialstring", so that one may specify "user=dialstring" to encode a dial string as a 'sip:' or 'sips:' URI. "RADIUS Attributes for the Delivery of Keying Material", Glen Zorn, 27-Dec-06, This document defines a set of RADIUS Attributes designed to allow both the secure transmission of cryptographic keying material and strong authentication of any RADIUS message. "Extending the Space Available for TCP Options", Wesley Eddy, 9-May-05, This document describes a method for increasing the space available for TCP options. Two new TCP options (LO and SLO) are detailed which reduce the limitations imposed by the TCP header's Data Offset field. The LO option provides this extension after connection establishment, and the SLO option aids in transmission of lengthy connection initialization and configuration options. "TLS Express", Mohamad Badra, 16-Feb-05, This document defines a new extension that may be used to add Pre Shared Key authentication functionality to TLS. It is based on the TLS abbreviated handshake and it provides the ability to share a session key for data encryption. "IPv6 Label Switching Architecture", Sham Chakravorty, 12-Oct-06, This specification provides an architectural framework, called IPv6 Label Switching Architecture or 6LSA, for an end-to-end, IP-centric packet transmission technique that uses the IPv6 packet header Flow Label to establish IPv6-based label switched paths. The label switched paths, called 6LSPs, provide application and user specified routes for efficient transport of packets and as means for quality of service (QoS) or other service delivery. Through look-ups of 20-bit labels instead of 128-bit IPv6 addresses, the architecture provides potential memory and processing savings, the latter through significantly reduced address fetches for the low-powered, handheld devices. Although the label from the source is delivered to the destination unmodified as required for conformance to the basic tenet of the existing defintion of the 3-tuple flow, the intermediate network nodes in 6LSA are allowed to temporarily replace the original label with a label of local significance. This enables 6LSA flows to be hop-specific although session-based and as such a unique QoS delivery technique for bandwidth constrained media. 6LSA also enhances security since label generation and assignment algorithms can be modified periodically. "Mobile IPv6 - NSIS Interaction for Firewall traversal", Hannes Tschofenig, 2-Mar-07, Most of the firewalls deployed today are Mobile IPv6 unaware. Widespread Mobile IPv6 deployment is not possible unless Mobile IPv6 messages can pass through these firewalls. One approach is to use a signaling protocol to communicate with these firewalls and instruct them to bypass these Mobile IPv6 messages. The goal of this document is to describe the interaction between NSIS and Mobile IPv6 for enabling Mobile IPv6 traversal. "Payment for Services in Session Initiation Protocol (SIP)", Cullen Jennings, 25-Oct-06, Service usage might require some form of compensation and this is also true for many communication systems where an entity receiving a call should be able to charge the caller. This is necessary for allowing fair communication between two communicating parties and is a major strategy for reducing the viability of SPAM. This draft proposes an approach for doing this in SIP using the Security Assertion Markup Language (SAML). It relies on a third party to act as a payment provider and is designed for low value transactions. It does not aim to provide the same capability as other authentication, authorization and accounting backend infrastructures. "SDP Descriptors for FLUTE", Harsh Mehta, 30-Jan-06, This document specifies the use of SDP to describe the parameters required to begin, join, receive data from, and/or end FLUTE sessions. It also provides a Composite Session SDP media grouping semantic for grouping media streams into protocol-specific sessions, such as multiple-channel FLUTE sessions. "Document Shepherding from Working Group Last Call to Publication", Henrik Levkowetz, 1-Feb-07, This document describes methodologies that have been designed to improve and facilitate IETF document flow processing. It specifies a set of procedures under which a working group chair or secretary serves as the primary Document Shepherd for a document that has been submitted to the IESG for publication. Before this, the Area Director responsible for the working group has traditionally filled the shepherding role. "GMPLS Inter-domain Traffic Engineering Requirements", Tomohiro Otani, 26-Feb-07, This draft provides requirements for the support of generalized multi-protocol label switching (GMPLS) inter-domain traffic engineering (TE). Its main objective is to present the differences between MPLS inter-domain TE and GMPLS inter-domain TE. This draft covers not only GMPLS Inter-domain architecture but also functional requirements in terms of GMPLS signaling and routing in order to specify these in a GMPLS Inter-domain environment. "Scope Modifiers in Intellectual Property Declarations", I Maturana, I Robredo, 16-Aug-05, The purpose of this RFC is to focus discussion on intellectual property problems in the Internet. This document introduces and defines scope modifiers to be used in intellectual property declarations. These modifiers abstract the ownership behavior of resources available in interoperable environnments, such as the Internet. "A Schema and Guidelines for Defining Session Initiation Protocol User Agent Profile Datasets", Daniel Petrie, 25-Oct-06, This document defines the requirements and a format for SIP user agent profile data. An overall schema is specified for the definition of profile datasets. The schema also provides for expressing constraints for how multiple sources of profile data are to be combined. This document provides a guide to considerations, policies and syntax for defining datasets to be included in profile data. It also explores some specific datasets to test the requirements, assumptions and syntax. "RADIUS NAS-Management Authorization", Greg Weber, David Nelson, 6-Mar-07, This document describes Remote Aauthentication Dial-In User Service (RADIUS) attributes for the authorization and service provisioning of local and remote management of embedded systems and other managed entities, generally referred to as Network Access Servers (NASes). Specific provisions are made for remote management via framed management protocols, and for more granular levels of access rights and management privileges. "Using XML Schema to define Netconf Content", Sandeep Admankar, Sharon Chisholm, 8-Feb-07, This memo defines a framework for defining content for Netconf using XML Schema. It defines requirements to enable interoperability, extensibility, easy parsing, usability and predictable modelling. "Guidelines for Writing an IANA Considerations Section in RFCs", Thomas Narten, Harald Alvestrand, 9-Mar-07, Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations in different implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA). In order for IANA to manage a given name space prudently, it needs guidelines describing the conditions under which new values can be assigned, or when modifications to existing values can be made. If IANA is expected to play a role in the management of a name space, the IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a name space and provides guidelines to document authors on the specific text that must be included in documents that place demands on IANA. "IPvLX - IP with virtual Link eXtension", Fred Templin, 22-Oct-06, The IPv6 128-bit addressing architecture was designed as a successor for IPv4. But, IPv4 deployment in the global Internet continues via private addressing domains behind Network Address Translators (NATs) such that long-term coexistence with IPv6 addressing and minimal perturbation of IPv4 networks is emerging as the dominant strategy. This document proposes a long-term IPv6/IPv4 coexistence scheme called: IPvLX - IP with virtual Link Extension. "Internet Security Glossary, Version 2", Rob Shirey, 15-Nov-06, This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 305 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. "Guidelines for an Arabic Domain Name System (ADNS)", Mansour Farah, 20-Dec-06, There have been several attempts aimed at developing an Arabic Domain Name System (ADNS) using Arabic characters in an Arabic-language coherent fashion. In the beginning of the second quarter of 2003, an Arabic Domain Name Task Force (ADNTF) was formed under the auspices of United Nations Economic and Social Commission for Western Asia (ESCWA), and the guidance of Multilingual Internet Names Consortium (MINC); one of its main objectives was to help define standards for ADNS through a Request For Comments (RFC) document. This document resolves many technical and linguistic issues, including the adoption of the client-side DNS-based approach to name resolution; syntax of the proposed Arabic Domain Names together with the character set and many Arabic language-specific issues were clearly resolved. This Internet-Draft proposes guidelines that are compatible with the Internet Consortium for Assigned Names and Numbers (ICANN) and the Internet Engineering Task Force (IETF) as far as Domain Names System (DNS) and Internationalized Domain Names (IDN) standards are concerned. Technical, management, operational, and language-specific issues are discussed and recommendations are made. "RIPv2 Cryptographic Authentication", M Fanto, Randall Atkinson, 17-Oct-06, This note describes a revision to the RIPv2 Cryptographic Authentication mechanism originally specified in RFC-2082. This document obsoletes RFC-2082. This document updates RFC-2453. This document adds details of how the SHA family of hash algorithms can be used with RIPv2 Cryptographic Authentication, whereas the original document only specified the use of Keyed-MD5. Also, this document clarifies a potential issue with an active attack on this mechanism and adds significant text to the Security Considerations section. "Marketing Buzzword "SIPPING 16" Considered Harmful", Rohan Mahy, 7-Mar-07, The Session Initiation Protocol (SIP) has become very popular, and with this popularity, the harmful misconceptions that there is a specific limit to the number of features that can be implemented using SIP primitives, and that informational documents produced by the SIPPING Working Group that show example call flows place restrictions on what can be implemented. One especially catchy buzzword--The "SIPPING 16"--supposedly refers to the sixteen basic features of SIP. This document describes why the mythical SIPPING 16 does not exist, and where to find out more information about SIP features. "Message Header for Indicating Sender Authentication Status", Murray Kucherawy, 26-Feb-07, This memo defines a new message header for use with electronic mail messages to indicate the results of sender authentication efforts to mail user agents (MUAs) in order to equip them to relay that information in a convenient way to users or to make sorting and filtering decisions. "Global HA to HA protocol", Pascal Thubert, 29-Sep-06, This HAHA protocol extends MIPv6 [15] and NEMO [16] to remove their link layer dependencies on the Home Link and distribute the HAs at IP layer. Global HAHA considers the distribution at the scale of the Internet, and introduces the MIP proxy for Local Mobility Management and Route Optimization in the Infrastructure. "Quality of Service for Ad hoc Optimized Link State Routing Protocol (QOLSR)", Hakim Badis, 5-Oct-06, The Optimized Link State Routing (OLSR) protocol for mobile ad hoc networks provides shortest routes in terms of number of hops using Dijkstra's shortest path algorithm. In order to support multiple- metric routing criteria, a quality of service (QoS) extension can be added to OLSR functioning. No additional control traffic is generated (only augmented HELLO and TC messages). QOLSR protocol uses standard multipoint relays (MPRs) to ensure that the overhead is as low as possible for forwarding control traffic. Local QoS metrics information on links are used to calculate quality of service MPRs (QMPRS) and then flooded in the network by TC messages to calculate routing tables. QOLSR can find optimal paths on the known partial topology having the same performances that those on the whole network. These paths contain only QMPRs as intermediate nodes between a source destination pair. This memo describes the QOLSR protocol, which is an enhancement of OLSR to support multiple-metric QoS routing. "Application Master Session Key (AMSK) for Mobile IPv6", Gerardo Giaretta, 22-Oct-06, The Extensible Authentication Protocol (EAP) defines an extensible framework for performing network access authentication. Most EAP authentication algorithms, also known as "methods", export keying material that can be used with lower layer ciphersuites. It can be useful to leverage this keying material to derive usage specific keys that can be used to authenticate users or protect information exchange by other applications or services.For this purpose [10] proposes to derive root keys for each usage application and, then, child keys to actual be used. This document defines how to generate a Usage Specific Root Key (USRK) and a series of Application Master Session Keys (AMSKs) specific to Mobile IPv6 service. These AMSKs can be used by Mobile Node and Home Agent to bootstrap Mobile IPv6 protocol operation. This document defines how to generate Application Master Session Keys (AMSKs) specific to Mobile IPv6. These AMSKs can be used by Mobile Node and Home Agent to bootstrap Mobile IPv6 protocol operation. "The IMG Envelope", Rod Walsh, 2-Feb-07, This document defines the metadata transfer envelope for Internet Media Guides (IMGs). IMG metadata describes files, resources and multimedia programs available for streaming or downloading via multicast or unicast. IMG metadata is encapsulated into, or associated with, an IMG envelope before actual transport. The IMG envelope is a structure providing independence between IMG transport protocols and different metadata formats. This specification provides the IMG envelope instantiation using structured Extensible Markup Language (XML) syntax, both as a wrapper in which to embed an IMG metadata object and as a distinct object to associate with a distinct IMG metadata object. "HIP Experiment Report", Tom Henderson, Andrei Gurtov, 8-Mar-07, This document is a report from the IRTF HIP research group documenting the collective experiences and lessons learned from studies, related experimentation, and designs completed by the research group. "IMAP extension for referencing the last SEARCH result", Alexey Melnikov, 16-Feb-07, Many IMAP clients use the result of a SEARCH command as the input to perform another operation, for example fetching the found messages, deleting them or copying them to another mailbox. This can be achieved using standard IMAP operations described in RFC 3501, however this would be suboptimal: the server will send the list of found messages to the client, after that the client will have to parse the list, reformat it and send it back to the server. The client can't pipeline the SEARCH command with the subsequent command. This document proposes an IMAP extension that allows a client to tell a server to use the result of the latest SEARCH (or UID SEARCH) command as an input to any subsequent command. "NSLP for Metering Configuration Signaling", Falko Dressler, 8-Mar-07, Monitoring, metering and accounting of packets are increasingly important functionality that needs to be provided in the Internet. This document proposes the definition of a new NSIS Signaling Layer Protocol (NSLP), named Metering NSLP (M-NSLP), which allows the dynamic configuration of Metering Entities on the data path. An accompanying document [I-D.fessi-nsis-m-nslp-framework] provides a problem statement, describes scenarios where such a path-coupled configuration of Metering Entities is useful, elaborates requirements for a path-coupled protocol for the configuration of Metering Entities and discusses the applicability of NSIS for this purpose. This document defines a Metering NSLP protocol design and messages, and describes the protocol operation. "A Framework for Loop-free Convergence", Stewart Bryant, Mike Shand, 20-Oct-06, This draft describes mechanisms that may be used to prevent or to suppress the formation of micro-loops when an IP or MPLS network undergoes topology change due to failure, repair or management action. "Traversing HIP-aware NATs and Firewalls: Problem Statement and Requirements", Hannes Tschofenig, Murugaraj Shanmugam, 25-Oct-06, The Host Identity Protocol (HIP) is a signaling protocol, which supports mobility and multihoming by adding a new layer in the TCP/IP stack. By carring relevant parameters in the signaling messages, HIP can be used to establish IPsec encapsulating security payload (ESP) security associations between two hosts. Middleboxes (e.g. firewalls and network address translators) cannot inspect transport layer headers of data traffic if that traffic is sent over an IPsec ESP tunnel. However, HIP is designed to be middlebox friendly; it enables the middleboxes to inspect the signaling messages. The information that they can derive from that messages enables the middleboxes to uniquely identify the subsequent data flows, e.g. for the purposes of multiplexing and demultiplexing . A middlebox that implements the relevant mechanisms is called "HIP-aware". This document presents a problem statement and lists some requirements that are necessary for a HIP-aware middlebox traversal technique. These include authentication and authorization of signaling end-hosts by the middleboxes. Such authorization will help the middleboxes to decide whether or not an end host is allowed to traverse, and can potentially limit unwanted traffic. "NEMO Route Optimisation Problem Statement", Thomas Clausen, 8-Mar-07, The NEMO basic support specification is not limited to a single level of mobile networks attaching to the stationary Internet. Rather, arbitrary levels of nested mobile networks are supported, employing for each level of nesting the same attachment, encapsulation and tunnelling mechanisms. With arbitrarily deep nested mobile networks, paths taken by data traffic can be extremely sub-optimal both inside the nested topology through successive mobile routers, and outside the nested topology, through successive Home Agents over the Internet. Moreover, the overhead incurred through tunnelling and encapsulation of data traffic can become prohibitively large. This document analyses the scenarios in which these problems are particularly acute. "Specification for the Explicit Control Protocol (XCP)", Aaron Falk, 8-Nov-06, This document contains an initial specification for the Explicit Control Protocol (XCP), an experimental congestion control protocol. XCP is designed to deliver the highest possible end-to-end throughput over a broad range of network infrastructure, including links with very large bandwidth-delay products, which are not well served by the current control algorithms. XCP is potentially applicable to any transport protocol, although initial testing has applied it to TCP in particular. XCP routers are required to perform a small calculation on congestion state carried in each data packet. XCP routers also periodically recalculate the local parameters required to provide fairness. On the other hand, there is no per-flow congestion state in XCP routers. This version specification (-02) includes protocol changes that move per-packet divisions from the router to the sender. "Interaction between SIP and HIP", Hannes Tschofenig, 25-Oct-06, This document investigates the interworking between the Session Initiation Protocol (SIP) and the Host Identity Protocol (HIP) and the benefits that may arise from their combined operation. The aspect of exchanging Host Identities (or Host Identity Tags) in SIP/SDP for later usage with the Host Identity Protocol Protocol (HIP) is described in more detail as an example of this interworking. "Things to think about when Renumbering an IPv6 network", Tim Chown, 20-Sep-06, This memo presents a summary of scenarios, issues for consideration and protocol features for IPv6 network renumbering, i.e. achieving the transition from the use of an existing network prefix to a new prefix in an IPv6 network. Its focus lies not in the procedure for renumbering, but as a set of "things to think about" when undertaking such a renumbering exercise. "Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)", Dimitri Papadimitriou, 26-Oct-06, There are requirements for the support of networks ccomprising LSRs with different data plane switching layers controlled by a single Generalized Multi Protocol Label Switching (GMPLS) control plane instance, referred to as GMPLS Multi-Layer Networks/Multi-Region Networks (MLN/MRN). This document defines extensions to GMPLS routing and signaling protocols so as to support the operation of GMPLS Multi-Layer/Multi-Region Networks. "QoS NSLP State Machine", Xiaoming Fu, 27-Dec-06, This document describes a state machine for the NSIS Signaling Layer Protocol for Quality-of-Service signaling (QoS NSLP). A combined state machine for QoS NSLP entities at different locations of a flow path is presented in order to illustrate how QoS NSLP may be implemented. "Using Kerberos V5 over the Transport Layer Security (TLS) protocol", Simon Josefsson, 22-Oct-06, This document specify how the Kerberos V5 protocol can be transported over the Transport Layer Security (TLS) protocol, to provide additional security features. "Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures", Loa Andersson, Adrian Farrel, 2-Mar-07, This document provides guidelines for applying or extending the MPLS or GMPLS ((G)MPLS) protocol suites and clarifies the IETF's (G)MPLS working groups' responsibility for the (G)MPLS protocols. This document is directed to multi-vendor fora and Standards Development Organizations (SDOs) to provide an understanding of (G)MPLS work in the IETF and documents the requisite use of IETF review procedures when considering (G)MPLS applications or protocol extensions in their work. This document does not modify IETF processes. "Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs", Joseph Touch, 14-Feb-07, This document describes the properties and use of a revised Microsoft Word template (.dot) for writing Internet Drafts and RFCs. It updates the initial template described in RFC 3285 to more fully support Word's outline modes and to be easier to use. This template can be direct-printed and direct-viewed, where either is line-for-line identical with RFC Editor-compliant ASCII output. This version is intended as an update to RFC3285. The most recent version of this template and post-processing scripts are available at http://www.isi.edu/touch/tools "NAT/FW NSLP State Machine", Constantin Werner, 7-Mar-07, This document describes the state machines for the NSIS Signaling Layer Protocol for Network Address Translation/Firewall signaling (NAT/FW NSLP). A set of state machines for NAT/FW NSLP entities at different locations of a signaling path are presented in order to illustrate how NAT/FW NSLP may be implemented. "Licklider Transmission Protocol - Motivation", Scott Burleigh, 6-Sep-06, This document describes the Licklider Transmission Protocol (LTP) designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long- haul" reliable transmission in interplanetary space, but has applications in other environments as well. In an Interplanetary Internet setting deploying the Bundling protocol being developed by the Delay Tolerant Networking Research Group, LTP is intended to serve as a reliable convergence layer over single hop deep-space RF links. LTP does ARQ of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful and has no negotiation or handshakes. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. "Licklider Transmission Protocol - Extensions", Stephen Farrell, 6-Sep-06, In an Interplanetary Internet setting deploying the Bundling protocol being developed by the Delay Tolerant Networking Research Group, the Licklider Transmission Protocol (LTP), is intended to serve as a reliable convergence layer over single hop deep-space RF links. LTP does ARQ of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful and has no negotiation or handshakes. LTP is designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long- haul" reliable transmission in interplanetary space, but has applications in other environments as well. This document describes extensions to LTP, and is part of a series of related documents describing LTP. Other documents in this series cover the motivation for LTP and the main protocol specification. We recommend reading all the documents in the series before writing code based on this document. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. "Care-of Address Test for MIPv6 using a State Cookie", Francis Dupont, Jean-Michel Combes, 23-Jan-07, This document defines a procedure which performs a "care-of address test" using a state cookie for routing optimization in Mobile IPv6 not protected by the routing routability procedure, i.e., protected by some alternative mechanisms like pre-shared secret or pre- established IPsec security associations. "TLS Sign", Mohamad Badra, Ibrahim Hajjeh, 10-Nov-06, TLS protocol provides authentication and data protection for communication between two entities. However, missing from the protocol is a way to perform non-repudiation service. This document defines extensions to the TLS protocol to allow it to perform non-repudiation service. It is based on [TLSSign] and it provides the client and the server the ability to sign by TLS, handshake and applications data using certificates such as X.509. "A URN namespace for the Open Geospatial Consortium (OGC)", Carl Reed, 21-Feb-07, This document describes a URN (Uniform Resource Name) namespace that is engineered by the Open Geospatial Consortium (OGC) for naming persistent resources published by the OGC. The formal Namespace identifier (NID) is "ogc". "Certificate Exchange Messaging for EDIINT", Kyle Meadors, Dale Moberg, 5-Mar-07, The EDIINT AS1, AS2 and AS3 message formats do not currently contain any neutral provisions for transporting and exchanging trading partner profiles or digital certificates. EDIINT Certificate Exchange Messaging provides the format and means to effectively exchange certificates for use within trading partner relationships. The messaging consists of two types of messages, Request and Response, which allow trading partners to communicate certificates, their intended usage and their acceptance through XML. Certificates can be specified for use in digital signatures, data encryption or SSL/TLS over HTTP (HTTPS). "RTCP XR VoIP Metrics Package for the Media Gateway Control Protocol", David Auerbach, 6-Oct-06, The main intent of this document is to define a Media Gateway Control Protocol (MGCP) package to control the reporting of metrics supported by the VoIP metrics block in RTCP Extended Reports as specified in [RFC 3611]. It also allows the call agent to control whether or not the gateway will request a peer device via SDP to send the VoIP metrics block in RTCP Extended Reports and whether it will respond positively to such requests from the peer device. Besides this primary focus, this MGCP RTCP-XR Package 4/11/2006 package also allows the reporting of metrics defined for RTCP Sender Reports and Receiver Reports [RFC 3550] and the reporting of session description parameters (based on the ones defined in RFC 2327, RFC 2198 etc.). "HTTP Enabled Location Delivery (HELD)", James Winterbottom, 2-Mar-07, A Geopriv using protocol is described that is used for retrieving location information from a server within an access network. The protocol includes options for retrieving location information either by-value or by-reference. The protocol supports mobile and nomadic devices through Location URIs. The protocol is an application-layer protocol that is independent of session-layer; an HTTP, web services binding is specified. "Circuit Cross-Connect", Kireeti Kompella, 9-Feb-06, Circuit Cross-Connect (CCC) was the ground-breaking design and implementation of the transport of Layer 2 frames over Multi-Protocol Label Switching (MPLS), which is now seen as an important application of MPLS. Thus, documenting CCC is important from a historical point of view. Furthermore, CCC is still in production in many networks, providing yet another reason to document it. It is hoped that those interested in this area will see where it started, how far we have come, and the strengths and weaknesses of this particular approach, and thereby gain some perspective of the area. If in the process they get new insights for the future development in this area, that is a bonus. "Encoding Instructions for the Robust XML Encoding Rules (RXER)", Steven Legg, 22-Dec-06, This document defines encoding instructions that may be used in an Abstract Syntax Notation One (ASN.1) specification to alter how ASN.1 values are encoded by the Robust XML Encoding Rules (RXER) and Canonical Robust XML Encoding Rules (CRXER), for example, to encode a component of an ASN.1 value as an Extensible Markup Language (XML) attribute rather than as a child element. Some of these encoding instructions also affect how an ASN.1 specification is translated into an Abstract Syntax Notation X (ASN.X) specification. Encoding instructions that allow an ASN.1 specification to reference definitions in other XML schema languages are also defined. "Session Initiation Protocol (SIP) over Datagram Transport Layer Security (DTLS)", Cullen Jennings, Nagendra Modadugu, 27-Feb-07, This specification defines how to use Datagram Transport Layer Security (DTLS) as a transport for Session Initiation Protocol (SIP). DTLS is a protocol for providing Transport Layer Security (TLS) security over a datagram protocol. This specification also specifies the IANA registrations for using SIP with Datagram Congestion Control Protocol (DCCP). "Considering Generalized Multiprotocol Label Switching Traffic Engineering Attributes During Path Computation", Tomohiro Otani, 2-Mar-07, This document provides guidelines for the consideration of Generalized Multiprotocol Label Switching (GMPLS) Traffic- Engineering (TE) attributes for computation of routes for Label Switched Paths (LSPs) in a GMPLS network. This document summarizes how GMPLS TE attributes on ingress links, transit links, and egress links may be treated as path computation constraints to determine the route of a GMPLS Label Switched Path. "A Framework of Media-Independent Pre-Authentication (MPA)", Yoshihiro Ohba, 8-Mar-07, This document describes a framework of Media-independent Pre- Authentication (MPA), a new handover optimization mechanism that addresses the issues on existing mobility management protocols and mobility optimization mechanisms. MPA is a mobile-assisted, secure handover optimization scheme that works over any link-layer and with any mobility management protocol. MPA's pre-authentication, pre- configuration, and proactive handover techniques allow many of the handoff related operations to take place before the mobile has moved to the new network. We describe the details of all the associated techniques and its applicability for different scenarios. "Transmitting Confidential Data in RADIUS", Glen Zorn, 19-Oct-06, This document defines a pair of RADIUS Attributes designed to allow the secure transmission of sensitive or confidential data between RADIUS clients and servers. "Mobility Header Signaling Message", Sri Gundavelli, Brian Haley, 2-Mar-07, This document specifies a new Mobility Header message type that can be used between a mobile node and home agent to signal an event that requires attention. "NAT Classification Test Results", Cullen Jennings, 23-Oct-06, IETF has several working groups that are considering the impact of NATs on various protocols. Having a classification of the types of NATs that are being developed and deployed is useful in gauging the impact of various solutions. This draft records the results of classifying NATs. This draft is not complete and has only a few test results but it is worth discussing all the testing we wish to do before all the test results are collected. The test results here are very old and work is being done to update them with more current information. "Split-View DNSSEC Operational Practices", Suresh Krishnaswamy, 6-Mar-07, The security extensions to the Domain Name System (DNSSEC) allow for integrity protection, whereby it is possible to make a determination of the verity of data returned from the Domain Name System in response to a query. Current operation of the Domain Name System also allows for the creation of multiple views of data, where the answer returned in response to a query is dependent on the origin of the query. Data integrity and the ability to return possibly conflicting values as in split-views may be construed to be mutually conflicting goals; but this apparent dichotomy is resolvable in practice through careful configuration. This document provides recommendations for configuring a manageable split-view DNSSEC environment in a representative enterprise network. "The LDAP Don't Use Copy Control", Kurt Zeilenga, 14-Feb-07, This document defines the Lightweight Directory Access Protocol (LDAP) Don't Use Copy control extension which allows a client to specify that copied information should not be used in providing service. This control is based upon the X.511 dontUseCopy service control option. "The XML Enabled Directory: Matching Rules", Steven Legg, Daniel Prager, 16-Nov-06, The XML (Extensible Markup Language) Enabled Directory (XED) allows the definition of directory attributes whose syntaxes are defined in terms of XML Schema types, RELAX NG patterns or XML document type definition (DTD) element type declarations. This document enables the matching of directory attribute values of such syntaxes by extending existing Lightweight Directory Access Protocol (LDAP) and X.500 directory matching rules. "Session Initiation Protocol (SIP) Session Mobility", Ron Shacham, 14-Nov-06, Session Mobility is the seamless transfer of media of an ongoing communication session from one device to another. This document describes the general methods and specifies the flows for providing this service as part of the Session Initiation Protocol (SIP). The basic steps involved in session mobility which are describe are service discovery to locate devices to use as transfer targets, for which the Service Location Protocol (SLP) is used, session transfer, and, sometimes, reconciliation of device capability differences. The described session mobility methods include the possibility of transferring any subset of the active media to one or more devices. "Application Design Guidelines for Traversal through Network Address Translators", Bryan Ford, 7-Mar-07, This document defines guidelines by which application designers can create applications that communicate reliably and efficiently in the presence of Network Address Translators (NATs), particularly when the application has a need for "peer-to-peer" (P2P) type of communication. The guidelines allow a P2P application to work reliably across a majority of existing NATs, as well as all future NATs that conform to the behave requirements specified in companion documents. The NAT traversal techniques described in the document do not require the use of special proxy or relay protocols, do not require specific knowledge about the network topology or the number and type of NATs in the path, and do not require any modifications to IP or transport-layer protocols on the end hosts. "Framework for Metering NSLP", Ali Fessi, 8-Mar-07, Monitoring, metering and accounting of packets are increasingly important functionalities that need to be provided in the Internet. This document motivates and describes a framework for the path- coupled configuration of Metering Entities to record monitoring and measurement data and report it to a data collector. Different scenarios are described where such a path-coupled configuration is useful. Currently, the focus is on two scenarios: accounting and QoS measurement. Moreover, this document gathers requirements for a path-coupled configuration protocol of Metering Entities. Finally, the applicability of the NSIS architecture for this purpose is discussed. The protocol itself is specified in a separate document [I-D.dressler-nsis-metering-nslp] "The 'mailto' URI Scheme", Martin Duerst, 25-Oct-06, This document defines the format of Uniform Resource Identifiers (URI) to identify resources that are reached using Internet mail. It updates the syntax of 'mailto' URIs from [RFC2368] for better compatibility with IRIs ([RFC3987]). "SDP and RTSP extensions defined for 3GPP Packet-switched Streaming Service and Multimedia Broadcast/Multicast Service", Per Frojdh, Magnus Westerlund, 23-Oct-06, The Packet-switched Streaming Service (PSS) and the Multimedia Broadcast/Multicast Service (MBMS) defined by 3GPP use SDP and RTSP with some extensions. This document provides information about these extensions and registers the RTSP and SDP extensions with IANA. "Complications from Network Address Translator Deployment Topologies", Bryan Ford, Pyda Srisuresh, 26-Oct-06, This document identifies two deployment scenarios that have arisen from the unconventional network topologies formed using Network Address Translator devices (NATs). First, the simplicity of administering networks through the combination of NAT and DHCP has increasingly lead to the deployment of multi-level inter-connected private networks involving overlapping IP address spaces. Second, the proliferation of private networks in enterprises, hotels and conferences, and the wide spread use of Virtual Private Networks (VPNs) to access enterprise intranet from remote locations has increasingly lead to overlapping IP address space between remote and corporate networks. The document does not dismiss these unconventional scenarios as invalid, but recognizes them as real and offers recommendations to ensure these real scenarios can funtion. "PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE", Shinta Sugimoto, 24-Sep-06, This document describes the need for an interface between Mobile IPv6 and IPsec/IKE and show how the two protocols can interwork. We propose a set of extensions to the PF_KEY framework which allows smooth and solid operation of IKE in a Mobile IPv6 environment. The first extension is called PF_KEY MIGRATE and is for migrating the endpoint addresses of a IPsec Security Association pair in tunnel mode. The second extension is named SADB_X_EXT_PACKET and allows IKE to make the right choice for address selection in bootstrapping process. Both extensions are helpful for assuring smooth interworking between Mobile IPv6 and IPsec/IKE and achieving performance optimization. "Requirements from SIP (Session Initiation Protocol) Session Border Control Deployments", Gonzalo Camarillo, 26-Oct-06, This documents describes functions implemented in Session Initiation Protocol (SIP) intermediaries known as Session Border Controllers (SBCs). Although the goal of this document is to describe all the functions of SBCs, a special focus is given to those practices that are viewed to be in conflict with SIP architectural principles. It also explores the underlying requirements of network operators that have led to the use of these functions and practices in order to identify protocol requirements and determine whether those requirements are satisfied by existing specifications or additional standards work is required. "A Scheme of Mobile Firewall in Mobile IPv6", Ying Qiu, 6-Sep-06, More and more activities rely on mobile devices. It is an important issue on how to protect mobile users engaged in mobile services. Unfortunately, the conventional firewalls are inappropriate for mobile networks. Furthermore, with a conventional firewall, an administrator of mobile nodes is unable to monitor / control dynamically the mobile nodes' activities when the mobile nodes roam. In this draft, we introduce a new concept of mobile personal firewall and propose a concrete scheme that matches the mobile environment and exploits the mobile network facilities. When a mobile node (MN) roams into a foreign network managed by a mobility anchor point (MAP), the home agent (HA) will authorize the MAP to serve as a security proxy. The HA will negotiate with the MAP on the security association and then transfer to the MAP the defined security rules that will be applied on all communications to the MN. According to HMIPv6 protocol, all packets to MN will go through MAP. Therefore, the MAP has the ability of filtering packets. The MAP could also send the MN's traffic logs to the HA. The MN's administrator could dynamically monitor the MN's activities by retrieving the MN's traffic logs through the HA. If necessary, the MN's administrator could update the security rules so that the MN's activities could be controlled dynamically. All the operations are transparent to the MN, and the MN will be served in a way specified by its administrator no matter where it roams. "Requirements for Firewall Configuration Protocol", Gabor Bajko, 5-Mar-07, 3GPP2 is working in specifying a way to allow the mobile network subscribers to configure the Firewalls in their network according to their needs[3]. This document defines requirements for a Firewall Configuration Protocol. It has been produced by a number of 3GPP2 member companies and endorsed by 3GPP2. It contains 3GPP2 requirements to a next generation Firewall Configuration Protocol. With the number of threats that keep increasing on the Internet, many networks have decided to deploy Firewalls to reduce the possible risks and protect their users as well as their network resources. Firewalls can however present many issues with new protocols, applications and scenarios to be supported. Data packets may be discarded at the Firewalls. In addition, the clients may often be the only parties that know the requirements and details of the data communications. This document therefore explains why a protocol allowing clients to configure Firewalls would be useful, and attempts to identify the requirements and features to be supported by such a protocol. "P3P Policy Attributes for LDAP", Mark Wahl, 12-Dec-06, This document defines attributes for use in the Lightweight Directory Access Protocol (LDAP) which contain URIs for privacy policy documents. These documents describe the privacy policy concerning access to a directory server, and the privacy policies that apply to the contents of the directory (a subtree of entries). "IP Fast Reroute Using Not-via Addresses", Stewart Bryant, 26-Oct-06, This draft describes a mechanism that provides fast reroute in an IP network through encapsulation to "not-via" addresses. A single level of encapsulation is used. The mechanism protects unicast, multicast and LDP traffic against link, router and shared risk group failure, regardless of network topology and metrics. "A Uniform Resource Name Namespace For The EPCglobal Electronic Product Code (EPC) and Related Standards", Michael Mealling, 8-Mar-07, This document describes URN namespaces that will identify various objects within the EPCglobal system for identifying products within ecommerce and supply chain management applications. "Multiple Attachments for EDI-INT", Kyle Meadors, 27-Dec-06, The EDIINT AS1, AS2 and AS3 message were designed specifically for the transport of EDI documents. Since multiple interchanges could be placed within a single EDI document, there was not a need for sending multiple EDI documents in a single message. As adoption of EDI-INT grew, other uses developed aside from single EDI document transport. Some transactions required multiple attachments to be interpreted together and stored in a single message. This informational draft describes how multiple documents, including non-EDI payloads, can be attached and transmitted in a single EDI-INT transport message. The attachments are stored within the MIME Multipart/Related structure. A minimal list of content-types to be supported as attachments is provided. "Best Current Practices of XCAST (Explicit Multi-Unicast) by 2004", Chih-Chang Hsu, 22-Jul-05, In 2000, XCAST (Explicit Multi-Unicast) was first proposed as a protocol intended for small group multicasting. It combined three similar datagram simulcasting protocols that were submitted as earlier Internet Drafts by a number of different research groups. After that, researchers in those groups worked together to further develop, experiment and conduct standardization in IETF as well as in the open source community. This resulted in several implementations of protocol stacks, systems of multi-party video conference and group management, and mechanisms for harmonizing XCAST with ASM and SSM. In addition, an XCAST backbone for various experiments has been launched to operate inter-continentally. One of the main purposes of this document is to summarize the efforts undertaken by XCAST community as "best current practices" that would then be formally introduced to the IETF/IRTF community. In addition, we raise an issue concerning IANA resource allocation, which prevents us from widely expanding our experimental networks as well as distributing our software. Finally, we request IESG and other experts to check the validity of our proposed protocol and make any suggestions about how IANA can assign appropriate resources accordingly. "IANA Considerations for XCAST (Explicit Multi-Unicast)", Chih-Chang Hsu, 4-Apr-05, XCAST (Explicit Multi-Unicast) is an experimental protocol for small group multicasting. This protocol requires IANA allocations for a new type of multicast address, a routing type of IPv6 routing header, an option type of Destination Option header and an option header of IPv6 Hop-by-Hop Options header. This document contains guidelines to IANA about what allocations are required for XCAST protocol. "SCTP NAT Traversal Considerations", Qiaobing Xie, 26-Nov-06, This document defines and classifies scenarios for the usage of SCTP in networks with NATs and similar middleboxes. "Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the XML Encoding Rules (XER)", Steven Legg, 22-Dec-06, Abstract Syntax Notation X (ASN.X) is an Extensible Markup Language (XML) representation for Abstract Syntax Notation One (ASN.1) specifications. This document specifies the ASN.X representation of encoding instructions for the XML Encoding Rules (XER). "Link Characteristics Information for Mobile IP", Soohong Daniel Park, 30-Jan-07, This document introduces a model for link characteristic information delivery from the mobile node to the home agent and correspondent node(s). This model allows the home agent and correspondent node(s) to know the characteristics of the link the mobile node is currently attached to. Based on this information, the home agent and correspondent node(s) may shape ongoing traffic according to the current available link capacity (e.g. bandwidth) to the mobile node. This model can be applicable for Mobile IPv4 as well as Mobile IPv6. "Registration Templates for Legacy Message Header Field Names", Bruce Lilly, 21-Apr-05, This memo documents several Internet Message Format message header field names and provides registration templates so that the names can be registered in the permanent message header field name registry. "A Problem Statement for Partly-Decoupled Signalling in NSIS", Robert Hancock, 26-Oct-06, The NSIS working group is currently developing a protocol suite for signalling which manipulates network state related to data flows. The protocol design incorporates the constraint that the signalling protocol will be processed on the nodes which also handle the data flows themselves ("path-coupled signalling"). This document discusses a particular deployment mode for GIST (the common lower layer of the NSIS protocol suite) which relaxes this constraint, allowing the signalling and data paths to be partially decoupled, without sacrificing the integration with routing (e.g. sensitivity to route changes) which is intrinsically provided by the baseline path- coupled solution. "The 'news' and 'nntp' URI Schemes", Frank Ellermann, 20-Feb-07, This memo specifies the 'news' and 'nntp' Uniform Resource Identifier (URI) schemes that were originally defined in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about these schemes on standards track. "IMMP -- Internet Message Mapping Protocol", Sabarish Ramanathan, 24-May-05, The Internet Message Mapping Protocol (IMMP) is designed to support the provision of mail in a medium to large scale operation. It is intended to be used as a companion to the SMTP protocol and mail receiving protocols (POP, IMAP, web mail also), providing services which are outside the scope of mail access. The services that IMMP provides are mapping mails into appropriate subinbox (inside the inbox) when the messages are received through SMTP, Extended inbox management and Spam guard management. "Common Local Transmit and Receive Ports (Symmetric RTP)", Dan Wing, 28-Feb-07, This document describes common local transmit and receive ports, commonly called "symmetric RTP" and "symmetric RTCP", and explains the advantages of using common local transmit and receive ports. "Scheduling Extensions to CalDAV", Bernard Desruisseaux, 29-Jan-07, This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of exchanging and processing scheduling messages based on the iCalendar Transport- Independent Interoperability Protocol (iTIP). This document defines the "calendar-schedule" feature of CalDAV. "Bundle Security Protocol Specification", Susan Symington, 5-Oct-06, This document defines the bundle security protocol, which provides data integrity and confidentiality services. We also describe various bundle security considerations including policy options. "Distributing Default Address Selection Policy using DHCPv6", Tomohiro Fujisaki, 3-Jan-07, This document describes a new DHCPv6 option for distributing default address selection policy information defined in RFC3484 to a client. With this option, site administrators can distribute address selection policy to control the node's address selection behavior. "Applicability of Loop-free Convergence", Stewart Bryant, Mike Shand, 20-Oct-06, This draft describes the applicability of loop free convergence technologies to a number of network applications. "Guidance for AAA Key Management", Russ Housley, Bernard Aboba, 28-Feb-07, This document provides guidance to designers of AAA key management protocols. The guidance is also useful to designers of systems and solutions that include AAA key management protocols. Given the complexity and difficulty in designing secure, long-lasting key management algorithms and protocols by experts in the field, it is almost certainly inappropriate for IETF working groups without deep expertise in the area to be designing their own key management algorithms and protocols based on Authentication, Authorization and Accounting (AAA) protocols. The guidelines in this document apply to documents requesting publication as IETF RFCs. Further, these guidelines will be useful to other standards development organizations (SDOs) that specify AAA key management. "Centralized Conferencing (XCON) Using the Message Session Relay Protocol (MSRP)", Chris Boulton, Mary Barnes, 1-Mar-07, The document "A Framework and Data Model for Centralized Conferencing" defines a centralized conference as both signaling and protocol agnostic. The primary examples within this framework focus on audio and video as the media types for the session. This document defines the mechanisms, in the context of this centralized conferencing framework, when using the Message Session Relay Protocol (MSRP) for instant messaging sessions. "NAT Port Mapping Protocol (NAT-PMP)", Stuart Cheshire, 20-Oct-06, This document describes a protocol for automating the process of creating Network Address Translation (NAT) port mappings. Included in the protocol is a method for retrieving the public IP address of a NAT gateway, thus allowing a client to make this public IP address and port number known to peers that may wish to communicate with it. This protocol is implemented in current Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations. "Mobile IPv6 Multicast with Dynamic Multicast Agent", Hong-Ke Zhang, 29-Jan-07, This document addresses the problem of delivering IPv6 multicast traffic to MN (Mobile Node). An approach named Mobile IPv6 Multicast with Dynamic Multicast Agent is proposed which combines Movement Based Method [2] and Distance Based Method [3], Such a design allows MN to optimize multicast route, and meanwhile reduce the handoff frequency by selecting new multicast agent dynamically. In addition to weakening the triangle route problem and diminishing the influence of handoff to multicast, this approach provides global mobility in Internet without limitations on network topology. This draft is the same as the earlier version, it is just an update of it. "The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push-to-talk over Cellular", Andrew Allen, 5-Mar-07, This document describes a private Session Initiation Protocol(SIP) header (P-header) used by the Open Mobile Alliance (OMA), for Push- to-talk over Cellular (PoC) along with its applicability, which is limited to the OMA PoC application. The P-Answer-State header is used for indicating the answering mode of the handset which is particular to the PoC application. "H-TCP: TCP Congestion Control for High Bandwidth-Delay Product Paths", Doug Leith, Robert Shorten, 19-Dec-06, Our objective in this document is to renew discussion on how the TCP congestion control algorithm might best be modified to improve performance in high bandwidth-delay product paths. We focus on changes to the additive increase element of the TCP AIMD algorithm. "Feed Paging and Archiving", Mark Nottingham, 26-Nov-06, This specification defines three types of syndicated Web feeds that enable publication of entries across one or more feed documents. "QoS-Enhanced Border Gateway Protocol", Mohammed Boucadair, 5-Jul-05, This memo describes a proposal for exchanging QoS-enabled reachability information between service providers. It defines new BGP attributes to be used in order to convey QoS performance characteristics between service providers and it describes how to use these QoS values in order to select the best path. An example of route selection process that takes into account the QoS performance values enclosed in BGP messages is also detailed. "Media-Independent Pre-Authentication (MPA) Implementation Results", Yoshihiro Ohba, 23-Oct-06, This document describes an initial implementation of Media independent Pre-Authentication (MPA) optimization. MPA is a mobile- assisted, secure handover optimization scheme that works over any link-layer and with any mobility management protocol. The implementation described in this document shows how existing protocols could be leveraged to realize the functionalities of MPA. It also includes empirical results gathered from experiments performed on a simulated network where the implementation resides. "An Anonymity and Unlinkability Extension for OMIPv6", Wassim Haddad, 25-Oct-06, The "Optimized Mobile IPv6 with CBA" (OMIPv6) protocol specifies a new route optimization (RO) mechanism, which offers better security, less signaling messages and reduces the handoff latency. This document describes a new extension to be added to the OMIPv6 protocol in order to provide the anonymity and the unlinkability aspects at the IP layer. "Establishing Handover Keys using Shared Keys", Vidya Narayanan, 8-Mar-07, This document describes a key management protocol to generate a handover key between a mobile node (MN) and an access router (AR) for the purpose of securing Fast Mobile IPv6 (FMIPv6) signaling messages. As such, it specifies a message exchange between the MN and the AR and assumptions that must hold in order for this protocol to work. The protocol itself is described here for FMIPv6 use, but is applicable to other protocols that need to establish shared keys between the MN and a network entity. "The Meta-QoS-Class concept", Pierre Levis, Mohammed Boucadair, 30-Jun-05, This document describes a framework for inter-domain Quality of Service (QoS). It makes use of a new concept denoted by Meta-QoS- Class. This new concept guides and simplifies QoS agreements between providers and opens up new perspectives for a global QoS-enabled Internet. "Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the Generic String Encoding Rules (GSER)", Steven Legg, 22-Dec-06, Abstract Syntax Notation X (ASN.X) is an Extensible Markup Language (XML) representation for Abstract Syntax Notation One (ASN.1) specifications. This document specifies the ASN.X representation of encoding instructions for the Generic String Encoding Rules (GSER). "Synchronisation of Loop Free Timer Values", Stewart Bryant, 20-Oct-06, This draft describes a mechanism that enables routers to agree on a common convergence delay time for use in loop-free convergence. "LowPan Mobility Requirements and Goals", Soohong Daniel Park, Samita Chakrabarti, 7-Mar-07, IETF LowPan working group defines IPv6 over low-power personal area network (IEEE 802.15.4). Lowpan architecture allows routing to take place at the link layer in order to save payload overhead over the IEEE 802.15.4 link and thus more efficient routing for low power, low data-rate networks such as sensor networks. This document discusses a few scenarios of mobility in LowPan network and states mobility requirements and goals for LowPan networks. "TCP and UDP based ForCES Protocol TML over IP Networks", Weiming Wang, 5-Mar-07, This document defines ForCES Transport Mapping Layer (TML) over IP networks, the framework and the specifications to meet the ForCES TML requirements. "Failover for Multiple Mobile Routers in a Mobile Network", Jiho Ryu, 25-Oct-06, This draft proposed the use of multiple mobile routers in a single NEMO. A failed mobile router is taken over by another mobile router using "prefix peer" relationship among mobile routers in a NEMO. "prefix peer" relationship enables a mobile router's prefix to be handled by another mobile router. "Loop-free convergence using oFIB", Pierre Francois, 20-Oct-06, This draft describes a mechanism for use in conjunction with link state routing protocols which prevents the transient loops which would otherwise occur during topology changes. It does this by correctly sequencing the FIB updates on the routers. This mechanism can be used in the case of non-urgent link or node shutdowns and restarts or link metric changes. It can also be used in conjunction with a FRR mechanism which converts a sudden link or node failure into a non-urgent topology change. This is possible where a complete repair path is provided for all affected destinations. After a non-urgent topology change, each router computes a rank that defines the time at which it can safely update its FIB. A method for accelerating this loop-free convergence process by the use of completion messages is also described. "LDP extension for Inter-Area LSP", Bruno Decraene, 2-Mar-07, To facilitate the establishment of Label Switched Paths (LSP) that would span multiple IGP areas in a given Autonomous System (AS), this document proposes a new optional label mapping procedure for the Label Distribution Protocol (LDP). This procedure allows the use of a label if the Forwarding Equivalence Class (FEC) Element matches an entry in the routing table (RIB). Matching is defined by an IP longest match search and does not mandate an exact match. "Simple Mail Transfer Protocol", John Klensin, 8-Mar-07, This document is a largely self-contained specification of the basic protocol for the Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of the obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" mail reading systems and mobile environments. "Distributed Multimodal Synchronization Protocol", Jonathan Engelsma, Chris Cross, 29-Jan-07, This document proposes a Distributed Multimodal Synchronization Protocol (DMSP) designed to enable multimodal interaction for mobile devices by accessing services in the network. More specifically, this protocol coordinates events of interest between a visual browser or application running on a mobile device with a VoiceXML (Voice Extensible Markup Language) browser running in the network. "OAM Requirements for GMPLS Networks", Thomas Nadeau, 6-Mar-07, This document describes requirements for operations and management for Generalized Multi-Protocol Label Switching networks, as well as for applications of Generalized Multi-Protocol Label Switching. "ATIS PTSC Work Program", Martin Dolly, 26-Oct-06, At the 67th San Diego IETF Meeting it is anticipated that the Real-time Applications and Infrastructure Area will meet and its ongoing work program will be an item for discussion. This Internet Draft has been prepared to share the relevant portions of the PTSC current work program with the IETF. It is hoped that awareness of the Packet Technologies Systems Committee (PTSC) work program will allow for more informed discussion. "RADIUS Quality of Service Support", Hannes Tschofenig, 7-Mar-07, This document describes an extension to the RADIUS protocol that performs authentication, authorization, and accounting for Quality- of-Service reservations. The described extensions allow network elements to authenticate the initiator of a reservation request (if desired), to ensure that the reservation is authorized, and to account for established QoS resources. Flexibility is provided by offering support for different authorization models and by decoupling specific QoS attributes carried in the QoS signaling protocol from the AAA protocol. This document is the RADIUS complement to the DIAMETER QoS application. "Construction of the Route Header Field in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 20-Oct-06, The Route header field in the Session Initiation Protocol (SIP) is used to cause a request to visit a set of hops on its way towards the final destination. Several specifications have defined rules for how a user agent obtains and then uses a set of Route header fields in the transmission of a request. These include the SIP specification itself, the Service-Route header field specification, the SIP server option in the Dynamic Host Configuration Protocol (DHCP), and others. Unfortunately, these specifications are not consistent and the resulting behavior at clients and servers is not clear or complete. This document resolves this problem by defining a consistent set of logic, and in the process, serves as an update to the Service-Route specification. "GIST NAT Traversal", Andreas Pashalidis, Hannes Tschofenig, 7-Mar-07, This document describes a number of mechanisms for the implementation of the General Internet Signalling Transport (GIST) protocol [1] on different types of Network Address Translator (NAT). The focus of these mechanisms is the interaction of GIST with the address translation function of the NAT, and their purpose is to enable GIST hosts that are located on either side of the NAT to correctly interpret signalling messages with respect to the data traffic they refer to. The purpose of this document is to provide guidance to people that implement GIST and NSLPs on both NAT and non-NAT nodes. "Extensions to OSPFv2 for Advertising Optional Prefix/Link Attributes", Sina Mirtorabi, 20-Oct-06, There are applications that require additional attributes to be advertised with an OSPF link or prefix. The existing OSPF LSA formats do not allow for backward compatible extension to advertise these attributes. This draft proposes an extension to OSPF for advertising additional attributes which will be associated with a link or prefix. It also introduces the support of administrative tags for any link type in the prefix-LSA and any prefix in summary- LSAs, NSSA-LSAs, or AS-external-LSAs. "Using SRTP transport format with HIP", Hannes Tschofenig, 25-Oct-06, The Host Identity Protocol (HIP) is a signaling protocol which adds a new layer between the traditional Transport and the Network layer. HIP is an end-to-end authentication and key exchange protocol, which supports security and mobility in a commendable manner. The HIP base specification is generalized and purported to support different key exchange mechanisms in order to provide confidentiality protection for the subsequent user data traffic. This draft explains a mechanism to establish Secure Real Time Protocol associations, to protect the user data packets, by using HIP. "Dynamic Provisioning using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)", Nancy Cam-Winget, 6-Mar-07, The flexible authentication via secure tunneling EAP method (EAP- FAST) enables secure communication between a client and a server by using Transport Layer Security (TLS) to establish a mutually authenticated tunnel. EAP-FAST also enables the provisioning credentials or other information through this protected tunnel. This document describes the use of EAP-FAST for dynamic provisioning. "Sieve Email Filtering: Date and Index Extensions", Ned Freed, 5-Mar-07, This document describes the "date" and "index" extensions to the Sieve email filtering language. The "date" extension gives Sieve the ability to test date and time values in various ways. The "index" extension provides a means to limit header and address tests to specific instances of header fields when header fields are repeated. "Pre-Congestion Notification marking", Bob Briscoe, 22-Oct-06, Pre-Congestion Notification (PCN) builds on the concepts of RFC 3168, "The addition of Explicit Congestion Notification to IP". However, Pre-Congestion Notification aims at providing notification before any congestion actually occurs. Pre-Congestion Notification is applied to real-time flows (such as voice, video and multimedia streaming) in DiffServ networks. As described in [CL-DEPLOY], it enables "pre" congestion control through two procedures, flow admission control and flow pre-emption. The draft proposes algorithms that determine when a PCN-enabled router writes Admission Marking and Pre-emption Marking in a packet header, depending on the traffic level. The draft also proposes how to encode these markings. We present simulation results with PCN working in an edge-to-edge scenario using the marking algorithms described. Other marking algorithms will be investigated in the future. "An edge-to-edge Deployment Model for Pre-Congestion Notification: Admission Control over a DiffServ Region", Bob Briscoe, 25-Oct-06, This document describes a deployment model for pre-congestion notification (PCN) operating in a large DiffServ-based region of the Internet. PCN-based admission control protects the quality of service of existing flows in normal circumstances, whilst if necessary (eg after a large failure) pre-emption of some flows preserves the quality of service of the remaining flows. Each link has a configured- admission-rate and a configured-pre-emption-rate, and a router marks packets that exceed these rates. Hence routers give an early warning of their own potential congestion, before packets need to be dropped. Gateways around the edges of the PCN-region convert measurements of packet rates and their markings into decisions about whether to admit new flows, and (if necessary) into the rate of excess traffic that should be pre-empted. Per-flow admission states are kept at the gateways only, while the PCN markers that are required for all routers operate on the aggregate traffic - hence there is no scalability impact on interior routers. "Combined Presence Schemas Utilizing RELAX NG", Jari Urpalainen, 7-Mar-07, This memo describes a batch of Presence Information Data Format (PIDF) and its extension schemas written with the RELAX NG schema language. Unlike with the current W3C XML Schema language it is possible to write reasonable forwards and backwards compatible presence combination schemas. These RELAX NG schemas are stricter than the W3C Schemas and thus the instance documents that validate with these schemas follow the intended content model more closely. Especially, these schemas are targeted to actual implementations in order to decrease interoperability problems. "A Design Rationale for Providing IP Services Over DVB-S2 Links", Jerome Lacan, Juan Cantillo, 7-Dec-06, This document describes a framework for the transmission of IP datagrams over DVB-S2, the second generation standard for Digital Video Broadcasting over Satellite. The new standard features an improved and adaptive physical layer, as well as a new framing structure at link level, the Generic Streams. Combined use of adaptability and Generic Streams is expected to offer throughputs never achieved for IP services up to now, but no standard way to carry IP data using the specific features of DVB-S2 has been published up to date. The present document analyzes these issues, and it identifies the requirements for the definition of a standard interface between the DVB-S2 link layer and an IP subnetwork. "The Core Session Initiation Protocol User Agent Protocol Data Set", Daniel Petrie, 25-Oct-06, This document defines the properties and format for the core SIP user agent protocol dataset. The properties defined in this document are expected to be common to most SIP user agents regardless of whether the user agent support audio, video, text or any combination of media. These core SIP properties are considered to be a dataset. Several datasets may be combined into documents or profiles that are provided to SIP user agents so that they can operate with the desired behavior. "Media Server Control Protocol (MSCP)", Scott McGlashan, 7-Mar-07, This document specifies MSCP (Media Server Control Protocol), a protocol to control interactive dialog and conferencing functions on a media server. The protocol messages - requests, responses and notifications - are modeled on dialog and conferencing elements defined in CCXML (Voice Browser Call Control), and interactive dialogs can be specified in VoiceXML (Voice Extensible Markup Language). MSCP messages have self-contained XML representation and transaction models, so the protocol is independent of the underlying transport channel. Messages may be transported using SIP or, preferably, using a dedicated transport channel. "Update to OSPF Graceful Restart procedure", Ashok Holla, 13-Sep-06, This document suggests improvements to OSPF v2 Graceful Restart. The basic protocol working remains as specified in [OSPFGR]. The draft describes a two pronged approach for improving the current graceful restart mechanism. It improves the restarting Router’s ability to detect and react to topology changes. It also reduces the conservative behavior of the helper Router in reacting to topology changes. In addition, it adds certain clarifications for interpretation of the RFC 3623. "UniDirectional Link Detection (UDLD) Protocol", Marco Foschiano, 28-Aug-06, This document describes a protocol that can be used to detect and disable unidirectional Ethernet fiber or copper links caused for instance by mis-wiring of fiber strands, interface malfunctions, media converters' faults, etc. It operates at Layer 2 in conjunction with IEEE 802.3's existing Layer 1 fault detection mechanisms. Please note that this document is not meant to be used as an implementation reference for inter-vendor interoperability purposes. Its objective instead is to be an informative reference for users who wish to deploy services based on the protocol herein described. "An IPFIX-Based File Format", Brian Trammell, 5-Mar-07, This document describes a file format for the storage of flow data based upon the IPFIX message format. It proposes a set of requirements for flat-file, binary flow data file formats, evaluates flow storage systems presently in use for their conformance to these requirements, then applies the IPFIX message format to these requirements to build a new file format. This IPFIX-based file format is designed to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools. "Atom License Extension", James Snell, 22-Nov-06, This memo defines an extension to the Atom Syndication Format for describing licenses associated with Atom feeds and entries. "Link Adaptation for IPv6-in-IPv4 Tunnels", Fred Templin, 22-Oct-06, IPv6-in-IPv4 tunnel endpoints support an MTU of 1280 bytes or larger via static prearrangements and/or dynamic MTU determination based on ICMPv4 messages, but these methods have known operational limitations. This document proposes a new MTU determination mechanism for IPv6-in-IPv4 tunnels that supports larger MTUs using a link adaptation scheme with tunnel endpoint-based segmentation/ reassembly and dynamic segment size probing. "EDI-INT Features Header", Kyle Meadors, 13-Nov-06, With the maturity of the EDI-INT standard of AS1, AS2 and AS3, applications and additional features are being built upon the basic secure transport functionality. These features are not necessarily supported by all EDI-INT applications and could cause potential problems with implementations "Using Spurious Retransmissions to Adapt the Retransmission Timeout", Mark Allman, 12-Dec-06, This document describes a method for using spurious retransmission timeouts as the trigger for slightly changing the way TCP's retransmission timeout is computed in an effort to avoid subsequent unnecessary retransmissions. "Metrics for the Evaluation of Congestion Control Mechanisms", Sally Floyd, 6-Mar-07, This document discusses the metrics to be considered in an evaluation of new or modified congestion control mechanisms for the Internet. These include metrics for the evaluation of new transport protocols, of proposed modifications to TCP, of application-level congestion control, and of Active Queue Management (AQM) mechanisms in the router. This document is the first in a series of documents aimed at improving the models that we use in the evaluation of transport protocols. This document is a product of the Transport Modeling Research Group (TRMG), and has received detailed feedback from many members of the Research Group (RG). As the document tries to make clear, there is not necessarily a consensus within the research community (or the IETF community, the vendor community, the operations community, or any other community) about the metrics that congestion control mechanisms should be designed to optimize, in terms of tradeoffs between throughput and delay, fairness between competing flows, and the like. However, we believe that there is a clear consensus that congestion control mechanisms should be evaluated in terms of tradeoffs between a range of metrics, rather than in terms of optimizing for a single metric. "HIP DHT Interface", Jeff Ahrenholz, 13-Feb-07, This document specifies a common interface for using HIP with a DHT to provide a HIT-to-address lookup service and an unmanaged name-to- HIT lookup service. "Stream Control Transmission Protocol (SCTP) Stream Reset", Randall Stewart, 12-Jan-07, Many applications that desire to use SCTP have requested the ability to "reset" a stream. The intention of resetting a stream is to start the numbering sequence of the stream back at 'zero' with a corresponding notification to the upper layer that this act as been performed. The applications that have requested this feature normally desire it so that they can "re-use" streams for different purposes but still utilize the stream sequence number for the application to track the message flows. Thus, without this feature, a new use on an old stream would result in message numbers larger than expected without a protocol mechanism to "start the streams back at zero". This documents presents also a method for resetting the transport sequence numbers and all stream sequence numbers. "Extensible Provisioning Protocol (EPP)", Scott Hollenbeck, 21-Nov-06, This document describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 3730 if approved. "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", Pekka Nikander, 14-Feb-07, This document introduces Overlay Routable Cryptographic Hash Identifiers (ORCHID) as a new, experimental class of IPv6-address- like identifiers. These identifiers are intended to be used as end- point identifiers at applications and Application Programming Interfaces (API) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like vanilla IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered as non-routable addresses from the IPv6 layer point of view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses. This document requests IANA to allocate a temporary prefix out of the IPv6 addressing space for Overlay Routable Cryptographic Hash Identifiers. By default, the prefix will be returned to IANA in 2027, continued use requiring IETF consensus. "Extensible Provisioning Protocol (EPP) Host Mapping", Scott Hollenbeck, 21-Nov-06, This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. This document obsoletes RFC 3732 if approved. "Extensible Provisioning Protocol (EPP) Contact Mapping", Scott Hollenbeck, 10-Jan-07, This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in Extensible Markup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts. This document obsoletes RFC 3733 if approved. "Extensible Provisioning Protocol (EPP) Transport Over TCP", Scott Hollenbeck, 10-Jan-07, This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. This document obsoletes RFC 3734 if approved. "Extensible Provisioning Protocol (EPP) Domain Name Mapping", Scott Hollenbeck, 21-Nov-06, This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names. This document obsoletes RFC 3731 if approved. "Security requirements for the Unidirectional Lightweight Encapsulation (ULE) protocol", Haitham Cruickshank, 19-Oct-06, The MPEG-2 standard defined by ISO 13818-1 [ISO-MPEG2] supports a range of transmission methods for a range of services. This document provides a threat analysis and derives the security requirements when using the Transport Stream, TS, to support an Internet network-layer using Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. The document also provides the motivation for link-level security for a ULE Stream. A ULE Stream may be used to send IPv4 packets, IPv6 packets, and other Protocol Data Units (PDUs) to an arbitrarily large number of Receivers supporting unicast and/or multicast transmission. "Tools for the Evaluation of Simulation and Testbed Scenarios", Sally Floyd, Eddie Kohler, 15-Dec-06, This document describes tools for the evaluation of simulation and testbed scenarios used in research on Internet congestion control mechanisms. We believe that research in congestion control mechanisms has been seriously hampered by the lack of good models underpinning analysis, simulation, and testbed experiments, and that tools for the evaluation of simulation and testbed scenarios can help in the construction of better scenarios, based on better underlying models. One use of the tools described in this document is in comparing key characteristics of test scenarios with known characteristics from the diverse and ever-changing real world. Tools characterizing the aggregate traffic on a link include the distribution of per-packet round-trip times, the distribution of connection sizes, and the like. Tools characterizing end-to-end paths include drop rates as a function of packet size and of burst size, the synchronization ratio between two end-to-end TCP flows, and the like. For each characteristic, we describe what aspects of the scenario determine this characteristic, how the characteristic can affect the results of simulations and experiments for the evaluation of congestion control mechanisms, and what is known about this characteristic in the real world. We also explain why the use of such tools can add considerable power to our understanding and evaluation of simulation and testbed scenarios. "Authentication for TCP-based Routing and Management Protocols", Ronald Bonica, 14-Feb-07, This memo describes a TCP extension that enhances security for BGP, LDP and other TCP-based protocols. It is intended for applications where secure administrative access to both the end-points of the TCP connection is normally available. TCP peers can use this extension to authenticate messages passed between one another. The strategy described herein improves upon current practice, which is described in RFC 2385. Using this new strategy, TCP peers can update authentication keys during the lifetime of a TCP connection. TCP peers can also use stronger authentication algorithms to authenticate routing messages. "Extended ICMP to Support Multi-part Messages", Ronald Bonica, 30-Jan-07, This document redefines selected ICMP messages to support multi-part operation. A multi-part ICMP message carries all of the information that ICMP messages carried previously, as well as additional information that applications may require. Multi-part messages are supported by an ICMP extension structure. The extension structure is situated at the end of the ICMP message. It includes an extension header followed by one or more extension objects. Each extension object contains an object header and object payload. All object headers share a common format. This document further redefines the above mentioned ICMP messages by specifying a length attribute. All of the currently defined ICMP messages to which an extension structure can be appended include an "original datagram" field. The "original datagram" field contains the initial octets of the datagram that elicited the ICMP error message. Although the original datagram field is of variable length, the ICMP message does not include a field that specifies its length. Therefore, in order to facilitate message parsing, this draft allocates eight previously reserved bits to reflect the length of the "original datagram" field. The proposed modifications change the requirements for ICMP compliance. The impact of these changes on compliant implementations is discussed, and new requirements for future implementations are presented. This memo updates RFC 792 and RFC 4443. "Delay-Tolerant Networking Security Overview", Stephen Farrell, 5-Oct-06, This document provides an overview of the security requirements and mechanisms considered for delay tolerant networking security. It discusses the options for protecting such networks and describes reasons why specific security mechanisms were (or were not) chosen for the relevant protocols. The entire document is informative, given it's purpose is mainly to document design decisions. "OCSP Extensions to IKEv2", Michael Myers, Hannes Tschofenig, 25-Oct-06, While IKEv2 supports public key based authentication (PKI), the corresponding use of in-band CRLs is problematic due to unbounded Certificate Revocation List (CRL) size. The size of an Online Certificate Status Protocol (OCSP) response is however well-bounded and small. This document defines the "OCSP Content" extension to IKEv2. A CERTREQ payload with "OCSP Content" identifies zero or more trusted OCSP responders and is a request for inclusion of an OCSP response in the IKEv2 handshake. A cooperative recipient of such a request responds with a CERT payload containing the appropriate OCSP response. This content is recognizable via the same "OCSP Content" identifier. When certificates are used with IKEv2, the communicating peers need a mechanism to determine the revocation status of the peer's certificate. OCSP is one such mechanism. This document applies when OCSP is desired and security policy prevents one of the IKEv2 peers from accessing the relevant OCSP responder directly. Firewalls are often deployed in a manner that prevents such access by IKEv2 peers outside of an enterprise network. "Passive Duplicate Address Detection for the Dynamic Host Configuration Protocol for IPv4 (DHCPv4)", Andrea Forte, 11-Oct-06, In a Layer 3 (L3) handoff procedure, one of the biggest components in terms of delay is introduced by the DHCP address acquisition time required for obtaining a valid IP address for the new subnet. Duplicate Address Detection (DAD) is the most time consuming part of the whole DHCP procedure. In this document we propose a new DAD scheme which has been proven to be effective without introducing any significant delay. By using such a scheme we can avoid duplicate address and at the same time keep the address acquisition time in the order of a few milliseconds. Using the new procedure will also permit to detect an unauthorized use of a particular IP address even if no duplicate IP has yet occurred. "Requirements for IP-in-IP Tunnel MTU Assurance", Fred Templin, 22-Oct-06, IP-in-IP tunnels present a Maximum Transmission Unit (MTU) to layer 3 via static prearrangements and/or dynamic MTU determination based on layer 2 ICMP messages, but these methods have known operational limitations that can fail to enforce an assured MTU resulting in degraded performance and communications failures. A method for providing an assured MTU to layer 3 over IP-in-IP tunnels is needed. "Guidelines for Implementing the GRUU Support in User Agents", Dale Worley, 20-Feb-07, Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI which can be used by anyone on the Internet to route a request to that specific UA instance. A URI which routes to a specific UA instance is called a Globally Routable UA URI (GRUU). An Internet-Draft is progressing toward standardization that specifies procedures for proxies and UAs by which proxies can construct and delver GRUUs to UAs that request them. This document summarizes for UA implementors how to obtain "public" GRUUs and gives guidance on effectively using public GRUUs. "GRE Key Extension for Mobile IPv4", Parviz Yegani, 5-Mar-07, The GRE specification contains a Key field, which MAY contain a value that is used to identify a particular GRE data stream. This specification defines a new Mobile IP extension that is used to exchange the value to be used in the GRE Key field. This extension further allows the Mobility Agents to setup the necessary protocol interfaces prior to receiving the mobile's traffic. The new extension option allows a foreign agent to request GRE tunneling without disturbing the Home Agent behavior specified for Mobile Ipv4. GRE tunneling provides an advantage that allows operator's private home networks to be overlaid and allows the HA to provide overlapping home addresses to different subscribers. When the tuple < Care of Address, Home Address and Home Agent Address > is the same across multiple subscriber sessions, GRE tunneling will provide a means for the FA and HA to identify data streams for the individual sessions based on the GRE key. In the absence of this key identifier, the data streams cannot be distinguished from each other, a significant drawback when using IP-in-IP tunneling. "SIP-based Network Mobility (SIP-NEMO) Route Optimization (RO)", Chao-Hsien Lee, 20-Oct-06, The Network Mobility (NEMO) Basic Support protocol enables a mobile network to change its point of attachment and keeps nodes in the mobile network reachable when the mobile network moves in the Internet. However, using the NEMO Basic Support protocol, all traffic must pass through the bi-directional tunnel between a mobile router and its home agent when the mobile router leaves its home network. The bi-directional tunnel results in sub-optimal routing and long transmission delay. This document describes the SIP-based Network Mobility (SIP-NEMO) Route Optimization (RO) that achieves optimal routing and reduces the limitation induced by Mobile IPv6. "NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication", Martin Stiemerling, 7-Mar-07, The Host Identity Protocol (HIP) changes the way in which two Internet hosts communicate. One key advantage over other schemes is that HIP does not require modifications to the traditional network- layer functionality of the Internet, i.e., its routers. In the current Internet, however, many devices other than routers modify the traditional network-layer behavior of the Internet. These "middleboxes" are intermediary devices that perform functions other than the standard functions of an IP router on the datagram path between source and destination hosts. Whereas some types of middleboxes may not interfere with HIP at all, others can affect some aspects of HIP communication and others can render HIP communication impossible. This document discusses the problems associated with HIP communication across network paths that include specific types of middleboxes, namely, network address translators and firewalls. It identifies and discusses issues in the current HIP specifications that affect communication across these types of middleboxes. This document is a product of the IRTF HIP Research Group. "People and Content video streams", Roni Even, 2-Mar-07, This document describes the procedures for using more than one video channel in SIP based systems enabling the other endpoints to understand the semantics of each channel. The document describe how to label individual channels with a "role". The "role" indicates the requirements for processing the channel and the role of the channel content in the SIP call. The procedure address multipoint and point to point scenarios. "RTP Payload Format for SVC Video", Stephan Wenger, 20-Oct-06, This memo describes an RTP Payload format for the scalable extension of the ITU-T Recommendation H.264 video codec which is the technically identical to ISO/IEC International Standard 14496-10 video codec. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by the video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bit-rate conversational usage, to Internet video streaming with interleaved transmission, to high bit-rate video-on-demand. "MTLS: TLS Multiplexing", Mohamad Badra, Ibrahim Hajjeh, 24-Jan-07, The Transport Layer Security (TLS) standard provides connection security with mutual authentication, data confidentiality and integrity, key generation and distribution, and security parameters negotiation. However, missing from the protocol is a way to multiplex application data over a single TLS session. This document defines MTLS, a new TLS sub-protocol running over TLS (or DTLS) Record protocol. The MTLS design provides application multiplexing over a single TLS (or DTLS) session. Therefore, instead of associating a TLS connection with each application, MTLS allows several applications to protect their exchanges over a single TLS session. "SIMCO over SCTP", Sebastian Kiesel, 26-Sep-06, This document specifies how to use SCTP for the transport of the SIMCO (Version 3.0) protocol. SIMCO (SImple Middlebox COnfiguration) is a protocol that implements the MIDCOM semantics. It can be used for controlling middleboxes such as firewalls and network address translators. SCTP (Stream Control Transmission Protocol) is a transport layer protocol that is expected to have advantages for this type of application, compared to TCP, which is the default transport layer protocol for SIMCO. The specific requirements for SIMCO when using SCTP instead of TCP are specified in this document. "Four-octet AS Specific BGP Extended Community", Yakov Rekhter, 25-Sep-06, This document defines a new type of a BGP extended community - four- octet AS specific extended community. This community allows to carry 4 octet autonomous system numbers. "Mobile IPv6 Bootstrapping with IKEv1", Vijay Devarapalli, Mohan Parthasarathy, 9-Oct-06, The current Mobile IPv6 bootstrapping mechanisms require the use of IKEv2 between the mobile node and the home agent. If the Mobile IPv6 signaling messages are protected by IKEv1 and IPsec as described in RFC 3776, then the bootstrapping mechanism based on IKEv2 cannot be used. This document describes a bootstrapping mechanism for Mobile IPv6 when RFC 3776 is used. "Password Authenticated Diffie-Hellman Exchange (PAK)", Alec Brusilovsky, 8-Mar-07, This document proposes to add mutual authentication, based on human-memorizable password, to the basic unauthenticated Diffie-Hellman key exchange. The proposed algorithm is called Password Authenticated Key exchange (PAK). PAK allows two parties to authenticate themselves while performing the Diffie-Hellman exchange. The protocol is secure against all passive and active attacks. In particular, it does not allow either type of attackers to obtain any information that would enable an off-line dictionary attack on the password. The use of Diffie-Hellman exchange ensures Forward Secrecy. "Moving Forwards with IETF Process Evolution", Elwyn Davies, 26-Oct-06, This document provides a summary of previously identified problems with the Internet Engineering Task Force (IETF) process for developing standards and other specifications; and then identifies a set of goals to aim at, and guidelines that should be followed during any activity seeking to revise and update this process. It does not propose specific changes to the process, which should be the subject of future documents. "vCard Extensions to WebDAV (CardDAV)", Cyrus Daboo, 23-Oct-06, This document specifies a set of methods, headers and resource types that define an extension to the WebDAV protocol to support vCard data stored as address books on the server. The new protocol elements are intended to make WebDAV-based address book management an interoperable standard that supports address book access, address book sharing, and address book publishing. "Media Control Protocol Requirements", Martin Dolly, 26-Sep-06, This document provides requirements for a protocol, that will enable one physical entity that includes the media policy server, notification server and the focus to interact with one or more physical entities that serves as mixer or media server. It will address all phases and aspects of media handling in a conferencing service including announcements and IVR functionality. "Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP)", James Polk, 5-Mar-07, The offer/answer model for SDP assumes that endpoints establish, somehow, the QoS required for the media streams they establish. Endpoints in closed environments typically agree out of band (e.g., using configuration information) which QoS mechanism to use. However, on the Internet, there is more than one QoS service available. Consequently, there is a need for a mechanism to negotiate which QoS mechanism to use for a particular media stream. This document defines such a mechanism. "Improving DNS Service Availability by Using Long TTL Values", Vasileios Pappas, 26-Oct-06, Due to the hierarchical tree structure of the Domain Name System [RFC1034][RFC1035], losing all of the authoritative servers that serve a zone can disrupt services to not only that zone but all of its descendants. This problem is particularly severe if all the authoritative servers of the root zone, or of a top level domain's zone, fail. Although proper placement of secondary servers, as discussed in [RFC2182], can be an effective means against isolated failures, it is insufficient to protect the DNS service against distributed denial of service attacks (DDoS). This document proposes to mitigate the impact of DDoS attacks against top level DNS servers by setting long TTL values for NS records and the associated A records. Our proposal involves only operational changes and can be deployed incrementally. "The Session Initiation Protocol User Agent Identity Profile Data Set", Daniel Petrie, 25-Oct-06, This document defines the properties and data format for the SIP user agent identity profile data set. The properties in this data set define identities or SIP address of records (AORs) related to incoming or outgoing SIP signaling on a user agent. The identities may be those that are registered via the SIP REGISTER method or identities which are provisioned on the user agent. These identities may be used or referenced when defining identity specific handling related to SIP features on the user agent. "Dynamic MANET On-demand for 6LoWPAN (DYMO-low) Routing", Ki-Hyung Kim, 6-Mar-07, This document specifies how to use the Dynamic MANET On-demand Routing Protocol over IEEE802.15.4 networks. "The Session Initiation Protocol User Agent VoIP Features Data Set", Daniel Petrie, 25-Oct-06, This document defines the properties and format for the SIP user agent VoIP Features data set. The properties defined in this document are expected to be common to most SIP user agents that provide VoIP capabilities. These VoIP Feature properties are considered to be a data set. Several types of datasets may be combined into documents that are provided to SIP user agents so that they can operate with the desired behavior. "UDP Encapsulation of SCTP Packets", Michael Tuexen, Randall Stewart, 27-Nov-06, This document describes a simple method of encapsulating SCTP Packets. This makes it possible to use SCTP in networks with legacy NAT not supporting SCTP. "Privacy Aspects Terminology", Wassim Haddad, Erik Nordmark, 29-Jan-07, This memo introduces terminology for the main privacy aspects. The prime goal is to avoid situations where different interpretations of the same key privacy aspects result in different requirements when designing specific solutions, thus leading to an unnecessary confusion. "Address Resolution for GMPLS controlled PSC Ethernet Interfaces", Zafar Ali, 7-Mar-07, This document outlines some interoperability issues observed with the use of ARP over GMPLS controlled Ethernet router-to-router (PSC) interfaces transiting from a non-Ethernet core, e.g., FSC or LSC GMPLS core. The document also recommends some procedures to address these issues. The aim of this document is to facilitate and ensure better interworking of GMPLS-capable Label Switching Routers (LSRs), based on experience gained in interoperability testing. "Re-ECN: Adding Accountability for Causing Congestion to TCP/IP", Bob Briscoe, 26-Oct-06, This document introduces a new protocol for explicit congestion notification (ECN), termed re-ECN, which can be deployed incrementally around unmodified routers. The protocol arranges an extended ECN field in each packet so that, as it crosses any interface in an internetwork, it will carry a truthful prediction of congestion on the remainder of its path. Then the upstream party at any trust boundary in the internetwork can be held responsible for the congestion they cause, or allow to be caused. So, networks can introduce straightforward accountability and policing mechanisms for incoming traffic from end-customers or from neighbouring network domains. The purpose of this document is to specify the re-ECN protocol at the IP layer and to give guidelines on any consequent changes required to transport protocols. It includes the changes required to TCP both as an example and as a specification. It also gives examples of mechanisms that can use the protocol to ensure data sources respond correctly to congestion. And it describes example mechanisms that ensure the dominant selfish strategy of both network domains and end-points will be to set the extended ECN field honestly. "Considerations for Having a Successful BOF", Thomas Narten, 8-Mar-07, This document discusses tactics and strategy for hosting a successful IETF Birds-of-a-Feather (BOF) Session, especially one oriented at the formation of an IETF Working Group. It is based on the experiences of having participated in numerous BOFs, both successful and unsuccessful. "A mechanism defined for requesting a mobile nodes binding information", Robert Jaksa, 7-Mar-07, This draft documents an idea whereby a Mobile IPv6 supported correspondent node (CN) may request or solicit binding information about a Mobile IPv6 node (MN) either directly or by way of its respective Home Agent. Such a solicitation may be used for peer-to- peer applications and services. A new Mobile IPv6 Group management system is also defined in this revision. "DNS Glue RR Survey and Terminology Clarification", Peter Koch, 2-Oct-06, This document presents a survey of the use of the term "glue record" in DNS related RFCs and proposes a terminology for the various glue policies seen in different TLDs. "Call Pickup Examples in SIP", Dale Worley, 5-Mar-07, This document walks through various examples and call flows for implementing "call pickup" operations in SIP telephony. It focuses on distributing as much processing as possible in the user agents in accordance with the philosophy of end-point controlled call-control (EPCC). Various difficulties in implementing call pickup are discussed, and further suggestions and discussion are solicited. "Quality of Service Extension to Dynamic MANET OnDemand Routing Protocol", Namhi Kang, Younghan Kim, 8-Mar-07, This document describes extensions to the Dynamic MANET On-demand (DYMO) routing protocol in order to enable mobile nodes to discover and maintain QoS routes. DYMO is a reactive (on-demand) routing protocol designed for use by mobile nodes in multi-hop wireless ad hoc networks. Extensions of this document include the necessary entries to the routing table and DYMO routing messages. "CableLabs - IETF Standardization Collaboration", Mark Townsley, Jean-Francois Mule, 1-Feb-07, This document describes the collaboration and liaison relationship between the Internet Engineering Task Force (IETF) and the Cable Television Laboratories, Inc. (CableLabs). "Multicast Mobility in MIPv6: Problem Statement", Thomas Schmidt, Matthias Waehlisch, 5-Mar-07, In this document we discuss mobility extensions to current IP layer multicast solutions. Problems arising from mobile group communication in general, in the case of multicast listener mobility and for mobile Any Source Multicast as well as Source Specific Multicast senders are documented. Characteristic aspects of multicast routing and deployment issues are summarized. The principal approaches to the multicast mobility problems are outlined subsequently. "IANA Considerations for PPP over Ethernet (PPPoE)", Peter Arberg, Vince Mammoliti, 25-Oct-06, This document describes the IANA considerations for the PPP over Ethernet (PPPoE) protocol. "Guaranteed TCP Friendly Rate Control (gTFRC) for DiffServ/AF Network", Emmanuel Lochin, 5-Sep-06, This memo introduces gTFRC, a TCP-Friendly Rate Control providing throughput guarantee over the DiffServ/AF class. gTFRC is largely based on TFRC [2]. It provides a mean to take into account the quality of service negotiated with the network. As a result, the mechanism is able to reach a minimum throughput guarantee whatever the flow's RTT and target rate. "Registration of media type audio/sp-midi", Timo Kosonen, Tom White, 27-Dec-06, The MIDI Manufacturers Association (MMA) and the Association of Music Electronics industry (AMEI) have produced the Scalable Polyphony MIDI (SP-MIDI) standard [n1]. SP-MIDI has been approved for 3GPP standardization and a dedicated SP-MIDI profile has been defined for 3GPP SP-MIDI devices [n2]. Since MIDI information is a very compact media type, 3GPP is initially focusing on the application of SP-MIDI for music downloading and messaging applications that require MIME registration. "IKEv2-based Home Agent Assignment in Mobile IPv6/NEMO Bootstrapping", Kilian Weniger, Francis Dupont, 31-Jan-07, This document specifies how to use IKEv2 for Home Agent assignment in Mobile IPv6 or NEMO bootstrapping. It uses IPv6 anycast addresses and should not introduce new security issues. "IAX2: Inter-Asterisk eXchange Version 2", Brian Capouch, 25-Oct-06, This document describes the Inter-Asterisk eXchange protocol, Version 2, (IAX2) an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX2 is targeted primarily at the control of Voice over Internet Protocol (VoIP) calls, but can be used with streaming video or any other type of multimedia. IAX2 is an "all in one" protocol for handling multimedia in Internet Protocol (IP) networks. It combines both control and media services in the same protocol. IAX2's compact encoding decreases bandwidth usage and since IAX2 uses a single, static, UDP port, it facilitates native support for Network Address Translation (NAT) transparency. IAX2 is well suited for Internet telephony service, but, is open enough to support additional services. "Identifiers for Internet Media Guides (IMG)", Janico Greifenberg, 19-Dec-06, This document defines a Uniform Resource Name (URN) namespace for identifying Internet Media Guides (IMGs). IMG metadata describes files, resources and multimedia programs available for streaming or downloading via multicast or unicast. "DTCP: Dynamic Tasking Control Protocol", David Cavuto, 8-Sep-06, Dynamic Tasking Control Protocol is a message-based interface by which an authorized client may connect to a server -- usually a network element (NE) or security policy enforcement point (PEP) -- and issue dynamic requests for data. These tasking requests contain, among other parameters, packet matching criteria that may apply to certain packets flowing through that network element. The primary intent of the tasking request is to instruct that network element to send copies of packets matching those criteria to a destination (usually via tunneling) for further inspection or other action. The protocol contains a security architecture to address client or server spoofing as well as replay prevention. The protocol assumes that multiple clients may simultaneously control a single server. "Use of Hash Algorithms in IKE and IPsec", Paul Hoffman, 5-Mar-07, This document describes how the IKEv1, IKEv2, and IPsec protocols use hash functions, and explains the level of vulnerability of these protocols to the reduced collision resistance of the MD5 and SHA-1 hash algorithms. "SIP Interface to VoiceXML Media Services", Dave Burke, 21-Nov-06, This document describes a SIP interface to VoiceXML media services, which is commonly employed between application servers and media servers offering VoiceXML processing capabilities. "ICMP Extensions for Unnumbered Interfaces", Alia Atlas, 7-Mar-07, This memo defines extensions to ICMP that permit identification of unnumbered interfaces. The interface the triggering IPv4 or IPv6 packet was received upon can be identified by appending an ifIndex and/or a string describing the interface. These extensions are defined to facilitate troubleshooting in network with unnumbered interfaces. Additionally, to facilitate debugging of numbered interfaces, an IPv4 or IPv6 address of the interface the triggering IPv4 or IPv6 packet was received upon can be identified by appending an IPv4 or IPv6 address. "OCRA: OATH Challenge-Response Algorithms", David M'Raihi, 24-Oct-06, This document describes the OATH algorithm for challenge-response authentication and signatures. This algorithm is based on the HOTP algorithm [RFC4226] that was introduced by OATH (initiative for Open AuTHentication) [OATH] and submitted as an individual draft to the IETF last year. "Extensions to RSVP-TE Fast Reroute", Jiang Weilian, 27-Oct-06, This document defines extensions to the Fast Reroute (FRR) mechanism of Facility Backup defined in RFC4090. Through the extensions, the node that has set up FRR relation is capable of notifying the tail node of backup tunnel to act as Merge Point (MP) of the protected and backup tunnels. In addition, after the FRR switchover, PLR and MP nodes can refresh the protocol state of protected tunnel by the Refresh message of backup tunnel, so that the protocol messages of protected tunnel don't need to be refreshed through the backup tunnel. "L2VPN Management Information Base", Jiang Weilian, 25-Oct-06, This draft not only describes the management model which is universal to all PSN types supported by PWE3 architecture, but also defines an experimental part of MIB on Internet community network management protocol. Especially, the draft describes the managed objects of L2VPN service on packet switching network, including VPWS, VPLS and IPLS services. Different from PW MIB, the MIB provides the management models for L2VPN service, including the management models of L2VPN service instance, L2VPN PW specific parameters, L2VPN AC Access parameters and traffic statistics for L2VPN service. "Update to OSPF Hello procedure", Zengjie Kou, 22-Jan-07, This memo documents an extension of the OSPF protocol to reach "ExStart" state more quickly. Currently, the OSPF behavior requires the Hello Packet to be sent between the neighbors every HelloInterval. This document proposes to generalize the use of Immediately Replying Hello which could reduce the time required to reach the OSPF "ExStart" state and expedite the routing table convergence. "A Basic Interactive Voice Response (IVR) Control Package for the Session Initiation Protocol (SIP)", Chris Boulton, 7-Mar-07, This document defines a Session Initiation (SIP) Control Package for basic Interactive Voice Response (IVR) interaction. The control of Media Servers and their related resources in decomposed network architectures plays an important role in various Next Generation Networks. This Control Package provides IVR functionality using the SIP Control Framework. "A Control Framework for the Session Initiation Protocol (SIP)", Chris Boulton, 8-Feb-07, This document describes a Framework and protocol for application deployment where the application logic and processing are distributed. The framework uses the Session Initiation Protocol (SIP) to establish an application-level control mechanism between application servers and associated external servers such as media servers. The motivation for the creation of this Framework is to provide an interface suitable to meet the requirements of a distributed, centralized conference system, as defined by the XCON work group of the IETF. It is not, however, limited to this scope and it is envisioned that this generic Framework will be used for a wide variety of de-coupled control architectures between network entities. "Centralized Conferencing Manipulation Protocol", Mary Barnes, 13-Feb-07, The Centralized Conferencing Manipulation Protocol (CCMP) defined in this document provides the mechanisms to create, change and delete objects related to centralized conferences, including participants, their media and their roles. The protocol relies on web services and SIP event notification as its infrastructure, but can control conferences that use any signaling protocol to invite users. CCMP is based on the Simple Object Access Protocol (SOAP), with the data necessary for the interactions specified via Web Services Description Language (WSDL). "Widget Description Exchange Service (WIDEX) Framework", Vlad Stirbu, Dave Raggett, 6-Nov-06, This document defines a framework used to support XML-based user interfaces, where the user interface and application logic may be on different machines, and coupled via an exchange of XML DOM events and update operations. "GSMP extensions for Access Node Control Mechanism", Sanjay Wadhwa, 26-Oct-06, This document describes proposed extensions to the GSMPv3 protocol to allow its use in a broadband environment, as a control plane between Access Nodes (e.g. DSLAM) and Broadband Network Gateways (e.g. BRAS). These proposed extensions are required to realize a protocol for "Access Node Control" mechanism as described in [9]. The resulting protocol with the proposed extensions to GSMPv3 [4] is referred to as "Access Node Control Protocol" (ANCP). This document focuses on specific use cases of access node control mechanism for topology discovery, line configuration, and OAM. It is intended to be augmented by additional protocol specification for future use cases considered in scope by the ANCP charter. "Private Extensions to the Session Initiation Protocol (SIP) for Service Interaction Indicator", Yuzhong Shen, 26-Feb-07, In SIP-based networks, a SIP session MAY involve several application servers on the originating and terminating side. In a certain case, an application server needs to set some indications in SIP message to indicate service information (what are invoked, what can be allowed and what should blocked). This kind of information will be also required for composition of SIP applications. There is a need to provide indicators for service interaction between SIP application servers or other SIP endpoints. This document describes a mechanism of service interaction indicator for the Session Initiation Protocol (SIP) that enhances service interaction between SIP application servers in a trusted network. "An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification", Aki Niemi, 8-Mar-07, The Session Initiation Protocol (SIP) events framework enables receiving asynchronous notification of various events from other SIP user agents. This framework defines the procedures for creating, refreshing and terminating subscriptions, as well as fetching and periodic polling of resource state. These procedures have a serious deficiency in that they do not allow state to persist over a subscription refresh, or between two consecutive polls. This inability to suppress notifications of state already known to the subscriber results in superfluous traffic in the network. This memo defines an extension to SIP events that allows the subscriber to condition the subscription request to whether the state has changed since the previous notification was received. When such a condition is true, either the body of an event notification or the entire notification message is suppressed. "Channel Binding Mechanism based on Parameter Binding in Key Derivation", Yoshihiro Ohba, 5-Dec-06, This document describes a channel binding mechanism based on parameter binding in the key derivation procedure. The method cryptographically binds service information to a key without need to carry the service information in EAP methods. "Location Configuration Protocol", Marc Linsner, John Schnizlein, 16-Nov-06, Location Configuration Protocol provides a host with physical location based on its IP address. This document describes the communication protocol and mechanism for an IP host to discovery the physical location associated with its own IP address by communicating with a Location Information Server. This document describes the overall protocol and communication architecture. "DHCP Option for Discovering IEEE 802.21 Information", Soohong Daniel Park, 10-Sep-06, In IEEE 802 Standard, the Media Independent Handover (MIH) Services are under work through IEEE 802.21 Working Group. It is consist of three services, Media Independent Event Service (MIES), Media Independent Command Service (MICS) and Media Independent Information Service (MIIS). This document provides a mechanism by which the DHCP can provide information about the MIIS Discovery Information. "Simple Ad hoc Key Management (SAKM)", Manel Guerrero Zapata, 6-Sep-06, The Simple Ad hoc Key Management (SAKM) is a key management system that allows to the nodes of an ad hoc network to use asymmetric cryptography with zero configuration. It is intended to be applied to MANET routing protocols that provide security features that require the use of asymmetric cryptography (like SAODV). "Transport Layer Security (TLS) Authorization Extensions", Mark Brown, Russ Housley, 5-Jun-06, This document specifies authorization extensions to the Transport Layer Security (TLS) Handshake Protocol. Extensions carried in the client and server hello messages to confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, authorization information is exchanged in the supplemental data handshake message. "Trusted Transactions for Network-Enabled Devices", Jeff Stapleton, Phillip Griffin, 12-Dec-06, This document specifies a cryptographically protected message format and transaction protocol for managing network-enabled devices. The message format consists of a header, content and trailers. The message header uniquely identifies the message type. The message content is afforded (i) authentication by means of a digital signature trailer and (ii) confidentiality by means of encryption trailer; and the whole message (header, content, trailers) is afforded integrity by means of a trusted time stamp trailer. All message structures are defined using ASN.1 and all cryptographic structures use CMS. The transaction protocol consists of request messages, response messages, acknowledgement messages, and notification messages. "Accounting on Softwires", Bruno Stevant, 11-Oct-06, For access network operators, accounting information are crucial: they provide information for billing and give an overview of the traffic usage. This document defines the requirements for accounting information needed on Softwires. "A Keying hierarchy for managing Wireless Handover security", Madjid Nakhjiri, 16-Jan-07, The Problem of AAA-based key management for facilitating secure handovers in a wireless mobile environment as well as for optimizing re-authentications has been described in [I-D.nakhjiri-aaa-hokey-ps] and [I-D.clancy-hokey-reauth-ps]. This document provides a solution for the problems described in those drafts. Specifically an EAP initiated key hierarchy to significantly reduce handover and re- authentication latency is defined. A number of architectural and protocol trade-offs are also presented. Signaling messages, extensions and attributes for deploying the handover key hierarchy are shown in proactive and reactive modes. Document also proposes a method to solve channel binding problem. "Requirements for delivering MPLS Services Over L3VPN", Raymond Zhang, Kenji Kumaki, 1-Mar-07, This document describes Service Provider requirements for providing end-to-end MPLS TE LSPs over L3VPN. The main objective is to present a set of requirements which result in general guidelines for the definition, selection and specification of a technical solution addressing these requirements. Specification for this solution itself is out of scope in this document. "Methodologies for Scaling Server Load Balancing Environments", Zeeshan Naseh, 25-Jan-07, This document defines details of several design methodologies and current best practices for scaling server load balancing (a.k.a. content switching) environments in today’s enterprise data centers. The scenarios covered in this document covers utilization of protocols and technologies ranging from IPv4 routing to DNS for scalability of server load balancing. "Portable Symmetric Key Container", Apostol Vassilev, 22-Oct-06, This document specifies a shared secret token format for transport and provisioning of shared secrets (One Time Password (OTP) keys or symmetric cryptographic keys) to different types of strong authentication devices. The standard token format enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure. This work is a joint effort by the members of OATH (Initiative for Open AuTHentication) to specify a format that can be freely distributed to the technical community. The authors believe that a common and shared specification will facilitate adoption of two- factor authentication on the Internet by enabling interoperability between commercial and open-source implementations. "IPv6 Benchmarking Methodology", Chip Popoviciu, 11-Oct-06, The Benchmarking Methodologies defined in RFC2544 [1] are IP version independent however, they do not address some of the specificities of IPv6. This document provides additional benchmarking guidelines which in conjunction with RFC2544 will lead to a more complete and realistic evaluation of the IPv6 performance of network elements. "Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for Authorization of Early Media", Richard Ejzak, 2-Jan-07, This document describes a private Session Initiation Protocol (SIP) header (P-header) to be used by the European Telecommunications Standards Institute (ETSI) Telecommunications and Internet converged Services and Protocols for Advanced Networks (TISPAN) for the purpose of authorizing early media flows in Third Generation Partnership Project (3GPP) IP Multimedia Subsystems (IMS). This header is useful in any SIP network that is interconnected with other SIP networks and needs to control the flow of media in the early dialog state. "LowPan Neighbor Discovery Extensions", Samita Chakrabarti, Erik Nordmark, 8-Mar-07, IETF 6LowPan working group defines IPv6 over low-power personal area network (IEEE 802.15.4). IEEE 802.15.4 link layer does not have multicast support, although it supports broadcast. Due to the nature of LowPan network or sensor networks, broadcast messages should be minimized. This document suggests some optimizations to IPv6 Neighbor Discovery related multicast messages in order to reduce signaling in the low-cost low-powered network. "The Jabber-ID Header Field", Peter Saint-Andre, 27-Sep-06, This document defines a header field that enables a sender to include a Jabber Identifier in the header block of an email message for the purpose of associating the email message or sender with a particular Extensible Messaging and Presence Protocol (XMPP) address. "Authorization Policies for Preventing SPIT", Thomas Froment, 26-Feb-07, SPAM, defined as sending unsolicited messages to someone in bulk, might be a problem on SIP open-wide deployed networks. The responsibility for filtering or blocking calls can belong to different elements in the call flow and may depend on various factors. This document discusses mechanisms to establish policies to react on potentially unwanted communication attempts. These policies match a particular Session Initiation Protocol (SIP) communication pattern based on a number of attributes. The range of attributes includes information provided, for example, by the SIP itself, by the SIP identity mechanism, by information carried within SAML assertions (as introduced with SIP-SAML) and by the SPIT-SAML extensions. This document raises the question whether it is worth to investigate the aspect of authorization policy usage for SPIT prevention. If so, then the choice of a policy language for describing authorization policies and the details of the authorization policies becomes important. Mechanisms to create, modify and delete authorization policies that are stored in XML documents are already available with XCAP or WEBDAV and they could be reused. "BR Organization Mapping for the Extensible Provisioning Protocol (EPP)", Frederico Neves, Hugo Koji Kobayashi, 24-Aug-06, This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of .br organizational social information stored in a shared central repository. Specified in XML, this mapping extends the EPP contact mapping to provide additional features required for the provisioning of .br organizational social information. "Geodetic Shapes for the Representation of Uncertainty in PIDF-LO", Martin Thomson, 13-Dec-06, This document defines a set of shapes for the representation of uncertainty for PIDF-LO geodetic location information. This includes a GML profile and a schema that defines additional geometries. Further recommendations are made to restrict the use of geographic Coordinate Reference Systems (CRS) and units of measure restrictions that improve interoperability. "Encrypted Key Transport for Secure RTP", David McGrew, 5-Mar-07, SRTP Encrypted Key Transport (EKT) is an extension to SRTP that provides for the secure transport of SRTP master keys, Rollover Counters, and other information, within SRTCP. This facility enables SRTP to work for decentralized conferences with minimal control, and to handle situations caused by SIP forking and early media. "4over6 Transit using Encapsulation and BGP-MP Extension", Jianping Wu, 10-Sep-06, Due to the rapid deployment of IPv6 networks, especially IPv6 backbones, the existing long-live IPv4 networks are going to be connected to these IPv6 networks. In the environment that ISP hopes to use IPv6 backbones while still provides end users IPv4 access to support existing IPv4 applications, IPv4 traffic needs to be transported over IPv6 backbones. Along with the growth of IPv6 backbones, the number of IPv4 access networks increases and the IPv4/v6 interconnection topology becomes complex. Therefore, the existing manual configuration mechanism for a large number of end-2- end tunnels will cause an insufferable burden. This draft addresses this problem and presents a mechanism of automatic 4over6 tunnel-end discovery with BGP extensions. "3GPP2 Generic EAP Encapsulation (GEE) Protocol", Peter Barany, 7-Mar-07, The Extensible Authentication Protocol (EAP) is a general authentication protocol that supports multiple authentication methods and typically runs directly over data link layers without requiring IP. EAP can be used for different types of authentication, where multiple providers provide different services. However, EAP itself does not have the ability to differentiate between multiple EAP conversations between a peer and an authenticator. This document specifies the 3GPP2 Generic EAP Encapsulation (GEE) protocol for differentiating between multiple EAP conversations between a peer and an authenticator. "InterDomain-QOSM: The NSIS QOS Model to Fulfill the E2E QoS Control in the ITU-T RACF Functional Architecture", Jian Zhang, 7-Mar-07, This document has three goals. First of all, it presents our analysis of how to use the NSIS signaling (inter-domain QOSM and intra-domain QOSM) to fulfill the QoS control in accord with the ITU-T RACF functional architecture. For this goal, we discuss how the ITU-T RACF entities in the ITU-T RACF functional architecture can be mapped to the NSIS entities and how the RACF reference points can be implemented by using the NSIS protocol suites and QOSMs. Secondly, we aim at specifying an NSIS Inter-domain QOSM for E2E QoS control across heterogeneous IP networks and applying this Inter-domain QOSM to the e2e QoS control in the ITU-T RACF functional architecture based on the above ITU-T RACF analysis. The detailed description of the NSIS Inter-domain QOSM are given and the e2e QoS control scenarios in the ITU-T RACF architecture (including RACF Push and Pull resource control modes), which will be covered by the NSIS Inter-domain QOSM are described and implemented. Thirdly, we specify and implement those QSPECs that will be used by the Inter-domain QOSM for the e2e QoS control in the ITU-T RACF architecture. "Privacy Analysis for the SHIM6 protocol", Marcelo Bagnulo, 22-Oct-06, This note presents a privacy analysis for the SHIM6 protocol for IPv6 site multihoming support and the failure detection extensions for the SHIM6 protocol.This note does not attempt to provide a solution for providing SHIM6 protocol privacy. "Diameter Interoperability Test Suite", Victor Fajardo, 1-Feb-07, This document describes a collection of test cases to be used for Diameter base protocol and Diameter applications interoperability testing. "Automated key selection extension for the TCP Enhanced Authentication Option", Brian Weis, 1-Mar-07, This memo describes an automated key selection extension for the TCP [RFC0793] authentication option [I-D.bonica-tcp-auth]. This key selection extension allows two TCP endpoints to authenticate TCP segments using a Message Authentication Code (MAC) key chosen dynamically by an endpoint, rather than using a pre-configured MAC key. "Requirements for Management of Overload in the Session Initiation Protocol", Jonathan Rosenberg, 23-Oct-06, Overload occurs in Session Initiation Protocol (SIP) networks when proxies and user agents have insuffient resources to complete the processing of a request. SIP provides limited support for overload handling through its 503 response code, which tells an upstream element that it is overloaded. However, numerous problems have been identified with this mechanism. This draft summarizes the problems with the existing 503 mechanism, and provides some requirements for a solution. "The Effect of NATs on P2PSIP Overlay Architecture", Eric Cooper, Philip Matthews, 6-Mar-07, This paper explains the problems created by Network Address Translators (NATs) in Peer-to-Peer (P2P) overlays and recommends some NAT traversal techniques appropriate for P2PSIP networks. Two P2PSIP overlay architectures that accommodate the presence of NATs are described and analyzed. The first is the super-peer scheme used in a number of p2p file-sharing systems today. The second is a scheme where all peers play an equal role in the overlay. "IPv6 over Network based Mobile IPv4", Jay Navali, 25-Oct-06, There is a growing demand for routable IP addresses to support large wireless user base today. Wireless operators are looking for ways to leverage the IPv6 address space to meet the ever increasing number of wireless data users. The operators who have network based IPv4 mobility solutions can leverage the same scheme to provide mobility access service with larger address pool using IPv6 addressing. The proposed approach solves both, by allowing the provision of the mobility service, and the IPv6 address acquisition for the MN, either by the Access Router, or by the virtual link-layer through the Access Node. "DNSSEC Lookaside Validation (DLV)", Samuel Weiler, 7-Mar-07, DNSSEC Lookaside Validation (DLV) is a mechanism for publishing DNSSEC trust anchors outside of the DNS delegation chain. It allows resolvers to validate DNSSEC-signed data from zones whose ancestors either aren't signed or refuse to publish Delegation Signer (DS) records for their children. "A Policy Data Set for Flow Distribution", Koshiro Mitsuya, 8-Mar-07, The multiple care-of addresses registration protocol [1] allows a mobile node to maintain, at the same time, multiple virtual paths with its home agent or correspondent nodes. This document presents a policy data set for flow distribution to be used with the multiple care-of addresses registration protocol. This policy data set defines policies, in an OS-independant manner, for a mobile node and its home agent or correspondent node, from the point of view of one of these nodes. This data set is aimed to be processed by this node and the output is a set of filter rules to be used and exchanged with its correspondents. "Mobility Management using Proxy Mobile IPv4", Kent Leung, 11-Jan-07, Mobile IPv4 is a standard mobility protocol that enables IPv4 device to roam between networks. The mobile device has the Mobile IP function to signal its location to the routing anchor, known as the Home Agent. However, there are many IPv4 devices without such capability due to various reasons. This document describes a solution based on Proxy Mobile IPv4, which enables some other entity to provide mobility support on behalf of an unaltered and mobility- unaware IPv4 device. "Media Server Markup Language (MSML)", Adnan Saleem, Garland Sharratt, 24-Oct-06, The Media Server Markup Language (MSML) is used to control and invoke many different types of services on IP Media Servers. Clients can use it to define how multimedia sessions interact on a Media Server and to apply services to individuals or groups of users. MSML can be used, for example, to control Media Server conferencing features such as video layout and audio mixing, create sidebar conferences or personal mixes, and set the properties of media streams. As well, clients can use MSML to define media processing dialogs, which may be used as parts of application interactions with users or conferences. Transformation of media streams to and from users or conferences as well as IVR dialogs are examples of such interactions, which are specified using MSML. MSML clients may also invoke dialogs with individual users or with groups of conference participants using VoiceXML. "Guidelines for Implementing the Dialog Event Package in User Agents", Dale Worley, 13-Feb-07, This document sets out guidelines for how Session Initiation Protocol (SIP) user agents (UAs) should implement the dialog event package in order to be usable in systems that implement end-point controlled call-control (EPCC) features. The guidelines are in addition to the basic requirements for dialog event package implementation in RFC 3265 and RFC 4235. "PCC-PCE Communication Requirements for Point to Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE)", Seisho Yasukawa, Adrian Farrel, 26-Feb-07, The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs). Since P2MP TE LSP routes are sometimes complex to compute, and given the use of PCE in MPLS networks it is likely that PCE will be used in P2MP MPLS-TE networks. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in "Path Computation Element (PCE) Communication Protocol Generic Requirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements for point-to-multipoint MPLS traffic engineering. "PCC-PCE Communication Requirements for VPNs", Seisho Yasukawa, 7-Feb-07, The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. An important application of MPLS and GMPLS networks is Virtual Private Networks (VPNs) that may be constructed using Label Switched Paths (LSPs) in the MPLS and GMPLS networks as VPN tunnels. PCE may be applied as a tool to compute the paths of such tunnels in order to achieve better use of the network resources and to provide better levels of service to the VPN customers. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in "Path Computation Element (PCE) Communication Protocol Generic Requirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements that are specific to the application of PCE to VPNs. "An analysis of scaling issues in MPLS-TE backbone networks", Seisho Yasukawa, Adrian Farrel, 7-Mar-07, Traffic engineered Multiprotocol Label Switching (MPLS-TE) is deployed in providers' backbone networks. As providers plan to grow these networks, they need to discover whether existing protocols and implementations can support the network sizes that they are planning. This document presents an analysis of some of the scaling concerns for MPLS-TE backbone networks, and examines the value of two techniques for improving scaling. The intention is to motivate the development of appropriate deployment techniques and protocol extensions to enable the applicaiton of MPLS-TE in large networks. This document considers only scalability for point-to-point MPLS-TE. Point-to-multipoint MPLS-TE is for future study. "Supporting Multipoint-to-Point Label Switched Paths in Multiprotocol Label Switching Traffic Engineering", Seisho Yasukawa, 26-Feb-07, Traffic engineered Multiprotocol Label Switching (MPLS-TE) uses Resource Reservation Protocol traffic engineering extensions (RSVP-TE) as the signaling protocol to establish Label Switched Paths (LSPs). Although the Resource Reservation Protocol (RSVP) on which RSVP-TE is built supports the convergence of traffic flows toward a common destination, this concept has not been exploited in MPLS-TE which has been limited to point-to-point (P2P) and point-to-multipoint (P2MP) LSPs. This document describes extensions to RSVP-TE procedures and protocol elements to support multipoint-to-point (MP2P) LSPs. "Mobile IPv6 Location Privacy Solutions", Ying Qiu, 7-Nov-06, Mobile IPv6 [10] enables mobile nodes to remain reachable while roaming on the Internet. With its current specification, the location of a mobile node can be revealed and its movement can be tracked by simply monitoring its IP packets. In this document, we look into the MIP6 location privacy problem described in [14] and propose efficient and secure techniques to protect the location privacy of a mobile node. "Network Based Layer 3 Connectivity and Mobility Management for IPv6", Kuntal Chowdhury, Ajoy Singh, 26-Sep-06, The layer 3 connection and mobility management is essential in providing seamless access to services and enhanced user experience in a mobile and nomadic envoirnment. This document defines a mechanism via which service providers can deploy a managed layer 3 connectivity and mobility management scheme that is entirely based on the capabilities in the Network. "HIP Extensions for the Traversal of Network Address Translators", Vivien Schmitt, 19-Oct-06, This document specifies extensions to Host Identity Protocol (HIP) to support traversal of Network Address Translator (NAT) middleboxes. The traversal mechanism tunnels HIP control and data traffic over UDP and enables HIP initiators which MAY be behind NATs to contact HIP responders which MAY be behind another NAT. "Resource Unavailability (RU) Per Domain Behavior", Georgios Karagiannis, 20-Oct-06, This draft specifies a Per Domain Behavior that provides the ability to Diffserv nodes located outside Diffserv domain(s), e.g., receiver or other Diffserv enabled router to detect when the resources provided by the Diffserv domain(s) are not available. The unavailability of resources in the domain is monitored and detected by proportionally marking packets whenever the current link rate exceeds some pre-configured SLS agreed throughput (bandwidth) threshold. It is considered that the SLS agreed throughput threshold is not statically but loosely defined in order to allow a more efficient utilization of the Diffserv domain(s) and a simpler network management operation. This PDB can be applied in association with either a single Diffserv domain or multiple neighboring Diffserv domains, when a trust relationship exist between these multiple Diffserv domains. This specification is denoted as Resource Unavailability (RU) PDB and it follows the guidelines given in [RFC3086]. "Organizing IETF Process Change", Elwyn Davies, 13-Jun-06, This document sets out a strawman proposal for how to organize the revision and update of any part of the Internet Engineering Task Force (IETF) processes including those for developing standards and other specifications. It does not propose specific changes to any of these processes, which should be the subject of future documents. However, it does propose an initial target area for process change. "3G Wireless Support in the SIP/SDP Static Dictionary for Signaling Compression (SigComp)", Haseeb Akhtar, 12-Sep-06, While using SIGComp [4] based compression in SIP/SDP [5] [6], it is imperative to have access to a static dictionary to be used on the first SIP message that the compressor sends out. The session set up time can be reduced significantly if the compression rate of the first SIP message is considerably high. The existing static dictionary for SIP and SDP [2], however, does not include some wireless specific data elements. This document introduces these new data elements that are specific to various wireless access technologies. These new data elements are part of the first SIP message (i.e., originating SIP Invite) used to initiate a session. "New SIP Headers for Reducing SIP Message Size", Haseeb Akhtar, 12-Sep-06, Current SIP messages are text based and inherently large, especially when these messages are to be transmitted over the bandwidth-strained wireless access technologies (a typical orginiating SIP Invite is about 1200 bytes). For most wireless technologies, transmitting the session initiation messages (such as SIP Invite) over the signaling channel can reduce the call setup time substantially. The size limitation of these wireless signaling channels are typically very small (~210 bytes in the uplink and ~110 bytes in the downlink). To address this problem, a new function called Encoding Assitant (EA) has been introduced in the User Agent (UA) and in the SIP Proxy server within the network. Additionally, the method provided in this document defines new SIP option tags and headers. These new option tags and headers allow the UA and a SIP Proxy server within the network (such as the P-CSCF), to exchange information using the signaling channels supported by most wireless access networks. "GIST Extension for Hybrid On-path Off-path Signaling (HyPath)", Luís Cordeiro, 7-Mar-07, In a multi-domain Internet that offers QoS guaranties for applications, there is the need of signaling among the domain entities which are responsible for QoS management. Because different do the HyPath approach uses the NSIS protocol and interactions with the local routing protocols to achieve an off path signaling in hybrid environments. "Requirements for PW Security", Yakov Stein, 1-Mar-07, To date IETF's security suite has been entirely IP-centric, IPsec only being applicable to IP packets. This document addresses security requirements for MPLS pseudowires. We investigate security considerations arising from the PWE3 architecture, and discuss example threats, authentication, and confidentiality. "Datagram Transport Layer Security for Stream Control Transmission Protocol", Michael Tuexen, 23-Oct-06, This document describes the usage of the Datagram Transport Layer Security (DTLS) protocol over the Stream Control Transmission Protocol (SCTP). "Authorization for NSIS Signaling Layer Protocols", Jukka Manner, 7-Mar-07, Signaling layer protocols in the NSIS working group may rely on GIST to handle authorization. Still, the signaling layer protocol itself may require separate authorization to be performed when a node receives a request for a certain kind of service or resources. This draft presents a generic model and object formats for session authorization within the NSIS Signaling Layer Protocols. The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to coordinate actions between the signaling and transport planes. "Enhanced validation of domains for HTTP State Management Cookies using DNS", Yngve Pettersen, 26-Oct-06, HTTP State Management Cookies are used for a wide variety of tasks on the Internet, from preference handling to user identification. An important privacy and security feature of cookies is that their information can only be sent to a servers in a limited namespace, the domain. The variation of domain structures that are in use by domain name registries, especially the country code Top Level Domains (ccTLD) namespaces, makes it difficult to determine what is a valid domain, e.g. example.co.uk and example.no, which cookies should be permitted for, and a registry-like domain (subTLDs) like co.uk where cookies should not be permitted. This document specifies an imperfect method using DNS name lookups for cookie domains to determine if cookies can be permitted for that domain, based on the assumption that most subTLD domains will not have an IP address assigned to them, while most legitimate services that share cookies among multiple servers will have an IP address for their domain name to make the user's navigation easier by omitting the customary "www" prefix. "The TLD Subdomain Structure Protocol and its use for Cookie domain validation", Yngve Pettersen, 26-Oct-06, This document defines a protocol and specification format that can be used by a client to discover how a Top Level Domain (TLD) is organized in terms of what subdomains are used to place closely related but independent domains, e.g. commercial domains in country code TLDs (ccTLD) like .uk are placed in the registry-like .co.uk subTLD domain. This information is then used to limit which domains an Internet service can set cookies for, strengthening the rules already defined by the cookie specifications. "Flow Bindings in Mobile IPv6 and Nemo Basic Support", Hesham Soliman, 9-Mar-07, This document introduces extensions to Mobile IPv6 [1] and Nemo Basic Support [2] that allow nodes to bind one or more flows to a care-of address. These extensions allow multihomed nodes to take full advantage of the different properties associated with each of their interfaces. "ZRTP: Media Path Key Agreement for Secure RTP", Philip Zimmermann, 7-Mar-07, This document defines ZRTP, a protocol for media path Diffie-Hellman exchange to agree on a session key and parameters for establishing Secure Real-time Transport Protocol (SRTP) sessions. The ZRTP protocol is media path keying because it is multiplexed on the same port as RTP and does not require support in the signaling protocol. ZRTP does not assume a Public Key Infrastructure (PKI) infrastructure or require the complexity of certificates in end devices. For the media session, ZRTP provides confidentiality, protection against Man in the Middle (MITM) attacks, and, in cases where a secret is available from the signaling protocol, authentication. ZRTP can utilize two Session Description Protocol (SDP) attributes to provide discovery and authentication through the signaling channel. To provide best effort SRTP, ZRTP utilizes normal RTP/AVP profiles. "A Federation based VoIP Peering Architecture", Otmar Lendl, 10-Sep-06, This document defines the federation concept and proposes a peering and routing architecture for SIP-based applications. Federations can be used to establish selective peerings e.g. in the Voice over IP and Instant Messaging space. Service providers may announce federation membership as domain attributes. This document contains the policy- type definition for federations within the Domain Policy DDDS Application. "OSPF MPR Extension for Ad Hoc Networks", Emmanuel Baccelli, 8-Mar-07, This document specifies an OSPFv3 interface type tailored for mobile ad hoc networks. This interface type is derived from the broadcast interface type, enhanced with MANET techniques based on multi-point relaying (MPR). "ECMQV Ciphersuites for TLS", Robert Dugal, Brian Minard, 18-Oct-06, This document describes the changes necessary to permit Transport Layer Security (TLS) to support the Elliptic Curve Menezes-Qu- Vanstone Key Agreement (ECMQV). "Address Autoconfiguration for Hybrid Mobile Ad Hoc Networks", Ilkyun Park, 25-Oct-06, Most of current address autoconfiguration mechanisms for MANET introduce significant load like message flooding, or are dependent on the underlying routing protocols. This document proposes a new mechanism that is intended to minimize these drawbacks. It is also designed to be applicable for hybrid MANET, where a MANET is connected to Internet through one or more Interet gateways. "A New Forking Mechanism for Session Initiation Protocol (SIP)", Dale Worley, 13-Feb-07, The rules for SIP proxies are organized so that when a UAC sends an out-of-dialog request, even if the request is forked to a number of UASs, (usually) only one UAS will accept the request, and only the final response from that UAS will be returned to the UAC. This forking mechanism is optimal for an INVITE intended to connect one human user with another human uses, but is poor for requests that have a "one to many" nature, especially PUBLISH and SUBSCRIBE requests, but also including some INVITEs. This document proposes an alternative forking mechanism that better supports "one to many" requests, and that mechanism be the standardized meaning of the (existing but weakly specified) "Request-Disposition: no-cancel, parallel" header. "A simple heuristic for handover decisions in WLANs", Shigeru Kashihara, 8-Mar-07, This document discusses handover decision criteria for avoiding deterioration in communication quality during WLAN handover, in particular at handover initiation. We first describe problems for handover decision criteria employed by existing mobility management technologies, such as Mobile IP and mSCTP. We then propose the number of frame retransmissions as a simple heuristic for handover decisions and discuss its advantages and disadvantages. In addition, we introduce our proposed method using the number of frame retransmissions. "Datagram Transport Layer Security (DTLS) Protocol for Protection of Media Traffic Established with the Session Initiation Protocol", Jason Fischl, 8-Mar-07, This document specifies how to use the Session Initiation Protocol (SIP) to establish secure media sessions using or over the Datagram Transport Layer Security (DTLS) protocol. It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the key that will be presented during the DTLS handshake. It relies on the SIP identity mechanism to ensure the integrity of the fingerprint attribute. This allows the establishment of media security along the media path. "Session Description Protocol (SDP) Indicators for Datagram Transport Layer Security (DTLS)", Jason Fischl, Hannes Tschofenig, 6-Mar-07, This specification defines how to use the Session Description Protocol (SDP) to signal that media will be transported over Datagram Transport Layer Security (DTLS) or where the SRTP security context is established using DTLS and. It reuses the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate which will be presented during the DTLS handshake. "DNSSEC Validator API", Abhijit Hayatnagarkar, Suresh Krishnaswamy, 9-Jan-07, The DNS Security Extensions (DNSSEC) provide origin authentication and integrity of DNS data. However, the current resolver Application Programming Interface (API) does not allow a security-aware resolver to communicate detailed results of DNSSEC processing back to the application. This document describes an API between applications and a validating security-aware stub resolver that allows applications to control the validation process and obtain results of DNSSEC processing. "Mobile IPv6 Bootstrapping for the Authentication Option Protocol", Vijay Devarapalli, 2-Mar-07, The current Mobile IPv6 bootstrapping mechanisms require the use of IKEv2 between the mobile node and the home agent. If the Mobile IPv6 signaling messages are protected by the mobility option authentication protocol, then the bootstrapping mechanism based on IKEv2 cannot be used. This document describes bootstrapping mechanisms for Mobile IPv6 when the mobility option authentication protocol is used. "Secure Neighbor Discovery (SEND) Optimization and Adaptation for Mobility: The OptiSEND Protocol", Wassim Haddad, 26-Oct-06, This memo describes a new set of mechanisms, which aims to increase the Secure Neighbor Discovery (SEND) protocol usability by reducing the required processing power on small devices and adapting it to mobile environment requirements while maintaining its efficiency. "Firewall friendly RTT for MIPv6", Gabor Bajko, 25-Oct-06, Firewalls represent an integral part of today's IP networks, currently based on IPv4 technology. Deployment of IPv6 is under way, and firewall vendors will need to deploy firewalls which will be able to handle IPv6 packets, including its many extensions. Mobile IPv6, standardized in RFC3775, specifies a number of extensions and procedures to IPv6, which do not work when firewalls are on the data communication path [1]. This document defines a slightly modified Return Routability Test (RRT) for MIPv6 [2]. The new method is firewall friendly and allows a mobile node to send Binding Update message to its correspondent node (so that Route Optimization can be applied) and ensures that the CN receives the Binding Update, even when either the mobile node, the CN, or both are located behind firewalls. "Pseudo Wires over Provider Backbone Transport", David Allan, 2-Feb-07, This memo describes architecture and procedures for the operation of pseudo wires over provider backbone transport (PBT). "SIP Extensions for SPIT identification", Saverio Niccolini, 23-Feb-07, This memo analyzes the need for SIP extensions for SPIT (Spam Over Internet telephony) identification. This memo describes requirements and gives an overview of possible solutions to send feedback information using the SIP protocol for the scope of SPIT. Feedback information from the users to the SPIT identification system (e.g., working closely with the callee's SIP proxy server) are important for SPIT detection and prevention. The overall SPIT protection systems on the internet will benefit from such information. The basic idea is that each user who receives a SPIT session request, will send a feedback to SPIT identification system (for example, using a button on the user interface of the client). Information could be also exchanged among domains and/or servers in order to increase effectiveness of SPIT detection systems. The idea is that SIP proxy servers and/or B2BUAs include SPIT likeliness estimations (based on some knowledge they have which is out of the scope of this draft) as additional message headers (e.g. INVITE headers) when forwarding such messages to other domains. This memo identifies the parameters that the SPIT identification system may need in order to detect abusive behaviors; moreover it proposes an overview of technical solutions how such information can be sent back to the SPIT identification system by means of the SIP protocol. The memo also addresses the technical solutions on how forward information could be passed among domains as well as how communication initiation could be denied to users (e.g. blacklisted ones). "Diameter Quality of Service Application", Frank Alfano, 20-Oct-06, This document describes a Diameter application that performs Authentication, Authorization, and Accounting for Quality of Service (QoS) reservations. This protocol is used by elements along the path of a given application flow to authenticate a reservation request, ensure that the reservation is authorized, and to account for resources consumed during the lifetime of the application flow. Clients that implement the Diameter QoS application contact an authorizing entity/application server that is located somewhere in the network, allowing for a wide variety of flexible deployment models. "Examples call flow in race condition on Session Initiation Protocol", Miki Hasebe, 24-Oct-06, This document gives examples of Session Initiation Protocol (SIP) call flows in race condition. Call flows in race conditions are confusing and this document shows the best practices to handle them. The elements in these call flows include SIP User Agents and SIP Proxies. Call flow diagrams and message details are shown. "An Evaluation of Session Initiation Protocol (SIP) for use in Streaming Media Applications", Steven Whitehead, 23-Oct-06, This draft summarizes a set of use-cases and their associated requirements that suggest a convergence between the Session Initiation Protocol (SIP) [2] and the Real Time Streaming Protocol (RTSP and RTSP v2) [3] and [4] that may be beneficial for streaming media applications. This benefit is especially apparent in the context of converged/blended media services. "A URN Namespace for the Name Identification Service", Kyung Soo Ham, 22-Dec-06, This document describes URN namespace for Name Identification Service enabling users to conveniently access such digital resources as e-book, music, moving picture, image, home page, blog page on the world wide web using such simple names as title of contents, author, organization name, blog name, etc. and receive relevant information services. "A Conference Control Package for the Session Initiation Protocol (SIP)", Chris Boulton, 6-Mar-07, This document defines a Session Initiation (SIP) Control Package for Conference Control. The control of Media Servers and their related resources in decomposed network architectures plays an important role in various Next Generation Networks. This Control Package aims to fulfill Conferencing requirements using the SIP Control Framework. "A VoiceXML Interactive Voice Response (IVR) Control Package for the Session Initiation Protocol (SIP)", Chris Boulton, 7-Mar-07, This document defines a Session Initiation (SIP) Control Package for Interactive Voice Response (IVR) interaction using VoiceXML. This Control Package provides IVR functionality using the SIP Control Framework and extends the Basic IVR control package with support for VoiceXML dialogs. "MANET Generalized Location Signaling Format", Jerome Haerri, 25-Oct-06, This document decribes a generalized format for transmitting mobility information, which MAY be used by mobile ad hoc network routing and other protocols. "Survey of Research towards Robust Peer-to-Peer Networks: Search Methods", John Risson, Tim Moors, 5-Mar-07, The pace of research on peer-to-peer (P2P) networking in the last five years warrants a critical survey. P2P has the makings of a disruptive technology - it can aggregate enormous storage and processing resources while minimizing entry and scaling costs. Failures are common amongst massive numbers of distributed peers, though the impact of individual failures may be less than in conventional architectures. Thus the key to realizing P2P's potential in applications other than casual file sharing is robustness. P2P search methods are first couched within an overall P2P taxonomy. P2P indexes for simple key lookup are assessed, including those based on Plaxton trees, rings, tori, butterflies, de Bruijn graphs and skip graphs. Similarly, P2P indexes for keyword lookup, information retrieval and data management are explored. Finally, early efforts to optimize range, multi-attribute, join and aggregation queries over P2P indexes are reviewed. Insofar as they are available in the primary literature, robustness mechanisms and metrics are highlighted throughout. However, the low-level mechanisms that most affect robustness are not well isolated in the literature. Recommendations are given for future research. "Optimizations to Secure Connectivity and Mobility", Meghana Sahasrabudhe, Vijay Devarapalli, 20-Oct-06, Users that need to connect to their enterprise network from an untrusted network require secure connectivity and mobility. Enterprise users are increasingly using mobile nodes. A user may need to connect to the enterprise network from anywhere, and in a number of scenarios, from untrusted networks. There are existing specifications developed by the Mobile IPv4 working group that describe solutions for enterprise secure connectivity and mobility. This document proposes optimizations to those solutions to reduce the tunneling overhead and allow for a number of new access modes. "NETCONF over TLS", Mohamad Badra, 1-Dec-06, The NETCONF configuration protocol provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use TLS to secure NETCONF exchanges. "Handling Normative References for Standards Track Documents", Sam Hartman, John Klensin, 13-Feb-07, The IETF and RFC Editor have a long-standing rule that a document at a given maturity level cannot be published until all documents it references as normative are at that maturity level or higher. This rule has sometimes resulted in very long publication delays for documents and some claims that it was a major obstruction to advancing documents in maturity level. The IETF agreed to a way to bypass this rule with RFC 3967. This document replaces the "hold on normative reference" rule will be replaced by a "note downward normative reference and move on" approach. RFC 3967 is also updated to encourage annotations to be added when that procedure is applied. "Fast Initial OSPFv2 LSDB Synchronization for BMA", Mitchell Erblich, 27-Mar-06, This memo documents a feature that significantly decreases the initial LSDB synchronization time in Broadcast Multiple Access (BMA) environments. This implementation only requires a single OSPF speaker per psuedo-node to support this functionality. These changes are implicitly supported within the OSPFv2 protocol. This memo is not intended to serve as a model for any other implementation. "Access Right Distribution Protocol (ARDP)", Alexandre Cassen, 28-Sep-06, This document describes a protocol to securely distribute service access rights to IPTV customers using multicast over a national backbone. The protocol typically runs on any piece of equipments to locally store owned customers TV service access right. This design provides access control at edge level. "Backbone Infrastructure Attacks and Protections", Pekka Savola, 16-Jan-07, A number of countermeasures for attacks against service provider backbone network infrastructure have been specified or proposed, each of them usually targeting a subset of the problem space. There has never been a more generic analysis of the actual problems, and which countermeasures are even necessary (and where). This document tries to provide that higher-level view. "IPv4 Reassembly Errors at High Data Rates", John Heffner, 26-Jan-07, IPv4 fragmentation is not sufficiently robust for use under some conditions in today's Internet. At high data rates, the 16-bit IP identification field is not large enough to prevent frequent incorrectly assembled IP fragments, and the TCP and UDP checksums are insufficient to prevent the resulting corrupted datagrams from being delivered to higher protocol layers. This note describes some easily reproduced experiments demonstrating the problem, and discusses some of the operational implications of these observations. "Limited IP Header Compression over PPP", Janusz Jurski, 8-Mar-07, The negotiation options specified in RFC 2509 defined an all-or-nothing strategy for applying header compression: peers were assumed to support compression for any combination of headers. [RFC3544] refined that strategy to make it possible to negotiate header compression for only TCP or only non-TCP packets (and also added Enhanced RTP-Compression negotiation option). The current document further refines the strategy by also making it possible to negotiate header compression for only particular combinations of headers or header types. "Domain Certificates in the Session Initiation Protocol (SIP)", Vijay Gurbani, 8-Mar-07, This document attempts to clarify the use of domain certificates in the Session Initiation Protocol (SIP). "Definitions of Managed Objects for the DS1, J1, E1, DS2 and E2 Interface Types", Orly Nicklass, 24-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 objects used for managing DS1, J1, E1, DS2 and E2 interfaces. This document is a companion to the documents that define Managed Objects for the DS0, DS3/E3 and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Types. This document obsoletes RFC 3895. "MPLS Benchmarking Methodology", Rajiv Asati, Aamer Akhter, 11-Dec-06, The purpose of this draft is to describe a methodology specific to the benchmarking of MPLS imposition, forwarding and disposition devices. The scope of this benchmarking will be limited to various types of packet-forwarding and delay measurements. It builds upon the tenets set forth in RFC2544, RFC1242 and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts into the MPLS paradigm. The BMWG produces two major classes of documents: Benchmarking Terminology documents and Benchmarking Methodology documents. The Terminology documents present the benchmarks and other related terms. The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents. "Authenticating FMIPv6 Handovers", Wassim Haddad, Suresh Krishnan, 26-Sep-06, This document specifies a scheme to secure the handover signaling in FMIPv6 using one way hash chains. The values generated in a one way hash chain will be used one at a time during each handoff to authenticate the signaling messages. "MANET Local IPv6 Addresses", Christophe Jelger, 6-Oct-06, This document defines how Unique Local IPv6 Unicast Addresses (RFC- 4193) can be used in wireless mobile ad hoc networks (MANETs) as MANET Local IPv6 Addresses (MLAs). MLAs are intended to be used inside a MANET and are not expected to be routable on the global Internet. Each MANET router is expected to generate its MLA locally without any coordination with other MANET routers. "A Uniform Resource Name (URN) Namespace for the International Organization for Standardization (ISO)", J Goodwin, 27-Dec-06, This document describes a Uniform Resource Name Namespace Identification (URN NID) for the International Organization for Standardization (ISO). This URN NID is intended for use for the identification of persistent resources published by the ISO standards body (including documents, document metadata, extracted resources such as standard schemata and standard value sets, and other resources). "Independent Submissions to the RFC Editor", John Klensin, 22-Dec-06, There is a long-term tradition in the Internet community, predating the IETF by many years, of use of the RFC series to publish materials that are not rooted in the IETF standards process and its review and approval mechanisms. These documents, known as "independent submissions", serve a number of important functions for the Internet community, both inside and outside of the community of active IETF participants. This document discusses the independent submission model and some reasons why it is important. It then describes editorial and processing norms that can be used for independent submissions as the community goes forward into new relationships between the IETF community and its primary technical publisher. "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", Vishwas Manral, 17-Jan-07, The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Encapsulating Security Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPsec Security Association (SA). To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to- implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time. "Telnet START-TLS Option", Jeffrey Altman, 15-Dec-06, Telnet service has long been a standard Internet protocol. However, a standard way of ensuring privacy and integrity of Telnet sessions has been lacking. This document proposes a standard method for Telnet servers and clients to use the Transport Layer Security (TLS) protocol. It describes how two Telnet participants can decide whether or not to attempt TLS negotiation, and how the two participants should process authentication credentials exchanged as a part of TLS startup. "Telnet Authentication Option", Jeffrey Altman, 15-Dec-06, This document describes the authentication option to the Telnet protocol, RFC 854, as a generic method for negotiating an authentication type and mode including whether encryption should be used and if credentials should be forwarded. While this document summarizes currently utilized commands and types it does not define a specific authentication type. Separate documents are to be published defining each authentication type. This document updates a previous specification of the Telnet authentication option, RFC 2941, to allow the AUTHENTICATION option to be used in conjunction with the START_TLS option, RFC XXXX. "Telnet Authentication: Kerberos Version 5", Jeffrey Altman, 15-Dec-06, This document describes how Kerberos Version 5 [RFC 4120] is used with the Telnet protocol [RFC 854]. It describes an Telnet Authentication suboption to be used with the Telnet Authentication option [RFC YYYY]. This mechanism can also used to provide keying material to provide data confidentiality services in conjunction with the Telnet Encryption option [RFC 2946]. This document updates a previous specification of the Telnet Authentication Kerberos 5 method, RFC 2942 [4], to allow Kerberos 5 Telnet authentication to be used in conjunction with the START_TLS option [RFC XXXX]. "Telnet Authentication: SRP", Jeffrey Altman, 18-Dec-06, This document specifies an authentication scheme for the Telnet protocol [RFC 854] under the framework described in [RFC YYYY], using the Secure Remote Password Protocol (SRP) authentication mechanism. The specific mechanism, SRP-SHA1, is described in [RFC2945]. This document updates a previous specification of the Telnet Authentication SRP method, RFC 2944, to allow SRP Telnet authentication to be used in conjunction with the Telnet START_TLS option [RFC YYYY]. "Gap analysis on the EAP keying hierarchy", Vidya Narayanan, Lakshminath Dondeti, 25-Oct-06, The extensible authentication protocol (EAP) keying framework [1] leaves out guidelines for using the extended master session key (EMSK) for future discussion and specification. While the keying framework does provide guidance for EAP master session key (MSK) usage, some SDOs use that key in a non-compliant manner. This document provides a description and analysis of MSK and EMSK usage and provides an outline for a discussion on these topics. "Experiences from Using Unicast RPF", Pekka Savola, 16-Nov-06, RFC 3704 (BCP 84) published in March 2004 provided an ingress filtering technique update to RFC 2827 (BCP 38). This memo tries to document operational experiences learned practising ingress filtering techniques, in particular ingress filtering for multihomed networks. "Using Self-Delimiting Numeric Values in Protocols", Wesley Eddy, 11-Dec-06, Self-Delimiting Numeric Values (SDNVs) have recently been introduced as fields used in proposed Delay-Tolerant Networking protocols. The basic goal of an SDNV is to hold a non-negative integer value of arbitrary magnitude, without consuming much more space than necessary. The primary motivation is to conserve the bits sent across low-capacity or energy-intensive links typical of NASA deep- space missions, with a secondary goal of allowing the protocol to automatically adjust to unforseen usage scenarios. This can be desirable in that it allows protocol designers to avoid making difficult and potentially erroneous engineering decisions that may have to be hacked around in the future. This document describes formats and algorithms for SDNV encoding and decoding, and discusses implementation and usage of SDNVs. "The EAP-TLS-PSK Authentication Protocol", Thomas Otto, Hannes Tschofenig, 2-Mar-07, The Extensible Authentication Protocol (EAP), defined in RFC 3748, is a network access authentication framework which provides support for multiple authentication methods. One proposal is EAP-TLS, which relies on the Transport Layer Security (TLS) protocol and allows for certificate-based authentication. This document specifies EAP-TLS- PSK, which also relies on TLS, but allows for shared secret-based authentication. EAP-TLS-PSK supports the pre-shared key ciphersuites specified in RFC 4279. specified in RFC 4279. "CEQMM: A Complete and Efficient Quality of service Model for MANETs", Hakim Badis, 6-Oct-06, This draft specifies CEQMM, a Complete and Efficient Quality of Service (QoS) Model for MANETs which combines the positive aspects of both IntServ and DiffServ. It uses a hybrid per-flow and per-class provisioning scheme. In such a scheme, traffic of highest priority is given per-flow provisioning while other priority classes are given per-class provisioning. To offer this scheme and to ensure that certain packets receive higher priority transmission than other packets, priority classifier, active queue management and packet scheduler are integrated. CEQMM applies the QOLSR protocol to support multiple-metric routing criteria and to respond quickly when changes in topology and/or QoS conditions are detected. Once a path is chosen for one QoS flow, CEQMM performs call admission control (CAC) at each intermediate node. For only QoS flows of highest priority, a node can precede to soft and later hard bandwidth reservation on links during the CAC process. CEQMM implements congestion avoidance mechanisms to prevent a network from entering the congested state. However, in MANETs, network congestion can still occur frequently under mobility. In order to prevent performance degradation due to mobility-triggered congestion, CEQMM uses congestion control scheme based on: (i) rated control of best-effort traffic, (ii) path selection for best-effort traffic, (iii) next hop maintaining for each QoS class (except the high-priority class), (iv) active queue management and (v) backoff timer method. "ODETTE File Transfer Protocol 2.0", Ieuan Friend, 29-Sep-06, This memo updates the ODETTE File Transfer Protocol, an established file transfer protocol facilitating electronic data interchange of business data between trading partners, to version 2.0. The protocol now supports secure and authenticated communication over the Internet using Transport Layer Security, provides file encryption, signing and compression using Cryptographic Message Syntax and provides signed receipts for the acknowledgement of received files. The protocol supports both direct peer to peer communication and indirect communication via a Value Added Network and may be used with TCP/IP, X.25 and ISDN based networks. "DHCPv6 Relay Agent Echo Request Option", Shengyou Zeng, 8-Mar-07, 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. "MIKEY General Extension Payload for OMA BCAST LTKM/STKM Transport", Lakshminath Dondeti, 7-Feb-07, This document specifies a new MIKEY General Extension payload [1] to transport the short term key message (STKM) and long term key message (LTKM) payloads defined in the Open Mobile Alliance's (OMA) Browser and Content (BAC) Broadcast (BCAST) group's Service and Content protection specification. "Unicode Format for Network Interchange", John Klensin, Michael Padlipsky, 5-Mar-07, The Internet today is in need of a standardized form for the transmission of internationalized "text" information, paralleling the specifications for the use of ASCII that date from the early days of the ARPANET. This document specifies that format, using UTF-8 with specification of normalization and specific line-ending sequences. "The CIDR Network Descriptor expands the size of the IPtX Address Space beyond the IPv6 IP Addressing Specification", Eugene Terrell, 8-Mar-07, This document, which Obsoletes RFC 2373, RFC 1517, RFC 1518, RFC 1519, and IEEE Specification 1541-2002 (Re-defining the Electromagnetic Spectrum and the 'SI Units' as a Base 2 Exponential Binary Conversion), provides the final clarification of the conclusions that redefines the 'CIDR' notation as the 'Network Descriptor', and proves that the IP Address Pool Total for the IPtX Specification is greater than IPv6. And more importantly, because these conclusions reveal the actual design of the Binary Communication System, the Revolutionary impact sustained, is an upheaval affecting the entire field of Computer Science. In other words, IPtX is a more powerful and cost effective IP Addressing Specification, and when using the 'IPtX-MX Protocol' {'2"X : 1'; the Compression Ratio for "The Intelligent Quantum Tunneling Worm Protocol" - The Design of the 'Internet Protocol telecommunications Xchange Specification'}, the interface of the "Front-End" can mimic or simulate a 32 Bit-Mapped IP Address. And this, in conjunction with the IPv4 IP Addressing Overlay, provides a 100% Backward Compatibility with the IPv4 Specification, in the Backbone environment approaching an unlimited size 'Bit-Map' Address Space. "The Mathematics of Quantification, and the Rudiments Of the Ternary Logical States of the Binary Systems", Eugene Terrell, 28-Dec-06, This paper, opening with the historical that documents the source of the Binary Enumeration Error, utilizes the proof of 'Fermat's Last Theorem' (Normative References - [1], [2] and [3]), the Mathematics of Quantification, and the Logic of Set Theory, to prove that the Binary System represents an Alternate Mathematical Field, which is Closed and Finite. That is, using the Elementary Laws of Algebra, with the Basic Principles from Analytic Geometry, provides the final clarification simplifying the proof for the correction of the Counting Errors and the Logical Foundation for the New Binary System. And more importantly, this also establishes the basic foundational principles for 3 State Ternary Logic. In other words, using an askew, or mathematically incorrect Binary System, defined as the misinterpretation of ZERO, sustains the Counting Error (an Accumulating Propagation) levying a substantial loss of IP Addresses in the IPv4 IP Specification, affecting as well, the Address Pool Total for the IPv6 Specification. Hence, from the foregoing foundation an unquestionable proof concludes; the Elementary Mathematical 'Resolution of the Counting Error in the Binary System' - [4. IANA Considerations]. "OSPF Version 2 MIB for Multi-Topology (MT) Routing", Namita Rawat, 28-Sep-06, This memo defines an extension to the Open Shortest Path First version 2 Management Information Base (OSPFv2 MIB) for use with network management protocols in the Internet community. In particular it describes objects and lists considerations for the management of OSPF Multi-Topology routing. At present, the OSPF Multi-Topology extensions are defined within a standards track internet draft [5]. "SNMP Traffic Measurements and Trace Exchange Formats", Juergen Schoenwaelder, 26-Jan-07, The Simple Network Management Protocol (SNMP) is widely deployed to monitor, control and configure network elements. Even though the SNMP technology is well documented, it remains relatively unclear how SNMP is used in practice and what typical SNMP usage patterns are. This document proposes to carry out large scale SNMP traffic measurements in order to develop a better understanding how SNMP is used in real world production networks. It describes the motivation, the measurement approach, and the tools and data formats needed to carry out such a study. "Network Localized Mobility Management using DHCP", Fred Templin, 22-Oct-06, Mobile nodes require a means to automatically configure globally routable IP addresses/prefixes that remain stable across localized mobility events. This document specifies mechanisms for network localized mobility management (NETLMM) using the Dynamic Host Configuration Protocol (DHCP). Solutions for both IPv4 and IPv6 are given. "Requirements on I-D Tracker Extensions for Working Group Chairs", Henrik Levkowetz, Allison Mankin, 8-Feb-07, This document describes the changes required to make it possible for working group chairs to update the I-D tracker during document shepherding, after the request for publication. It also describes additional requirements for the chairs to use the I-D tracker for managing WG documents from their earliest stages. Having the tracker support the working groups more fully is a primary benefit, but in addition, this moves towards the goal of providing an integrated view of document states from -00 to RFC publication. "Requirements on I-D Tracker Extensions for IAB and IRTF Document Shepherds", Henrik Levkowetz, 8-Feb-07, This document describes the states which need to be added to the I-D tracker to make it possible for IAB and IRTF document shepherds (whoever the IAB and IRTF designate, e.g. the IAB Chair, RG Chairs) to update the I-D tracker during document shepherding. It is a companion document of draft-proto-wgchair-tracker-ext which describes additional requirements for the chairs to use the I-D tracker for managing WG documents from their earliest stages. "Extensions to CT-KIP to support one- and two-pass key initialization", Magnus Nystroem, Salah Machani, 16-Oct-06, This document describes extensions to the Cryptographic Token Key Initialization Protocol (CT-KIP) to support one-pass (i.e. one message) and two-pass (i.e. one round-trip) cryptographic token key initialization. "Requirements for Web Authentication Resistant to Phishing", Sam Hartman, 6-Mar-07, This memo proposes requirements for protocols between web identity providers and users and for requirements for protocols between identity providers and relying parties. These requirements minimize the likelihood that criminals will be able to gain the credentials necessary to impersonate a user or be able to fraudulently convince users to disclose personal information. To meet these requirements browsers must change. Websites must never receive information such as passwords that can be used to impersonate the user to third parties. Browsers should perform mutual authentication and flag situations when the target website is not authorized to accept the identity being offered as this is a strong indication of fraud. "A URN Namespace for GEANT", Tomaz Kalin, Maurizio Molina, 29-Nov-06, This document describes a proposed URN (Uniform Resource Name) namespace that would be managed by DANTE, representing European Research and academic networks, for naming persistent resources defined by GEANT, the Consortium of European R&E networks, its projects, activities, working groups and other designated subordinates. "SIP End-to-End Performance Metrics", Daryl Malas, 22-Jan-07, This document defines a set of metrics and their usage to evaluate the performance of end-to-end Session Initiation Protocol (SIP) based services in both production and testing environments. The purpose of this document is to combine a set of common metrics, allowing interoperable performance measurements, easing the comparison of industry implementations. "Procedures for SCTP, TCP, and UDP Port Assignments by IANA", Eliot Lear, 25-Oct-06, Amongst other things the IANA manages port assignments for TCP, UDP, and SCTP protocols. This document specifies the procedure by which those assignments take place. The distinction between so-called "well known ports" and other public static assignments is deprecated, the use of SRV records is encouraged, and documentation of port use is strongly encouraged. "The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header)", Jani Hautakorpi, Gonzalo Camarillo, 24-Jan-07, This document specifies the Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header). This P-Header is used in the Open Mobile Alliance's (OMA) Push to talk over Cellular (PoC) system. It enables URI-list servers to refuse the handling of an incoming URI-list, which has an embedded URI-list inside it. This P-Header also makes it possible for the URI-list server to inform the client about the embedded URI-list that caused the rejection and the individual URIs that form such a URI-list. "Identity Protection within EAP-TLS", Pascal Urien, Mohamad Badra, 19-Oct-06, This document defines a mechanism that ensures EAP-TLS identity protection. The main idea is to encrypt the client's certificate. Three procedures are proposed in order to determine the certificate encryption mechanism, - Implicit, the client's certificate is encrypted according to a pre-defined algorithm, deduced from the server's certificate. - Notified, the EAP-identity response message, delivered by the client includes information that precise the encryption algorithm to be used. - Negotiated, the client indicates a list of encryption algorithm, the server chooses one of them, and indicates its choice. "The Session Initiation Protocol (SIP) P-Profile-Key Private Header (P-Header)", Gonzalo Camarillo, German Blanco, 18-Sep-06, This document specifies the SIP P-Profile-Key P-header. This header field is used in the 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) to provide SIP registrars and SIP proxy servers with the key of the profile corresponding to the destination SIP URI of a particular SIP request. "Data format and interface to an external peer-to-peer network for SIP location service", Kundan Singh, Henning Schulzrinne, 4-Dec-06, This document describes the data format and interface to an external peer-to-peer (P2P) protocol for use as a location service in the Session Initiation Protocol (SIP)-based Internet telephony. "TCP Response to Lower-Layer Connectivity-Change Indications", Simon Schuetz, 7-Mar-07, When the path characteristics between two hosts change abruptly, TCP can experience significant delays before resuming transmission in an efficient manner or TCP can behave unfairly to competing traffic. This document describes TCP extensions that improve transmission behavior in response to advisory, lower-layer connectivity-change indications. The proposed TCP extensions modify the local behavior of TCP and introduce a new TCP option to signal locally received connectivity-change indications to remote peers. Performance gains result from a more efficient transmission behavior and there is no difference in aggressiveness in comparison to a freshly-started connection. "Terminology for Benchmarking SIP Networking Devices", Scott Poretsky, 26-Oct-06, This document provides a terminology for benchmarking SIP performance in networking devices. Terms are included for test components, test setup parameters, and performance benchmark metrics for black-box benchmarking of SIP networking devices. The Performance Benchmark Metrics are obtained for the SIP Control Plane and Media Plane. The terms are intedned for use in a companion Methodology document for complete performance characterization of a device in a variety of network conditions making it possible to compare performance of different devices. It is critical to provide Test Setup Parameters and a Methodology document for SIP performance benchmarking because SIP allows a wide range of configuration and operational conditions that can influence performance benchmark measurements. It is necessary to have terminology and methodology standards to ensure that reported benchmarks have consistent definition and were obtained following the same procedures. Benchmarks can be applied to compare performance of a variety of SIP networking devices. "OTP Kerberos", Gareth Richards, 11-Oct-06, The Kerberos protocol provides a framework authenticating a client using the exchange of pre-authentication data. This document describes the use of this framework to carry out One Time Password (OTP) authentication. "Evaluation of SRTP Keying with SIP", Francois Audet, Dan Wing, 1-Feb-07, Over a dozen incompatible mechanisms have been defined to key an Secure RTP (SRTP) media stream. This document evaluates the keying mechanisms, concentrating on their interaction with SIP features and their security properties. This document is discussed on the rtpsec mailing list, . "MANET Autoconfiguration", Fred Templin, 5-Mar-07, Mobile Ad-hoc Networks (MANETs) consist of routers operating over multihop wireless links, and may or may not connect to other networks and/or the Internet. Routers in MANETs must have a way to automatically provision local and global-use IP addresses/prefixes. This document specifies mechanisms for MANET autoconfiguration. Both IPv4 and IPv6 are discussed. "Dynamic Prefix Allocation for NEMOv4", George Tsirtsis, 1-Feb-07, The base NEMOv4 specification defines extensions to Mobile IPv4 for mobile networks. This specification defines a dynamic prefix allocation mechanism. "FA extensions to NEMOv4 Base", George Tsirtsis, 1-Feb-07, The base NEMOv4 specification defines extensions to Mobile IPv4 for mobile networks. NEMOv4 extensions are defined for use only by the mobile node and the home agent. This specification introduces extensions for NEMO support on the foreign agent. "IANA Registration for an Enumservice to Hint to E.164 Resolution Namespaces (ERN)", Richard Stastny, 1-Dec-06, This document registers the Enumservice type "ern" and subtype "http" using the URI scheme 'http', as well as the subtype "urn" using the URI scheme 'urn' as per the IANA registration process defined in the ENUM specification RFC 3761. This Enumservice is used to provide a hint in ENUM to an E.164 Resolution Namespace a service provider chooses to populate with E.164 numbers to be shared within a limited group of other service providers. "Diameter Routing Extensions", Tina Tsou, 7-Mar-07, This document describes two(2) extensions to the current diameter routing scheme. The first extension describes an explicit routing mechanism that MAY be employed by Diameter nodes to allow specific stateful Diameter proxies to remain in the path of all messages exchanges constituting a Diameter session. The second extension describes a realm based redirection scheme as an alternative to host based redirection descrbied in [RFC3588]. "Concepts and Terminology for Peer to Peer SIP", Dean Willis, 6-Mar-07, This document defines concepts and terminology for use of the Session Initiation Protocol in a peer-to-peer environment where the traditional proxy-registrar function is replaced by a distributed mechanism that might be implemented using a distributed hash table or other distributed data mechanism with similar external properties. This document includes a high-level view of the functional relationships between the network elements defined herein, a conceptual model of operations, and an outline of the related open problems that might be addressed by an IETF working group. "The Additional Modes of Operation for Camellia and Its Use With IPsec", Akihiro Kato, Masafumi Kanda, 7-Mar-07, This document describes the use of the Camellia block cipher algorithm in Counter (CTR) mode and Counter with CBC-MAC (CCM) Mode , as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality, data origin authentication, and connectionless integrity. "Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)", Marcelo Bagnulo, Jari Arkko, 5-Mar-07, This document analyzes the implications of recent attacks on commonly used hash functions on Cryptographically Generated Addresses (CGAs) and updates the CGA specification to support multiple hash algorithms. "Multicast IP Security Composite Cryptographic Groups", George Gross, Haitham Cruickshank, 19-Oct-06, The Multicast IP Security extension architecture [Weis] implicitly assumes a basic group endpoint population that shares homogeneous cryptographic capabilities and security policies. In practice, large- scale cryptographic groups may contain a heterogeneous endpoint population that can not be accommodated by that basic multicast IPsec architecture. For example, some endpoints may not have been upgraded to handle the successor algorithm for one that is being retired (e.g. SHA1 transition to SHA-ng). Group deployments that span multiple legal jurisdictions may have a different security policy in each jurisdiction (e.g. key strength). This document defines the "composite cryptographic group" IP security architecture capability. A composite cryptographic group allows multicast IPsec applications to transparently interact with the single logical group that is formed by the union of one or more basic cryptographic groups. "Admission Control enabled On demand Routing (ACOR)", Kettaf Noureddine, 13-Nov-06, The Admission Control enabled On-demand Routing (ACOR) protocol is intended for use by MANETs. It is a reactive routing protocol designed to support quality of service (QoS) on the end to end route. ACOR is based on simple local cost functions at each node, and global cost function to represent the end-to-end cost of a route, in addition to a simple admission control mechanism for implicit resource reservation adapted to frequent changing of network topology. "Extension of DHCP Leasequery in Bridging/Switching networks", Bharat Joshi, Pavan Kurapati, 25-Sep-06, As per industry trends, Access Networks have been migrating from traditional ATM based networks to Ethernet networks. In Ethernet based access networks, Access Concentrators are typically configured to act as traditional bridge. These Access Concentrators also act as relay agents and relay DHCP messages between hosts and DHCP servers. It also maintains and updates lease/location information while relaying the DHCP messages. Access Concentrators may use the lease/ location information for anti-spoofing, data forwarding etc. This lease/location information is lost if an Access Concentrator gets rebooted. RFC 4388 [5] has defined a new message type DHCPLEASEQUERY to address similar limitation in Routed Access Networks. This document initially gives an overview of the functioning of the Access Concentrator acting as a relay agent in a Layer 2 aggregation network. The limitation[as mentioned above] in a typical switched/ bridged[layer 2] is then discussed followed by the proposal to extend the DHCPLEASEQUERY message to address this limitation. "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) co-operation with HTTP Extensions for Distributed Authoring (WEBDAV)", Jari Urpalainen, 7-Mar-07, The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) allows a client to read, write and modify application configuration data, stored in XML format on an HTTP server. HTTP Extensions for Distributed Authoring (WebDAV) provides many useful HTTP extensions for web content authoring. This document describes conventions for the co-operation of XCAP resources with WebDAV. "Duplicate Address Detection Optimization Using Enhanced Neighbor Discovery", Frank Xia, Behcet Sarikaya, 11-Dec-06, This draft describes a possible optimization to Duplicate Address Detection (DAD) which can be used to successfully terminate DAD early. The method is based on a positive RA message sent by an Neighbor Discovery Relay Agent that knows all the IPv6 addresses of the nodes currently attached to it. "The TCP Simple Authentication Option", Joseph Touch, Allison Mankin, 24-Oct-06, This document specifies a TCP Simple Authentication Option (TCP-SA) which is intended to replace the TCP MD5 Signature option of RFC-2385 (TCP/MD5). TCP-SA specifies the use of stronger HMAC-based hashes and provides more details on the association of security associations with TCP connections. TCP-SA assumes an external, out-of-band mechanism (manual or via a separate protocol) for session key establishment, parameter negotiation, and rekeying, replicating the separation of key management and key use as in the IPsec suite. The result is intended to be a simple modification to support current infrastructure uses of TCP/MD5, such as to protect BGP and LDP, to support a larger set of hashes with minimal other system and operational changes. TCP-SA requires no new option identifier, though it is intended to be mutually exclusive with TCP/MD5 on a given TCP connection. "Transport of Media Independent Handover Messages Over IP", Akbar Rahman, 2-Mar-07, This document describes a mechanism for using UDP/IP for the transport of Media Independent Handover (MIH) messages between network nodes. MIH messages carry technology specific link layer information and commands that can be used to optimize handover procedures across different access technologies such as cellular and WLAN. MIH will complement Layer 3 mobility protocols such as Mobile IP. "Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer", Miguel Garcia-Martin, 4-Dec-06, This document provides a mechanism to negotiate the transfer of one or more files between two endpoints by using the Session Description Protocol (SDP) offer/answer model specified in RFC 3264. SDP is extended to describe the attributes of the files to be transferred. The offerer can either describe the files it wants to send, or the files it would like to receive. The answerer can either accept or reject the offer separately for each individual file . The transfer of one or more files is initiated after a successful negotiation. The Message Session Relay Protocol (MSRP) is defined as the default mechanism to actually carry the files between the endpoints. The conventions on how to use MSRP for file transfer are also provided in this document. "A Session Initiation Protocol (SIP) Event Package and Data Format for Describing Generic Resources", Miguel Garcia-Martin, Marcin Matuszewski, 20-Dec-06, This document specifies the format and semantics associated to a 'resource' event package that allows SIP endpoints to publish the availability of generic resources. A resource can be, for example, files (e.g., images, video files, audio files), chat rooms, streaming content, printers, printer jobs, etc. This event package also allows SIP endpoints to subscribe to changes in the availability of resources, or perform searches for the availability and location of a given resource. Support for partial notifications and publications is also accomplished by using XML patch operations. "A Framework for Sharing Resources with the Session Initiation Protocol (SIP)", Miguel Garcia-Martin, 20-Dec-06, This memo proposes a SIP framework used for advertising and searching for shared resources, such as services or files, within a given community. The memo defines the signaling used by users to signal the availability of resources stored in their User Agents (UA). It also provides the signaling for users to perform searches of available resources and monitor changes in existing resources. Additionally, we provide the signaling used to access a resource. These methods can be used in (but are not limited to) SIP peer-to- peer systems based on centralized, semi-centralized or fully distributed architectures. "Secure Beacon: Securely Detecting a Trusted Network", Yoav Nir, Yaron Sheffer, 27-Nov-06, Remote access clients, in particular IPsec-based ones, are heavily deployed in enterprise environments. In many enterprises the security policy allows remote-access clients to switch to unprotected operation when entering the trusted network. This document specifies a method that lets a client detect this situation in a secure manner, with the help of a security gateway. We propose a minor extension to IKEv2 to achieve this goal. "THUMP -- The HTTP URL Mapping Protocol", John Kunze, 1-Mar-07, The HTTP URL Mapping Protocol (THUMP) is a set of URL-based conventions for retrieving information and conducting searches. THUMP can be used for focused retrievals or for broad database queries. A THUMP request is a URL containing a query string that starts with a `?', and can contain one or more THUMP commands. Returned records are formatted with kernel metadata as Electronic Resource Citations, which are similar to blocks of email headers. "Mobile IPv6 Vendor Specific Option", Vijay Devarapalli, 23-Oct-06, There is a need for vendor specific extensions to Mobility Header messages so that Mobile IPv6 vendors are able to extend the protocol for research or deployment purposes. This document defines a new vendor specific mobility option. "Mobile IPv6 Experimental Messages", Vijay Devarapalli, 23-Oct-06, This document defines a new experimental Mobility header message and a mobility option that can be used for experimental extensions to the Mobile IPv6 protocol. "GMPLS control of Ethernet", Don Fedyk, 26-Oct-06, Carrier Grade Ethernet transport solutions require the capability of flexible service provisioning and fast protection switching. Currently, Ethernet is being extended in IEEE to meet the scalability needs of transport networks. The IETF specified GMPLS to control transport networks. To enable integration of Ethernet based transport solutions the extension of GMPLS control plane for Ethernet is of value. This memo describes how a GMPLS control plane may be applied to Provider Backbone Transport (PBT) and how GMPLS can be used to configure VLAN-aware Ethernet switches in order to establish Ethernet P2P and P2MP MAC switched paths and P2P/P2MP VID based trees. This document assumes any standard changes to IEEE data planes will be undertaken only in the IEEE. "Simplifying Process for IGMPv3 and MLDv2 Protocols", Hui Liu, 18-Oct-06, This document proposes simplified IGMPv3 and MLDv2 protocols, which are called IGMPv3-lite and MLDv2-lite. The interoperability with other versions of IGMP and MLD is also considered. "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP)", Eric Rescorla, David McGrew, 6-Mar-07, The Secure Real-time Transport Protocol (SRTP) is a profile of the Real-time Transport Protocol that can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). This document describes a method of using DTLS key management for SRTP by using a new extension that indicates that SRTP is to be used for data protection, and which establishes SRTP keys. "The Definitions of Managed Objects for Mobile IP UDP Tunneling", Hans Sjostrand, 13-Feb-07, This memo defines the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Mobile Node, Foreign Agent and Home Agent when Mobile IP Traversal of Network Address Translation (NAT) Devices are used. "Relaxing Gratuitous TSIG Requirement", Rob Austein, Michael Graff, 26-Oct-06, GSS-TSIG is not implementable as specified due to an omission, and the specification contains an unnecessary restriction. This note proposes a fix to both of these problems. "A Template for Documents Containing a MIB Module", David Harrington, 9-Jan-07, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing [TODO]. [TODO]: describe what functionality will be managed using this MIB module. It can be good to mention the protocol being managed, and whether there is a particular aspect of the protocol to be managed, or a particular goal of the module. But keep it brief. "Extensions to the Session Initiation Protocol (SIP) for the support of the Call Completion Services for the European Telecommunications Standards Institute,", Joachim Poetzl, 1-Mar-07, This document specifies the extensions to the Session Initiation Protocol (SIP) for the call completion services provided in the context of ETSI Next Generation Networks (NGN). Therefore this document describes a SIP event package that enables subscribing to and managing call completion queues. Furthermore this document extends the usage of the Allows-events header field to 180 Ringing and 486 Busy responses, and specifies an indication used for the prioritization of call-completion calls. "Preserving Topology Confidentiality in Inter-Domain Path Computation using a key based mechanism", Richard Bradford, 5-Jan-07, Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASs), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. However, in some cases (e.g. when ASs are administered by separate Service Providers), it would break confidentiality rules for a PCE to supply a path segment to a PCE in another domain, thus disclosing internal topology information. This issue may be circumvented by returning a loose hop and by invoking a new path computation from the domain boundary LSR during TE LSP setup as the LSP enters the second domain, but this technique has several issues including the problem of maintaining path diversity. This document defines a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS). The CPS may be replaced by a path-key that can be conveyed in the PCE Communication Protocol (PCEP) and signaled within in a Resource Reservation Protocol (RSVP) explicit route object. "A Management Request Event Package for the Session Initiation Protocol (SIP)", Joshua Littlefield, 22-Oct-06, In many environments, firewall, NAT and IP addressing issues make remote management of devices containing SIP user agents difficult. This document defines a SIP event package for notifying a user agent that it should initiate a session with a management entity for management operations. This type of "call-home" management avoids the need to maintain persistent TCP connections, or generate additional STUN traffic, with the management entity. This event package is intended not to tunnel management protocols or otherwise provide management itself, but instead to provide a means for signaling a SIP UA that a management session is desired. "The LDAP entryDN Operational Attribute", Kurt Zeilenga, 14-Feb-07, This document describes the LDAP/X.500 'entryDN' operational attribute. The attribute provides a copy of the entry's distinguished name for use in attribute value assertions. "The Presence-specific Dictionary for the Signaling Compression (Sigcomp) Framework", Miguel Garcia-Martin, 7-Mar-07, The Session Initiation Protocol (SIP) [4] is a text-based protocol for initiating and managing communication sessions. The protocol is extended by the SIP-events framework [5] to provide, e.g., subscriptions and notifications to presence information that are carried in presence documents [8]. SIP can be compressed by using Signaling Compression (SigComp) [2], which is enhanced by using the SIP/SDP dictionary [7] to achieve better compression rates. However, the SIP/SDP dictionary [7] is not able to increase the compression factor of (typically lengthy) presence documents. This memo defines the presence-specific static dictionary that SigComp may use in order to achieve higher efficiency. The dictionary is compression algorithm independent. "The LDAP Relax Rules Control", Kurt Zeilenga, 14-Feb-07, This document defines the Lightweight Directory Access Protocol (LDAP) Relax Rules Control which allows a directory user agent (a client) to request the directory service temporarily relax enforcement of various data and service model rules. "Diameter Base Protocol MIB", Subash Comerica, Glen Zorn, 8-Mar-07, Along with providing support for certain basic authentication, authorization and accounting functions, the Diameter protocol is designed to provide a framework for AAA applications. This document defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage an implementation of the Diameter protocol. "Diameter Credit Control Application MIB", Subash Comerica, Glen Zorn, 8-Mar-07, Along with providing support for certain basic authentication, authorization and accounting functions, the Diameter base protocol is intended to provide a framework for AAA applications. This document defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage an implementation of the Diameter Credit Control application. "VCCV Extension for Ethernet OAM", Dinesh Mohan, 13-Feb-07, This document proposes extensions to Virtual Circuit Connection Verification (VCCV) procedures to add Ethernet OAM functionality. VCCV supports connection verification applications for PWs regardless of the underlying public service network technology. This document proposes VCCV to support Ethernet OAM as an option to perform operations and maintenance functions; especially when the PSN is Ethernet. "Domain Name System (DNS) Cookies", Donald Eastlake 3rd, 24-Oct-06, DNS cookies are a light-weight DNS transaction security mechanism. They provides limited protection to DNS servers and resolvers against a variety of increasingly common denial-of-service and cache poisoning attacks by off-path attackers. "Management Information Base for TCP and UDP processes", Anders Persson, 8-Nov-06, In RFC 4113 and 4022 there is a set of objects that have some outstanding issues. This document provides a short discussion of the issues and how they can be addressed. "SDP Capability Negotiation", Flemming Andreasen, 22-Oct-06, The Session Description Protocol (SDP) was intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability indication or capability negotiation, however over the years, SDP has seen widespread adoption and as a result it has been gradually extended to provide limited support for these. SDP and its current extensions however do not have the ability to negotiate one or more alternative transport protocols (e.g. RTP profiles) which makes it particularly difficult to deploy new RTP profiles such as secure RTP and RTP with RTCP-based feedback. The purpose of this document is to address that by identifying a set of requirements, evaluate existing work in this area, and provide a recommended solution for extending SDP with capability negotiation. "Virtual Private Lan Services (VPLS) Management Information Base", Thomas Nadeau, 15-Feb-07, This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Virtual Private LAN services. It needs to be used in conjunction with Pswudo Wire (PW) Management Information Base [PWE3-PW-MIB]. "A Comparison of IP Mobility-Related Protocols", Dave Thaler, 25-Oct-06, Mobile IPv6 (MIP6), the Level 3 Multihoming Shim Protocol (SHIM6), and the Host Identity Protocol (HIP) all address various aspects of mobility and multi-homing in similar ways. This document gives a brief comparison of their features. "Interface selection for a multihomed mobile network", Chulhyun Park, 27-Oct-06, In this draft, we discuss how to make use of multiple interfaces in a single mobile router. We will focus on the scenario in which each interface is attached to different access network. Especially, we propose how a mobile router selects proper interfaces to provide services to different traffic flows. We suggest a new option carried in IPv6 hop-by-hop options header to maintain and advertise the flow requirment and characteristics. New option contains a service type value and a preference value. A servie type value is used for traffic classification, and a preference value enables mobile router to control the traffic in detail. The propsed multiple interface selection mechanism in a multihomed mobile router (MMR) chooses an appropriate interface for each flow, depending on traffic requirements and access network characteristics. "Mobile IPv6 Extension for Configuration Options", Jayshree Bharatia, Kuntal Chowdhury, 27-Feb-07, This document describes the mechanism for providing the host configuration information during Mobile IPv6 Binding Update procedure. The Configuration Options extension may be included in the Mobile IPv6 Binding Update message for requesting the home agent to include configuration parameters needed for network service usage (e.g. DNS). The requested information is provided by the Home Agent in one or more Configuration Options extensions. "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", Hesham Soliman, 26-Oct-06, This document introduces extensions to Mobile IPv6 and IPv6 Neighbour Discovery to allow for local mobility handling. Hierarchical mobility management for Mobile IPv6 is designed to reduce the amount of signalling between the Mobile Node, its Correspondent Nodes, and its Home Agent. The Mobility Anchor Point (MAP) described in this document can also be used to improve the performance of Mobile IPv6 in terms of handover speed. "Domain-based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", Leslie Daigle, 13-Feb-07, The purpose of this document is to define a new, straightforward Dynamic Delegation Discovery Service (DDDS) application to allow mapping of domain names to URIs for particular application services and protocols. Although defined as a new DDDS application, dubbed U-NAPTR, this is effectively an extension of the Straightforward NAPTR (S-NAPTR) DDDS application. "EAP Extensions for Efficient Re-authentication", Vidya Narayanan, Lakshminath Dondeti, 22-Jan-07, The extensible authentication protocol (EAP) is a generic framework supporting multiple types of authentication methods. In the most common deployment scenario, a peer and server authenticate each other through an authenticator; the server sends the master session key (MSK) to the authenticator so that the peer and the authenticator can establish a security association for per-packet access enforcement. It is desirable to not repeat the entire process of authentication when the peer moves to another authenticator. This document specifies extensions to EAP keying hierarchy and an EAP method- independent protocol to facilitate such efficient Re-authentication between the peer and the server through an authenticator. "Mobility Signaling Delegation in OptiSEND", Wassim Haddad, 25-Oct-06, This memo describes a mechanism which delegates the exchange of mobility signaling messages between the mobile and correspondent nodes to the network infrastructure. Goals outlining the proposed delegation are to further reduce the IP handoff latency and to relieve the mobile node from exchanging a considerable amount of signaling messages with correspondent nodes while retaining full control on the critical ones. "Configuration Data Model for IPFIX and PSAMP", Gerhard Muenz, 21-Dec-06, This document proposes a configuration data model for IPFIX and PSAMP Devices as well as IPFIX concentrators and proxies based on Extensible Markup Language (XML). "Routing of mid dialog requests using sip-outbound", Kevin Johns, 1-Feb-07, This document describes a solution for routing of mid-dialog requests in the presence of NATs. The solution leverages and extends the concepts described in the Internet Draft titled Managing Client Initiated Connections in the Session Initiation Protocol. This solution is necessary to support routing of mid-dialog requests while preserving Edge Proxy failover within an outbound-proxy-set. "Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture", Flemming Andreasen, 15-Feb-07, In order to deploy a residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol (SIP) [RFC3261] for supporting the exchange of customer information and billing information between trusted entities in the PacketCable Distributed Call Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required. "IGP Routing extensions for discovery of P2MP TE LSP Leaf LSRs", Jean-Louis Le Roux, 22-Oct-06, In various situations, such as TV broadcasting with several regional sources, it is required to setup a series of Point-To-MultiPoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) between a set of head-end Label Switching Routers (LSRs) and a group of leaf LSRs referred to as a Leaf Group. Setting up such a series of P2MP TE LSPs requires for the set of head-end LSRs to be aware of all leaf LSRs, which may lead to the cumbersome configuration of a potentially large number of leaf LSRs on each head-end LSRs. Furthermore leaf LSRs may want to dynamically join or leave a Leaf Group without requiring manual configuration on the head-end LSRs. This document specifies IGP routing extensions for IS-IS and OSPF so as to provide an automatic discovery of the set of leaf LSRs members of a Leaf Group, in order to automate the creation and modification of a series of P2MP TE-LSPs. "Considerations for Information Services and Operator Services Using SIP", John Haluska, 7-Nov-06, Information Services are services whereby information is provided by the network in response to user requests, and may include involvement of a human or automated agent. A popular existing Information Service is Directory Assistance (DA). Moving ahead, Information Services providers envision exciting multimedia services that support simultaneous voice and data interactions with full operator backup at any time during the call. Information Services providers are planning to migrate to SIP based platforms, which will enable such advanced services, while continuing to support traditional DA services. This document aims to identify how such services can be implemented using existing or currently proposed SIP mechanisms. "Certificate Authentication in SIP", Steve Dotson, 14-Feb-07, This document defines requirements for adding certificate authentication to the Session Initiation Protocol (SIP). It is intended that potential solutions specifying certificate authentication within SIP will use these requirements as guidelines. Supporting certificate authentication in SIP would provide strong authentication and increase the types of possible deployment scenarios. "Explicit Congestion Marking in MPLS", Bruce Davie, 19-Oct-06, RFC 3270 defines how to support the Diffserv architecture in MPLS networks, including how to encode Diffserv Code Points (DSCPs) in an MPLS header. DSCPs may be encoded in the EXP field, while other uses of that field are not precluded. RFC3270 makes no statement about how Explicit Congestion Notification (ECN) marking might be encoded in the MPLS header. This draft defines how an operator might define some of the EXP codepoints for explicit congestion notification, without precluding other uses. "Extension Formats for Unidirectional Link Encapsulation (ULE) and the Generic Stream Encapsulation (GSE)", Bernhard Collini-Nocker, Gorry Fairhurst, 11-Jan-07, This document describes a set of Extension Headers for the Unidirectional Lightweight Encapsulation (ULE). The Extension Header formats defined in this document provide new extensions that are common extensions to both ULE and the Generic Stream Encapsulation (GSE) defined by the second generation framing structure DVB-S2 standard (Channel coding and modulation systems for Broadcasting, Interactive Services, News Gathering and other broadband satellite applications). "A Minimalist Approach to Direct Peering", Rohan Mahy, 2-Mar-07, This document describes a concrete example of a peering convention for domains and federations of domain which use SIP for communications, especially in conjunction with E.164 addresses (telephone numbers). The author hopes this example mechanism will promote and facilitate discussion within the speermint working group. "VCCV Extensions for Segmented Pseudo-Wire", Neil Hart, 24-Oct-06, This document describes extensions to Single Hop Virtual Circuit Connectivity Verification (SH-VCCV) procedures for segmented pseudo wires to test the end-to-end forwarding datapath and to provide a MS- PW segment trace capability. This is accomplished by changing the adaptation function for the Single Hop VCCV parameter at the switching point between two distinct PW control planes. "Link and Path Characteristic Information Delivery Analysis", Jouni Korhonen, 25-Oct-06, This document analyses capabilities and applicability of various IP Mobility, signaling and transport protocols for delivering Link and Path Characteristic Information between communicating end points. "Softwire Mesh Framework", John Wu, 1-Mar-07, The Internet needs to be able to handle both IPv4 and IPv6 packets. However, it is expected that some constituent networks of the Internet will be "single protocol" networks. One kind of single protocol network can parse only IPv4 packets and can process only IPv4 routing information; another kind can parse only IPv6 packets and can process only IPv6 routing information. It is nevertheless required that either kind of single protocol network be able to provide transit service for the "other" protocol. This is done by passing the "other kind" of routing information from one edge of the single protocol network to the other, and by tunneling the "other kind" of data packet from one edge to the other. The tunnels are known as "Softwires". This framework document explains how the routing information and the data packets of one protocol are passed through a single protocol network of the other protocol. The document is careful to specify when this can be done with existing technology, and when it requires the development of new or modified technology. "Signaling media decoding dependency in Session Description Protocol (SDP)", Stephan Wenger, Thomas Schierl, 7-Mar-07, This memo defines semantics that allow for signaling the decoding dependency of different media descriptions with the same media type in the Session Description Protocol (SDP). This is required, for example, if media data is separated and transported in different network streams as a result of the use of a layered or multiple descriptive media coding process. A new grouping type "DDP" -- decoding dependency -- is defined, to be used in conjunction with RFC 3388 entitled "Grouping of Media Lines in the Session Description Protocol". In addition, an attribute is specified describing the relationship of the media streams in a "DDP" group. "GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements", Hannes Tschofenig, Henning Schulzrinne, 25-Oct-06, This document provides a problem statement, lists requirements and captures discussions for a GEOPRIV Layer 7 Location Configuration Protocol (LCP). This protocol aims to allow an end host to obtain location information, by value or by reference, from a Location Information Server (LIS) that is located in the access network. The obtained location information can then be used for a variety of different protocols and purposes. For example, it can be used as input to the Location-to-Service Translation Protocol (LoST) or to convey location within SIP to other entities. "Problem Statement for SIP/SIMPLE", Tim Rang, 25-Oct-06, As more experience of deploying SIMPLE based presence systems is accumulated, it seems that deploying a large SIMPLE presence system is actually a very hard task. The document analyzes several aspects of SIMPLE based presence system deployment and shows that difficulties around the amount of messages (network), state management (memory) and processing load (cpu). Although this document is a problem statement document and not a BCP document, several possible optimizations and directions are listed at the end of the document in addition to an initial set of requirements for what should be the characteristic of the solution to the problem stated in the document This document is intended to be used by the SIMPLE WG in order to work on possible solutions that will make the deployment of a presence server more reasonable task. Note that the document does not try to compare the SIP based presence server to other types of presence servers but only analyzes the SIP based presence server. "DNS Scoped Data Through Attribute Leaves", David Crocker, 25-Oct-06, Historically, any DNS RR may occur for any domain name. Recent additions have defined DNS leaf nodes that contain a reserved node name, beginning with an underscore. The underscore construct is used to define a semantic scope for the associated, parent domain name, within which the use of some RRs is constrained. Hence the underscore construct defines a basic paradigm modification to the DNS. This note explores the nature of this DNS usage and defines the procedures for registering "underscore names" with IANA. "OSPF Database Exchange Summary List Optimization", Richard Ogier, 20-Oct-06, This document describes a backward compatible optimization for the Database Exchange process in OSPFv2 and OSPFv3. In this optimization, a router does not list an LSA in Database Description packets sent to a neighbor, if the same or a more recent instance of the LSA was listed in a Database Description packet already received from the neighbor. This optimization reduces Database Description overhead by about 50% in large networks. This optimization does not affect synchronization, since it only omits unnecessary information from Database Description packets. "RELO: Retrieving End System Location Information", Henning Schulzrinne, 6-Mar-07, In some network configurations, it is desirable for the end system to be able to obtain its geodetic or civic location using an application-layer protocol. This document describes RELO (Retrieving End system LOcation), a simple, HTTP-based stateless protocol profile that fulfills this need. "Auditing Functionality in Diameter", Ulf Bodin, 6-Mar-07, Diameter is being increasingly included in the work of other standards organizations and has become a key protocol in many architectures. One of the uses of Diameter includes setting and maintaining hard-state and soft-state during failover and in the event of delayed refresh messages respectively. Often there is a need to query for information on active sessions for backup or synchronization purposes. "Procedure for Multiple Node Graceful Restart", Dan Li, 6-Mar-07, The Hello message for the Resource Reservation Protocol (RSVP) has been defined to establish and maintain basic signaling node adjacencies for Label Switching Routers (LSRs) participating in a Multiprotocol Label Switching (MPLS) traffic engineered (TE) network. The Hello message has been extended for use in Generalized MPLS (GMPLS) network for state recovery of control channel or nodal faults. "Data Channel Status Confirmation Extensions for the Link Management Protocol", Dan Li, 13-Feb-07, This document defines simple additions to the Link Management Protocol (LMP) to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent LSRs to confirm data channel statuses, and provides triggers for notifying the management plane if any discrepancies are found. "Transmission of IP Packets over Ethernet over IEEE 802.16", Maximilian Riegel, 25-Oct-06, This document describes the behavior of the Ethernet emulation on top of IEEE 802.16 to efficiently support the transmission of IPv4 as well as IPv6 packets over IEEE 802.16 radio links. Due to resource constraints of radio transmission systems and the limitations of the IEEE 802.16 MAC layer for the emulation of Ethernet, the transmission of IP over an emulated LAN on top of IEEE 802.16 may considerably benefit by adding IP specific support functions within the Ethernet emulation on top of IEEE 802.16. "Multiple aggregated control URIs for RTSP", Torbjorn Einarsson, 21-Dec-06, By introducing multiple aggregated control URIs to be used with PLAY requests inside one single RTSP session, it is possible to switch content channel with minimal delay, since no new transport setup is needed. This is important for delivering TV-like services with short zapping times over unicast networks. Another important use case is hybrid unicast and broadcast distribution of live media, e.g. mobile TV. The possibility of this mechanism can be signalled implicitly using a standard SDP description for each content channel but with identical media control URIs, or by one common SDP description with a new attribute for multiple control URIs. "RADIUS Usage for SNMP SSH Security Model", Kaushik Narayan, David Nelson, 6-Mar-07, The Secure Shell Security Model (SSHSM) describes a Security Model for the Simple Network Management Protocol, using the Secure Shell protocol within an SNMP Transport Mapping. This memo describes the usage of the Secure Shell Security Model with a RADIUS authentication and authorization system. "Controlling FLUTE sessions with Real-Time Streaming Protocol (RTSP)", Thorsten Lohmar, 19-Dec-06, File Delivery over Unidirectional Transport (FLUTE) is defined in RFC 3926 and provide an extensible framework for delivering any type of files over UDP. FLUTE is mostly intended for IP multicast communication, but the use with IP unicast is not excluded. Real- time Streaming Protocol (RTSP) allow the play-out of media packets to multicast and unicast sessions. "The NetLMM Protocol", Gerardo Giaretta, 5-Oct-06, This document specifies an Internet protocol that allows mobile nodes to move around in a local mobility domain, changing their point of attachment within the domain, but without ever being aware at the IP layer that their point of attachment has changed, and maintaining seamless communication in the presence of such changes. It defines two protocol entities, a Mobile Access Gateway and a Local Mobility Anchor, and a set of messages between them, that together make these mobility events transparent to the mobile nodes at the IP layer, as long as they remain within the local mobility domain. "DMMP: Dynamic Mesh-based Overlay Multicast Protocol", Jun Lei, 20-Oct-06, This document describes a Dynamic Mesh-based overlay Multicast Protocol (DMMP) to support multicast data delivery applications without relying on classic IP multicast, including multicast group management, overlay hierarchy establishment, multicast tree construction and data forwarding scheme from the source to a number of receivers. The DMMP framework builds on control plane functions which dynamically manage an overlay core and a multicast tree layer. The key idea is a number of end hosts self-organize into an overlay mesh, and dynamically maintain such a mesh. Based on the constructed mesh, some core-based clusters are built with capacity-aware trees inside. Then, a multicast tree consisting of DMMP-aware end hosts (and/or specific routers) is built on the top of the overlay core for the efficient delivery of the multicast data. "Reporting Metrics: Different Points of View", Al Morton, 24-Oct-06, Consumers of IP network performance metrics have many different uses in mind. This memo categorizes the different audience points of view. It describes how the categories affect the selection of metric parameters and options when seeking info that serves their needs. "Identifying and Reacting to Unsolicited DNS Queries", Peter Koch, 21-Feb-07, This document deals with unsolicited Domain Name System (DNS) queries directed towards authoritative name servers. It identifies reasons for the existence of these queries and lists some observed or proposed reactions. "Design Considerations for the Common MIH Protocol Functions", Eleanor Hepworth, 26-Oct-06, The MIPSHOP working group is currently developing functionality to support media independent handover services, which are intended to aid IP handover mechanisms between heterogeneous wired and wireless access systems. These handover services provide a mechanism by which information such as the presence of neighbouring links and networks, and their associated characteristics, can be delivered to mobile and other network nodes for the purposes of supporting better handover decisions. A key component of the solution is the set of protocols that is used to deliver the various types of information to the appropriate destination node. A separate problem statement draft outlines a structure for this set of protocols as a unified set of common functions, supporting a more diverse set of application specific protocols. This draft outlines the key considerations that have to be considered when selecting or designing protocols for such common functionality. This draft is offered for use as a mechanism to capture working group discussions on the design of the common protocol functions during their initial development, without imposing a particular solution on the discussion process. It is not intended as a long term output. "MIKEYv2: SRTP Key Management using MIKEY, revisited", Lakshminath Dondeti, 8-Mar-07, The Multimedia Internet Keying (MIKEY) protocol is a general purpose key management protocol; it is used especially for key management for secure RTP. We specify a couple of variations of that protocol to support mode negotiation, media path key establishment and other assorted requirements. "A Filter Rule Mechanism for Multi-access Mobile IPv6", Conny Larsson, 8-Mar-07, This draft introduces filter rules as a means for a multi-homed node to perform per flow interface selection. Per flow interface selection is typically needed when there exist multiple network interfaces, each with different network characteristics, and an application has specific performance requirements for a data flow that makes one network interface more suitable than another. The use of OpenBSD Packet Filter (PF) syntax is proposed to describe the filter rules. "LDP Capabilities", Bob Thomas, 5-Mar-07, A number of enhancements to the Label Distribution Protocol (LDP) have been proposed. Some have been implemented, and some are advancing toward standardization. It is likely that additional enhancements will be proposed in the future. At present LDP has no guidelines for advertising such enhancements at LDP session initialization time. There is also no mechanism to enable and disable enhancements after the session is established. This document provides guidelines for advertising LDP enhancements at session initialization time. It also defines a mechanism to enable and disable enhancements after LDP session establishment. "SAMLv2 Lightweight Web Browser SSO Profile", Jeff Hodges, Scott Cantor, 16-Oct-06, This document specifies a SAMLv2 lightweight Web Browser Single Sign-On Profile. This profile is modeled on the OASIS SAMLv2 Web Browser SSO profile, adding various constraints, and using a new lighterweight SAMLv2 HTTP POST binding offering an optional signature technique that is more simple-to-implement than the also optional XML Digital Signature approach. "Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)", Thomas Phelan, 22-Oct-06, This document describes the use of Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP). "Specifying Access controls for XCAP data models", Harindranath Nair, Sumanth Channabasappa, 23-Oct-06, This document presents the need, and a proposal for defining access control definitions for data elements, defined using XML Schemas for use with the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) protocol. "Key Change Strategies for TCP-MD5", Steven Bellovin, 8-Jan-07, The TCP-MD5 option is most commonly used to secure BGP sessions between routers. However, changing the long-term key is difficult, since the change needs to be synchronized between different organizations. We describe single-ended strategies that will permit (mostly) unsynchronized key changes. "Destination Address Selection Analysis for a MONAMI6 MN", Robert Jaksa, 25-Oct-06, When a correspondent node (CN) initiates a session with a multi-homed Mobile Node (MN), it should choose the "best" destination address based on the available information about the MN. Presently there is no mechanism allowing the MN to indicate on which interface (i.e., address) a CN may reach it. This draft documents a method whereby the MN may communicate to the CN address selection preferences so that the CN may initiate a session to the desired address (interface) for of the MN. The method is based on the notion of storing address selection preference information for the MN in the DNS. "The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in IPsec", Lakshminath Dondeti, Ran Canetti, 25-Oct-06, This document specifies the use of Timed Efficient Stream Loss- tolerant Authentication (TESLA) -- a source authentication mechanism for multicast or broadcast data streams -- with IPsec ESP. In addition to the source authentication using TESLA, group authentication of the ESP packet can be provided using a shared symmetric group key. Thus, the proposed extension to ESP combines group secrecy, group authentication, and source authentication transforms in an ESP packet. "Definitions of Managed Objects for IP Flow Information Export", Thomas Dietz, 25-Oct-06, This document defines managed objects for IP Flow Information Export (IPFIX). These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors including some minor configuration information. "Session Peering Use Case for Cable", Yiu Lee, 28-Sep-06, This document describes a typical use case of session peering in cable industry. Caller Alice makes a VoIP call to Callee Bob. Alice and Bob are served by two different cable operators, mso-o and mso-t. mso-o and mso-t have bi-lateral peering agreement to peer at SIP layer. This document focuses on the SIP layer interactions and discuss some common practices for Layer 5 Peering in cable industry. "Human-regenerable IPv6 interface identifiers and addresses", Pars Mutaf, 6-Nov-06, This document defines the human-regenerable IPv6 interface identifiers and addresses. "Canonical Textual Representation of 4-byte AS Numbers", George Michaelson, 19-Oct-06, A single textual representation for 4-byte Autonomous System (AS) numbers is defined, to avoid any confusion in interpreting the two 2-byte quantities of which it is comprised. The syntax chosen avoids collision with Border Gateway Protocol (BGP) community string parsing of AS numbers. It is recommended that only this textual representation be used by all documents and systems referring to 4-byte AS numbers. "Requirements for Scalable Adaptive Multicast Framework in Non-GIG Networks", Eiichi Muramoto, 21-Nov-06, The Scalable Adaptive Multicast (SAM) Research Group is chartered to explore and research techniques which improve multicast performance with respect to dimensions such as number of groups, dynamics of group membership, dynamics of the network topology, and network resource constraints. This document describes requirements for SAM framework, especially for non-GIG environment. "ASP Congestion (ASPCONG) for Signalling User Adaptation Layers", Brian Bidulock, 7-Feb-07, This memo describes ASP Congestion (ASPCONG) that provides the ability for an Application Server Process (ASP) to indicate congestion to a Signalling Gateway (SG) for the SS7 Signalling User Adaptation Layers [M2UA], [M3UA], [SUA], [ISUA], [TUA]. Extension parameters and procedures are added by this memo in extension to those of the User Adaptation layers to provide for ASP congestion. "SS7 MTP2-User Peer-to-Peer Adaptation Layer Implementer's Guide", Brian Bidulock, 7-Feb-07, This Internet-Draft provides information for the Internet community on clarifications and interpretations of the text of the SS7 MTP2-User Peer-to-Peer Adaptation Layer [M2PA] based on working group comments and experience at interoperability events. It also provides information on specification addendum and errata -- whether of an editorial or technical nature -- discovered to the date of this document. "LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS", Marc Lasserre, Pranjal Dutta, 5-Mar-07, [RFC4762] defines a mechanism to remove or unlearn MAC addresses that have been dynamically learned in a VPLS Instance for faster convergence on topology change. The MAC addresses removed in this procedure also include the MAC addresses learned in a VSI that are not affected due to such topology change. This document defines an extension to LDP Address Withdraw Message with empty MAC List defined in [RFC4762], that enables a Provider Edge(PE) device receiving the message to remove only the MAC addresses that are affected and need to be relearned. "DHCP Option for LDAP Directory Services discovery", Giuseppe Paterno, 28-Sep-06, This document defines an experimental DHCP option for delivering configuration information for LDAP services. Through this option, the client receives an LDAP URL [8] of the closest available LDAP server/replica that can be used to authenticate users or look up any useful data. "OSPF HMAC Cryptographic Authentication", Manav Bhatia, 1-Mar-07, This document describes a mechanism for authenticating OSPF packets by making use of the HMAC algorithm in conjunction with the SHA family of cryptographic hash functions. Because of the way the hash functions are used in HMAC construction, the collision attacks currently known against SHA-1 do not apply. This will be done in addition to the already documented authentication schemes described in the base specification. "Cryptographic Algorithm Implementation Requirements for OSPF", Manav Bhatia, 1-Mar-07, OSPF defines three different kinds of authentication schemes: Null authentication, simple password and cryptographic authentication. The cryptographic authentication scheme can make use of various cryptographic algorithms in order to authenticate the OSPF packets. To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms to be used for the cryptographic authentication for OSPF as well as specifying the algorithms that should be implemented because they may be promoted to mandatory at some future time. "An Enhanced Mobile IPv6 Handover for Roaming between Administrative Domains Based on AAA", Youngsong Mun, 27-Dec-06, When Mobile IPv6 (MIPv6) is deployed in commercial network, a mobile node needs AAA services for authentication, authorization and accounting. MIPv6, however, does not provide any mean to authenticate mobile nodes that are roaming in different domains, although visited networks will need to check whether access of mobile nodes should be authorized or not. Hence schemes which support both AAA services and mobility have been emerged. These schemes enable access of the mobile node to be authorized by visited networks through AAA as well as to perform a home registration during AAA procedure. However, they introduce lots of signal messages and long handover latency during handover, since Route Optimization mode for MIPv6 is performed using Return Routability procedure. Especially, the long handover latency is a critical problem in real-time communication such as voice over IP (VoIP). To solve these problems, we propose an optimized scheme which performs Route Optimization mode using the AAA infrastructure between the home agent and a correspondent node instead of Return Routability procedure. "Traffic Engineering Attribute", Don Fedyk, 19-Oct-06, This document defines a new BGP attribute, Traffic Engineering attribute, than enables BGP to carry Traffic Engineering information. "Definitions for TCP Connection Metrics", Terry Brugger, 17-Aug-06, Numerous metrics, or features, have been used to describe TCP connections. These features are frequently of interest to the network intrusion detection community, and occasionally the network engineering community. While researchers may understand these terms when used by others, there are no formal definitions of these terms such that two researchers looking at the same connection will necessarily calculate the same values for all the metrics. This paper will propose a potential set of connection metrics with formal definitions of each. "GIST Legacy NAT Traversal", Andreas Pashalidis, Hannes Tschofenig, 7-Mar-07, This document describes an extension to the General Internet Signalling Transport (GIST) protocol that enables the protocol to traverse different types of Network Address Translator (NAT). These NATs are assumed to not support GIST, i.e. to be "legacy" NATs. The purpose of this extension is to enable GIST hosts to correctly interpret signalling messages with respect to the data traffic they refer to, in the presence of such NATs. Note that this extension does not require changes to the format of GIST messages; it merely requires some new behaviour for non-NAT GIST nodes. "RObust Header Compression: RTP, UDP, ESP Profiles with Efficient Support for Reordering", Rohit Kapoor, 22-Oct-06, This document describes ROHC (Robust Header Compression) profiles for compression of RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), UDP/IP and ESP/IP (Encapsulating Security Payload) headers. These profiles inherit most of their functionality from the RFC 3095 profiles, with the exception that efficient support for out-of-order delivery of packets is added to these new profiles. The profiles defined in this document do not provide mechanisms to alleviate the issues with reordering in the R mode, and these profiles SHOULD be used only in the U/O modes. "LDAP Schema for eXtensible Resource Identifier (XRI)", Marty Schleiff, 25-Sep-06, This document describes Attribute Types and an Object Class for use in representing XRI (eXtensible Resource Identifier) values in LDAP (Lightweight Directory Access Protocol) and X.500 directory services. "Device Capability Negotiation for Device-Based Location Determination and Location Measurements in HELD", Martin Thomson, James Winterbottom, 21-Feb-07, A framework for the exchange of capabilities in HELD is described. A device is able to use this framework to notify a LIS of its location determination or location measurement capabilities. A method based on this framework where the LIS can use the location determination capability of the device is described. Guidelines for diverse location measurement technologies are included. "Cryptographic Algorithm Implementation Requirements for IS-IS", Manav Bhatia, Vishwas Manral, 1-Mar-07, IS-IS currently defines two different kinds of authentication schemes: Clear Text password and HMAC-MD5. There has been recently a new draft submitted that adds support for a generic cryptographic authentication scheme, which can make use of different cryptographic algorithms in order to authenticate the IS-IS PDUs. To ensure interoperability between disparate implementations, it is imperative that we specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms to be used for the cryptographic authentication for IS-IS as well as specifying the algorithms that should be implemented because they may be promoted to mandatory at some future time. "Coping with Early Media in the Session Initiation Protocol (SIP)", Brian Stucker, 19-Oct-06, Several mechanisms for early media have been proposed in the past, each attacking a different aspect of the problem. A good example of this is RFC-3960 which talks about two models of early media: the gateway model, and the application model. The gateway model uses a series of offer/answer exchanges to control the rendering of early media, but breaks down in the presence of forking (as mentioned in section 3 of RFC-3960). The application model relies on the UAS to know when it is generating early media and use RFC-3959 to keep early media and regular media streams separate to avoid clipping. Even in the presence of the recommendations in RFC-3960 some problems exist within SIP in the area of early media. Although some of these challenges are likely to never be overcome, for example when interworking with a PSTN gateway that does not take into account CPG or ACM messages (in the case of ISUP). However, the potential to improve on what is already there does exist. This document attempts to go into more detail around early media where RFC-3960 left off, what sorts of mechanisms are in use today in existing implementations to deal with the challenges at hand, derives requirements and a possible mechanism to improve upon the current model. In addition, the document goes into other areas that can complicate or be complicated by the presence of early media (especially with forking) such as SRTP keying and media flow authorization. "MANET IANA Needs", Ian Chakeres, 19-Oct-06, This document enumerates IANA assignments for immediate use in MANET. Specifically, a UDP port, two link-local multicast group addresses (IPv4 & IPv6), and two site-local multicast group addresses (IPv4 & IPv6). "The application/xspf+xml Media Type", Lucas Gonze, 26-Sep-06, This document defines a new media type for the XML Shareable Playlist Format (XSPF, pronounced like "spiff"). XSPF allows playlists to be exchanged between different software, across networks and across administrative boundaries. A media type registration enhances shareability. An XSPF playlist describes a sequence of objects to be rendered in time. Objects might be audio, video, text, playlists, or any other media type with an inherent duration. The function of an XSPF document is to identify the objects and communicate their order. "Authentication, Authorization and key management for DHCPv6", Vishnu Ram, 5-Sep-06, Dynamic Host Configuration Protocol version 6 (DHCPv6) authentication, as described in RFC3315, makes use of a model described in RFC3118. The DHCP threat model is described in RFC3118. However, RFC3118 does not discuss the distribution of keys to the server and the client. It assumes that the keys are transferred to the server and client using out of band mechanisms. This draft proposes to make use of the security association that the client shares with its home Authentication, Authorization and Accounting (AAA) servers. The security association between the client and server are established during DHCPv6 messaging. This document specifies options to DHCPv6 messages that can be used to create DHCPv6 Security Associations between the client and server. "LDAP Session Tracking Control", Mark Wahl, 27-Feb-07, Many network devices, application servers, and middleware components of a enterprise software infrastructure generate some form of session tracking identifiers, which are useful when analyzing activity and accounting logs to group activity relating to a particular session. This document discusses how Lightweight Directory Access Protocol version 3 (LDAP) clients can include session tracking identifiers with their LDAP requests. This information is provided through controls in the requests the clients send to LDAP servers. The LDAP server receiving these controls can include the session tracking identifiers in the log messages it writes, enabling LDAP requests in the LDAP server's logs to be correlated with activity in logs of other components in the infrastructure. The control also enables session tracking information to be generated by LDAP servers and returned to clients and other servers. Three formats of session tracking identifiers are defined in this document. "Unified L2 Abstractions for L3-Driven Fast Handover", Fumio Teraoka, 21-Feb-07, This draft proposes unified L2 abstractions for L3-driven fast handovers. For efficient network communication, it is vital for a protocol layer to know or utilize other layer's information such as a form of L2 triggers. However, each protocol layer is basically designed independently. Since each protocol layer is also implemented independently in current operating systems, it is very hard to exchange control information between protocol layers. To solve the problem, this draft defines nine kinds of L2 abstractions in the form of "primitive" to achieve fast handovers in the network layer. This mechanism is called "L3-driven fast handovers" because the network layer initiates L2 and L3 handovers by using the "primitives". "IP Performance Metrics (IPPM) reporting registry", Emile Stephan, Barriac Vincent, 7-Mar-07, The intend of this memo is to set up an IANA registry that collects best current practices in terms of reporting IP Performance Metrics (IPPM) measurements for composition, to users and to end-users. It proposes default values for well known usages and focuses on the identification of the information that should be reported to increase interoperabilty between standard metrics measurements and to facilitate the exchange of measurements results through measurement applications. "Address Autoconfiguration for MANET: Terminology and Problem Statement", Emmanuel Baccelli, 7-Mar-07, Traditional dynamic IPv6 address assignment solutions are not adapted to mobile ad hoc networks. This document elaborates on this problem, states the need for new solutions, and requirements to these solutions. "P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels", Jean-Louis Le Roux, 7-Mar-07, This document defines procedures for fast reroute protection of Point-To-MultiPoint (P2MP) Traffic Engineering Label Switched Paths (TE-LSP) in MultiProtocol Label Switching (MPLS) networks, based upon Point-To-MultiPoint bypass tunnels. The motivation for using P2MP bypass tunnels is to avoid potentially expensive data duplication along the backup path that could occur if point-to-point bypass tunnels where used, i.e. to optimize the bandwidth usage, during fast reroute protection of a link or a node. During link or node failure the traffic carried onto a protected P2MP TE-LSP is tunnelled within one or several P2MP bypass tunnels towards a set of Merge Points. To avoid data duplication backup labels (i.e. inner labels) are assigned by the Point of Local Repair (PLR) following the RSVP-TE upstream label assignment procedure. "Mobile Ad hoc Network Architecture", Ian Chakeres, 5-Oct-06, This document discusses Mobile Ad hoc NETworks (MANETs). It introduces basic MANET terms, characteristics, and challenges. This document also defines several MANET entities and architectural concepts. "Logging Capabilities for IP Network Infrastructure", George Jones, Patrick Cain, 20-Sep-06, This document lists logging capabilities originally defined in RFC3871 and needed to support the current practices, including those described in the Operational Security Current Practices document[CURPRAC] Logging is defined as the delivery to another entity or system of messages about the device, the data passing through the device, or the device's interaction with another device. Capabilities are defined without reference to specific technologies. This is done to leave room for deployment of new technologies that implement the capability. Each capability cites the practices it supports. Current implementations that support the capability are cited. Special considerations are discussed as appropriate listing operational and resource constraints, limitations of current implementations, trade offs, etc. "Delay-Tolerant Networking Custodial Multicast Extensions", Susan Symington, 19-Oct-06, This document defines optional extensions to the Bundle Protocol [2] for supporting the custodial multicast delivery of bundles within a Delay-Tolerant Network (DTN). The protocol extensions described herein may be used to support custody transfer and custody-based reforwarding during the transmission of a bundle from a single source node to multiple destination nodes. "Delay-Tolerant Networking Previous Hop Insertion Block", Susan Symington, 2-Feb-07, This document defines an extension block that may be used with the Bundle Protocol [2] within the context of a Delay-Tolerant Network architecture [4]. This Previous Hop Insertion Block is designed to be inserted by a forwarding node to provide information to its next- hop receiving node. This block is always removed from the bundle by the receiving node so that it's duration within the bundle lasts for exactly one hop. It provides a general insertion capability to enable any node that forwards a bundle to insert an arbitrary record (or records) of information into the bundle. While this block is defined to provide an arbitrary insertion capability, this specification also defines two specific, mandatory, information record formats for the information that may be carried in the Previous Hop Insertion block. Using these mandatory information record formats, an insertion block may be used to carry the inserting/forwarding node's endpoint ID (EID), which may be required in some circumstances to support certain routing protocols (e.g., flood routing). This document defines the format and processing of this Previous Hop Insertion Block. "Sender Policy Framework: SPF Options", Frank Ellermann, 25-Oct-06, In discussions about the Sender Policy Framework (SPF) users often want to add optional properties to their sender policies. The modifier "match_subdomains=yes" made it into early SPF drafts. This memo proposes a general syntax for a modifier "op=" for this purpose. "Application Mechanism for maintaining alive the Network Address Translator (NAT) mappings associated to RTP flows.", Xavier Marjou, 2-Feb-07, This document defines a mechanism that enables applications using Real Time Protocol (RTP) to maintain their RTP Network Address Translator (NAT) mappings alive. "Interworking between P2PSIP Overlays and Conventional SIP Networks", Enrico Marocco, David Bryan, 2-Mar-07, This document describes how user agents registered in P2PSIP overlay networks can interwork with those in conventional SIP networks. Communications between any two user agents will happen through the SIP protocol and the location of SIP servers will follow the usual procedures. However, interworking in some environments may require the support of additional elements; this document also describes such elements and how to locate them in P2PSIP overlays. "The Hypertext Transfer Protocol (HTTP) Entity Tag ("ETag") Response Header in Write Operations", Julian Reschke, 27-Nov-06, The Hypertext Transfer Protocol (HTTP) specifies a state identifier, called "Entity Tag", to be returned in the "ETag" response header. However, the description of this header for write operations such as PUT is incomplete, and has caused confusion among developers and protocol designers, and potentially interoperability problems. This document explains the problem in detail and suggests both a clarification for a revision to the HTTP/1.1 specification (RFC2616) and a new header for use in responses, making HTTP entity tags more useful for user agents that want to avoid round-trips to the server after modifying a resource. "Progressive Posting Rights Suspensions", Brian Carpenter, 18-Oct-06, This document restores the previous option of finite posting rights suspensions authorized by an Area Director. It also abolishes the existing form of indefinite Posting Rights Action. It obsoletes RFC 3683 and RFC 3934, and updates RFC 2418. "BGP Protocol extensions for PCE Discovery across Autonomous systems", C Vijayanand, 27-Nov-06, It is desirable for a PCC to dynamically discover a PCE and its capabilities for computing paths which span multiple areas and autonomous systems. When the path to be computed spans across multiple IGP domains or autonomous systems, it is advantageous to use BGP to distribute information about PCEs. This document describes means to carry PCE discovery information using Multi-protocol extensions of BGP(MP-BGP). "On the Use of Channel Bindings to Secure Channels", Nicolas Williams, 7-Mar-07, The concept of channel binding allows applications to establish that the two end-points of a secure channel at one network layer are the same as at a higher layer by binding authentication at the higher layer to the channel at the lower layer. This allows applications to delegate session protection to lower layers, which has various performance benefits. This document discusses and formalizes the concept of channel binding to secure channels. "The SIP BLOCKED Response", Amardeep Sinha, Sunil Kumar Sinha, 23-Jan-07, This document defines a new response code, 4XX(Blocked), for the Session Initiation Protocol (SIP). This response code can be used by User Agent Client (UAC) that intentionally does not want to have session with an incoming request from another user with particular SIP services. For example UAC does not want to establish a session with an incoming request for video conference from particular domain. The existing mechanisms in SIP do not provide any such facility to refuse a request based request Uniform Resource Identifier (URI), SIP application, media type or other SIP services. "On the Use of Channel Bindings to Secure Channels", Jeffrey Altman, Nicolas Williams, 13-Dec-06, This document defines a form of channel bindings for TLS (Transport Layer Security), namely the concatenation of the initial client and server "finished" messages for a TLS connection. "Transport Layer Security (TLS) Evidence Extensions", Mark Brown, Russ Housley, 21-Nov-06, This document specifies evidence creation extensions to the Transport Layer Security (TLS) Protocol. Extension types are carried in the client and server hello message extensions to confirm that both parties support the protocol features needed to perform evidence creation. The syntax and semantics of the evidence creation alerts and messages are described in detail. "Automatic Telephone Configuration Protocol", Bernd Buxmann, Ralf Hintner, 16-Aug-06, This document is about the Automatic Telephone Configuration Protocol (ATCP). ATCP provides a framework for passing configuration information to SIP-telephones in a Voice over IP-network and to register users in the network. ATCP needs DHCP for configuring the telephones with TCP/IP-networkparameters (e.g. IP-address). "An Interface and Algorithms for Authenticated Encryption", David McGrew, 5-Mar-07, This document defines algorithms for authenticated encryption with additional authenticated data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. "IPv6 Prefix Delegation using ICMPv6", Satya Rao, 21-Feb-07, The currently proposed solution for IPv6 Prefix Delegation is based on DHCPv6 protocol. We believe that in certain network topologies and configurations where the CPE routers may not be capable or configured to use DHCPv6 and hence can not utilize the currently proposed DHCPv6 based ipv6 prefix delegation procedure. Therefore an alternate ipv6 prefix delegation procedure that does not require or depend on the DHCPv6 protocol is needed. This document proposes an ICMPv6 based prefix delegation (PD) mechanism which is in conformance with RFC 3769 that describes the requirements for IPv6 prefix delegation. This proposal involves using the Router Solicitation (RS) message for the prefix request and the Router Advertisement(RA) message for the prefix delegation. A new flag called P-flag (bit 0 of the reserved field) is defined to indicate that the RS message includes a PD request. RS messages with PD request can now include PIO option(s) to carry PD information such as prefix preference(s) or PD parameters such as lease etc. It also proposes defining a new flag called D-flag (reserved bit 26) of the PIO option to indicate the presence of PD specific PIO in RS and RA messages. "Use of DNS SRV and NAPTR Records for SPEERMINT", Tom Creighton, Gaurav Khandpur, 15-Sep-06, The objective of this document is to specify the Best Current Practice (BCP) adopted by a Voice Over IP (VoIP) service provider in order to locate another VoIP service provider to peer with in the context of Session PEERing for Multimedia INTerconnect. "VoIP Shim for RTP Payload Formats", Ingemar Johansson, 23-Oct-06, This document provides a general mechanism to provide with compact and efficient inband signaling mechanisms for VoIP applications using the RTP (Real-Time Transport Protocol). It provides the option to include a few additional inband signaling bytes in between the RTP header and the RTP payload. The intention of using Shim is to enable a fast inband signaling channel that can be used for adaptation purposes. The intention of the proposed inband signaling is that it should act as a wrapper around the actual payload. For instance if the payload is AMR-NB (RFC 3267), shim will encapsulate the payload in a fashion similar to RCF2198. In order to distinguish this encapsulated payload from a "normal" payload, necessary attributes are specified in SDP. The main application is for two party teleconferencing but the presented mechanism can be used for multi party teleconferencing applications as well. The name Shim is to refer to the "little thing something that one put in between". The name Shim is to refer to the "little thing something that one put in between". "RPSL extensions for 32 bit AS Numbers", Katie Petrusha, Henk Uijterwaal, 26-Sep-06, This document specifies extensions to the RPSL language for dealing with 32 bit (4 byte) AS numbers. It also gives a list of RPSL attributes that will be affected by this change and that may require tools to be updated. "MAC Hiding in an H-VPLS Environment", Ian Cowburn, 20-Oct-06, This document describes a mechanism for hiding customer MAC addresses on a PE-rs in an H-VPLS environment. In the H-VPLS hierarchy, a PE-rs is exposed to the MAC addresses for customers on its directly attached MTU-s and the remote MAC addresses for all of its configured VPLS instances. This can result in the requirement to store a large number of a MAC addresses. This document introduces the concept of an MTU-id per MTU-s which is included with the customer frame sent by an MTU-s. The PE-rs is then able to switch based on the MTU-id rather than the customer MAC addresses, thereby reducing the address storage requirements on the PE-rs to be of the order of the number of MTU-s. "TLS and DTLS Transport Mapping for IPFIX", Fuyou Miao, 23-Jan-07, This document describes the use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) to provide a secure communication for the transport of IPFIX protocol. "VoIP Security Threats relevant to SPEERMINT", Eric Chen, Saverio Niccolini, 1-Mar-07, This memo presents the different security threats related to SPEERMINT classifying them into threats to the Location Function, to the Signaling Function and to the Media Function. The different instances of the threats are briefly introduced inside the classification. Finally the existing security solutions in SIP and RTP/RTCP are presented to describe the countermeasures currently available for such threats. The objective of this document is to identify and enumerate the SPEERMINT-specific threat vectors in order to specify security-related requirements. Once the requirements are identified, methods and solutions how to achieve such requirements can be selected. "LDAP Subtree Data Source URI Attribute", Mark Wahl, 12-Dec-06, This document defines an attribute that enables administrative clients using the Lightweight Directory Access Protocol (LDAP) to determine the source of directory entries. "SAM Problem Statement", Shivanand Kadadi, John Buford, 2-Jan-07, We describe the generally expected behavior of a scalable and adaptive multicast architecture, leaving further details to separate documents on requirements and the SAM design space. This document is a starting point for discussions of feasibility, priority, and deployability. "Session Description Protocol (SDP) Offer/Answer Negotiation For Best-Effort Secure Real-Time Transport Protocol", Francois Audet, Hadriel Kaplan, 25-Oct-06, This document defines the requirements and a proposed solution for an SDP Offer/Answer exchange model for negotiating best-effort SRTP keys, i.e., in a backward-compatible manner with non-SRTP devices. The proposed solution is a trivial interpretation of the usage of the profile and the usage of SDP indication of [sdesc] and [kmgmt]. "NFSv4 file_masks Attribute", Andreas Gruenbacher, J. Bruce Fields, 24-Sep-06, Some NFSv4 servers allow a mode SETATTR to restore ACL permissions which were removed by a previous mode SETATTR. This allows servers to handle mode SETATTRs without destroying the information in ACLs. However, these temporarily masked permissions are not exposed to clients. This proposal adds an optional new file attribute, file_masks, which can be used by clients to see these temporarily masked permissions. "A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure", Henning Schulzrinne, 28-Sep-06, The Location-to-Service Translation Protocol (LoST) describes an XML- based protocol for mapping service identifiers and geospatial or civic location information to service contact Uniform Resource Locators (URLs). LoST servers can be located anywhere but a placement closer to the end host, e.g., in the access network, is desireable. Such a LoST server placement provides benefits in disaster situations with intermittent network connectivity regarding the resiliency of emergency service communication. This document describes how a LoST client can discover a LoST server using the Dynamic Host Configuration Protocol (DHCP). "Dynamic Feature Extensions to the Presence Information Data Format Location Object (PIDF-LO)", Vishal Singh, 8-Mar-07, The Geopriv Location Object introduced by the Presence Information Data Format Location Object (PIDF-LO), RFC 4119, defines a basic XML format for carrying geographical information of a presentity. This document extends the element specified in RFC 4119 to carry temporal feature elements useful for tracking moving objects. It defines five elements, namely speed, bearing, acceleration elevation and directionOfObject. The document also specifies mechanism to carry multiple moving object's status elements and proposes mechanism to indicate the type of the PIDF-LO content. "SCS: Secure Cookie Sessions for HTTP", Stefano Barbato, 7-Sep-06, This document provides an overview of SCS, a cryptographic protocol aimed at the protection of "client-side" HTTP sessions, i.e. sessions in which the application state is held entirely on the client in the form of cookies [10]. "Analysis of IPv6 Link Models for 802.16 based Networks", Syam Madanapalli, 27-Sep-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. "The Call Type tel URI Parameter for Session Initiation Protocol (SIP)", C Sivachelvan, 8-Sep-06, This document describes a standardized mechanism to convey the "Call Type" parameter in tel Uniform Resource Identifiers (URIs). A new extension to the tel URI is defined for this purpose. Call Type is a form of classification of a dialed number in a telephony call; it classifies the call as a Local-Call, Toll-Call, International-Call, etc. A definition of each Call Type addressed in this specification is provided in Section 2. "Multiplexing RTP Data and Control Packets on a Single Port", Magnus Westerlund, Colin Perkins, 25-Sep-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. "An Authorized IP Firewall Control Application", Melinda Shore, David McGrew, 10-Sep-06, The Authorized Firewall Control Protocol provides an interface that allows network entities to request firewall and NAT services and resources. It is an instance of a protocol that provides authorizations and other security servcies, and interworks with other such instances. AFWC uses its authorization facilities to provide network administrators more control over network border admissions decisions than is provided by other firewall pinholing protocols. "Node behavior upon originating and receiving Resource ReserVation Protocol (RSVP) Path Error message", JP Vasseur, 22-Oct-06, The aim of this document is to describe a common practice with regard to the behavior of a node sending a Resource ReserVation Protocol (RSVP) Path Error message and to the behavior of a node receiving an RSVP Path Error message for a particular Multi-Protocol Label Switching - Traffic Engineering (MPLS-TE) Label Switched Path (LSP). "An ITSP Problem Statement Regarding SIP Peering", Andrew Newton, 10-Sep-06, This document illustrates the operational considerations of Internet Telephony Service Providers (ITSP) with regard to SIP peering. "Transmission of IPv6 packets over Ethernet CS over IEEE 802.16 network", HongSeok Jeon, 10-Sep-06, This document describes transmission of IPv6 packets over Ethernet CS over IEEE 802.16 network. In this document, two possible network deployment scenarios are discussed and behaviors for corresponding scenario are suggested in order to support IPv6 transmission over Ethernet CS over IEEE 802.16 network. "Channel bindings for HTTP+TLS transport", Leif Johansson, 7-Mar-07, This document specifies a channel concept for HTTP with TLS and a representation of that channel which can be used by protocols which use channel bindings to delegate session protection to lower layers. "BGP Community for PA Multihoming", Iljitsch van Beijnum, 28-Sep-06, When an organization wants to connect to the internet using two or more Internet Service Providers (multihoming), this is usually done by setting up BGP routing between the organization in question and each of its ISPs. For this, the multihomed organization needs a block of address space. This can either be a provider independent (PI) address block that belongs to the organization, or a block out of the provider aggregatable (PA) address space of one its ISPs. With IPv4, an address block of at least /24 will generally be suitable for multihoming, whether its origin is PI or PA. However, until now, ISPs were encouraged to only accept /32 and shorter prefixes from IPv6 PA space, while end-users generally receive a /48. This makes multihoming with PA address space in IPv6 very difficult. This memo describes a new well-known BGP community attribute for tagging prefixes used for multihoming with PA space in order to facilitate filtering, rather than filter based on prefix length alone. "Text conversation with real-time preview", Gunnar Hellstrom, 27-Feb-07, This specification defines a method for presentation of a real-time text conversation. The aim is to give the participants in a conversation a good opportunity to perceive the real-time flow of the conversation and also provide a display of the history of the conversation that makes it easy to read. This is achieved by arranging the presentation of the conversation in separate areas for real-time text entries in creation versus completed text entries. "DHCPv6 Relay Agent Link Selection(RALS) Option", Yuping Zhao, 12-Sep-06, This document defines a new Relay Agent Link Selection(RALS) option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6).The new option is inserted by the DHCPv6 relay agent when forwarding client- originated DHCPv6 packets to a DHCPv6 server. Servers recognizing this new option can include link-selection information as part of policies about address assignment, prefix delegation, or other DHCP parameters. "Cosmogol: a language to describe finite state machines", Stephane Bortzmeyer, 13-Nov-06, Several RFCs contain a state machine to describe a protocol. There is no standard way of describing such a machine, the most common way being an ASCII-art diagram. This document specifies an other solution: a domain-specific language for finite state machines. It allows state machine descriptions to be automatically checked and may be translated into other formats. Its purpose is to provide a stable reference for RFCs which use this mini-language. "Mobility Independent Services: Problem Statement", Eleanor Hepworth, 27-Oct-06, There are on-going activities in the networking community to develop solutions that aid in IP handover mechanisms between heterogeneous wired and wireless access systems including, but not limited to, IEEE 802.21. Intelligent access selection, taking into account link layer attributes, requires the delivery of a variety of different information types to the terminal from different sources within the network and vice-versa. The protocol requirements for this signalling have both transport and security issues that must be considered. The signalling must not be constrained to specific link types, so there is at least a common component to the signalling problem which is within the scope of the IETF. This draft presents a problem statement for this core problem. "Transporting User to User Information for Call Centers using SIP", Alan Johnston, Joanne McMillen, 28-Dec-06, Several approaches to transporting User to User Information (UUI) in Contact Center scenarios have been implemented. This document discusses the approaches and recommends a single approach for standardization. "IPv4 over IPv6 multicast", Mingwei Xu, 13-Sep-06, The 4over6 mechanism is a mechanism to interconnect IPv4 networks over IPv6 backbones and provide IPv4-to-IPv6 transparent routing. The 4over6 unicast has been described in draft-wu-softwire-mesh-framework-00.txt. This memo provides the 4over6 multicast mechanism. We use BGP for discovering and maintaining the membership among all the Provider Edges (PE), and use IPv6 and IPv4 PIM-SM to construct the distribution tree. In the IPv6 backbone, static PIM-SSM trees are initially constructed for every PE. All the multicast traffic from the same PE are forwarded through only one PIM-SSM tree to avoid P routers maintaining too much state information. The process of encapsulation and decapsulation is the same as 4over6 unicast. "MLDv1 and MVDv2 Optimization", Arun Prasad, 14-Sep-06, This document describes an optimization for MLDv1 (RFC 2710) and MLDv2 (RFC 3810). As per this optimization, a new router on coming up will not send periodic "General Query" messages to get the list of multicast listeners. Instead, it will try to get the same from the Querier on the link. Only if no Querier are present on the link, will the new router move to Querier state and send "General Query" messages. This approach provides an advantage in eliminating possibly large number of "Multicast Listener Report" messages every time a new router comes up on a link. More the number of listeners on a link, more the advantage. "The PANA API", Yoshihiko Kainuma, Fumio Teraoka, 20-Oct-06, Protocol for carrying Authentication for Network Access (PANA) provides support for authentication for network access between end- user and the Internet. This document proposes the design a standardised API for the PANA protocol. The API is defined in the C language. The goal of the API is to foster extensible PANA implementation. "Pre-Congestion Notification Problem Statement", Kwok Ho Chan, 25-Oct-06, DiffServ mechanisms have been developed to support Quality of Service (QoS). However, the level of assurance that can be provided with DiffServ without substantial over-provisioning is limited. Pre- Congestion Notification (PCN) investigates the use of per-flow admission control to provide the required service guarantees for the admitted traffic. While admission control will protect the QoS under normal operating conditions, an additional flow pre-emption mechanism is necessary in the times of heavy congestion (e.g. caused by route changes due to link or node failure). This document provides a problem statement on the addition of flow admission control and flow pre-emption functionality to a DiffServ network, in particular for the support of real time services such as voice and video. "An Adaptive FEC to Protect RoHC and UDP-Lite Vital Video Data", Zhikui Chen, 15-Sep-06, This document generally describes how to use an Adaptive Forward Error Correction (AFEC) algorithm to efficiently protect the compressed header vital data as well as UDP-Lite’s vital data for data transport in the radio-link layer of an error-prone wireless connection. Augmented with RoHC and UDP-Lite, for video transmissions over wireless channels in a heterogeneous wired- wireless environment, the erroneous packet payloads can be useful and the applications better able to cope with lost packets (native UDP case), by adopting some of the erasure and error resilient modes in the latest video codecs, such as H.264. The context transfer in the inter/intra handover is also covered. "Specific Route uRPF (SRU)", Dai Guangming, Zhao Ye, 15-Sep-06, This document describes a mechanism to extend Unicast Reverse Path Forwarding(uRPF). By associating an uRPF flag with a specific route, uRPF can be controlled in a finer granularity than traditional one. It may be used to reduce the cost to network devices caused by uRPF. "IPv6 Dynamic Flow Label Switching (FLS)", Martin Beckman, 26-Nov-06, This document seeks to establish a standard for the utilization of the Class of Service Field and the us of the Flow Label Field within the IPv6 Header and establish a methodology of switching packets through routers using the first 32-bits of the IPv6 header using Flow Label Switching on packets rather than full routing of packets. Within the first 32-bits of an IPv6 header exists the requisite information to allow for the immediate “switching” on an ingress packet of a router, allowing for “Label Switching” of a native IPv6 packet. This allows the establishment of VPN circuits in a dynamic manner across transit networks. The establishment of “Flows” based upon the 20-bit “Flow Label” value can be done dynamically with minimal effort and configuration of the end-point routers of the flow. The flows can be managed or open, encrypted or in the clear, and will allow for greater scalability, security, and agility in the management and operation of networks. "The IMAP ENABLE Extension", Arnt Gulbrandsen, 2-Mar-07, Most IMAP extensions are used by the client when it wants to and the server supports to. However, a few extensions require the server to know whether a client supports that extension. The ENABLE extension allows an IMAP client to say which extensions it supports. "IMAP4 extension for named searches (filters)", Curtis King, Alexey Melnikov, 19-Sep-06, The document defines a way to persistently store named IMAP (RFC 3501) searches on the server. Such named searches can be subsequently referenced in a SEARCH command. "IMAP QUOTA Extension", Dave Cridland, Alexey Melnikov, 19-Sep-06, The QUOTA extension of the Internet Message Access Protocol (RFC 3501) permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol. This memo obsoletes RFC 2087, but attempts to remain backwards compatible whenever possible. "A Session Initiation Protocol (SIP) Event package for Peering", Reinaldo Penno, 20-Oct-06, This document defines a new SIP event package for the exchange of SIP peering policies. It describes how SIP SUBSCRIBE/NOTIFY and PUBLISH methods can be used by SIP Proxies engaged in peering to exchange peering polices with minimal user or administrative intervention. It also provides a description of the surrounding architecture in the context of SPEERMINT. "IPv6 Header Compression via Addressing Mitigation Protocol (IPv6 AMP)", Martin Beckman, 9-Mar-07, This document outlines a methodology for IPv6 Header Compression via mapping the source and destination addresses into a flow label value per address pair sessions with a specific traffic class field value to identify the packet as “address-less” compressed header. The resultant headers, sans addresses shrink from 320 bits to 64 bits. This mapping is locally specific to the router port and the connecting hosts/router ports. Specifically written for use on low bandwidth links (less than T1 or 1.544Mbps), IPv6 AMP’s applicability goes to integration of cellular/WiFi appliances and will be critical for tactical uses for military and first responder applications. "SIP and SAML roaming profile", Silvana Greco, Henning Schulzrinne, 19-Sep-06, Roaming services allow users that have a contract with a voice service provider to use access resources owned by other providers known as internet access providers. This draft proposes a token- based Authentication, Authorization, Accounting (AAA) and billing model for roaming users. It also introduces a protocol solution for the proposed model that is based on the Assertion Markup Language (SAML) protocol and the Session Initiation Protocol (SIP). "Multi-Domained, Multi-Homed Mobile Networks", William Ivancic, 20-Sep-06, This document describes numerous problems associated with deployment of multi-homed mobile platforms consisting of multiple networks and traversing large geographical areas. The purpose of this document is to provide insight to real-world deployment issues and provide information to working groups that are addressing many issues related to multi-homing, policy-base routing, route optimization and mobile security. "Pre-Authentication AAA requirements", Madjid Nakhjiri, Yoshihiro Ohba, 20-Sep-06, Pre-authentication as a solution for providing expedited authenticataion service as part of handover is being considered within a potentially new working group. This draft intends to describe the requirements set forth by Pre-authentication procedure on AAA protocols and attributes. "Application of PANA framework to DSL networks", Lionel Morand, 20-Sep-06, This document provides guidelines for PANA deployment over DSL access networks. The document specifically describes the introduction of PANA in DSL networks migrating from a traditional PPP access model to a pure IP-based access environment. "A Novel Framework for Inter-area MPLS Optimal Routing", Peng He, Gregor Bochmann, 25-Sep-06, We propose a novel framework for inter-area MPLS optimal routing. The key to our proposal lies in deploying an overlaid star optical network in the OSPF backbone area and introducing the concept of "virtual area border routers" (v-ABRs). Compared with other proposals, our framework can provide globally optimized inter-area routing and has very good compatibility to existing traditional IP/MPLS routers. "IPv6 Address Specific BGP Extended Communities Attribute", Yakov Rekhter, 25-Sep-06, Current specifications of BGP Extended Communities [BGP-EXTCOMM] support IPv4 Address Specific Extended Community, but do not support IPv6 Address Specific Extended Community. The lack of IPv6 Address Specific Extended Community may be a problem when an application uses IPv4 Address Specific Extended Community, and one wants to use this application in a pure IPv6 environment. This document defines a new BGP attribute, IPv6 Address Specific Extended Community that addresses this problem. The IPv6 Address Specific Extended Community is similar to the IPv4 Address Specific Extended Community, except that it carries an IPv6 address rather than an IPv4 address. "MIB for the UDP-Lite protocol", Gerrit Renker, Gorry Fairhurst, 22-Nov-06, This document specifies a Management Information Base (MIB) for the Lightweight User Datagram Protocol (UDP-Lite, RFC 3828). It defines a set of new MIB entities to characterise the behaviour and performance of transport layer entities deploying UDP-Lite. UDP-Lite resembles UDP (RFC 768), but differs from the semantics of UDP by the addition of a single (socket) option. This adds the capability for variable-length data checksum coverage, which can benefit a class of applications that prefer delivery of (partially) corrupted datagram payload data in preference to discarding the datagram. "The application/www-form-urlencoded format", Bjoern Hoehrmann, 25-Sep-06, This memo defines a compact data format that encodes data sets of name-value pairs. It is designed to be suitable for use as query strings in Internationalized Resource Identifiers and as standalone format. "The Internet Standards Process -- Version 4", Scott Bradner, Eliot Lear, 26-Sep-06, This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. "IMAP4 Multimailbox SEARCH Extension", Barry Leiba, Alexey Melnikov, 2-Oct-06, The IMAP4 specification allows the searching only of the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the round-trips and waiting for various searches to complete. This also introduces mailbox field in ESEARCH responses, allowing a client to pipeline the searches if it chooses. "Pseudowire (PW) Redundancy", Praveen Muley, 8-Mar-07, This document describes few scenarios where PW redundancy is needed. A set of redundant PWs is configured between PE nodes in SS- PW applications, or between T-PE nodes in MS-PW applications. In order for the PE/T-PE nodes to indicate the preferred PW path to forward to one another, a new status bit is needed to indicate the preferential forwarding status of active or standby for each PW in the redundancy set as defined in [7]. "BGP UPDATE Advertisement Restriction", Dai Guangming, 27-Sep-06, SIDR working group is working on an extended architecture for interdomain routing security framework. One of the functions that this architecture should provide is origin authentication of prefixes for BGP, i.e. a BGP speaker must be able to determine whether an AS (autonomous system) is authorized to originate certain prefixes. This draft documents some ideas from the perspective of internal control in order to alleviate this problem. "Aviation Global Internet Operations Requirements", Terry Davis, 27-Sep-06, The commercial aviation industry is among the first to develop and deploy mobile networks capable of utilizing Internet communications services around the world. In development of this capability the industry developed their own standards for the use of IP based communications within the aircraft and on the direct connected off- board links. This document defines aviationOs desired Internet usages and capabilities and the gaps the industry sees in basic Internet technology required for the full utilization of the Internet by mobile platforms. "BGP Anycast Node Requirements for Authoritative Name Servers", Shinta Sato, 8-Mar-07, This memo describes the details of requirements and preconditions for making "Global-Scope" IP anycast nodes for authoritative name servers, with the conformance of the practices in RFC 2182, 2870, 3258 and 4786. This memo is intended to be used for the DNS operators who are going to deploy IP Anycast nodes, especially for the TLD operators. "RTP payload format for UEMCLIP speech codec", Yusuke Hiwasaki, Hitoshi Ohmuro, 21-Feb-07, This document describes the RTP payload format of an ITU-T G.711 enhanced speech codec, UEMCLIP. The bitstream has a scalable structure with an embedded u-Law bitstream, also known as PCMU, thus providing a handy transcoding operation between narrowband and wideband speech. "The record-jar Format", Addison Phillips, 28-Sep-06, The record-jar format provides a method of storing multiple records with a variable repertoire of fields in a text format. This document provides a description of the format. Comments are solicited and should be addressed to the mailing list 'record-jar@yahoogroups.com' and/or the author. "Atom Publishing Protocol Features Extension", James Snell, 10-Oct-06, This document introduces extensions to the Atom Publishing Protocol introspection format for expressing metadata about the features supported by an Atom Publishing Protocol server implementation. "Diameter base loop avoidance Extension", Vishnu Ram, Satendra Gera, 29-Sep-06, The Diameter base protocol which is intended to provide Authentication, Authorization and Accounting (AAA) framework for applications (such as network access) is specified in [RFC 3588]. [RFC 3588] specifies a loop detection mechanism which handles looped messages at the intermediate diameter agent nodes. This draft discusses a possible loop avoidance mechanism for diameter request messages. "DKIM Originating Signing Policy (DOSP)", Douglas Otis, 10-Oct-06, DOSP (DKIM Originator's Signing Policy) is a DNS-based mechanism for associating domain-names and asserting separate DKIM related policies for all originating header fields and parameters found in DKIM related messages. DOSP can associate an email-address with a list of signing domains, and a signing domain with a list of SMTP Clients. DOSP also provides a means to assert whether signatures are always initial provided, whether there was an effort to protect these signatures, and their role related to offering assurances, such as when an identity referencing the DOSP policy is assured to be valid. "The IMAP NOTIFY Extension", Curtis King, 2-Mar-07, This document defines an IMAP extension which allows a client to request specific kinds of unsolicited notifications, such as messages being added to or deleted from mailboxes. "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 With IPsec", Scott Kelly, Sheila Frankel, 8-Jan-07, This specification describes the use of HMAC in conjunction with the SHA-256, SHA-384, and SHA-512 algorithms in IPsec. These algorithms may be used as the basis for data origin authentication and integrity verification mechanisms for the AH, ESP, IKE and IKEv2 protocols, and also as Pseudo-Random Functions (PRFs) for IKE and IKEv2. Truncated output lengths are specified for the authentication-related variants, with the corresponding algorithms designated as HMAC-SHA-256-128, HMAC-SHA-384-192, and HMAC-SHA-512-256. The PRF variants are not truncated, and are called HMAC-SHA-PRF-256, HMAC-SHA-PRF-384, and HMAC-SHA-PRF-512. "NETCONF Master-agent Sub-agent Communication Protocol", Jayaprakash Kulkarni, 2-Oct-06, This memo contains a mechanism by which NETCONF server and client can extended to operate in a master-agent sub-agent scheme. It extends the base NETCONF protocol with additional NETCONF operations, describes the protocol for this interaction and provides error messages exchanged during this interaction. "Authority Information Access Attribute Certificate Extension", Dave Cooper, 2-Oct-06, This document updates RFC 3281 by specifying the use of the id-ad- caIssuers access method of the Authority Information Access extension in an attribute certificate (AC). The Authority Information Access extension is defined in RFC 3280 and RFC 3281 specifies the use of the id-ad-ocsp access method of the Authority Information Access extension in attribute certificates. When present in an attribute certificate, the id-ad-caIssuers access method provides a means of discovering and retrieving the public key certificate of the attribute certificate's issuer. "DHCP User-based Authentication", Yuping Zhao, 1-Mar-07, This document defines a mechanism to couple DHCP to an authentication, authorization and accounting (AAA) system in an access network, thus enabling users to supply user credentials for AAA via DHCP. "Congestion Control in the RFC Series", Michael Welzl, Wesley Eddy, 2-Oct-06, This document is a survey of congestion control topics within the RFC series. The intent of this document is to be an informational snapshot of the current state of Internet standards and other IETF products related to congestion control. This is an initial product of the IRTF's Internet Congestion Control Research Group and may be used as one reference or starting point for the future work of the research group. "Binary to Decimal Conversion for Location Configuration Information", John Schnizlein, Marc Linsner, 4-Oct-06, This document describes the nature of the data expressed in the geographic LCI defined in RFC 3825, and includes examples of conversion from its binary format to decimal character strings. "QoS-aware SIP User Agent operation in QoS-supporting networks", Vincenzo Mancuso, 4-Oct-06, This document describes the inter-working of a SIP (Session Initiation Protocol) User Agent, SUA, located into a software instance of a IP phone (Softphone), and a SIP Proxy located in the access network where the user connects to Internet. The model addressed is the one of a customer using a service offered by a service provider, and the operation described only applies to the negotiation and management of such kind of services. The network architecture is supposed to be private, and the service provider is in charge to negotiate network resources with network provider(s) on behalf of the customer, if necessary. Aim of this draft is to highlight the need of inter-working functions that allows service providers to use network-driven SIP messages to establish and manage multimedia over IP connections. "Handling Large User Datagram Protocol (UDP) Responses in the Session Initiation Protocol (SIP)", Vijay Gurbani, Scott Lawrence, 4-Oct-06, The Session Initiation Protocol (SIP) mandates a maximum size for any request transmitted over UDP. This maximum is set to the lesser of 1300 bytes or the path maximum transmission unit (MTU) size minus 200 bytes. If the size of the request exceeds this maximum, SIP requires implementations to switch the downstream transport to be a congestion controlled transport. However, when sending a response, a SIP implementation cannot choose the transport; it must use the transport specified by the Via. This document discusses the problems large responses can cause on UDP, and proposes an update to SIP to help diagnose and avoid those problems. "URI Template", Joe Gregorio, 4-Oct-06, URI Templates are strings that can be transformed into URIs after embedded variables are substituted. This document defines the structure and syntax of URI Templates. "DHCP Option Processing, Explained", David Hankins, 5-Oct-06, Most protocol developers ask themselves if a protocol will work, or work efficiently. These are important questions, but another less frequently considered is wether the proposed protocol changes present themselves barriers to adoption by deployed software (more importantly, needlessly so). This document seeks to provide information on the challenges to DHCP Option software implementers, and in doing so to provide guidance to prospective DHCP Option authors to help them produce options that are easily adoptable. "Preventing IP Fragmentation in Responses for the Session Initiation Protocol (SIP)", Marc Petit-Huguenin, 5-Mar-07, There is limited support to prevent IP fragmentation when using a UDP or Datagram Transport Layer Security (DTLS) transport with the Session Initiation Protocol (SIP). This document describes an extension to prevent fragmentation in SIP responses. "JSON Uniform Messaging Protocol (JUMP)", Robert Sayre, 29-Jan-07, JUMP uses HTTP and a lightweight layout for JSON records to edit the Web. "Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer", Jon Green, Douglas Stebila, 19-Oct-06, This document describes algorithms based on Elliptic Curve Cryptography (ECC) for use within the Secure Shell (SSH) transport protocol. In particular, it specifies: Elliptic Curve Diffie-Hellman (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement and Elliptic Curve Digital Signature Algorithm (ECDSA) for use in the SSH Transport Layer protocol. "LDP Typed Wildcard FEC", Bob Thomas, Ina Minei, 6-Oct-06, The LDP specification [RFC3036] for the Wildcard FEC element has several deficiencies. This document corrects those deficiencies. In addition, it specifies the Typed Wildcard FEC for the Prefix FEC Element Type defined in RFC3036. "Registry for tv:URIs", Iko Keesmaat, Oskar van Deventer, 6-Oct-06, The tv:URI is an existing Uniform Resource Identifier (URI) scheme to refer to television broadcasts. These include all types of analog and digital television broadcasts, like terrestrial TV broadcasts, satellite TV broadcasts, cable TV broadcast, IP television and web TV. This document defines a registry for tv:URIs. A registry is needed to solve the ambiguity about tv:URIs in two directions: for each (registered) tv:URI it identifies uniquely and unambiguously the television broadcast it refers to, and vice versa it provides a single tv:URI for each (registered) television broadcast. "Media Type Registrations for OEBPS Package File (OPF)", Garth Conboy, 6-Oct-06, This document serves to register a media type for the Open eBook Publication Structure (OEBPS) Package Files. "Authentication Scheme for Public ENUM Applications", Chen Hui, 9-Oct-06, ENUM possesses the feature of E.164 number authenticity, therefore by being carried with initiation signal of application services, ENUM number can be used to identify originer. The service initiation signal includes sender's (originer's) un- encrypted ENUM number and encrypted ENUM number, or some other information needed by specific applications, then receiver decrypts encrypted ENUM number and compares decrypted result with the un- encrypted ENUM number to authenticate the originer's identity. "IPsec Application Programming Interfaces", Sasu Tarkoma, Miika Komu, 8-Mar-07, IPsec based security is usually transparent for applications and and they h have no common mechanism for gathering information about protected network connections and being aware of underlying security mechanisms. This document specifies an API that increases the visibility of IPsec to applications. The API allows applications to use the Stand-alone BTNS mode, control the channel bindigs, and control also other network security properties related to IPsec. "IPv6 Prefix Delegation routing state maintenance approaches", Markus Stenberg, Ole Troan, 9-Oct-06, The maintenance of Prefix Delegation (PD) routing state is an issue that people have discussed in the IETF DHC WG, and there have been drafts on the topic. However, as the pros and cons of the different routing state maintenance solutions have not been examined thoroughly, this text attempts to shed some light on both the actual problem and the various alternative solutions. "RTP Payload Format for DV (IEC 61834) Video", Katsushi Kobayashi, 9-Oct-06, This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as "DV" into a payload format for the Real-Time Transport Protocol (RTP). This document Obsoletes RFC 3189. "Access Node ANCP MIB", Stefaan De Cnodder, Moti Morgenstern, 9-Oct-06, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing access nodes as described in [ANCPFW] that are using the Access Node Control Protocol (ANCP) defined in [ANCPPR]. "DAI Parameter for the "tel" URI", James Yu, 8-Mar-07, This document defines a "dai" parameter for the "tel" Uniform Resource Identifier (URI) to support the Dial Around Indicator (DAI). The "dai" parameter is associated with the "cic" parameter, defined in [RFC 4964], and indicates how the carrier identified in the "cic" parameter is chosen to handle the call. This document expands the use of the "cic" parameter so that implementations that support pre-subscribed and dial carrier requirements. "Authentication/Confidentiality for OSPFv2", Mukesh Gupta, Nagavenkata Melam, 9-Oct-06, This document describes means and mechanisms to provide authentication/confidentiality to OSPFv2 using IPsec (IP Security). "Route Distinguisher Zero Value Usage", Luca Martini, Keyur Patel, 10-Oct-06, The behaviour that must be followed when an route distinguisher (RD) of value zero is received is not clearly defined in rfc4364. This document clarifies the use of an RD with a value of zero in the context defined in rfc 4364. "Contexts for IMAP4", Dave Cridland, Curtis King, 11-Oct-06, The IMAP4rev1 protocol has powerful search facilities as part of the core protocol, and a similarly powerful SORT extension, but lacks the ability to create live, updated results which can be easily handled. This memo provides such an extension, and shows how it can be used to provide a facility similar to virtual mailboxes. "An encapsulation for TRILL", Silvano Gai, 11-Oct-06, A new layer of encapsulation is required with RBridges. A previous Internet Draft [2] (draft-bryant-perlman-trill-pwe-encap-00) proposes an encapsulation header that contains a Nickname, a flag, TTL and CoS. This document introduces additional fields, and gives arguments for their usefulness. As a result the encapsulation header needs to be expanded and will no longer be able to be in MPLS format. The WG will need to decide on the tradeoffs between this additional functionality, and compatibility with an existing (MPLS) format. "BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute", Pradosh Mohapatra, Eric Rosen, 20-Feb-07, This document specifies a new BGP SAFI, Encapsulation SAFI. A BGP update message of this SAFI contains an NLRI which uniquely identifies the BGP speaker that originated the update. The purpose of such an update is to carry attributes that define how encapsulated packets need to be delivered to the sender. For instance, if one BGP speaker needs to use an IP-based encapsulation in order to deliver traffic to a second, the second BGP speaker can use this SAFI to specify information about the encapsulation header that it expects. A BGP tunnel encapsulation attribute is specified for this purpose. Other attributes, including communities and/or extended communities, can also be included. "Path Computation Element Communication Protocol (PCECP) Requirements and Protocol Extensions In Support of Global Concurrent Optimization", Young Lee, 1-Mar-07, The Path Computation Element (PCE) is a network component, application, or node that is capable of performing path computations at the request of Path Computation Clients (PCCs). The PCE is applied in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to determine the routes of Label Switched Paths (LSPs) through the network. The Path Computation Element Communication Protocol (PCEP) is specified for communications between PCCs and PCEs, and between cooperating PCEs. When computing or re-optimizing the routes of a set of LSPs through a network it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network- wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A Global Concurrent Optimization is able to simultaneously consider the entire topology of the network and the complete set of existing LSPs, and their respective constraints, and look to optimize or re-optimize the entire network to satisfy all constraints for all LSPs. This document provides application-specific requirements and the PCEP extensions in support of a global concurrent path computation application. "Session Description Protocol (SDP) Format for Real Time Streaming Protocol (RTSP) Streams.", Xavier Marjou, 12-Oct-06, This document specifies how to describe RTSP streams in SDP session descriptions. Agents using the offer/answer model to establish RTSP streams use this format in their offers and their answers. "Authentication-Key Rollover mechanism for Routing and Management Protocols", Sriram Viswanathan, 12-Oct-06, This memo discusses the authentication for routing and management protocols based on preconfigured keys,the need and basis for key rollover, and an mechanism to seamlessly rollover the authentication keys. It is intended for an application where secure administrative access to all the end-points of the protocol connection is normally available. The strategy described herein improves upon the current practice where a key is preconifigured at all endpoints and the key rollover is done manually within a short synchronized window to avoid connection drops due to key mismatch. "Inter-AS PCE Path Sequence Autoexplore", Mach Chen, 12-Oct-06, In Inter-AS scenario, as usual, multiple Path Computation Elements (PCEs) will take part in path computation. [PCE-DISCO-OSPF], [PCE- DISCO-ISIS],PCE-DISCO-BGP] or some other means can be used to discover all underling PCEs, but there is lack of solutions to find out those PCEs and their sequence which are engaged in computing an end-to-end inter-AS TE LSP. This document proposes a solution to identify these PCEs and their sequence which can be used to compute a TE LSP across multiple ASes. "A Framework Migrating Legacy Routers to ForCES Architecture", Huanyuan Ma, 18-Jan-07, The forwarding and Control Element Separation (ForCES) working group is defining a protocol by which control elements (CEs) can communicate with forwarding elements (FEs) and control the behaviors of FEs. It is well known that ForCES based solutions have good scalability. Therefore, it makes sense to adopt ForCES to better integrate existing physical routers with ForCES routers. Plus, someone may want going forward to be able to use the developed hardware and software from existing routers as a part of ForCES based solutions. This draft presents a framework in which some possible migration solutions are discussed in details and some security implications are considered. "Nexthop Based Outbound Route Filter for BGP-4", Renhai Zhang, Mach Chen, 12-Oct-06, This document defines a new Outbound Route Filter type for BGP, termed "Nexthop Outbound Route Filter", which can be used to provide Nexthop based route filtering. "Locate ASBR in PCE", Renhai Zhang, Mach Chen, 12-Oct-06, The ability to compute constrained shortest Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. This document specifies a procedure for an inter-AS PCE to locate boundary node within its domain dynamically, which is used for path computation. "Design considerations for protocol extensions", Brian Carpenter, 5-Mar-07, This document discusses issues related to the extensibility of Internet protocols, with a focus on the architectural design considerations involved. Concrete case study examples are included. It is intended to assist designers of both base protocols and extensions. "Requiring support for appealing to the IESG and IAB", Olaf Kolkman, 12-Oct-06, RFC 2026 outlines the procedure for appealing decisions or process failures to the IESG and the IAB. This document describes how an appellant should first gain support for filing their appeal before an appeal is being considered. "Multicast VPN Scalability Benchmarking", Silvija Dry, 28-Feb-07, Multicast VPN (MVPN) is a service deployed by VPN service providers to enable their customers to use IP multicast applications over VPNs. With the increased popularity the scalability of deploying such a service is becoming of a great interest. This document defines standard metric and test methodology for characterizing and comparing control plane MVPN scalability of Provider Edge (PE) devices that implement MVPN service. "Advertising an IPv4 NLRI with an IPv6 Next Hop", Francois Le Faucheur, Eric Rosen, 19-Dec-06, MultiProtocol-BGP (MP-BGP) specifies that the set of Network Layer protocols to which the address carried in the Next Hop field may belong is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The current AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a Next Hop address that belongs to the IPv4 protocol when advertising an IPv4 Network Layer Reachability Information (NLRI) or a VPN-IPv4 NLRI. This document specifies the extensions necessary to allow advertising an IPv4 NLRI or a VPN-IPv4 NLRI with a Next Hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the Next Hop for an IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the Next Hop in order to determine which of the protocols the address actually belongs to, and a new BGP Capability allowing MP-BGP Peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. "Atom Bidirectional Attribute", James Snell, 6-Dec-06, This document adds a new attribute to the Atom Syndication Format used to indicate the base directionality of directionally-neutral characters. "Multicast VPN Deployment Recommendations", Yiqun Cai, 13-Oct-06, Multicast VPN based on early standards has been in operation in production networks for several years now. This document describes some of the experience gained from implementation and deployment and as such is informational only. "A set of monitoring tools for Path Computation Element based Architecture", Jean-Louis Le Roux, JP Vasseur, 1-Mar-07, A Path Computation Element (PCE) based architecture has been specified for the computation of Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks in the context of single or multiple domains (where a domain is referred to as a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems). In PCE-based environments it is thus critical to monitor the state of the path computation chain that can be used for performance monitoring and troubleshooting purposes. This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) in order to gather such information. "GDOI Extensions", Ya Liu, Xu Chen, 13-Oct-06, The GDOI Protocol [RFC3547] specifies a standard mechanism of group SA management. Two extensions are described in this document to increase the Protocol's availability. "Specification for use of EAP EMSK in deriving Mobile IP root keys", Madjid Nakhjiri, Changsheng Wan, 13-Oct-06, [USRK] proposes a new mechanism for deriving cryptographically separate usage specific root keys (USRK) from the EAP extended master session key (EMSK). This document follows the procedure suggested in [USRK] to derive root keys for Mobile IPv4, Mobile IPv6, and proxy Mobile IP. "FMIPv6 extension for Multicast Handover", Frank Xia, Behcet Sarikaya, 7-Mar-07, FMIPv6 extends Mobile IPv6 for reducing handover delays. But it does not deal with the scenario that an MN joins multicast trees using it's CoA in a visited link. The document proposes an extension to FMIPv6 to handle local multicast traffic during handover. "Generic Action RPC for Netconf", Balazs Lengyel, 13-Oct-06, The NETCONF protocol defines a number of operations to read and write configuration data. However, it does not define actions on the managed nodes. Such actions are useful for 1) operations that do not change the configuration data (e.g. ping) 2) reading or writing a set of data that forms a logical group but might be scattered in different parts of the management data model. This document defines a new Netconf capability supporting a generic operation. A modeling view of how the content of the generic operation can be defined is also described. Please send comments to netconf@ops.ietf.org. To subscribe, use netconf-request@ops.ietf.org. "Requirements for vertical handover of multimedia sessions using SIP", Saverio Niccolini, 23-Feb-07, This document analyses the issue of handling vertical handovers among different network technologies using SIP. "GSSAPI authentication for HTTP", Leif Johansson, 7-Mar-07, This document specifies an extention to the HTTP Negotiate authentication mechanism defined in RFC4559 which supports mutual authentication, fast session-based reauth and channel bindings. "Diameter Location-Update common message", Vishnu Ram, Satendra Gera, 13-Oct-06, The Diameter base protocol which is intended to provide Authentication, Authorization and Accounting (AAA) framework for applications (such as network access) is specified in [RFC 3588]. [RFC 3588] specifies a number of reusable common messages which can be used across applications. This draft adds to the list of common messages by adding a location update message which can be used in different existing and potential authentication ,authorization and accounting scenarios. "MIPv6 bootstrapping solution for split and integrated scenario using DHCPv6", Saumya Upadhyaya, 13-Oct-06, In mobile IPv6 (MIP6), there is a need to transfer the home agent address, home IP address to the mobile node when the mobile node is in the foreign network. This problem is referred to as bootstrapping. This document defines a Bootstrapping Information Server Function (BISF) and Bootstrapping Information Client Function (BICF). The BICF uses AAA messaging for obtaining the bootstrapping information from the BISF. Such a mechanism can be used by either the integrated or split scenarios. "Delay-Tolerant Networking Retransmission Block", Susan Symington, 13-Oct-06, This document defines an optional extension block, called a Retransmission Block, that may be used with the Bundle Protocol [2] within the context of a Delay-Tolerant Network architecture [4]. The Retransmission Block (RB) is designed to be inserted by a custodian when re-forwarding a bundle, so as to mark the bundle as a legitimate custody-based retransmission rather than an unauthorized bundle duplicate. By providing a way for nodes that receive the re- forwarded bundle to distinguish it from an unauthorized duplicate, the RB enables those nodes whose local security policies do not permit them to forward replayed bundles to detect and delete unauthorized bundle replays but forward authorized custody-based bundle retransmissions. This document defines the format and processing of this new Retransmission Block. "Discovering Outbound Proxies and Providing High Availability with Client Initiated Connections in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 13-Oct-06, In many deployment configurations, Session Initiation Protocol (SIP) clients are capable of initiating connection requests towards their SIP server, but the SIP server cannot open connections towards the client. Specifications have been developed which allow for a client- initiated connection to be used for incoming requests towards the client. This outbound connection involves the use of a SIP proxy, called an outbound proxy, that the client connects to. However, the specification does not provide a means to discover the outbound proxy, nor does it support high availability for failures of the outbound proxy mid-dialog. This specification fills those gaps. The resulting mechanism additionally provides solutions for inter-proxy connection reuse and usage of certificates with SIP. "DHCP v4/v6 Proxy", Behcet Sarikaya, Kuntal Chowdhury, 13-Oct-06, Dynamic Host Configuration Protocol Proxy server is a DHCP server and hence it supports DHCP protocol but it does not have local address repository. It outsources the address repository function to external nodes or functional elements in a network. This document explains Proxy DHCP operation and presents some use cases. "Applying Loose Routing to Session Initiation Protocol (SIP) User Agents (UA)", Jonathan Rosenberg, 13-Oct-06, A key part of the behavior of the Session Initiation Protocol (SIP) is that SIP proxies rewrite the Request-URI as a request moves throughout the network. Over the years, experience has shown this to be problematic. It makes it difficult to use Request URI for service invocation, complicates emergency services, makes it more complex to support aliases, and so on. Architecturally, it confounds the concepts of address and route. This document proposes to change this through a new mechanism called UA loose routing. "User Defined Errors for RSVP", George Swallow, Adrian Farrel, 5-Mar-07, The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object for communicating errors. That object has a defined format that permits the definition of 256 error codes. As RSVP has been developed and extended, the convention has been to be conservative in defining new error codes. Further, no provision for user defined errors exists in RSVP. This document defines a new RSVP object to permit user defined error values to be communicated. "Extensions to RFC4379 in Support of Link Bundles", Thomas Nadeau, 16-Oct-06, This document specifies extensions to MPLS LSP Ping's tracing function as specified in IETF RFC4379 to support link bundle constructs. In particular, we extend the Echo Request packet format to include a new Link Bundle TLV that can contain both the virtual link bundle interface ID, as well as a description of the ECMP algorithm used by said interface. The existing downstream mapping processing algorithm for midpoints is modified to specify that when link bundles are encountered, that the component links should be revealed as would non-component links in the existing algorithm. "Problem statement on the cross-realm operation of Kerberos in a specific system", Shoichi Sakane, 9-Nov-06, There are some issues when the cross-realm operation of the Kerberos Version 5 [RFC4120] is employed into the specific systems. This document describes some manners of the real example, and lists requirements of the operation in such real system. Then it clarifies issues when we apply the cross-realm operation to such specific system. "Context updates in BGP", Martin Djernaes, 16-Oct-06, Currently BGP protocol can carry reachability information for multiple Address Families (AFI) and Subsequence Address Families (SAFI) using the Multiprotocol Extension[RFC2858], but it is limited to grouping of information based on the AFI/SAFI hierarchy. This document describes a mechanism to group and exchange prefix information based on properties other than just the AFI/ SAFI[RFC2858]. The mechanism is flexible and backwards compatible with the current methods for exchanging prefixes and hence does not require any changes to the the protocol formats. It introduces a new capability that allows two BGP speakers negotiate during the BGP OPEN phase in order to define what each AFI/SAFI means. In other words, the concept of a 'context' is defined and each such 'context' can be mapped to an AFI/SAFI. The context to AFI/SAFI mapping is only relevant to the BGP peers of the BGP session and hence offers great flexibility in how 2 BGP speakers can choose to group and exchange prefix information. "Application of PWE3 to MPLS Transport Networks", Stewart Bryant, 16-Oct-06, A need has been identified to identify a strict subset of the PWE3 over MPLS pseudowire functionality suitable for the construction of transport networks. This draft describes the IETF recommended profile for such cases. This document describes the IETF-recommended profile for such a configuration. In particular the profile of an RFC4448 PWE3 Ethernet pseudowire that can be used to address these requirements is described. "Hypertext Transfer Protocol -- HTTP/1.1", YVES LAFON, 21-Nov-06, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [RFC2324]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC2616. "GDOI Key Establishment for the SRTP Data Security Protocol", Mark Baugher, Adrian-Ken Rueegsegger, 16-Oct-06, The Secure Real-time Transport Protocol (SRTP) secures unicast and multicast media streams. Multicast receivers of an SRTP stream therefore share an SRTP master key for multicast message authentication and decryption. This document describes how to establish a shared, "group key" for an SRTP session using RFC 3547, the Group Domain of Interpretation (GDOI) and RFC 2408, the Internet Security Association and Key Management Protocol. This document extends GDOI for SRTP group key establishment. "Extensible Messaging and Presence Protocol (XMPP): Core", Peter Saint-Andre, 29-Jan-07, This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a technology for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network-aware entities. XMPP provides a generalized, extensible framework for incrementally exchanging XML data, upon which a variety of applications can be built. The framework includes methods for stream setup and teardown, channel encryption, authentication of a client to a server and of one server to another server, and primitives for push-style messages, publication of presence and availability information, and request-response interactions between any two XMPP entities. This document also specifies the format for XMPP addresses, which are fully internationalizable. This document obsoletes RFC 3920. "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", Peter Saint-Andre, 29-Jan-07, This document describes extensions to the core features of the Extensible Messaging and Presence Protocol (XMPP) that provide basic instant messaging (IM) and presence functionality in conformance with RFC 2779. This document obseletes RFC 3921. "Interoperability Report for the Extensible Messaging and Presence Protocol (XMPP)", Peter Saint-Andre, 16-Oct-06, This document provides an interoperability report regarding the Extensible Messaging and Presence Protocol (XMPP), as that technology is specified in RFCs 3920 and 3921 (and their proposed successors). This report specifies both a protocol feature set and a protocol implementation report, in accordance with the concepts and formats proposed by Larry Masinter within the NEWTRK Working Group. "Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic", David McGrew, Brian Weis, 16-Oct-06, This memo describes the use of Advanced Encryption Standard (AES) counter modes when applied to the Encapsulating Security Payload (ESP) and Authentication Header (AH) in multiple-sender group applications. "A Uniform Resource Name Namespace For The GSM Association (GSMA) and the International Mobile station Equipment Identity(IMEI)", Michael Montemurro, 6-Feb-07, This specification defines a Uniform Resource Name namespace for the GSMA and sub namespaces for the IMEI (International Mobile station Equipment Identity), and for the IMEISV (International Mobile station Equipment Identity and Software Version number). The IMEI is 15 decimal digits long and the IMEISV is 16 decimal digits long and are both encoded using Binary Encoded Decimal (BCD). The IMEI and IMEISV were introduced as part of the specification for Global System for Mobile (GSM) and are also now incorporated by the 3rd Generation Partnership Project (3GPP) as part of the 3GPP specification for GSM, and the Universal Mobile Telecommunications System (UMTS). The IMEI and IMEISV are used to uniquely identify Mobile Equipment within these systems and are managed by the GSMA (GSM Association). "How to Share Transaction Fraud (Thraud) Report Data", David M'Raihi, 8-Mar-07, This document describes a data-format and protocol for defining and exchanging Transaction Fraud (Thraud) Report Data. It extends the INCH WG's IODEF XML [IODEF] incident reporting format. Both inbound (Thraud Reports) and outbound (Thraud Watchlists) mechanisms are presented. This work has been endorsed by the Initiative for Open AuTHentication [OATH]. "A User Identifier for Centralized Conferencing (XCON)", Chris Boulton, Mary Barnes, 1-Mar-07, A conferencing system is defined by "A framework and Data Model for Centralized Conferencing" and represents a container for administering and managing all conference related information. The conference user concept is introduced in the framework to identify the entity participating in a conference and manipulating conferencing system related properties. This document defines a Conference User Identifier and provides some guidelines for identifying a specific conference user within a conferencing system. The document also provides some examples of the logical mapping of this conference user identifier to protocol and signaling interface specific user identifiers. "A Universal Resource Identifier (URI) for Centralized Conferencing (XCON)", Chris Boulton, Mary Barnes, 1-Mar-07, A Uniform Resource Identifier (URI) is defined as a compact string of characters for identifying an abstract or physical resource. This document defines a URI scheme and syntax for the conference object identifier, as defined in "A Framework and Data Model for Centralized Conferencing". "Analysis of the Enhanced Mode in Layer One Virtual Private Networks (L1VPNs)", Dan Li, 13-Feb-07, This document presents detailed information with respect to the four sub-models of the Layer One Virtual Private Network (L1VPN) enhanced mode. Each sub-model is evaluated from different points of view, such as Topology Confidentiality, scalability, and reliability. The requirements on GMPLS to support each sub-model of the L1VPN enhanced mode are also discussed in this document. "Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)", Hasnaa Moustafa, 16-Oct-06, The Access Node Control Protocol (ANCP) aims to communicate QoS-, service- and subscriber-related operations between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)). The main goal of this protocol is to configure and manage access equipments and allow them to report information to the NAS in order to enable and optimize configuration. This document investigates security threats that all ANCP nodes could encounter, developing a threat model for ANCP security aiming to decide which security functions are required at the ANCP level. Based on this, security requirements regarding the Access Node Control Protocol are defined. "Route Optimization for Mobile Nodes in Mobile Network", Zheng Huang, 16-Oct-06, This document specifies a mechanism for enabling mobile nodes in IPv6 mobile network to perform route optimization. The route optimization is possible because mobile router provides a care-of address for mobile nodes in mobile network which we call Virtual Care-of Address (VCoA). The VCoA uses the network prefix of the access network. Mobile nodes register VCoA as its own care-of address with home agent and correspondent nodes. With little modification to mobile nodes and correspondent nodes, mobile router deals with the packets forwarding between them. "Multihomed IPv6 prefix delegation, aggregation, and distribution", Fred Baker, Marla Azinger, 16-Oct-06, This document presents IETF commentary to the Registry and ISP communities on how to maximize aggregation while supporting multihoming. Multihomed networks fall broadly into two categories, those that are in some senses comparable to an ISP and those that are simply edge networks or VPNs of edge networks. The best solution for multihoming may be different for these differing categories of networks. "CAPWAP Roaming Protocol in 802.11R Domains", Behcet Sarikaya, Robert Jaksa, 16-Oct-06, This document describes the Control And Provisioning of Wireless Access Points (CAPWAP) Roaming Protocol (CAPWAPRP) for roaming in domains where 802.11R is supported. "SIP Controlled Admission and Preemption", Jozef Babiarz, 16-Oct-06, This framework defines a method of providing Explicit Congestion Control to real-time inelastic traffic like voice and video through the use of session admission control and preemption mechanisms. This approach uses the Pre-Congestion Notification Marking (PCN) [1] mechanism. PCN marking is deployed in routers to measure and convey two levels of onset of congestion with the SIP controlled endpoints responding to the marking. This approach is different from what is defined in An edge-to-edge Deployment Model for Pre-Congestion Notification [3], as here the admission and preemption control function resides in the application (either in the endpoint or the application server that controls the endpoint. This framework is focused on using Session Initiated Protocol (SIP) as the application signaling protocol but other application signaling protocols could be extended for this purpose. "The OSPF Opaque LSA Option", Lou Berger, 16-Oct-06, This memo defines enhancements to the OSPF protocol to support a new class of link-state advertisements (LSA) called Opaque LSAs. Opaque LSAs provide a generalized mechanism to allow for the future extensibility of OSPF. Opaque LSAs consist of a standard LSA header followed by application-specific information. The information field may be used directly by OSPF or by other applications. Standard OSPF link-state database flooding mechanisms are used to distribute Opaque LSAs to all or some limited portion of the OSPF topology. This document replaces [RFC2370], and adds to it a mechanism to enable an OSPF router to validate AS-scope opaque LSAs originated outside of the router's OSPF area. "Definitions of Textual Conventions for Path Computation Element", Emile Stephan, 16-Oct-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 Textual Conventions to represent commonly used Path Computation Element (PCE) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in PCE related MIB modules to avoid duplicating conventions. "Dynamic Symmetric Key Provisioning Protocol", Mingliang Pei, Salah Machani, 26-Oct-06, This document specifies a symmetric key provisioning protocol that supports provisioning of symmetric keys (One Time Password (OTP) keys or symmetric cryptographic keys) and associated attributes dynamically to already issued different types of strong authentication devices. This work is a joint effort by the members of OATH (Initiative for Open AuTHentication) to specify a protocol that can be freely distributed to the technical community. The authors believe that a common and shared specification will facilitate adoption of two- factor authentication on the Internet by enabling interoperability between commercial and open-source implementations. "The SIP SPECIFY Method", Sreeram Kanumuri, Subhodeep Sarkar, 16-Oct-06, This document proposes an extension to the Session Initiation Protocol (SIP). This extension adds the SPECIFY method to the SIP protocol. The intent of the SPECIFY method is to allow conveying SIP entity's (Proxy, User Agent, Redirect Server) intention of asynchronous service change (i.e. to be taken out of service or has just return to service) with and with out a backup SIP entity within the same administrative domain. "A Call Completion Service for the Session Initiation Protocol (SIP) Using the Binary Floor Control Protocol (BFCP)", Adam Roach, 16-Oct-06, This document proposes extensions to the Session Initiation Protocol (SIP) and the Binary Floor Control Protocol (BFCP) for service request and queue manipulation related to the Completion of Calls to Busy Subscribers (CCBS) and Completion of Calls on No Reply (CCNR) services. "Transport-layer Considerations for Explicit Cross-layer Indications", Pasi Sarolahti, 8-Mar-07, Several types of explicit cross-layer communication schemes have been proposed to enhance the transport protocol performance. However, various challenges with such schemes have been identified, for example concerning the interactions with the middleboxes and tunnels in the network. This document discusses different types of explicit cross-layer notification mechanisms that have been proposed to enhance end-to-end transport performance. We analyze the different mechanisms using a taxonomy based on what kind of network interactions they require, and discuss the benefits and disadvantages different approaches have. The objective is to get a common understanding of the possibilities and challenges with these mechanisms, with pointers to past discussions on this topic, and to describe the possible next steps towards removing barriers from explicit cross-layer communication in future protocols. "Pseudo Wire (PW) over L2TPv3 Management Information Base", Thomas Nadeau, 16-Oct-06, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a MIB module for PW operation over Layer Two Tunneling Protocol (Version 3) "L2TPV3". "The use of Asserted Identity in the Session Initiation Protocol (SIP) UPDATE method", John Elwell, 28-Feb-07, SIP has a mechanism for conveying the asserted identity of the originator of a request by means of the P-Asserted-Identity header field. This header field is specified for use in requests using a number of SIP methods, in particular the INVITE method. However, RFC 3325 does not specify the insertion of this header field by a UAC, does not specify the use of this header field with the SIP UPDATE method, and is unclear on the use of this header field in responses. This document extends RFC 3325 to cover these situations. This work is being discussed on the sipping@ietf.org mailing list. "Simple SIP Usage Scenario for Applications in the Endpoints", Alan Johnston, 2-Mar-07, This memo discusses the usage scenario of SIP where all the applications reside in the endpoints. This is an alternative to the current usage of SIP where the services reside in the network. The use of SIP where the applications reside in the endpoints is applicable to P2P SIP networks and also to client-server networks. Such an approach reduces the number of required SIP related standards (as by spring 2007) from roughly 100 to about 11. Successful IP communications must also include the relevant standards for NAT traversal, some of which are not directly related to SIP and also several standards for security. These standards are included in the simple usage scenario for SIP as well. "Session Initiation Protocol Response Code for Invalid Event Parameter Values", Daniel Petrie, 16-Oct-06, This document defines a new error response code and header for SIP Events to indicate when an invalid value is provided in a SUBSCRIBE request Event header parameter. These changes update behavior defined in RFC 3265. "Using DHCPv6 and AAA Server for Mobile Station Prefix Delegation", Behcet Sarikaya, Frank Xia, 6-Mar-07, In the 802.16 Per-MS prefix model, one prefix can only be assigned to one mobile station by an access router and different mobile stations can't share a prefix. Managing Per-MS prefixes is likely to increase the processing load at the access router. Based on the idea that DHCPv6 servers can manage prefixes as well as addresses, we propose a new technique in which the access router offloads delegation and release tasks of the prefixes to an DHCPv6 server. The access router first requests a prefix for an incoming mobile station to the DHCPv6 server. The access router next advertises the prefix information to the mobile station with a Router Advertisement message. When the mobile station leaves, the prefix is returned to the DHCPv6 server. We also describe how prefix delegation can be done by AAA servers as an alternative technique. "Peer-to-Peer SIP Implementation Report", Martin Stiemerling, 16-Oct-06, This memo is an implementation report about the peer-to-peer SIP system developed in the European IST Ambient Networks research project. This system replaces the traditional SIP proxy-registrar function with a distributed lookup mechanism, adds overlay functionality to the SIP signalling and to RTP traffic, takes care about media/packet relay lookup and insertion into the SIP/RTP paths. Standard SIP user agents are used for communication. The presented system is work in progress. "Path Computation Policy Information Model (PCPIM)", Igor Bryskin, Lou Berger, 5-Mar-07, The Policy-Enabled Path Computation Framework [PCE-POLICY] introduced the use of the Policy Core Information Model (PCIM), [RFC3060], as a framework for supporting path computation policy within the context of the Path Computation Element (PCE)-Based Architecture, [RFC4655]. This document defines the Path Computation Policy Information Model (PCPIM), which provides the specifics of using PCIM as the method for supporting path computation policy. PCPIM includes classes that model constraints, conditions, actions, variables and values associated with supporting path computation policy. While PCPIM was conceived to operate within the path computation element (PCE)-based architecture, it can be applied to any path computation methodology. "An IDNA problem in right-to-left scripts", Harald Alvestrand, Cary Karp, 16-Oct-06, The use of right-to-left scripts in internationalized domain names has presented several challenges. This memo discusses one problem resulting from a constraint on the use of combining characters at the end of an RTL domain label, resulting in some words being declared invalid as IDN labels, and proposes a means for ameliorating this problem. "Pre-Congestion Notification Using Single Marking for Admission and Pre-emption", Anna Charny, 6-Mar-07, Pre-Congestion Notification [I-D.briscoe-tsvwg-cl-architecture] approach proposes the use of an Admission Control mechanism to limit the amount of real-time PCN traffic to a configured level during the normal operating conditions, and the use of a Pre-emption mechanism to tear-down some of the flows to bring the PCN traffic level down to a desirable amount during unexpected events such as network failures, with the goal of maintaining the QoS assurances to the remaining flows. In [I-D.briscoe-tsvwg-cl-architecture], Admission and Pre- emption use two different markings and two different metering mechanisms in the internal nodes of the PCN region. This draft proposes a mechanism using a single marking and metering for both Admission and Pre-emption, and presents a preliminary analysis of the tradeoffs. A side-effect of this proposal that a different marking and metering Admission mechanism than that proposed in[I-D.briscoe-tsvwg-cl-architecture] may be also feasible. "Definitions of Managed Objects for Path Computation Element Discovery Protocol", Emile Stephan, 16-Oct-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 objects used for managing Path Computation Elements Discovery. "RTC Provisioning Requirements", Avshalom Houri, 16-Oct-06, The document describes several use cases for peering between two or more communities that provide real time communications services and presence and IM in particular. The communities create a peering relationship between themselves thus enabling their users to collaborate with users on other communities. The target of the document is to help understanding the requirements for peering between domains with regard to real time services "Towards a TCP Security Option", Steven Bellovin, 16-Oct-06, The TCP-MD5 option, commonly used to secure BGP sessions between routers, has many serious deficiencies. We present here justifications for designing a new, more capable version of that option; we also discuss some of the design criteria for one. "Generalized Labels of Lambda-Switching Capable Label Switching Routers (LSR)", Richard Rabbat, 16-Oct-06, Technology in the optical domain is constantly evolving and as a consequence new equipment providing lambda switching capability has been developed and is currently being deployed. RFC 3471 [RFC3471] has defined that a wavelength label (section 3.2.1.1) "only has significance between two neighbors". However, in a network composed of a new generation of lambda switch-capable equipment, this document explains new models that require standardization of the label. It highlights new operator requirements and describes signaling extensions to satisfy those requirements. This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It defines the Label Switching Capable (LSC) technology specific information needed when using GMPLS. "Integrating Identity Based Cryptosystem with Cryptographically Generated Address in Mobile IPv6", Zhen Cao, 17-Oct-06, This document specifies a mechanism to address the address ownership problem as well as the trust relationship between different nodes in the mobile IPv6 network. A mechanism integrating the Identity Based Cryptosystem with Cryptographically Generated Address is utilized to do the job. "Diameter Specification Errata and Issues", Victor Fajardo, 17-Oct-06, This document is a compilation the defects found in the DIAMETER protocol specification based on interoperability event(s) and general implementation discussions. This document is meant to be a companion document to RFC3588 and provides a historical reference to the changes that will incorporated in RFC3588's BIS document. "Proxy LSP Ping", George Swallow, Vanson Lim, 5-Mar-07, This document defines a means of remotely initiating Multiprocal Label Switched Protocol Pings on Label Switched Paths. A proxy ping request is sent to any Label Switching Routers along a Label Switched Path. The primary motivations for this facility are first to limit the number of messages and related processing when using LSP Ping in large Point-to-Multipoint LSPs, and second to enable leaf to root tracing. "Connectivity Verification for Multicast Label Switched Paths", George Swallow, 5-Mar-07, Requirements for MPLS P2MP LSPs extend to hundreds or even thousands of endpoints. This document defines a more scalable approach to verifying connectivity for P2MP LSPs. "Packet Delay Variation Applicability Statement", Benoit Claise, Al Morton, 8-Mar-07, Packet delay variation metrics appear in many different standards documents. The metric definition in RFC 3393 has considerable flexibility, and it allows multiple formulations of delay variation through the specification of different packet selection functions. Although flexibility provides wide coverage and room for new ideas, it can make comparisons of independent implementations more difficult. Two different formulations of delay variation have come into wide use in the context of active measurements. This memo examines a range of circumstances for active measurements of delay variation and their uses, and recommends which of the two forms is best matched to particular conditions and tasks. "Session Initiation Protocol (SIP) Overload Control", Volker Hilt, 5-Mar-07, Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 response code, SIP servers are still vulnerable to overload. This document proposes several new overload control mechanisms for the SIP protocol. "Cryptographic Token Key Initialization Protocol (CT-KIP) Web Service Version 1.0 Revision 0", Andrea Doherty, Magnus Nystroem, 17-Oct-06, This document defines a SOAP-based Web Service interface intended for use by implementor's of the Cryptographic Token Key Initialization Protocol (CT-KIP) to support four-pass (i.e., two round-trip) cryptographic token key initialization. Reader familiarity with CT- KIP is required. "Authentication between the Inbound Proxy and the UAS for Protecting SPIT in the Session Initiation Protocol (SIP)", Souhwan Jung, 17-Oct-06, This memo proposes to add a digest message authentication scheme between the inbound proxy and the UAS for protecting SPIT. Spammers can directly send SIP calls (such as call spam and IM spam) to the UAS using P2P call signaling. For rejecting the SPIT, the UAS should be able to verify that the SIP messages are forwarded by the proxy server, not directly from spammers. By applying the message digest scheme similar to the HTTP digest, the UAS processes the request after assuring that the INVITE message comes through the inbound proxy server. The main advantage of this scheme is to protect SPIT by adding a very simple message authentication scheme between the proxy server and the UAS. "Forward Error Correction (FEC) Framework", Mark Watson, 17-Oct-06, This document provides an initial proposal for a framework for using forward error correction (FEC) codes with applications in the Internet to provide protection against packet loss. The framework supports applying Forward Error Correction to arbitrary packet flows and is primarily intended for streaming media. This framework can be used to define Content Delivery Protocols that provide Forward Error Correction for streaming media delivery or other packet flows. Content Delivery Protocols defined using this framework can support any FEC Scheme (and associated FEC codes) which is compliant with various requirements defined in this document. Thus, Content Delivery Protocols can be defined which are not specific to a particular FEC Scheme and FEC Schemes can be defined which are not specific to a particular Content Delivery Protocol. "CAPWAP Threat Analysis for 802.11 Deployments", Scott Kelly, Charles Clancy, 17-Oct-06, Early Wireless LAN (WLAN) deployments feature a "fat" Access Point (AP) which serves as a standalone interface between the wired and wireless network segments. However, this model raises scaling, mobility, and manageability issues, and the CAPWAP protocol [CAPWAP] is being developed in reponse. CAPWAP effectively splits the fat AP functionality into two network elements, and the communication channel between these components may traverse potentially hostile hops. This document analyzes the security exposure resulting from the introduction of CAPWAP, and summarizes the associated security considerations for CAPWAP implementations and deployments. "Response Code for Dynamic Proxy Redirect", Rajesh Ramanathan, 7-Mar-07, The Session Initiation Protocol (SIP) allows for sessions to be redirected by the use of the 3xx response code. This response code allows redirect servers and proxies to redirect the session or for the message to be sent all the way back to the initiating client to recurse. There is no way to direct the domain responsible for the Request-URI to perform the redirection. This document defines a new response code that clients and redirect servers could use to ensure that recursion take place within the domain responsible for the Request-URI rather than allowing the initiating client do perform the redirect. "Serial Forking and 605", Rajesh Ramanathan, 6-Mar-07, The session initiation protocol (SIP) [2] allows users' end systems to decline calls for many reasons. 6xx response codes communicate global failures generated by callee's end system. It defines 6xx class response codes in the spirit of parallel forking scenarios only. There're scenarios where, authoritative server performs parallel forking of the call to callee's own set of endpoints, and then serially move on to fork call to alternate set of endpoints (callee's voice mail and/or team call). This draft clarifies behavior for existing 603 response code and proposes new 605 response code to handle complete rejection of the call, which halts any further processing of the call. "Bicast packet identification header", Henrik Petander, 17-Oct-06, Bicasting or multicasting of traffic can be used to reduce the impact of a handoff by allowing a Mobile Node to receive a stream via multiple paths simultaneously. However, receiving of multiple copies of the packets may have a negative impact on applications which cannot distinguish duplicate packets. This holds true for all applications using TCP which mistakes the packet duplication from bicasting with congestion and reduces the sending rate drastically. This document specifies an IPv6 destination option header which can be used to identify and discard duplicate copies of bicasted packets. "IANA Registering a SIP Resource Priority Header Namespace for Local Emergency Communications", James Polk, 17-Oct-06, This document IANA registers the new Session Initiation Protocol (SIP) Resource Priority header (RPH) namespace Fred&Barney for local emergency usage to a public safety answering point (PSAP), between PSAPs, and between a PSAP and first responders and their organizations. "Dynamic Placement of Pseudowires using a Path Computation Element", Luca Martini, 23-Oct-06, When dynamically established Pseudowires (PW) span across multiple service providers networks, or across multiple autonomous systems, there is a need to calculate the best route among a set of switching point PEs (S- PE). A method for calculating said "best route", and choosing the S-PEs is described in this document using the existing Path Computation Element work done in the PCE WG. "Configuring the Differentiated Services Codepoint of Session Description Protocol Established Media Streams", James Polk, 7-Mar-07, The offer/answer model for SDP currently is without a mechanism for dynamic configuration of the Differentiated Services Codepoint to use for the media streams endpoints establish. Endpoints in more controlled environments, typically bounded within a domain, require intermediary servers to notify them what specific DSCP a media stream should be set to, as granular as at the media stream level, when more than one stream is in a session description, or changed to, based on dynamic network conditions. "Methodology for Benchmarking SIP Networking Devices", Scott Poretsky, 17-Oct-06, This document describes the methodology for benchmarking Session Initiation Protocol (SIP) performance as described in Terminology document [Po06]. The methodology and terminology are to be used for benchmarking SIP control plane performance with varying control and media load. Both scale and establishment rate are measured by control plane performance. The SIP Devices to be benchmarked may be a single device under test (DUT) or a system under test (SUT). Benchmarks can be obtained and compared for different types of devices such as SIP Proxy Server, SBC, P-CSCF, and Server paired with a Firewall/NAT device. "Load-Balancing Proactive Internet Gateway Selection in MANET", Youngmin Kim, 2-Mar-07, The mobile ad hoc network (MANET) is a rapidly configurable multi-hop wireless network without an infrastructure and originally proposed for the military use. In order to make the MANET a more commonly used network in our daily lives, it may be necessary to connect the MANET to the global Internet. A MANET node can communicate with an Internet node via the Internet gateway. To support fault tolerance and increase the bandwidth, multiple Internet gateways can be deployed within a MANET and, in this case, the network performance can be improved by balancing the load among Internet gateways. In this draft, we propose load-balancing Internet gateway selection mechanisms for the MANET with multiple stationary Internet gateways. In addition to this, we propose a scheme that reduces the routing control message overhead in the MANET when a MANET node sets up the route to Internet gateway using global address. "Signaling Standby State of Pseudowire Groups in H-VPLS", Pranjal Dutta, 17-Oct-06, H-VPLS is an architecture that follows hub-and-spoke connectivity model among VPLS aware devices and is proposed in [VPLS-LDP] for creating scalable VPLS implementations. To protect from failure of the spoke PW or the failure of host PE-rs, MTU-s may be dual homed to two PE-rs devices for a VPLS instance through primary spoke PW and secondary(standby) spoke PW. The respective PE-rs devices(s) are unaware of the primary or secondary status of spoke PWs. So Broadcast, Unlearned unicast and Multicast (BUM) traffic received from full mesh core by a PE-rs is replicated to MTU-s over secondary spoke PW to get dropped at MTU-s. In such scenerios it may be desirable to block the standby spoke PW at PE-rs end with minimal compromise on traffic disruption when MTU-s performs a switchover to secondary spoke PW. This document proposes an extension to PW status TLV defined in [RFC 4447] to signal Standby or Active state of PW by MTU-s to PE-rs in a scalable manner. "Performance Evaluation of CL-PHB Admission and Pre-emption Algorithms", Xinyang Zhang, 6-Mar-07, Pre-Congestion Notification [I-D.briscoe-tsvwg-cl-architecture] approach proposes Admission Control to limit the amount of real-time PCN traffic to a configured level during the normal operating conditions, and Preemption use to tear-down some of the flows to bring the PCN traffic level down to a desirable amount during unexpected events such as network failures, with the goal of maintaining the QoS assurances to the remaining flows. Preliminary performance evaluation results on example admission and Preemption mechanisms were presented in [I-D.briscoe-tsvwg-cl-phb]. This draft presents the results of a follow-up simulation study and identifies a number of open issues. "Extensions to the IODEF-Document Class for Phishing, Fraud, and Other Crimeware", Patrick Cain, David Jevans, 17-Oct-06, This document extends the Incident Object Description Exchange Format (IODEF) to support the reporting of phishing, fraud, other types of electronic crime, and widespread spam incidents. These extensions are flexible enough to support information gleaned from activities throughout the entire electronic fraud cycle. Both simple reporting and complete forensic reports are possible, as is consolidated reporting of multiple phishing incidents. The extensions defined in this document are used to generate two different reports: a fraud and phishing report and a wide-spread spam report. Although similar in structure, each report has different required objects and intents. This document had completed working group last call and was in revision when the INCH working group was disbanded. "A Geopriv Registry for Location-based Error Response Codes", James Polk, 17-Oct-06, This document IANA registers a list of GEOPRIV location-specific error response indications, to be used by signaling protocols describing a location-based error experienced by an intermediary or recipient endsystem. For example, the registered values here can be placed in a SIP Reason header contained within a 424 (Bad Location Information) response, or in a Location-to-Service Translation (LoST) query failure, giving specific meaning to the reason for the error. This additional information is to provide the location transmitter more granular information about what was wrong with the supplied location in the original request message. "Bicasting with Buffering and Selective Delivery for Fast Handovers for Mobile IPv6", Henrik Petander, 17-Oct-06, More and more mobile nodes are being equipped with multiple radios, such as 3G and 802.11. This document specifies use of Bicasting with Buffering and Selective Delivery (BBSD) with Fast Handovers for Mobile IPv6 (RFC 4068). The BBSD scheme takes advantage of the additional radio capabilities of Mobile Nodes. As in Simultaneous Bindings for Fast Handovers, the BBSD extension uses bicasting to allow a Mobile Node to continue receiving packets directly from the Previous Access Router during the handoff process. In addition, the selective delivery uses sequence numbers in the bicasted packets to enable the New Access Router to only deliver those packets from its buffer that the Mobile Node has not already received directly from the Previous Access Router. This reduces the overhead of bicasting and mitigates the negative impacts of packet duplication on the application performance in Mobile Node. "Controlling NAT Bindings using STUN", Dan Wing, Jonathan Rosenberg, 14-Feb-07, Simple Traversal Underneath NAT (STUN) is a mechanism for traversing NATs. STUN requests are transmitted through a NAT to external STUN servers. While this works very well, its two primary drawbacks are the inability to modify the properties of a NAT binding and the need to query a public STUN server for every NAT binding. These drawbacks require frequent messages which present a load on servers (like SIP servers and STUN servers) and are bad for low speed access networks, such as cellular. This document proposes that the STUN server be embedded in the NAT itself, and describes how these STUN servers can be readily discovered and utilized to reduce queries to public STUN servers and to reduce NAT keepalive traffic. "Authentication Protocol for Mobile IPv6", Alpesh Patel, 17-Oct-06, IPsec is specified as the means of securing signaling messages between the Mobile Node and Home agent for Mobile IPv6 (MIPv6). MIPv6 signalling messages that are secured include the Binding Updates and Acknowledgement messages used for managing the bindings between a Mobile Node and its Home Agent. This document proposes an alternate method for securing MIPv6 signaling messages between a Mobile Nodes and Home Agents. The alternate method defined here conists of a MIPv6-specific authentication option that can be added to MIPv6 signalling messages "Initial and Pass Through Authentication Using Kerberos V5 and the GSS-API (IAKERB)", Jeffrey Altman, Larry Zhu, 7-Mar-07, This document defines extensions to the Kerberos protocol and the GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to exchange messages with the KDC using the GSS-API acceptor as the proxy, by encapsulating the Kerberos messages inside GSS-API tokens. With these extensions a client can obtain Kerberos tickets for services where the KDC is not accessible to the client, but is accessible to the application server. "Clarification of Privacy Mechanism for SIP", Mayumi Munakata, 17-Oct-06, This document is an informational RFC to clarify the use of privacy mechanism for Session Initiation Protocol (SIP) that is specified in RFC 3323 and extended in subsequent RFCs, such as RFC 3325. It is intended to clarify the semantics of each privacy header value (priv-value) and the handling of the relevant target SIP headers for each of the priv-value. It also provides some guidelines on providing privacy considerations for future specifications that define SIP headers which may be influenced by the privacy mechanism. "Implementing SHIM6 Protocol", Kunwoo Park, 17-Oct-06, The SHIM6 protocol is a conceptual sublayer (hereafter "shim") for providing multihoming. This document reports the current status of the implementation for the shim6 protocol. The implementation is done on a IPv6-enabled Linux machine. "XTR algorithm for MIKEY", Jing Liang, 17-Oct-06, This document proposes extensions to the encryption and digital signature methods described for use in MIKEY, employing a new method of public cryptographic algorithm called Efficient and Compact Subgroup Trace Representation (XTR stands for ECSTR). "Problem Statement on EAP Efficient Re-authentication and Key Management", Vidya Narayanan, Lakshminath Dondeti, 17-Oct-06, The extensible authentication protocol (EAP), specified in RFC3748 [1] is a generic framework for network access authentication, in which a peer engages in a full EAP conversation each time. A full EAP conversation involves several roundtrips between the peer and the authentication server in the home domain, and that is not acceptable for fast roaming. In this document, we explain the requirements for low-latency EAP re-authentication and associated key management. "A Protocol for Implementing Various DHT Algorithms", Salman Baset, 17-Oct-06, This document defines DHT-independent and DHT-dependent features of DHT algorithms and presents a comparison of Chord, Pastry and Kademlia. It then describes key DHT operations and their information requirements. "Handover Key Hierarchy for Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", Hui Deng, 17-Oct-06, The Hierarchy Mobile IPv6 document introduces the Mobile Anchor Point, which improve the performance of IPv6 in terms of handover speed. This document specifies a proactive key distribution method (push mode) within the same MAP, while the use of the handover keying hierarchy among different MAPs is in a reactive mode (pull mode). "Security Association Derivation between Access Nodes", Zhen Cao, 17-Oct-06, This document specifies a mechanism to establish Security Associations (SAs) between Access Nodes in the handover keying architecture. The proposed mechanism negotiates the SA with the help of existing SAs between Access Nodes and Access Domain Controller, and between Access Domain Controller and AAA server as well. "SIP Identity Usage BCP", Steffen Fries, 11-Dec-06, This document describes a use case for RFC4474 (SIP Identity) for verifying a certificate that might not be publicly verifiable by traditional means. It provides a best current practice document for binding an identity to a certificate for the duration of a session. The certificate may then be used to bootstrap further security parameters, e.g., for securing media data. A discussion of possible enhancements is included in the appendix. Editors Note: The first version of this draft was discussed in the SIPPING WG. As the target of this draft is a BCP for current issues, the draft was updated and submitted to the SIP WG. "HELD Service Discovery using DHCP", James Winterbottom, Martin Thomson, 17-Oct-06, This document describes a means by which a device can learn the URI of the Local Location Information Server (LIS) using a DHCP option. "HA-AAA Diameter interface for MIP6", Vihang Kamble, 18-Oct-06, This document specifies a Diameter application between AAAH and HA that allows authentication, authorization and accounting for Mobile IPv6 services. Further, this interface could also be used for bootstrapping of MIPv6. "U-NAPTR Discovery for HELD Services", Martin Thomson, James Winterbottom, 18-Oct-06, A method is described where URI-enabled NAPTR (U-NAPTR) is applied to the discovery of a local Location Information Server (LIS). This document defines an Application Service for a LIS, with a specific Application Protocol for the HTTP Enabled Location Delivery (HELD) protocol. This document also discusses several solutions that enable this method where Network Address Translation (NAT) devices are employed. "HELD End-Point identity Extensions", James Winterbottom, Martin Thomson, 2-Mar-07, This document describes a schema for extending HELD Target identification beyond source IP Address. It describes real-world situations where such a mechanism can be deployed, and provides examples of HELD message syntax including identity extensions. "EAP Keying and Re-authentication in Visited Domains", Lakshminath Dondeti, Vidya Narayanan, 18-Oct-06, This document specifies a visited domain key hierarchy derived from the extended master session key (EMSK) from EAP to facilitate visited domain key management for various purposes including fast handovers and visited domain services. The visited domain key hierarchy avoids the latency associated with communicating with the home domain as in case of a full EAP method run or even in a single round trip as with the EAP efficient reauthentication scheme, and that is especially desirable when the protocol is in the critical path of a handover. "Tunneled Inter-domain Routing (TIDR)", Juan Jose Adan, 11-Dec-06, In this paper we propose a new hierarchical method to enhance the current routing and forwarding paradigm for the Internet called Tunneled Inter-Domain Routing (TIDR). We will present the way in which TIDR permits to establish tunnels to the edge of the network, and how they will be used to forward traffic to stub networks. These tunnels will be explicitly signaled by using a new transitive BGP attribute called LOCATOR. This new routing and forwarding paradigm provides, among others, the following benefits: global routing table reduction, inter-domain routing infrastructure protection, improved multi-homing of edge networks, numerous forwarding decisions for a particular address prefix, it stops the AS number consumption, and it can be smoothly deployed. "A Process for Handling Essential Corrections to the Session Initiation Protocol (SIP)", Keith Drage, 8-Mar-07, The Session Initial Protocol (SIP) defined in RFC 3261 and a large number of extensions forms a considerable body of work, which through sheer size has a number of errors that require correction. This document explains the process for managing essential corrections to SIP. "Order of Information Elements", Hitoshi Irino, 6-Mar-07, This draft describes guidelines for the order of Information Elements of the IPFIX protocol for the creation of Templates. It aims to improve the efficiency of the Collecting Process on the assumption that multiple Exporting Processes send Flow Records containing the same Information Elements to a Collecting Process. Exporters can make (almost) the same Template from the same combination of Information Elements by applying the order rule defined in this draft. Furthermore, some Templates will have a suitable data structure for hardware processing if the rule is applied because the rule defines that fixed-length Information Elements and other Information Elements are separated in position. "The Logical Structure of a P2PSIP Overlay Node", Jani Hautakorpi, 18-Oct-06, This document describes the logical structure of a P2PSIP overlay peer and client. The document is not normative in nature, it is intended mainly as a clarification for the application developers. Editors note: Possible outcomes of this draft are 1) Informational RFC, 2) Incorporated to Concepts and Terminology draft, or 3) Seen as redundant and discarded altogether. "Routing Extensions to Support Network Elements with Switching Constraint", Wataru Imajuku, 26-Oct-06, This document proposes routing extensions in support of carrying switching constraint information in corresponding link state information for Generalized Multi-Protocol Label Switching (GMPLS). With the proposed extension, GMPLS routing protocols can handle network elements with blocking switch architecture. "Applicability Statement for Layer 1 Virtual Private Networks (L1VPNs) Basic Mode", Tomonori Takeda, 18-Oct-06, This document provides an applicability statement on the use of Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms to support Basic Mode Layer 1 Virtual Private Networks (L1VPNs). L1VPNs provide customer services and connectivity at layer 1 over layer 1 networks. The operation of L1VPNs is divided into the Basic Mode and the Enhanced Mode where the Basic Mode of operation does not feature any exchange of routing information between the layer 1 network and the customer domain. This document examines how GMPLS protocols can be used to satisfy the requirements of a Basic Mode L1VPN. "Localized RSVP for Controlling RSVP Proxies", Jukka Manner, 18-Oct-06, This draft specifies a mechanism for explicit control of RSVP proxies. The scheme is based on one bit and two new RSVP messages, and allows triggering both RSVP Sender and Receiver proxies. "Filter Interface Identifier Binding in Mobile IPv6", Tero Kauppinen, 18-Oct-06, Mobile nodes using more than one interface for communicating with other nodes in the network need a mechanism that controls how these interfaces are used. One way of controlling the interface usage is to define rules that map flows to network interfaces. These rules can also be called filter rules that are bound to Filter Interface Identifiers. This document describes a mechanism to associate Filter Interface Identifiers with the current location information of a mobile node in case when the mobility protocol used by the mobile node is Mobile IPv6. "Applicability analysis of Generalized Multiprotocol Label Switching (GMPLS) protocols for the Layer 1 Virtual Private Network (L1VPN) Enhanced Mode", Tomonori Takeda, 18-Oct-06, This document provides an applicability analysis on the use of Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms to satisfy the requirements of the Layer 1 Virtual Private Network (L1VPN) Enhanced Mode. L1VPNs provide customer services and connectivity at layer 1 over layer 1 networks. The operation of L1VPNs is divided into the Basic Mode and the Enhanced Mode, where the Enhanced Mode of operation features exchange of routing information between the layer 1 network and the customer domain. In addition, this document identifies areas where additional protocol extensions or procedures are needed to satisfy the requirements of the L1VPN Enhanced Mode, and provides guidelines for potential extensions. "Requirements for Inter-Domain LSP Recovery", Wataru Imajuku, 26-Oct-06, The Generalized MPLS(GMPLS) suite of protocols h as been defined the protection and restoration mechanisms of Label Switched Paths (LSPs) to realize the highly resilient and reliable networks. The objective of this document is to extract additional requirements for the signaling mechanisms in order to extend the applicability of the protection and restoration mechanisms for inter-domain LSPs. "Prefix binding based mobility management in WiMAX network", JinHyeock Choi, 18-Oct-06, This document describes a protocol which provides movbility support for an ordinary IPv6 host in WiMAX network. The protocol allows session continuity for every IPv6 node in WiMAX network as it moves across subnets. The protocol exploits the facts that a single prefix is assigned per an IPv6 host in WiMAX network and prefix binding scheme is defined in NEMO WG. WiMAX access routers perform prefix binding for the hosts' stead and the mobility is transparent to the hosts inside WiMAX network. "Optimized Routing in Nested NEMO Networks", Varaporn Pangboonyanon, 18-Oct-06, In nested mobile networks (NEMO), packets that are routed from/to any nodes inside the nested NEMO have additional overheads (i.e., bi- directional tunnels) and delays. These additional overheads and delays increase respectively to the depth of the current location of the node in nested NEMO since the packets have to go through all the HAs of the MRs along the path to an endpoint. This draft provides a solution to this problem, providing optimizations to the nested NEMO concept thereby making it worthwhile to implement the nested NEMO concept. "Signature-Only DNSSEC: A Simplified Approach", Michael StJohns, 18-Oct-06, Work on the DNS Security Extensions (DNSSEC)( [RFC4033] et al) has been in progress for close to 15 years and DNSSEC is still not "mature" enough to be considered complete. A substantial issue is the complexity of the system. This document describes a simplified version of DNSSEC that can co-exist with the current protocols, but with characteristics such that the author believes it can be implemented and deployed with much less effort. "Problems Analysis of NSIS Aggregation Teardown Signaling in Mobility Scenarios", Shivanajay Marwaha, 18-Oct-06, If a Mobile Node communicates with different Corresponding Nodes and there exists a common path for these sessions, NSIS allows these reservations to be aggregated. However, change of aggregation path caused by mobility event creates problems related to the prompt removal of the old aggregation state in case Correspondent Nodes are NSIS Initiators, i.e. multiple Correspondent Nodes will send multiple teardown messages for tearing down the same unused aggregated section and may cause problems of extra signaling overhead, delay in tearing down, reliability, redundancy and extra processing overhead. This draft presents the analysis of these problems. "The SIEVE mail filtering language - extension for accessing mailbox metadata", Alexey Melnikov, 20-Feb-07, This memo defines and extension to the SIEVE mail filtering language (RFC 3028) for accessing IMAP mailbox and server annotations. "Problem and Applicability Statements for the use of Generalized Multi-Protocol Label Switching (GMPLS) to Support Multiplex Section Shared Protection Ring (MS-SPRing)", Jianhua Gao, Dan Li, 16-Nov-06, In order to provide high availability for transport networks, link protection technologies are adopted in the data plane. In present Synchronous Digital Hierarchy (SDH) and Synchronous Optical Network (SONET) optical transport networks, one of these protection technologies, shared ring protection technologies, such as the 2/4- Fiber Bi-directional Multiplex Section Shared Protection Ring(MS- SPRing), are widely used. The same technologies can also be applied in Optical Transport Networks (OTNs). This document describes a set of issues to be addressed when applying GMPLS) to support MS-SPRings, and sets out how GMPLS can be applied. "Media Security Requirements", Dan Wing, 7-Mar-07, A number of proposals have been published to address the need of securing media traffic. Different assumptions, requirements, and usage environments justify every one of them. This document aims to summarize the discussed media security requirements in order progress the work on identifying a small subset applicable to a large range of deployment environments. "IPFIX Mediators", Atsushi Kobayashi, 26-Oct-06, An IPFIX Mediator is an intermediate node between IPFIX Devices and traffic Collectors. This node acts as a IPFIX proxy or IPFIX concentrator. Therefore, IPFIX Mediators enables cascade connection. This document defines the Option Template required by cascade connection and a reference internal component model and describes several solution scenarios that use IPFIX Mediators. An IPFIX Mediator is an intermediate node between IPFIX Devices and traffic Collectors. This node acts as a IPFIX proxy or IPFIX concentrator. IPFIX Mediator has several capabilities such as storage function of original Flow Records, flexible aggregation function, and proper distribution function for collector or analyzer. The combination of these capabilities can solve several problems related to traffic monitoring. "HTTP State Management Mechanism v2", Yngve Pettersen, 18-Oct-06, This document specifies a way to create a stateful session with Hypertext Transfer Protocol (HTTP) requests and responses. It describes three headers, Cookie, Cookie2, and Set-Cookie2, which carry state information between participating origin servers and user agents. The method described here differs from both Netscape's Cookie proposal [Netscape], and [RFC2965], but it can, provided some requirements are met, interoperate with HTTP/1.1 user agents that use Netscape's method. (See the HISTORICAL section.) This document defines new rules for how cookies can be shared between servers within a domain. These new rules are intended to address security and privacy concerns that are difficult to counter for clients implementing Netscape's proposed rules or the rules specified by RFC 2965. This document reflects implementation experience with RFC 2965 and obsoletes it. "IANA Considerations for the IPv4 and IPv6 Router Alert Option", Andrew McDonald, 18-Oct-06, This document provides new instructions to IANA on the allocation of IPv4 and IPv6 Router Alert Option Values. "Analysis of SIPPING WG and its efficiency", Shida Schubert, 18-Oct-06, This draft looks at drafts revision cycle, general submission trends from the past few years, average time-frame for draft to become an RFC, impact of presentations to RFC publcation etc. Through this analysis, this draft hopes to aid in the discussion of how SIPPING WG may improve its efficiency on draft handling etc. "Requirements for Header Integrity Protection for the Session Initiation Protocol (SIP)", Shida Schubert, 18-Oct-06, This document lays out a set of requirements related to integrity protection over the headers for the Session Initiation Protocol (SIP). While mechanism such as SIP-Identity and S/MIME may be used to provide integrity protection between the end-points, it can not provide integrity protections over some of the headers which may benefit from having an integrity protection. "Advertising S/MIME Capabilities with Presence", Shida Schubert, 18-Oct-06, This document specifies a means to integrate Certificate Management Service for The Session Initiation Protocol(SIP) with presence. Presentities employing the Presence Information Data Format (PIDF) can use the extensions in this draft to advertise their ability to exchange signalling using S/MIME, and thus allow secure signalling between the two peers. In a presence application, the presence of this information could be displayed to watchers as the padlock "secure signalling available" of the presentity. "Flow Rate Fairness: Dismantling a Religion", Bob Briscoe, 18-Oct-06, We were moved to write this memo because the applied research and standards communities in networking are using completely unrealistic and impractical fairness criteria. The issue is not whether they should use this or that allocation scheme; they don't even allocate the right thing and they don't allocate it between the right entities. We explain as bluntly as we can that sharing out flow rates (as TCP and many other popular fairness mechanisms do) has no intellectual heritage from any concept of fairness in philosophy or social science, or indeed real life. Comparing and controlling flow rates alone will never achieve fairness and should never again be claimed as a fairness mechanism for production networks. Instead, a realistic fairness mechanism must share out the `cost' of each users actions on others. "Format for IPv6 extension headers", Suresh Krishnan, 18-Oct-06, In IPv6,optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the transport layer header. There are a small number of such extension headers currently defined. This document defines a format for defining new IPv6 extension headers. "Validation Certificates in Certificate Revocation Lists", Stefan Santesson, 18-Oct-06, This specification specifies a Certificate Revocation List (CRL) Extension for storage of X.509 certificates defined in RFC 3280. Certificates stored in this extension may be used to construct a valid certificate path from a CRL to an appropriate trust anchor. "Protocols for IPsec Gateway or Server Redundancy", Vidya Narayanan, Lakshminath Dondeti, 18-Oct-06, Recovering from failure of IPsec gateways or servers maintaining large numbers of SAs may take several minutes, if they need to re- establish the IPsec SAs by re-running the key management protocol, IKEv2. This draft proposes IPsec and IKEv2 SA storage and retrieval mechanisms to improve the recovery time after an IPsec gateway or server failure. "Proxy Mobile IPv6", Sri Gundavelli, 18-Oct-06, This specification describes a network-based mobility management protocol. It is called Proxy Mobile IPv6 (PMIPv6) and is based on Mobile IPv6. This protocol is for enabling any IPv6 host to achieve protocol mobility with out requiring the host to participate in any mobility related signaling. "MIPv4 tunneling extensions", Yacine Mghazli, 18-Oct-06, Mobile IPv4 lacks the capability to dynamically configure the tunnel type and to configure tunnel-specific options and parameters. This document describes a new MIPv4 registration extension that allows a, mobile node or a foreign agent to provide tunnel information to the home agent. "Delay Tolerant Networking TCP Convergence Layer Protocol", Michael Demmer, Joerg Ott, 18-Oct-06, This document describes the protocol for the TCP-based Convergence Layer for Delay Tolerant Networking (DTN). "Method to specify optimal specificaiton of service ports for flow bindings", Robert Jaksa, 7-Mar-07, This method introduces a specification in the Mobile IPv6 MONAMI6 work that allow nodes to bind a particular flow based on the service port to a care-of address. This method is different and more flexible than a current solution in the Internet community in that multiple ranges of ports and individual specific ports not in any defined range may be specified within a single flow identification message. This is an idea that may be adopted or incorporated into currently proposed MONAMI6 flow redirection proposals. "Inter-Domain Reservation Aggregation for QoS NSLP", Mark Doll, Roland Bless, 18-Oct-06, QoS NSLP is a recently proposed signaling protocol that allows to establish QoS reservations in the Internet. In order to enable large scale deployment, inter-domain aggregation should be considered as mechanism to allow for the necessary scalability. This draft describes the major problems that must be solved and proposes also solutions to these problems, requiring only modest modifications and extensions to the currently defined GIST and QoS NSLP specifications. "ENUM-based Softswitch Requirement", JoonHyung Lim, 2-Mar-07, This document describes operational requirement and several considerations for ENUM-based softswitch, which can route a call between 2 Korean VoIP carriers during the ENUM pre-commercial trial hosted by National Internet Development Agency of Korea(NIDA) in 2006. This experience can be one of interim solution to maintain stability of on-going commercial softswitch system while initial stage of ENUM service that does not have sufficient data. "Security and Reliable Multicast Transport Protocols: Discussions and Guidelines", Brian Adamson, Vincent Roca, 18-Oct-06, This document describes some security risks of the Reliable Multicast Transport (RMT) Working Group set of building blocks and protocols. An emphasis is placed on risks that might be resolved in the scope of transport protocol design. However, relevant security issues related to IP Multicast control-plane and other concerns not strictly within the scope of reliable transport protocol design are also discussed. The document also begins an exploration of approaches that could be embraced to mitigate these risks. The purpose of this document is to provide a consolidated security discussion and provide a basis for further discussion and potential resolution of any significant security issues that may exist in the current set of RMT standards. "An Architecture and Framework for the Usage of Telephone Numbers with the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 18-Oct-06, The Session Initiation Protocol (SIP) is often used for the purposes of making and receiving Voice over IP (VoIP) calls, and in many of these cases one or both parties in the call is on the Public Switched Telephone Network (PSTN). For this reason, phone numbers are often used as part of SIP calls. Despite numerous small specifications describing usage of phone numbers for SIP, there remains a great deal of interoperability problems and feature loss. This document tries to address this by providing a general framework for the usage of phone numbers and phone naming and numbering services with SIP. "Moving MCAST.NET into the ARPA infrastructure top level domain", Peter Koch, 18-Oct-06, This document proposes to migrate the MCAST.NET domain into the ARPA top level domain that is dedicated to infrastructure support. It also covers migration issues and caveats. "Solution of MIPv6 Friendly Firewall", F Bao, 20-Oct-06, The mobile communication becomes the mainstream because more and more mobile devices, such as mobile phones, personal digital assistants, notebooks, etc., are used to access the Internet. In order to be reachable, the mobile devices need frequently change their communication IP addresses in mobile IPv6 network according to its current attached domain. However, the conventional firewalls are primarily based on IPv4 network where the security criteria are specified only to the fixed IP addresses or subnets. The goal of the document is to solve the conflict and propose some approaches to make the firewall friendly in mobile IPv6 network. "Experience of implementing NETCONF over SOAP", Iijima Tomoyuki, 25-Oct-06, NETCONF protocol is standardized to be exchanged over SSH, SOAP, or BEEP. We developed a network management system based on NETCONF protocol. For several reasons, we chose the SOAP protocol as a transport protocol of NETCONF. This document describes why we chose SOAP as a transport protocol and the insight gained from actual development. "Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems", Xavier Boyen, Luther Martin, 2-Mar-07, This document describes the algorithms that implement Boneh- Franklin and Boneh-Boyen Identity-based Encryption. This document is in part based on IBCS #1 v2 of Voltage Security's Identity-based Cryptography Standards (IBCS) documents. "EAP Pre-authentication Problem Statement", Yoshihiro Ohba, 5-Mar-07, EAP pre-authentication is defined as the utilization of EAP to pre- establish EAP keying material on an authenticator prior to arrival of the peer at the access network managed by that authenticator. This draft discusses EAP pre-authentication problems in details. "The Unicode Codepoints and IDN", Patrik Faltstrom, 26-Oct-06, This document specifies the codepoints in the Unicode tables that are safe for use in the standards for Internationalized Domain Names, IDN. "Proxy Mobile IPv6", Sri Gundavelli, 7-Mar-07, Host based IPv6 mobility is specified in Mobile IPv6 base specification [RFC3775]. In that model, the mobile node is responsible for doing the signaling to its home agent to enable session continuity as it moves between subnets. The design principle in the case of host-based mobility relies on the mobile node being in control of the mobility management. Network based mobility allows IP session continuity for a mobile node without its involvement in mobility management. This specification describes a protocol solution for network based mobility management that relies on Mobile IPv6 signaling and reuse of home agent functionality. A proxy mobility agent in the network which manages the mobility for a mobile node is the reason for referring to this protocol as Proxy Mobile IPv6. "SIP Peering Use Case for VSPs", Adam Uzelac, 19-Oct-06, This document describes the typical interconnection scenarios for SIP peering within varying contexts. In all the scenarios, two or more administrative domains have some pre-established agreement that permits both signaling and media to traverse the network boundary. "RSVP Extensions for Path Key Support", Richard Bradford, 19-Oct-06, Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASs), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. To preserve confidentiality of topology with each AS, the PCE supports a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS), by encoding the contents as a Path Key Sub-object (PKS). This draft describes the addition of this object to the Explicit Route Object. "Reflections on Internet Transparency", Bernard Aboba, 7-Mar-07, This document provides a review of previous IAB statements on Internet transparency, as well a discussion of new transparency issues. Far from having lessened in relevance, technical implications of intentionally or inadvertently impeding network transparency play a critical role in the Internet's ability to support innovation and global communication. This document provides some specific illustrations of those potential impacts. "Pseudowire Security (PWsec)", Yakov Stein, 19-Oct-06, This document proposes an extension to the MPLS pseudowire format to enhance pseudowire user-plane security. The extension, called PWsec, provides confidentiality, data integrity, and source authentication. The extension is based on the National Institute of Standards and Technology (NIST) Advanced Encryption Standard (AES) using the Galois/Counter Mode (GCM). "Proposed Issues and Changes for IDNA - An Overview", John Klensin, 23-Feb-07, A recent IAB report identified issues that have been raised with Internationalized Domain Names (IDNs). Some of these issues require tuning of the existing protocols and the tables on which they depend. Based on intensive discussion by an informal design team, this document provides an overview some of the proposals that are being made, provides explanatory material for them and then further explains some of the issues that have been encountered. "Guidelines for using IPsec and IKEv2", Lakshminath Dondeti, Vidya Narayanan, 19-Oct-06, IPsec encapsulation can be used to provide a secure channel between two entities, to enforce controlled access to a network, or to provide any combination of integrity protection, confidentiality, replay protection, and traffic flow confidentiality of data being transmitted between two or more endpoints over untrusted transmission media or networks. Whereas various assortments of the protections are possible to provide, it is not always safe to use some of the combinations. Next, IPsec SAs are established either manually or using a key management protocol such as IKEv2 with entity authentication verified locally or with the assistance of a third party. This document specifies when and how to use IPsec and IKEv2 and what combinations of protections afforded by those protocols are safe and when. "Passive Duplicate Address Detection for On-demand Routing Protocols", HongJong Jeong, 19-Oct-06, This document describes passive DAD schemes over on-demand ad-hoc routing protocols such as AODV and DYMO. In order to achieve these two goals: (a) improving the accuracy of detecting address conflicts and (b) reducing the time taken to detect these conflicts, this document provides several schemes using additional information including sequence, location, or neighbor knowledge. "Mobile Multi-path Transmission using SCTP", Chung-Ming Huang, Ching-Tien Tsai, 19-Oct-06, In this draft, MMP-SCTP (MMP: Mobile Multi-Path) is proposed to allow a host to improve the transmission throughput in wireless mobile networks using simultaneous multi-path transmission of Stream Control Transmission Protocol. Relevant mobility issues of MMP-SCTP included are: (1) data transmission modes and path selection, (2) multi-path handover, and (3) location management. Two transmission modes of MMP- SCTP, i.e., the "Data-duplicating Mode" and "Data-striping Mode", and the switching mechanism, are designed to enhance transmission throughput for different wireless link status. Since the transmission paths used for MMP-SCTP may differ when an MMP-SCTP host moves, the multi-path handover problem is defined, and a multi-path handover mechanism for MMP-SCTP is proposed. Additionally, a location management scheme is also designed in this draft to tackle the locating of an MMP-SCTP host. "A Location Reference Event Package for the Session Initiation Protocol (SIP)", Henning Schulzrinne, 19-Oct-06, Mobile devices sometimes want to give temporary access to their presence and location information to third parties that may not have a trust relationship with their presence server. Also, in addition to other mechanisms, application-layer location configuration protocols are helpful in building location-based systems. This document describes a Session Initiation Protocol (SIP) event package, locationref, that periodically delivers randomized presence URLs to the target, which the target can then hand to call recipients and other parties. "IEEE 802.1ah Mode for Ethernet Over MPLS", Wei Cao, 19-Oct-06, Ethernet has been widely deployed in metro-networks, and there are more and more customers select Ethernet PW services. With the deployment of IEEE 802.1ah network, there is a need to support 802.1ah attachment circuit. Based on the two modes defined in RFC 4448, this document introduces a new Ethernet encapsulation mode to support the new AC type. This document also describes some scenarios and procedures pertaining to the new mode. Some considerations relating to multi-segment PW are also discussed. "ASON/GMPLS Extension for Reservation and Time Based Automatic Bandwidth Service", Lucy Yong, Young Lee, 20-Oct-06, The draft presents ASON/GMPLS architecture extension for reservation and time based automatic bandwidth services. It introduces additional service intelligence function to the control plane. It describes the service scenarios and procedures for automatic bandwidth service. It also discusses the potential services enabled by the service intelligence function. "NSIS-PCN : NSIS Extensions for Admission Control over Diffserv using Pre- congestion Notification (PCN)", Mayutan Arumaithurai, 20-Oct-06, This document specifies the extensions to the NSIS QoS signalling protocol (QoS-NSLP)[QoS-NSLP] for support of the Controlled Load (CL) service over a DiffServ cloud using Pre-Congestion Notification as defined in [CL-DEPLOY]. The CL-DEPLOY is a QoS architecture similiar to RMD-QOSM measurement-based admission control. This draft is based on [RSVP-PCN] and uses some text from it. "Guidelines for a sender-based TFRC", Guillaume Jourjon, 20-Oct-06, This memo introduces the specification of a TFRC sender-based protocol. This protocol is based on TFRC [2] congestion control and SACK [1] mechanism. It enlights TFRC processing for the receiver and provides a robust architecture against selfish receiver behavior. This protocol remains compliant to the common TFRC as defined in [2]. "Best Current Practices for Session Peering on the Internet by Carriers through Federationsr", Brian Rosen, 22-Oct-06, This memo defines a first version Best Current Practice for peering among a federation of voice or other multimedia service providers "Towards the Specification of a Diameter Resource Control Application: gaps, functional requirements and models, and implementations", Zachary Zeltsan, Dong Sun, 5-Mar-07, This I-D is to analyze the gaps in the ongoing work of the QoS application in the DIME WG, discuss the extension of the scope of QoS application to a generic resource control application for a variety of network technologies and use cases, and investigate potential mechanisms to support additional resource control scenarios. The current Diameter Quality of Service Application (draft-tschofenig- dime-diameter-qos-01.txt) is limited to an environment where network elements triggered by certain mechanisms (e.g. path-coupled QoS signaling such as RSVP or NSIS initiated by end-hosts) can request QoS authorization of network resources. It does not address environments where end-hosts and/or network elements is unable to issue a resource request initiatively. In such environments, a different mode of operations is needed to allow an authorizing entity to not just authorize QoS resources upon the receipt of the request from network elements but also directly authorize resources and dictate routers/switches to enforce the decisions without the request from network elements. The new mode of operations also lends itself to address resource control in general. It can control resources for the purpose beyond QoS support, such as NAPT, media latching, and packet filtering. "The IMAP SEARCH=INTHREAD and THREAD=REFS Extensions", Arnt Gulbrandsen, 2-Mar-07, The SEARCH=INTHREAD extension extends the IMAP SEARCH command to search on entire threads as well as individual messages. Other commands which search are implicitly extended. The THREAD=REFS extension provides a threading algorithm using only the Feferences header field for use with the IMAP THREAD command. "Multihoming in SIP-based Network Mobility (SIP-NEMO)", Chao-Hsien Lee, Chung-Ming Huang, 6-Nov-06, Network mobility is proposed to let a mobile network change its point of attachment and still to keep all nodes attached to the mobile network globally reachable. However, due to scare bandwidth, limited signaling coverage and frequent link failure, a mobile network needs multihoming, i.e., multiple paths simultaneously to access the Internet, on the perspective of performance and reliability. The document specifies how to support multihoming in network mobility using the Session Initiation Protocol (SIP). The proposed Multihomed SIP-based Network Mobility (SIP-NEMO) can dynamically select a path per session according to the status of egress interfaces and/or gateways. "Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)", Sally Floyd, Eddie Kohler, 6-Nov-06, This document contains the profile for Congestion Control Identifier 4, the Small-Packet variant of TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol (DCCP). CCID 4 is for experimental use, and uses TFRC-SP [TFRC-SP], a variant of TFRC designed for applications that send small packets. The goal for TFRC-SP is to achieve roughly the same bandwidth in bits per second (bps) as a TCP flow using packets of up to 1500 bytes but experiencing the same level of congestion. CCID 4 is for experimental use for senders that send small packets and would like a TCP-friendly sending rate, possibly with Explicit Congestion Notification (ECN), while minimizing abrupt rate changes. "Control Plane Graceful Restart extensions for ANCP", Sanjay Wadhwa, 6-Nov-06, This document describes proposed extensions to ANCP (Access Node Control Protocol) for supporting a graceful state resynchronization between NAS (network access server) and AN (access node) upon control plane restart. Base ANCP as a dedicated control protocol between a NAS and an AN, and its various use cases are defined in [1]. "Resource-sharing Method for MBB CSPF by RSVP-TE", Yang Hui, 6-Nov-06, This document is based upon RSVP MBB£¨make-before-break£©defined in RFC3209, providing a method to realize resource-sharing between old path and new path while RSVP-TE calculating a new path using CSPF in MBB manner. "Implications of Network Initiation support on the NetLMM protocol", Eric Njedjou, 6-Nov-06, This document discusses the architecture and protocol implications of making network initiation support easier with NetLMM. The framework is restricted to inter-technology mobility within a single NETLMM domain. It is proposed to add a new NetLMM message from the LMA to the MAG, which function is to trigger, upon various events, the location registration procedure. Further, it is indicated how to complement NetLMM with 802.21 control mechanisms to achieve adequate network initiation. "Diameter Congestion Signaling", Tolga Asveren, Victor Fajardo, 12-Jan-07, Diameter base protocol defines the network layer functionality to be used by applications. This document adds hop-to-hop congestion notification mechanism to that functionality. "Session Peering Use Cases for Federations", Daniel Schwartz, 6-Nov-06, This document describes a use case involving session peering in Service Provider Federations. The scenario is based on the deployment experience gleaned from one such active federation. The focus in this document is on SIP layer interactions and supporting protocols commonly used in Federation based Layer 5 peering. "MIPv6 Correspondent Node-Targeted Location Privacy and Optimized Routing", Kilian Weniger, 1-Mar-07, This draft discusses the problem of simultaneous optimized routing and correspondent node-targeted location privacy for Mobile IPv6 and proposes a solution. The solution utilizes the MIPv6 bootstrapping mechanisms and requires no new network entities and no changes to home agent or correspondent node. "A Uniform Resource Name (URN) Namespace for Extensions to the Extensible Messaging and Presence Protocol (XMPP)", Peter Saint-Andre, 23-Feb-07, This document describes a Uniform Resource Name (URN) namespace for uniquely identifying Extensible Markup Language (XML) formats and protocols that provide extensions to the Extensible Messaging and Presence Protocol (XMPP) and are defined in specifications published by the XMPP Standards Foundation (XSF). "Framing ALC Packets over Connection-Oriented Transport", Imed Bouazizi, 7-Nov-06, ALC and FLUTE are reliable content delivery protocols designed mainly for scalable multicast distribution. However, this does not preclude their deployment in the Unicast distribution mode over connectionless or connection-oriented transport protocols. A method for framing ALC and FLUTE packets onto connection-oriented transport is presented. A definition of the descriptors of the framing method for those protocols is also given. "Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3 Dropped Packets Option", Eddie Kohler, 7-Nov-06, This document describes the Dropped Packets option, a mechanism for reporting the number of lost and marked packets per loss interval in the Datagram Congestion Control Protocol (DCCP)'s Congestion Control ID 3, TCP-Friendly Rate Control. This option may be useful for applications that need to know precisely how many packets are being dropped. "Encapsulation mechanism for Email Address Internationalization (EAI)", Kari Hurtta, 7-Nov-06, The Email Address Internationalization (EAI) is implemented by allowing UTF-8 characters in SMTP envelope and mail headers. To deliver email which uses UTF-8 on email headers through EAI incompliant environment converting (i.e downgrading) or encapsulation mechanism is required. Some of UTF-8 email may sign email headers or email header fields. This document describes mechanism for encapsulation when converting can not be used because of signed email headers. Encapsulation may also used to forward EAI email through EAI incompliant environment that way that original EAI email can be recovered. "VMAC: Message Authentication Code using Universal Hashing", Ted Krovetz, 8-Nov-06, This specification describes how to generate an authentication tag using the VMAC message authentication algorithm. VMAC is designed to have exceptional performance in software on 64-bit CPU architectures while performing well on 32-bit architectures. Measured speeds are as low as one-half CPU cycle per byte on the 64-bit Intel Core 2 architecture, and under five cycles per byte on recent 32-bit PowerPC and Intel processors. To generate the authentication tag on a given message, a "universal" hash function is applied to the message and key to produce a short, fixed-length hash value, and this hash value is then xor'ed with a key-derived pseudorandom pad. VMAC tags can be either 64 or 128 bits in length and have proven forgery probabilities on the order of 1/2"59 and 1/2"94, respectively. "Secure Location Objects", Russ Barnes, 8-Nov-06, Protection of location information is an essential requirement of the GEOPRIV architecture. Since using protocols cannot be relied upon to provide adequate protections to the location objects they carry, the location objects themselves must be secured. This document examines several candidates for a Secure Location Object format in the context of GEOPRIV and ECRIT security requirements, including both locations by value and by reference. "XTGSP, the Inter-TGS protocol for cross-realm operations in Kerberos.", Saber Zrelli, 5-Mar-07, Cross-realm operations in Kerberos allow users to access services offered by foreign realms. The cross-realm operations are based on inter-realm trust built using shared symmetric keys (aka. inter-realm keys) between the KDCs of the realms offering cross-realm services. The current cross-realm authentication model may be the origin of performance, scalability and security issues. This documents provides a brief overview of these issues and introduces a new cross- realm model based on PKINIT. The new model called XTGSP, defines a protocol that allows a client to obtain a service ticket, for a service offered by a foreign realm, in a single round trip. The protocol specifies an exchange between Kerberos KDCs that enables a local KDC to build a TGS-REP message for a service that is registered in a remote realm. The XTGSP exchange is secured using inter-realm keys maintained using the the PKINIT extension. "The 'javascript' resource identifier scheme", Bjoern Hoehrmann, 8-Nov-06, This memo defines syntax and semantics of the 'javascript' resource identifier scheme, enabling applications to specify script code in contexts where resource identifiers are expected. "Registration Event Package Extension for IP Multimedia Subsystem (IMS) Grouping of Addresses of Record (AoR)", Javier Arauz, 8-Nov-06, This draft defines an extension to RFC 3680 [2] for representing the grouping of AoRs associated with a user in registration event notifications. "Header Compression over Unidirectional Lightweight Encryption (ULE)", Do Byun, 26-Nov-06, Multi-Protocol Encapsulation (MPE) is widely deployed in DVB-S and DVB-S2 networks [DVB-S2]. Replacing MPE with Unidirectional Lightweight Encryption (ULE) has been proposed to gain flexibility and reduce overhead. This paper introduces a signaling method for sending header-compressed unicast packets over satellite networks using ULE, taking advantage of ULE's increased flexibility. "NETLMM Protocol Applicability Analysis for 3GPP SAE Network", Katsutoshi Nishida, Hidetoshi Yokota, 8-Nov-06, The protocol of NETLMM Design Team output, defined in draft-giaretta- netlmm-dt-protocol-02.txt assumes non-NETLMM triggers, provided by so-called MN_Access_Network API, to initiate NETLMM procedures such as sending location registration to LMA. In this document, the NETLMM application to a mobility scenario of the 3GPP network, so-called SAE (system architecture evolution), is analyzed. "Port Randomization", Michael Larsen, Fernando Gont, 13-Feb-07, Recently, awareness has been raised about a number of "blind" attacks that can be performed against the Transmission Control Protocol (TCP) and similar protocols. The consequences of these attacks range from throughput-reduction to broken connections or data corruption. These attacks rely on the attacker's ability to guess or know the four- tuple (Source Address, Destination Address, Source port, Destination Port) that identifies the transport protocol instance to be attacked. This document describes a simple and efficient method for random selection of the client port number, such that the possibility of an attacker guessing the exact value is reduced. While this is not a replacement for cryptographic methods, the described port number randomization algorithms provide improved security/obfuscation with very little effort and without any key management overhead. "Source Route Based Extensible IP Network (EIPv4)", Diao Yongping, 29-Nov-06, In order to resolve the problem of IP address shortage Internet society try hard and use or intend to use some technologies such as NAT/NAPT, IPv6. But the shortcoming or difficult deployment make it progress slowly. Here provides an extensible IP network realization method to exist IP version 4. Two-level extensible IP network architecture is adopted which includes public IP address domain and private IP address domain. With the position denotation of source IP node and destination IP node, IP datagram can progress through the whole extensible IP network freely using the source route based method. "Identity Protection Ciphersuites for Transport Layer Security", Ibrahim Hajjeh, Mohamad Badra, 13-Nov-06, TLS defines several ciphersuites providing authentication, data protection and session key exchange between two communicating entities. Some of these ciphersuites are used for completely anonymous key exchange, in which neither party is authenticated. However, they are vulnerable to man-in-the-middle attacks and are therefore deprecated. This document defines a set of ciphersuites to add client identity protection to the Transport Layer Security (TLS) protection. "ICMP Extensions for Routing Instances", Naiming Shen, Enke Chen, 13-Nov-06, This document specifies the extensions to ICMP that allows routing instance information to be included inside the ICMP packet. These extensions can be used to facilitate the troubleshooting network problems within a routing domain or across multiple routing domains. "Uniform Resource Identifier (URI) MIB", David McWalter, 1-Mar-07, This MIB module defines textual conventions to represent STD 66 Uniform Resource Identifiers (URIs). The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representation(s). "Language Tag MIB", David McWalter, 1-Mar-07, This MIB module defines a textual convention to represent BCP 47 language tags. The intent is that this textual convention will be imported and used in MIB modules that would otherwise define their own representation. "IODEF/RID over SOAP", Kathleen Moriarty, 15-Nov-06, Documents intended to be shared among multiple constituencies must share a common format and transport mechanism. The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange. This draft outlines the SOAP wrapper for all IODEF documents and extensions to facilitate an interoperable and secure communication of documents. The SOAP wrapper allows for flexibility in the selection of a transport protocol. The transport protocols will be provided through existing standards and SOAP binding, such as SOAP over HTTP/TLS and SOAP over BEEP. "Calendar Availability", Cyrus Daboo, Bernard Desruisseaux, 15-Nov-06, This document specifies a new iCalendar calendar component that allows the publication of available and unavailable time periods associated with a calendar user. This component can be used in standard iCalendar free-busy lookups, including iTIP free-busy requests, to generate repeating blocks of available or busy time with exceptions as needed. "Real-time Inter-network Defense", Kathleen Moriarty, 15-Nov-06, Network security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Network providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms across for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. "SIP Proxy Discovery using Anycast Address", Ravideep Bhatia, Michael Coulas, 15-Nov-06, SIP is an application-layer control protocol that can establish, modify, and terminate multimedia sessions. SIP makes use of elements called proxy servers to help route requests to and from the user's current location. Before a SIP request can be sent by a SIP client, an outbound SIP proxy (first hop proxy) has to be discovered to which the SIP request can be forwarded. This draft proposes a new method for discovering the address of first hop outbound SIP proxy server based on the use of anycast addressing and the SIP OPTIONS request. This new method can be used with either IPv4 or IPv6, however the description and examples given in this draft are for IPv6 only. "Media usages and SDP in the XCON data model", Tim Moore, Suresh Srinivasan, 8-Mar-07, The scope of this document is to describe the association of media streams to the XCON data model for various media usages captured in the XCON conferencing scenarios [11]. "Sieve Email Filtering: Environment and Ihave Extensions", Ned Freed, 15-Nov-06, This document describes the "environment" and "ihave" extensions to the Sieve email filtering language. The "environment" extension gives Sieve access to information about the environment where the Sieve interpreter is running. The "ihave" extension provides a means to write scripts that can take advantage of optional Sieve features but can still run when those optional features are not available. "i;basic - Registration of Unicode Collation Algorithm", Chris Newman, 2-Mar-07, The Unicode Collation Algorithm is a widely usable collation covering all of Unicode. It produces tolerable results for many locales as-is, and can be further improved using locale-specific tables. This document registers the UCA in the IETF's collation registry. "Trivial Hypertext Transfer Protocol (THTP)", Neil Gershenfeld, 16-Nov-06, THTP, the Trivial Hypertext Transfer Protocol, is an implementation of HTTP over UDP transport. THTP is designed for environments with limited computational power or bandwidth and single-packet exchanges. As such, THTP is best suited for the emerging class of applications running on embedded devices and sensor networks. THTP decouples HTTP from TCP and provides a subset of HTTP's functionality, in particular leveraging HTTP's URI naming scheme. This document describes the THTP protocol. "NETCONF access control framework", Vincent Cridlig, 16-Nov-06, This document defines a role-based access control framework for the NETCONF configuration protocol. "BFD Down Subcode for BGP Cease Notification Message", Bruno Rijsman, 20-Nov-06, This document defines a new "BFD session down" subcode for the BGP Cease NOTIFICATION message. "Multicast MPLS/BGP VPNs Revisited", Maria Napierala, 21-Nov-06, This document describes changes to inter-site signaling procedures in Multicast MPLS/BGP IP VPNs, defined in [ii], that result in the simplification of inter-PE multicast traffic patterns. It specifies a mechanism to bypass shared tree to shortest path tree VPN traffic switching between PE’s and to achieve congruency of multicast routing with VPN’s unicast routing policy. "The DCCP Service Code", Gorry Fairhurst, 2-Mar-07, This document describes the usage of Service Codes by the Datagram Congestion Control Protocol, RFC 4340. Service Codes provide a method to identify the intended service/application to process a DCCP Connection Request. This provides improved flexibility in the use and assignment of port numbers for connection multiplexing. The DCCP Service Code can also enable more explicit coordination of services behind NATs and firewalls. This document motivates the setting of Service Codes by applications, rather than assigning a default Service Code value of zero. "Delayed compression the SSH Transport Layer Protocol", Markus Friedl, Damien Miller, 26-Nov-06, This memo describes a new compression method for the SSH protocol. This new method uses the same zlib compression algorithm as the existing method described in the core SSH drafts but delays the start of compression until after user authentication has completed. This eliminates the risk of a bug in compression libraries resulting in a pre-authentication compromise of an SSH server. "Atom Feed Autodiscovery", Mark Pilgrim, James Snell, 1-Dec-06, This document specifies a machine-readable method of linking to an Atom feed from a HyperText Markup Language (HTML) or Extensible HyperText Markup Language (XHTML) document, using the element. "Synchronizing Location-to-Service Translation (LoST) Servers", Henning Schulzrinne, 27-Nov-06, The LoST (Location-to-Service Translation) protocol is used to map locations to service URLs. This document defines a set of LoST extensions that allow LoST servers to synchronize their lists of mappings. "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", Murtaza Chiba, 3-Jan-07, This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. "RTP payload format for EVRC-WB codec and MIME updates for EVRC-B codec", HariKishan Desineni, Qiaobing Xie, 29-Nov-06, This document specifies real-time transport protocol (RTP) payload formats to be used for the EVRC wideband codec (EVRC-WB) and updates the MIME registrations for EVRC-B codec. Several media type registrations are included for EVRC-WB RTP payload formats. In addition, a file format is specified for transport of EVRC-WB speech data in storage mode applications such as e-mail. "Internet Application Protocol Simple Unicode Comparator", Mark Crispin, 29-Nov-06, This document describes "i;unicode-casemap", a simple case-insensitive collation for Unicode strings. It provides equality, substring and ordering operations. "Short-Term Certificates", Arik Friedman, 27-Dec-06, This document describes an extension to IKEv2 that allows an endpoint which has authenticated to a gateway to request a short-term credential, possession of which proves the authentication. This allows it to prove to a security gateway that it was already authenticated by another trusted security gateway, thereby allowing the authentication of the endpoint without user intervention. This credential is a certificate issued by the authenticating gateway for a short period of time, which can be used to authenticate the user with IKE signature based authentication. "The IMAP COMMENT Extension", Dan Karp, 30-Nov-06, The COMMENT extension to the Internet Message Access Protocol [IMAP] permits a client to attach free-form text comments to messages stored in a mailbox on the server. These comments are persistent, public, mutable, readable, and searchable. "A BGP based method to compute inter-AS Traffic engineering Label Switched Paths with PCE", C Vijayanand, Somen Bhattacharya, 22-Jan-07, The ability to compute an optimal path for setting up Traffic engineering Label Switched Paths spanning multiple autonomous systems managed by different operators has been a key requirement in MPLS and GMPLS networks. This document specifies a method of computing inter-AS paths consisting of a list of ASes to be traversed and a list of TE-Tunnels to be traversed in each AS. The method described here uses BGP speakers in the PCEs of each AS to distribute the inter-AS connectivity information and the TE-Tunnels in each AS to its neighbors to facilitate the construction of an inter-AS topology graph which can be used for computing inter-AS paths. "Standard Data Types", Jim Eberle, 4-Dec-06, This document assigns 25 common data types clear, unambiguous names, and numerical identifiers. It also defines context dependencies, such as byte-order and charset, to the data types, where necessary. "Netnews Architecture and Protocols", Russ Allbery, Charles Lindsey, 4-Dec-06, This document defines the architecture of Netnews systems and specifies the correct manipulation and interpretation of Netnews articles by software which originates, distributes, stores, and displays them. It also specifies the requirements that must be met by any protocol used to transport and serve Netnews articles. "A Model of IPv4/IPv6 Dual Stack Anycast DNS Service", Seunghoon Lee, 6-Dec-06, This memo shows an example of how to provide and implement IPv4/IPv6 dual stack anycast DNS services, which are based on the experience of IPv4/IPv6 anycast DNS implementation. In order to provide a reference model to DNS operators who have a plan to deploy IPv4/IPv6 anycast DNS services onto their own DNS servers in the future, this memo mainly specifies a way to configure IPv6-related functions without IPv4-related matters. "i;unicode-casemap - Simple Unicode Collation Algorithm", Mark Crispin, 6-Dec-06, This document describes "i;unicode-casemap", a simple case-insensitive collation for Unicode strings. It provides equality, substring and ordering operations. "Specifying New Congestion Control Algorithms", Sally Floyd, Mark Allman, 6-Dec-06, The IETF's standard congestion control schemes have been widely shown to be inadequate for various environments (e.g., high-speed or wireless networks). Recent research has yielded many alternate congestion control schemes. Using these new congestion control schemes in the global Internet has possible ramifications to both the network and to traffic using the currently standardized congestion control. Therefore, the IETF must proceed with caution when dealing with alternate congestion control proposals. The goal of this document is to provide guidance for considering alternate congestion control algorithms within the IETF. "Preventing Fragmentation for Client Initiated Connections in the Session Initiation Protocol (SIP)", Marc Petit-Huguenin, 8-Mar-07, There is cases when a Session Initiation Protocol (SIP) client can initiate a bidirectional UDP stream or a TCP connection to a SIP server but the SIP server cannot do the same in the other direction. The server can reuse the existing bidirectional UDP stream or TCP connection but cannot use a TCP connection if the client chose to use a bidirectional UDP stream. This document described a method to force the client to initiate a TCP connection to the server. "OSPF Extensions for Dynamic Multi-segment Pseudo Wires", Matthew Bocci, 8-Dec-06, Multi-segment pseudo wires have been defined to enable emulated layer 1 and layer 2 services to be delivered from an IP based packet switched network over a sparse mesh of PSN tunnels and PW control protocol adjacencies. MS-PWs can be used to scale PW based networks over both a single AS, or between multiple ASs. However, there is a particular need to be able to automatically route MS-PWs through access and metro PSNs. These networks typically comprise a single AS. This draft proposes extensions to OSPF to enable the automatic advertisement of summarized PW FECs, thus enabling the automatic routing of MS-PWs across an OSPF domain. "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package", Jari Urpalainen, 7-Mar-07, This document describes an "xcap-diff" SIP event package with the aid of which the clients can receive partial changes of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) resources. The initial synchronization and document updates are based on using the XCAP-Diff format. This document extends this format by allowing subscriptions also to XCAP components. "Suite B Cryptographic Suites for IPsec", Laurie Law, Jerome Solinas, 12-Jan-07, This document proposes four optional cryptographic user interface suites ("UI suites") for IPsec similar to the two suites specified in RFC 4308. The four new suites provide compatibility with the United States National Security Agency's Suite B specifications. "A Protocol for Network-based Localized Mobility Management", Anand Bedekar, 8-Mar-07, This document suggests a localized mobility solution controlled by the network within a local mobility domain. The proposed solution is based on Proxy Mobile IPv6 (PMIP) technique and employs a PMIP client that generates a Proxy Binding Update message. The solution allows for a clean separation between the bearer and signaling paths, and reuse of MIPv6 home agent as the local mobility anchor. The security association between the network elements for executing the local mobility is also discussed. "SDP Capability Negotiation: Requirements and Review of Existing Work", Flemming Andreasen, 11-Dec-06, The Session Description Protocol (SDP) was intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability indication or capability negotiation, however over the years, SDP has seen widespread adoption and as a result it has been gradually extended to provide limited support for these. SDP and its current extensions however do not have the ability to negotiate one or more alternative transport protocols (e.g. RTP profiles) which makes it particularly difficult to deploy new RTP profiles such as secure RTP and RTP with RTCP-based feedback. The purpose of this document is to identify a set of requirements for SDP Capability Negotiation and evaluate existing work in this area. The document does not provide any solutions to SDP Capability Negotiation "Simple Network Management Protocol (SNMP) EngineID Discovery", Juergen Schoenwaelder, 2-Mar-07, The third version of the Simple Network Management Protocol (SNMP) assumes that a manager knows the identifier of a remote SNMP protocol engine (the so called snmpEngineID) in order to retrieve or manipulate objects maintained locally on the remote engine. This document introduces a well-known localEngineID and a discovery mechanism which can be used to learn the engine identifier of a remote SNMP protocol engine. The proposed mechanism is independent of the features provided by SNMP security models and may also be used by other protocol interfaces providing access to managed objects. "Dynamic Host Configuration Protocol Option for Geodetic Location Information", Martin Thomson, James Winterbottom, 13-Dec-06, This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for the coordinate-based geographic location of the client. The Location Configuration Information (LCI) includes latitude, longitude, and altitude, with an indication of uncertainty for each. Separate parameters indicate the reference datum for each of these values. "SuiteB CipherSuites for TLS", Margaret Salter, Eric Rescorla, 14-Dec-06, RFC 4492 describes elliptic curve cipher suites for Transport Layer Security (TLS). However, all those cipher suites use SHA-1 as their MAC algorithm, which makes them unsuitable for some applications. This document describes eight new CipherSuites for TLS/DTLS which specify stronger digest algorithms and therefore are suitable for use in applications which require compliance with the United States Government's guidelines for "NSA Suite B Cryptography" dated July, 2005. "Opaque PRF Inputs for TLS", Eric Rescorla, Margaret Salter, 14-Dec-06, This document describes a mechanism for using opaque PRF inputs with Transport Layer Security (TLS) and Datagram TLS (DTLS). "Internet Protocol, Version 6 (IPv6) Specification", Li Zengxing, 14-Dec-06, This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. This document obsoletes RFC2460, RFC1981 and RFC2675. "Using Higher Layer Triggers for Low Latency Handoffs in MIPv4", Stephane Antoine, 15-Dec-06, This document introduces the use of triggers coming from layers higher than the link layer to initiate the Low Latency Handoff in Mobile IPv4 (MIPv4) . The Low Latency Handoff for MIPv4 assumes availability of Layer 2 (L2) triggers that contain Layer 3 (L3) information for the Mobile Node (MN) to handoff. However, the low latency draft does not describe the method by which the L2 trigger is produced neither does it explicitly describe by what mechanism the L3 information present in the L2 trigger is acquired. The Low Latency Handoff for MIPv4 relies on availability of the L2 trigger. However relying only on the link information to initiate a handoff does not generally gather enough information for the MN to handoff to the most suitable available access network. Information from higher layers such as Higher Layer Triggers can be used to command a MN to quickly move from one access to another one. Using Higher Layer Triggers to initiate the handoff enables the implementation of policy based handoff to garantee load balancing of the wireless networks and Quality of Services to the end users. "Generic Security Service Application Program Interface (GSS-API) Extension for Transport Layer Security (TLS)", Stefan Santesson, 19-Dec-06, This document defines protocol extensions to the Transport Layer Security (TLS) protocol for user authentication and key negotiation based on the Generic Security Service Application Program Interface (GSS-API). Full flexibility for negotiation of GSS-API mechanisms is provided, allowing use of arbitrary GSS-API mechanisms provided that they support the GSS-API PRF. This document supersedes RFC 2712 [ref] as the mechanism to support Kerberos based authentication and key establishment for a TLS session. "Security Analysis of RFC4285", Vidya Narayanan, 19-Dec-06, RFC4285 [1] provides a means of using pre-shared key (PSK) based or AAA-based credentials for Mobile IPv6. It is intended to provide a light-weight security mechanism for MIP6 signaling. However, the protocol comes with a set of security issues that are worth looking at. This document presents a security analysis on the protocol. "Handover Key Management and Re-authentication Problem Statement", Charles Clancy, 3-Jan-07, This document describes the Handover Keying (HOKEY) problem statement. The current EAP keying framework is not designed to support re-authentication and handovers. This often cause unacceptable latency in various mobile wireless environments. HOKEY plans to address these HOKEY plans to address these problems by implementing a generic mechanism to reuse derived EAP keying material for hand-off. "Requirments for the Nameserver Communication protocol", Phil Regnauld, Stephane Bortzmeyer, 19-Dec-06, This document describes the requirments for a protocol to allow DNS nameservers to communicate among themselves, possibly outside the existing DNS protocol, for purposes of zone discovery and provisioning and remote management. "Ethernet Label Switching (ELS)", Francisco Eusebio, 19-Dec-06, This document proposes an evolution for MPLS forwarding component, based on a global hierarchical label, in order to reduce the number of labels managed by each router and to provide a stateless fast local repair mechanism. "Resource Descriptions Extension to the Presence Information Data Format (PIDF)", Miguel Garcia-Martin, Marcin Matuszewski, 20-Dec-06, The Presence Information Data Format (PIDF) defines a basic format for representing presence information for a presentity. This format defines a textual note, an indication of availability (open or closed) and a Uniform Resource Identifier (URI) for communication. Presentities who supply presence information often are willing to provide a description of a collection of resources (such as files, printers, etc.), that are at watchers' disposal. This document extends the PIDF to provide the syntax and format for the description of such resources within the PIDF. "Information Currency Trading Documents and Operations", J. Bedell, 20-Dec-06, The documents and operations used for the trading of information currency are presented in the course of an example trade. "Selective Encryption Support in SRTP", Sunil Mahajan, 21-Feb-07, Selective Encryption is good mechanism to improve performance of devices that support media encode/decode and transport and still meets basic requirement of confidentiality. SRTP is one of the popular mechanism used to support confidential media transport over IP channels. This draft suggests some enhancements to SRTP protocol management to enable SRTP to support "Selective Encryption". "Problem statement of key distribution for 802.11r using CAPWAP protocol", Chengping Ye, Changsheng Wan, 21-Dec-06, CAPWAP specifies a communication exchange mechanism between Wireless Termination Points (WTPs) and a centralized Access Controller (AC) to assist in better coordination and control across the entire ESS network. However it does not specify how to distribute keys used in 802.11r. This document focuses on the requirement for 802.11r key distribution using CAPWAP protocol. "Preparation of Internationalized Strings (stringprep)", Michel Suignard, 21-Dec-06, This document describes a framework for preparing Unicode text strings in order to increase the likelihood that string input and string comparison work in ways that make sense for typical users throughout the world. The stringprep protocol is useful for protocol identifier values, company and personal names, internationalized domain names, and other text strings. This document does not specify how protocols should prepare text strings. Protocols must create profiles of stringprep in order to fully specify the processing options. This document updates RFC3454 (stringprep). "Multi-homed VPN Model for Automating Credit / Debit Cards", A Padmakumar, 21-Dec-06, Credit Cards work on a 'trust model'. This document tries to replace this 'Trust Model' with a 'Secure Model' and proposes a way to cryptographically link Credit / Debit card identities to an end device. "Support for non-compund RTCP in RTCP AVPF profile, opportunities and consequences", Ingemar Johansson, Magnus Westerlund, 8-Mar-07, This memo discusses benefits and issues that arise when allowing RTCP packets to be transmitted as non-compound packets, i.e. not follow the rules of RFC 3550. Based on that analysis this memo proposes changes to the rules to allow feedback messages to be sent as non- compound RTCP packets when using the RTP AVPF profile (RFC 4585) under certain conditions. "IPsec Gateway Failover and Redundancy - Problem Statement and Goals", Vidya Narayanan, 1-Mar-07, Recovering from failure of IPsec gateways maintaining large numbers of SAs may take several minutes, if they need to re-establish the IPsec SAs by re-running the key management protocol, IKEv2. A similar problem arises in the event of a network outage resulting in the failure of several gateways and servers. The latency involved in this approach is significant, leading to a need for a faster and yet secure failover solution. This document describes the problem statement and the goals for an IPsec/IKEv2 gateway failover/ redundancy solution. "Fast Handovers for Macro Mobility in HMIPv6", Youngsong Mun, 27-Dec-06, In Hierarchical Mobile IPv6 (HMIPv6), the long handover latency and packet loss problems take place when a mobile node moves between access routers belonging to different Mobility Anchor Point (MAP) domain, called a macro mobility handover. To improve performance of the macro mobility handover, this document describes a method to execute macro mobility handover rapidly and to reduce both the handover latency and packet loss. The method described in this document is fast handovers for macro mobility handover by applying fast handover method of FMIPv6 protocol to the edge access routers in MAP domain. The two modes of fast handover are used according to the situation of the mobile node. "NETCONF Notification Transport Mappings", Sharon Chisholm, Hector Trevino, 28-Feb-07, This document defines the transport mappings for NETCONF event notifications. This is an optional capability built on top of the base NETCONF protocol. "Local Authentication Scheme Based on AAA Architecture in IEEE 802.16e BWA", Youngsong Mun, 28-Dec-06, Mobile IP has been recently getting popularity with some interesting transformation in order to be more suitable for use by existing and emerging wireless technology, such as IEEE 802.16e Broadband Wireless Access(BWA) One of the fundamental features to make Mobile IP available in commercial world is secure access with it. In this draft, we propose a novel scheme to locally authenticate and authorize inter-domain roaming users for efficient way in IEEE 802.16e BWA based on authentication, authorization and accout-ing(AAA) infrastructure. We present the detailed operations to establish local security association(SA) for authentication and performance evaluation by con-sidering the traffic and mobility properties of a roaming user as well as the dis-tance between the mobile node(MN) and its home AAA server. Proposed scheme outperforms exiting method with respect to authentication cost and ser-vice latency. "SubRTCP:RTCP Extension for Internal Monitoring of RTP Sessions.", Xiaode Xu, 29-Dec-06, This document describes SubRTCP, an extension to RTCP. SubRTCP operates on the same underlying transport establishement as for RTCP but functions independently of the latter. SubRTCP extends RTCP to the middle nodes of an RTP session to allow monitoring of its data delivery also at and between these middle nodes. Such an internal visibility provided by SubRTCP at the middle nodes complements the delivery monitoring by RTCP at the endpoints particularly in service providers' interest. "Compressing Protocol Identifiers for Frame Relay", Eswaran Srinivasan, 29-Dec-06, This document describes a method for compressing the network protocol identifiers for Frame Relay. This will reduce the payload overhead bytes and can improve the packet processing. "FTP EXTENSION ALLOWING IP FORWARDING (NATs)", Martin Rosenau, 29-Dec-06, The FTP protocol [1] needs two connections. A control and a data connection. Using networks with "port forwarding" (eg. SSH, DSL routers, VPN etc.) there is often only the possibility for the server to listen on only one TCP port. In such networks the traditional FTP protocol cannot be used. This memo describes an extension to the FTP protocol that allows the use of FTP using only one TCP port number for both control connections and passive-mode data connections. "Forward-shifted RTP Redundancy Payload Support", Qiaobing Xie, Joe Schumacher, 13-Feb-07, This document defines a simple enhancement to RFC 2198 to support RTP sessions with forward-shifted redundant encodings, i.e., redundant data is sent before the corresponding primary data. Forward-shifted redundancy can be used to conceal losses of a large number of consecutive media frames (e.g., consecutive loss of seconds or even tens of seconds of media). "RFC 4181 Update to Recognize the IETF Trust", C.M. Heard, 3-Jan-07, This document updates RFC 4181, "Guidelines for Authors and Reviewers of MIB Documents", to recognize the creation of the IETF Trust. "Compressed Bundle Header Encoding (CBHE)", Scott Burleigh, 4-Jan-07, This document describes a convention for representing Delay-Tolerant Networking (DTN) Bundle Protocol (BP) endpoint identifiers in a compressed manner within the primary blocks of bundles. "Accessing MIBs using NETCONF", Yan Li, David Harrington, 5-Jan-07, This memo describes a simple mechanism for accessing the Management Information Base (MIB), using the existing NETCONF RPC infrastructure. It defines a set of specific operations for accessing the MIB as a capability of NETCONF. "An EAP Method for EAP Extension (EAP-EXT)", Yoshihiro Ohba, 5-Mar-07, This document describes an EAP method that is used for extending EAP functionality. The extended functionality includes HOKEY re- authentication and MSK channel binding. The proposed EAP method (EAP-EXT) also allows sequencing of multiple EAP methods within itself. EAP-EXT can generate MSK (Master Session Key) and EMSK (Extended Master Session Key) in cases where inner method(s) implementations generate MSK but do not generate EMSK. "DNS Extension for EIPv4", Diao Yongping, 5-Jan-07, Source route based Extensible IP Network(EIPv4) implementation can efficiently resolve the problem of IP address shortage. It is necessary to provide domain name service in EIPv4 to make it suitable for practical application. Here provides a way to DNS extension for EIPv4. It discusses how to extend the architecture of DNS into two-level extensible IP network architecture to provide query between domain name and IP node position denotation. And a new DNS RR type has been defined for this purpose. "Signalling the Ability To Understand Packing of Multiple Telephony Events Into One RTP Packet", Tom Taylor, 5-Jan-07, Section 2.5.1.5 of RFC 4733 specifies how an implementation of the telephony-event payload type can pack multiple short-duration event reports into one RTP packet. Because this capability was added to RFC 4733 in a fashion which is not backward compatible with RFC 2833, it is desirable that a sender have the means to determine whether the receiver understands such packets. This memo specifies a new SDP attribute, a=multev, to indicate that capability. "LDP OSPF Synchronization and VPN Traffic Blackholing", Vijay Ayyangar, Thusitha Jayawardena, 8-Jan-07, This document describes two types of situations where VPN and non-VPN traffic dependent on label forwarding can be blackholed despite the use of LDP OSPF synchronization which helps minimize such blackholing. Ways of mitigating these situations are also discussed. Here, by VPN is meant a layer 3, MPLS-based VPN. "A Conference List Information Event Package for the Session Initiation Protocol (SIP)", Oded Koren, 8-Jan-07, This document describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications related to conference lists. A new conference list event package is specified. This event package allows a user to subscribe to a single event (the conference-list) and receive notifications that contain the list of conferences to which the user belongs and the status of each conference. The notifications sent from the conference server can contain either the entire list of the user's conferences or a partial list with the updates since the previous notification. "E.164 Number Provisioning - Data Set Requirements", David Schwartz, Eli Katz, 9-Jan-07, This document outlines which information should be captured when E.164 numbers are provisioned within a central registry. This document is not a specification but rather a set of information which, when associated with an addressable entity can assist in applying policy to subsequent queries. "Signaling TO Prevent SPIT (SPITSTOP) Reference Scenario", Saverio Niccolini, Juergen Quittek, 11-Jan-07, This memo discusses the need for standards that support SPam over Internet Telephony (SPIT) prevention applications. After explaining the general need for SPIT prevention applications the memo provides a reference scenario for potential communication between entities that may be involved in SPIT prevention. Within this scenario the need for standardizing communication is analyzed for each pair of communicating entities. The analysis is intended to serve as a starting point for discussing the requirements for signaling standards, for example, SIP extensions, that support SPIT prevention applications. This memo is not intended to suggest any solution of SPIT signaling issues. Such work, if necessary at all, would be subject of separate follow-up documents. "Bounce Address Tag Validation (BATV)", John Levine, 11-Jan-07, The envelope of Internet mail contains an RFC2821.MailFrom command, which may supply an address to be used as the recipient of transmission and delivery notices about the original message. Existing Internet mail permits unauthorized use of addresses in the MailFrom command, causing notices to be sent to unwitting and unwilling recipients. Bounce Address Tag Validation (BATV) defines an extensible mechanism for validating the MailFrom address. It also defines an initial use of that mechanism which requires no administrative overhead and no global implementation. This document is a revision of draft-levine-mass-batv-02. "A Uniform Resource Name (URN) Formal Namespace for the British Broadcasting Corporation", Paul Rissen, 12-Jan-07, This document describes a Uniform Resource Name (URN) Namespace Identification (NID) convention as prescribed by the World Wide Web Consortium (W3C) for identifying, naming, assigning, and managing persistent resources and XML artifacts for the British Broadcasting Corporation. "DNSSEC Trust Anchor Configuration and Maintenance", Matt Larson, Olafur Gudmundsson, 2-Mar-07, This document recommends a preferred format for specifying trust anchors in DNSSEC validating security-aware resolvers and describes how such a resolver should initalize trust anchors for use. This document also describes different mechanisms for keeping trust anchors up to date over time. "How to Implement Secure (Mostly) Stateless Tokens", Eric Rescorla, 1-Mar-07, A common protocol problem is to want to arrange to maintain client state with little or no local storage. The usual design pattern here is to provide the client with a token which is returned with subsequent interactions. In order to prevent tampering, forgery, and privacy issues, such tokens should be cryptographically protected. This draft describes one workable mechanism for constructing such tokens. "Keying Material Extractors for Transport Layer Security (TLS)", Eric Rescorla, 15-Jan-07, A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. "Hybrid Overlay Multicast Framework", John Buford, 29-Jan-07, We describe an experimental framework for constructing SAM sessions using hybrid combinations of Application Layer Multicast, native multicast, and multicast tunnels. We leverage AMT [THA2006] relay and gateway elements for interoperation between native regions and ALM regions. The framework allows different overlay algorithms and different ALM control algorithms to be used. "Requirements for In-Band QoS Signalling", John Harper, 16-Jan-07, This document describes the raionale and requirements for in-band signalling of Quality of Service (QoS) characteristics for the Internet Protocol (IP) There has been extensive work on QoS for IP, leading to the development of RSVP, NSIS and other protocols. New requirements emerging from the use of IP to carry services such as video and voice are leading in turn to additional requirements for QoS signalling. The authors believe that these can best be met by adding in-band signalling to IP, complementing the existing protocols for QoS signalling. "IEEE 802.21 Basic Schema", Yoshihiro Ohba, 16-Jan-07, This document describes the basic schema for IEEE 802.21 Media- Independent Information Service, an RDF (Resource Description Framework) schema defined in IEEE 802.21. This document serves as the Specification required by the IANA to maintain a global registry for storing the RDF schema. "Centralized Operator Call Control Framework for the Session Initiation Protocol (SIP)", Thomas Stolz, Michael Alexander, 17-Jan-07, This document proposes a call control framework for the Session Initiation Protocol (SIP). The framework is based on the SIP Subscribe/Notify Method and aims to facilitate implementation of a standardized approach in supporting vendor neutral centralized switchboard functionality for PBXs. "A VPN Library for use with the ForCES Protocol and Model", Joel Halpern, Huanyuan Ma, 18-Jan-07, The forwarding and Control Element Separation (ForCES) protocol defines a standard communication and control mechanism through which a Control Element (CE) can control the behavior of a Forwarding Element (FE). That control is accomplished through manipulating attributes of Logical Function Blocks (LFBs), whose structure is defined in a model RFC produced by the working group. In order to build an actual solution based on this protocol, defining a set of Logical Function Block definitions that can be instantiated by FEs and controlled by CEs is welcome. A base library definition of LFBs is already given in library [5]. VPN (Virtual Private Network) services, as a kind of important services widely employed in Internet, will certainly be implemented in routers using this protocol. This document provides an initial set of VPN LFB definitions in particular, a set of tunnel encapsulator and decapsulator LFBs. It is anticipated that additional VPN-related LFB definitions like L2VPN, L3VPN can be defined over time. "Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) loosely routed Label Switch Path (LSP) Locally", Cui Ying, 18-Jan-07, This document defines a mechanism for the local reoptimization of loosely routed MPLS and GMPLS (Generalized Multiprotocol Label Switching) Traffic Engineering (TE) LSPs signaled with RSVP-TE.This behavior of reoptimization is happened at loose node ,but not the ingress node . "Tasks previously assigned to the IETF Executive Director", Lucy Lynch, 18-Jan-07, This document identifies jobs originally assigned to the IETF Executive Director in existing IETF processes, and in most cases re- assigns them formally to the IETF Secretariat. It updates RFC 2028, 2418, 3005, 3710, 3777, 3929, and 3979. "ASCII Escaping of Unicode Characters", John Klensin, 23-Feb-07, There are a number of circumstances in which an escape mechanism is needed in conjunction with a protocol to encode characters that cannot be represented or transmitted directly. With ASCII coding the traditional escape has been either the decimal or hexadecimal offset of the character, written in a variety of different ways. The move to Unicode, where characters occupy two or more octets and may be coded in several different forms, has further complicated the question of escapes. This document discusses some options now in use and discusses considerations for selecting one for use in new IETF protocols and protocols that are now being internationalized. "A Network Service Identifier for separation of Mobile IPv6 service authorization from Mobile node authentication", Madjid Nakhjiri, Changsheng Wan, 19-Jan-07, Dime working group is designing a procedure for bootstrapping Mobile IPv6 using Diameter. In order to reduce the complexity of Diameter Mobile IPv6 application, the process of Mobile IPv6 service authorization is being separated from the initial mobile node authentication. This This allows for outsourcing the authentication process to another application such as Diameter EAP[RFC4072] . The process can have security considerations, if the authorizing server does not have a clear assurance that the MN has actually been authenticated before, especially if the authorizing server is different from the authenticating server. In this document we provide a procedure and number of extensions to Mobile IPv6 and Diameter signaling to address those considerations. Specifically a new Network Service Identifier (NSI) is defined to assist the interaction between the authorizing and authenticating procedures and servers. "Disposition Notification Requirements for Deferred Messaging", Matthew Stafford, 19-Jan-07, This memo expands the set of use cases for SIP MESSAGE and SIP- controlled MSRP sessions. Following OMA, the new use cases include MSRP for one time messages that exceed the size limit for SIP requests over UDP, and extend the paradigm to deferred messaging. In deferred messaging, which is invoked when the intended recipient is not available, the message is sent to a store and forward server. The new requirements are for disposition notification functionality in this context. "Multimedia Sessions in SILC protocol", Pekka Riikonen, 19-Jan-07, This document defines the use of multimedia protocols and the set up of multimedia sessions in the Secure Internet Live Conferencing (SILC) protocol [SILC1]. "AAA Separation for Roaming", Michaela Vanderveen, 19-Jan-07, This draft proposes a framework that achieves separation of AAA functionality between the home and local domain as it arises in the roaming process. "The SDP (Session Description Protocol) Dependency Attribute", Christian Schmidt, 22-Jan-07, The Session Description Protocol (SDP) was intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. Together with Offer/Answer model it defines a mechanism, how two entities can reach a common view of a multimedia session between them. In certain cases, there are dependencies between media streams, for example a text stream for subtitling make sense only together with a video stream. To avoid senseless connections, the SDP mechanism can be extended with a new Session Description Protocol (SDP) media-level attribute: "dependency". The "dependency" attribute allows the offerer to define dependencies of media streams. The updated offer/ answer mechanism used with new "dependency" attribute can be used furthermore, that in a multi-party SIP session all participants share at least one common media type. "TICTOC Problem Statement", Stewart Bryant, Yakov Stein, 22-Jan-07, This Internet draft describes a number of applications that require accurate time and/or frequency, and elucidates difficulties related to the transfer of high quality time and frequency across an IP or MPLS Packet Switched Network. This issue is not addressed by any currently chartered IETF working group, and we therefore propose the formation of a new working group to be called Transmitting Timing over IP Connections and Transfer of Clock (TICTOC). "Identification of Communications Services in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 8-Mar-07, This document considers the problem of how SIP endpoints can support a multiplicity of distinct SIP services within the context of a single user agent. The principle problem to be addressed is that of dispatching of incoming requests to the right services, and how service contexts are matched up between calling and called parties. This document proposes the usage of service URN and service URI to solve the problem. "Stateless Session Resumption for the IKE Protocol", Yaron Sheffer, 22-Jan-07, The Internet Key Exchange version 2 (IKEv2) protocol is computationally intensive with respect to the number of round-trips required and cryptographic operations involved. In particular the Extensible Authentication Protocol is used for authentication, which adds additional computational intensity. To re-establish security associations (SA) upon a failure recovery condition is time comsuming, especially when an IPsec peer, such as a VPN gateway, needs to re-establish a large number of SAs with various end points. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA restablishment. In many failure cases it would be useful to provide an efficient way to resume an interrupted IKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously establied IKE SA. A client can reconnect to a gateway from which it was disconnected, or alternatively migrate to another gateway that is associated with the previous one. The proposed approach conveys IKEv2 state information, in the form of an encrypted ticket, to a VPN client that is later presented to the VPN gateway for re-authentication. An encrypted ticket cannot be decrypted by a VPN client but allows a VPN gateway to restore state for faster session state setup. "Distributed DNS Implementation in IpV6", Lican Huang, 23-Jan-07, This file is a proposal for P2P based DNS query stratagy in IpV6. The DNS servers construct n-tuple overlay virtual hierarchical overlay network.With cached addresses of DNS servers, the overload of traffic in tree structure can be avoided. This strategy may use for DNS query in IpV6 for a large number of domain names. "ENUM Registry Interface Requirements", Edward Lewis, 23-Jan-07, An ENUM registry interacts with various elements to maintain what is essentially a telephone number to uniform (or a more modern version) resource identifier. The interfaces needed are identified in this requirements document, as well as the requirements for the more generic interfaces. "Locator/ID Separation Protocol (LISP)", Dino Farinacci, 23-Jan-07, This draft describes a simple, incremental, network-based protocol to implement separation of Internet addresses into Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). This mechanism requires no changes to host stacks and no major changes to existing database infrastructures. The proposed protocol can be implemented in a relatively small number of routers. This proposal was stimulated by the problem statement effort at the Amsterdam IAB Routing and Addressing Workshop (RAWS), which took place in October 2006. "EAP Peer Credential Protection", Mohamad Badra, 24-Jan-07, Actual EAP methods provide authentication services based on the use of certificates, secret keys or passwords. These methods, excepting the tunneling ones, exchange peer identity in clear text. Moreover, some of these methods do not enable the ability to exchange channel binding information. They do not, however, define a common encoding of the credential protection or of the channel binding or of. This document defines AVPs to securely exchange data related to the peer identity, when an EAP method deriving keys is deployed. "Anonymous Layers Identifiers (ALIen): Threat Model for Mobile and Multihomed Nodes", Wassim Haddad, 24-Jan-07, This memo describes privacy threats related to the MAC and IP layers identifiers in a mobile and multi-homed environment. "Anonymous Layers Identifiers for Mobile and Multi-homed Nodes: Problem Statement", Wassim Haddad, 24-Jan-07, This memo describes the anonymous layers identifiers in mobility and multi-homing problem statement. "SMTP service extensions for transaction checkpointing", Tony Finch, 7-Feb-07, This memo describes the SMTP service extension for checkpoint/resume, which allows a client to recover from a lost connection to the server without having to repeat all of the commands and message content sent prior to the interruption, and with less risk of duplicated messages. It also includes an updated specification of the predecessor SMTP service extension for checkpoint/restart. "Extenstion to RSVP-TE for GMPLS Controlled Ethernet - An experimental approach", Loa Andersson, Anders Gavler, 8-Mar-07, This document specifies the extensions to RSVP-TE that Acreo AB has used in the GMPLS part of testbed. "Generic Proxying as a Deployment Tool (GEPROD)", Pekka Nikander, 29-Jan-07, This document presents a generic way of using Forwarding Proxies, designed to be used as a transition mechanism in implementing various flavors of the so called Identifier / Locator separation, including both "above IP" and "below IP" approaches. This version of this draft is an very incomple version, intented to induce discussion. "Provisioning Extensions in Peering Registries for Multimedia Interconnection (PEPPERMINT) Problem Statement", Andrew Newton, 29-Jan-07, This document contains descriptions of the problems faced by operators and participants of multimedia interconnection (i.e. SIP) peering registries with respect to identity provisioning. "SMTP Service Extension for Deferred RCPT", Eric Hall, 29-Jan-07, This memo describes a mechanism for the negotiation and transfer of per-recipient notification responses in SMTP. "OSPF Extensions in Support of Inter-AS (G)MPLS TE", Mach Chen, Renhai Zhang, 1-Feb-07, This document describes extensions to the OSPF protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). It defines OSPF extensions for the flooding of inter-AS links which can be used to perform inter-AS path computation. "Internet Calendaring and Scheduling Venue Component Specification", Charles Norris, Jeff McCullough, 31-Jan-07, The currently existing iCalendar standard (RFC 2445) provides only a simple text field ("LOCATION" property) for specifying the location where an event (or "TODO" item) will occur. While this may be adequate for human readers, it is difficult for automated systems to make use of. With the recent advent of tools and services (event aggregators, for example) which would benefit greatly from structured location data, the need to specify detailed venue information has become apparent. This document describes a proposed method for addressing this need. Comments are solicited and should be addressed to the working group's mailing list at ietf-ical-extensions@eventful.com and/or the authors. Note: This document depends on RFC2445bis, currently in draft status, and should not proceed without RFC2445bis. "Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions", Eiji Oki, Adrian Farrel, 31-Jan-07, The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. When a Path Computation Client (PCC) requests a PCE for a route, it may be useful for the PCC to specify as constraints to the path computation abstract nodes, resources, and Shared Risk Link Groups (SRLGs) that are to be explicitly excluded from routes. Such constraints are termed route exclusions. The PCE Communication Protocol (PCEP) is designed as a communication protocol between PCCs and PCEs. This document presents PCEP extensions for route exclusions. "Progress notifications for HTTP", Andrien de Croy, 1-Feb-07, This document specifies extenions to HTTP to allow progress messages for user-agents during lengthy transactions, and to allow better flow-control of large message body submission in cases where HTTP authentication is required by servers and/or intermediaries. "Private Information Queries (Problem statement)", Pars Mutaf, 1-Feb-07, This document makes a problem statement for the "Private Information Queries" protocol. "Requirements for the XCON-DCON Synchronization Protocol", Alfonso Buono, 1-Feb-07, The Distributed Conferencing (DCON) framework provides the means to distribute Centralized Conference (XCON) information by appropriately orchestrating a number of centralized focus entities (clouds). The mechanism we propose to make each XCON cloud communicate with its related DCON peer is based on the use of some kind of XCON-DCON Synchronization Protocol (XDSP). This document gives the requirements for XDSP. "Requirements for Distributed Conferencing", Alfonso Buono, 1-Feb-07, This document examines the requirements for Distributed Conferencing (DCON). Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols as needed. Together, these documents will provide a guideline for building interoperable conferencing applications. The current works in SIPPING and XCON working groups marginally address the matter, which is nonetheless considered as out-of-scope. The requirements listed in this document are in part based on thoughts derived from the cited working groups activities. "A Framework for Distributed Conferencing", Alfonso Buono, 1-Feb-07, This document defines the framework for Distributed Conferencing (DCON). The framework draws inspiration from the work carried out in the XCON working group, which has defined a complete architecture for centralized conferencing. DCON is based on the idea that a distributed conference can be setup by appropriately orchestrating the operation of a number of XCON focus elements, each in charge of managing a certain number of participants. Interaction between each participant and the corresponding conference focus is based on the standard XCON framework, whereas inter-focus interaction is defined in this document. "Reliable Delivery for syslog", Eliot Lear, 6-Feb-07, The syslog protocol describes a number of service options related to propagating event messages. This memo describes a mapping of the syslog protocol to TCP connections, useful for reliable delivery of event messages through the use of a BEEP profile. The earlier RAW and COOKED BEEP syslog profiles are deprecated. The use of syslog over BEEP provides robustness and security in message delivery that is unavailable to the usual UDP-based syslog protocol, by providing encryption and authentication over a connection-oriented protocol. "Jitter considerations in MANETs", Thomas Clausen, 1-Mar-07, This document provides recommendations for jittering (randomly modifying timing) of control traffic transmissions in MANET routing protocols to reduce the probability of packet collisions. "SIP Certificate Authentication Solution", Steve Dotson, 7-Feb-07, This document specifies SIP Certificate Authentication (SCA), a challenge-response mechanism that uses public key cryptography to perform certificate-based authentication in Session Initiation Protocol (SIP) based architectures. Performing authentication in SIP with certificates will provide stronger authentication capabilities and increase possible deployment scenarios in SIP networks. The scope is limited to the authentication of the SIP UA to the SIP Service Provider's network. It does not include UA to UA authentication within its scope. "Extensions for RDCO and Static Macroblocks in the RTP Payload Format for H.264 Video", Tom Kristensen, 7-Feb-07, This document proposes extensions to the RTP payload format specification for H.264 video defined in RFC 3984. It addresses two separate issues: (i) The signalling of the framerate of static macroblocks a decoder is able to process in order to sustain high framerates with high resolutions. (ii) The signalling of a reduced- complexity decoding operation (RCDO) for H.264 Baseline profile bitstreams. "A Uniform Resource Name (URN) Namespace for the Society of Motion Picture and Television Engineers (SMPTE)", Thomas Edwards, 13-Feb-07, This document describes a Uniform Resource Name (URN) namespace for the Society of Motion Picture and Television Engineers (SMPTE) for naming persistent resources that SMPTE produces or manages. A subnamespace for Universal Labels is specifically described. "Use of Status-Server Packets in RADIUS", Alan DeKok, 7-Feb-07, [RFC2865] defines a Status-Server code for use in RADIUS, but labels it as "Experimental" without further discussion. This document describes practical uses for Status-Server that have been implemented as a method of querying the status of a RADIUS server. "Requirements for a Location-by-Reference Mechanism used in Location Configuration and Conveyance", Roger Marshall, 7-Mar-07, This document defines terminology and enumerates requirements for a location-by-reference approach to location configuration and conveyance interactions useful for emergency call routing for voice- over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end-to-end. "X.509 authentication in SSH", Oskari Saarenmaa, 8-Feb-07, This document specifies how X.509 certificates and signatures are used within the Secure Shell protocol for user and server authentication. "Early Media in SIP: Problem Statement, Requirements, and Analysis of Solutions", Russ Barnes, Matt Lepinski, 8-Feb-07, The Session Initiation Protocol (SIP) enables and permits endpoints in an INVITE transaction to send media packets before an SDP offer/ answer exchange has completed; we refer to such media packets as early media. The use of early media is common in current SIP implementations, and causes several problems, which have been documented elsewhere. This document puts forward the goal of modifying SIP so that compliant implementations will complete an SDP exchange before sending media, and lays out high-level requirements for such a solution. The set of possible solutions is then laid out, and each possibility examined in light of these requirements. "GRSVP-TE Signaling Extension For The Conversion Between Permanent Connections And Soft Permanent Connections In A GMPLS enabled Transport Network", Diego Caviglia, 8-Feb-07, In a transport network scenario, where Data Plane connections controlled either by GMPLS (Soft Permanent Connections - SPC) or by Management System (Permanent Connections - PC) may independently coexist, the ability of transforming an existing PC into a SPC and vice versa - without actually affecting Data Plane traffic being carried over it - is a valuable option. This applies especially when a GMPLS based Control Plane is first introduced into an existing network and there may be the need, from a Carrier point of view, to pass under GMPLS control existing connections already set up over Data Plane. In other terms, such operation could be seen as a way of transferring the ownership and control of an existing and in-use Data Plane connection between the Management Plane and the Control Plane, leaving its Data Plane state untouched. This memo provides a minor extension to GRSVP-TE signaling protocol, within GMPLS architecture, to enable such transfer of ownership and describes the proposed procedures. "Transmission of IPv4 packets over 802.16's IP Convergence Sublayer", Soohong Daniel Park, Syam Madanapalli, 8-Feb-07, IEEE 802.16 is an air interface specification for wireless broadband access. IEEE has specified several service specific convergence sublayers (CS) for 802.16 which are used by upper layer protocols. The ATM CS and Packet CS are the two main service-specific convergence sublayers and these are a part of the 802.16 MAC which the upper layers interface to. The packet CS is used for transport for all packet-based protocols such as Internet Protocol (IP), IEEE Std. 802.3 (Ethernet) and, IEEE Std 802.1Q (VLAN). The IP specific part of the Packet CS enables transport of IPv4 packets directly over the 802.16 MAC. This document specifies the frame format, the Maximum Transmission Unit (MTU) and address assignment procedures for transmitting Pv4 packets over IP Convergence Sublayer (IPCS) of IEEE 802.16. This document describes on how to deal with Address Resolution Protocol (ARP) and Mapping of multicast IP address to MAC address. "Source Address Validation Architecture (SAVA) Framework", Jianping Wu, 8-Feb-07, This document presents the framework for SAVA (Source Address Validation Architecture). "Source Address Verification Architecture Problem Statement", Jianping Wu, 8-Feb-07, This document outlines the problems for the Source Address Verification Architecture (SAVA) initiative to solve. It examines the current state in the internet, looks at current best practices and discusses why the current approach is unlikely to ever solve the problem of IP address spoofing. It also discusses some of the problems that SAVA should NOT attempt to solve. "A End-to-end Source Address Validation Solution for IPv6", Jianping Wu, 8-Feb-07, This document describes the detail mechanism and protocol definition of a light-weight signature based and end-to-end deployed method for preventing the spoofing of source IPv6 address. "Advertising Generic Information in IS-IS", Les Ginsberg, 8-Feb-07, This draft describes the manner in which generic application information (i.e. information not directly related to the operation of the IS-IS protocol) SHOULD be advertised in IS-IS LSPs and defines guidelines which SHOULD be used when flooding such information. "MANEMO Problem Statement", Ryuji Wakikawa, 8-Feb-07, This document outlines the fundamental problems and approach rationale of MANEMO. When mobile nodes converge at the edge of the Internet using wireless interfaces, they can form a network in an ad- hoc fashion and are able to provide Internet connectivity to one another. This type of network is called a MANEMO Fringe Stub (MFS). Several issues exist in the MFS such as network loop, un-optimized path and multiple exit routers to the Internet. While fixed routers provide connectivity constantly, mobile routers can experience intermittent connectivity to the Internet due to their movement. When NEMO Basic Support is used in this context, network loops naturally occur. NEMO forces the packets to always travel through the home agent, which in turn causes an un-optimized path that can become a considerable problem when mobile routers form a nested topology. Multicast support introduces emphasized inefficiency. Different types of routers are able to provide Internet connectivity in the MFS, including both mobile routers and fixed access routers. Any node requiring Internet connectivity has to select the best exit router toward the Internet, therefore it is necessary for mobile nodes to maintain a local topology in the MFS and to utilise any available connectivity with a degree of Intelligence. "Extensions to Resource Reservation Protocol (RSVP) for Mobile IPv6", Yi Sun, 8-Feb-07, RSVP [1] is designed as a signaling protocol that provides end-to-end QoS guarantee for real-time services in the fixed hardwired network. However, when used in the mobile environment, the protocol doesn't work well due to the mobility of the endpoints. Immediately after a handover occurs, because of the lack of resource reservation in the handoff target subnet, QoS of the session degrades notably. Another problem is that when route optimization is implemented, the protocol will be invalidated due to certain features of the route optimization mechanism. This document proposes extensions to RSVP. The extensions enable RSVP to operate in the mobile IPv6 network while providing advanced resource reservation before handover and resource reservation on the optimized route after handover. With these features, QoS of the sessions can be guaranteed and the utilization of network resources can be enhanced resulting in the improvement of overall network performance. "Representing multi-value time in MANETs", Thomas Clausen, Christopher Dearlove, 8-Feb-07, This document describes a general and flexible TLV (type-length-value structure) for representing time using the generalized MANET packet/ message format. It defines two message TLVs for representing validity and interval times for MANET routing protocols. "Requirements for a Session Initiation Protocol (SIP) Transparent Back-To-Back User-Agent (B2BUA)", Xavier Marjou, 8-Feb-07, A SIP Back-To-Back User Agent (B2BUA) refers to the concatenation of a SIP User Agent Client (UAC) and a SIP User Agent Server (UAS). A transparent B2BUA is a particular type of B2BUA that forwards SIP messages in a SIP proxy-like way, and that also benefits from some features of a User Agent (UA) element. This document recommends best current practices for the implementation of such a transparent B2BUA. Developing transparent B2BUAs that meet this set of requirements will greatly increase the likelihood that SIP applications will function properly. "TCP Maintenance and Minor Extensions", Mahesh Jethanandani, Murali Bashyam, 9-Mar-07, This document describes how a connection can remain infinitely in persist state and its Denial of Service (DoS) implication on the system if there is no mechanism to recover from this anomaly. "Dynamic Symmetric Key Provisioning Protocol", Mingliang Pei, Salah Machani, 13-Feb-07, This document specifies a symmetric key provisioning protocol that supports provisioning of symmetric keys (One Time Password (OTP) keys or symmetric cryptographic keys) and associated attributes dynamically to already issued different types of strong authentication devices. This work is a joint effort by the members of OATH (Initiative for Open AuTHentication) to specify a protocol that can be freely distributed to the technical community. The authors believe that a common and shared specification will facilitate adoption of two- factor authentication on the Internet by enabling interoperability between commercial and open-source implementations. "Portable Symmetric Key Container", Philip Hoyer, 13-Feb-07, This document specifies a shared secret token format for transport and provisioning of shared secrets (One Time Password (OTP) keys or symmetric cryptographic keys) to different types of strong authentication devices. The standard token format enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure. This work is a joint effort by the members of OATH (Initiative for Open AuTHentication) to specify a format that can be freely distributed to the technical community. The authors believe that a common and shared specification will facilitate adoption of two- factor authentication on the Internet by enabling interoperability between commercial and open-source implementations. "Relay Chaining in DHCPv4", Bharat Joshi, Pavan Kurapati, 13-Feb-07, DHCP Relay Agents eliminate the necessity of having a DHCP server on each physical network. DHCPv4 assumes that there is always only one Relay Agent between DHCP clients and DHCP server. In certain network configurations, a DHCP server may be multiple subnets away from the DHCP client and multiple Relay Agents may be configured to relay DHCP messages to and from DHCP client. Such configuration can be supported only when each Relay Agent adds certain Information to DHCP messages before relaying them. This additional information helps in relaying the DHCP reply back to the DHCP client through the same path. This mechanism is often referred as Relay Chaining. "Layer 2 Relay Agent", Bharat Joshi, 13-Feb-07, In Layer 2 Access Networks, Access Concentrators are present between DHCP Clients and Relay Agent. In this case, the Relay Agent can not uniquely identify the end host and hence can not add unique 'Relay Agent Information' option corresponding to the end hosts in DHCP messages. As the Access concentrators are closer to the end hosts, they can uniquely identify the end hosts and add the Relay Agent Information option in the DHCP message. Access concentrators do not set the 'giaddr' field. Access Concentrators in this mode are typically known as Layer 2 Relay agents. This document provides insight to the behavior of the Access Concentrators which act as DHCP Layer 2 Relay Agents in Access Networks. "Early Media INDirection (EMIND) in the Session Initiation Protocol (SIP)", Brian Stucker, 13-Feb-07, This document describes models that can be used to manage multiple early media streams in the Session Initiation Protocol (SIP). The model seeks to allow calling party endpoints to be able to better control the rendering of early media to the user, and distinguish early media from final media. Although some of early media challenges are likely to never be overcome, (e.g. when interworking with an ISUP PSTN gateway that does not take into account CPG or ACM messages), the potential to improve on what is already there does exist. The recommendations in this document are intended to be an update to RFC-3960 recommendations and to avoid many of the complications outlined in draft-stucker-sipping-early-media-coping. "Bandwidth Metrics", Guido Franceschini, 14-Feb-07, When delivering audio and video data through low capacity links, it is important to optimally exploit the limited resources in order to provide the best possible user experience. QoS aspects in this respect might relate to the pure audio and video quality, as well as to delay and lip-sync. The actual weights of the different QoS aspects depend on the service being offered, and are out of the scope of this document. In order to optimally exploit the limited resources, it is necessary to get a reasonable precise measurement of them. This document proposes metrics to address this problem. This document, in this initial draft, focuses only on the semantic aspects, leaving out the syntactical details. "PSTN scope of PCN Charter", Stuart Goldman, Robert Schafer, 14-Feb-07, As the effort to develop the PCN charter draws to a conclusion, it seems helpful to have a touchstone of some concerns relative to the PSTN network and IP network Gateway in order to confirm that they are either in scope of the initial charter or will be addressed in future work. This attempt is motivated by a desire to avoid the accidental omission of a topic that may be hard to "retrofit" in later. "'MSR' Bandwidth modifier in SDP Offer/Answer model", Nikolai Leung, HariKishan Desineni, 26-Feb-07, This document defines a new SDP bandwidth modifier that can be used to specify the maximum media bitrate in 'send' direction of a stream in SDP offer/answer model. "Guidelines for Considering Operations and Management of New Protocols", David Harrington, 15-Feb-07, New protocols or protocol extensions are best designed with due consideration of operations and management issues related to the protocol. Retrofitting operations and management recommendations to protocols is sub-optimal. The purpose of this document is to provide guidance to authors of protocol documents about aspects to consider related to the operations and management that should be considered for inclusion in documents defining requirements or functionality of new protocols or protocol extensions. "Extended packet types for the Secure Shell (SSH) Transport Layer Protocol", Ben Harris, 23-Feb-07, This memo introduces a new message type into the Secure Shell (SSH) Transport Layer Protocol whose meaning and contents are defined by a name at the start of the message, thus allowing for further extensions to the protocol to be implemented without using further message numbers. Comments are solicited and should be addressed to the mailing list at or to the author. "An enhancement of Mobile IPv6 Return Routability Procedure using Elliptic Curve Cryptography Key agreement Protocol", Chunqiang Li, 16-Feb-07, Mobile IPv6 Return Routability Procedure (RRP) is used to secure the Binding Updates between a Mobile Node and a Correspondent Node where there is no pre-established security relationship between the two parties. This document puts forward a mechanism called ECC RRP, which enhances the key management for Return Routability Procedure with anonymous Elliptic Curve Cryptography (ECC) Key Agreement Protocol. The proposed procedure is not prone to attacks by nodes on the route from correspondent node to home agent in way that the RRP process described in RFC3775 is. It also reduces the latency related to handovers that require new binding updates. "Service Selection for Mobile IPv6", Jouni Korhonen, 2-Mar-07, In some Mobile IPv6 deployments identifying the mobile node or the mobility service subscriber is not enough to distinguish between multiple services possibly provisioned to the said mobile node and its mobility service subscription. A capability to specify different services in addition to the mobile node identity can be leveraged to provide flexibility for mobility service providers on provisioning multiple services to one mobility service subscription. This document describes a Service Selection Mobility Option for both conventional Mobile IPv6 or Proxy Mobile IPv6 that is intended to assist home agents to make a specific service selection for the mobility service subscription during the binding update procedure. "Service Selection for Mobile IPv4", Jouni Korhonen, Ulf Nilsson, 16-Feb-07, In some Mobile IPv4 deployments identifying the mobile node or the mobility service subscriber is not enough to distinguish between multiple services possibly provisioned to the said mobile node and its mobility service subscription. A capability to specify different services in addition to the mobile node identity can be leveraged to provide flexibility for mobility service providers to provide multiple services within a single mobility service subscription. This document describes a Service Selection Extension for Mobile IPv4 that is intended to assist home agents to make specific service selections for the mobility service subscription during the registration procedure. "Use cases for Enterprise Peering using the Session Initiation Protocol (SIP)", John Elwell, Benny Rodrig, 16-Feb-07, Work in the SPEERMINT Working Group has focused to some extent on peering between carrier VoIP Service Providers (VSP). This draft describes some use cases involving SIP peering between enterprise VSPs, with and without the involvement of carrier VSPs, and also peering between enterprise VSPs and carrier VSPs. It also discusses some of the key technical considerations applicable to these use cases. This work is being discussed on the speermint@ietf.org mailing list. "A Modification to COPS to Improve Implementation of Push Mode", Huiying Xu, 16-Feb-07, COPS (RFC 2748) was originally designed for pull mode operation. The message exchanges for pull mode are efficient and support a close relationship between the protocol operations and state associated with particular events detected at the Policy Enforcement Point (PEP). The operation of push mode, as defined in COPS-PR (RFC 3084), is more awkward. Push mode involves extra messaging between the PEP and the Policy Decision Point (PDP) if one again wants to associate state arising from specific events (this time detected at the PDP) with specific protocol operations. This memo proposes to modify RFC 2748 to make push mode operation more efficient. Comments are invited on whether there are issues with the proposed solution. "Requirements for the End-Middle-End Research Group", Saikat Guha, Paul Francis, 17-Feb-07, This document proposes a set of requirements for the IRTF EME (End Middle End) research group. The intent is to serve as a starting point for discussions about EME requirements. "Additions to IKEv2 tutorial and Rationale for Decisions", Ana Kukec, 17-Feb-07, This document contains additions to the R. Perlman's draft Understanding IKEv2: Tutorial, and rationale for decisions. Its purpose is to request for comments and to incorporate it into draft-ietf-ipsec-ikev2-tutorial-01. This document describes some of controversial issues discussed on the IPsec mailing list and described in various IETF documents that were written after the publication of draft-ietf-ipsec-ikev2-tutorial-01. Its additional purpose is to explain some of IKEv2 protocol parts that were not described in draft-ietf-ipsec-ikev2-tutorial-01. It follows the original R. Perlman draft's concept to be both a tutorial for understanding IKEv2 and a summary of IKEv2 issues. "Son of IPSO (SIPSO)", Michael StJohns, 17-Feb-07, This document describes an optional method for encoding explicit packet sensitivity labels on IPv6 packets. It is intended for use only within multi-level secure (MLS) networking environments that are both trusted and trustworthy. "Container Option for Server Configuration", Ralph Droms, 20-Feb-07, In some DHCP service deployments, it is desirable for a DHCP server in one administrative domain to pass configuration options to a DHCP server in a different administrative domain. This DHCP option carries a set of DHCP options that can be used by another DHCP server. "Disclosing Secure RTP (SRTP) Session Keys with a SIP Event Package", Dan Wing, 20-Feb-07, Many Secure RTP (SRTP) key exchange mechanisms do not disclose the SRTP session keys to intermediate SIP proxies. However, these key exchange mechanisms cannot be used In environments where transcoding, monitoring, or call recording are needed. This document specifies a secure mechanism for a cooperating endpoint to disclose its SRTP master keys to an authorized party. "Mobile Node Agnostic Fast Handovers for Proxy Mobile IPv6", Frank Xia, Behcet Sarikaya, 20-Feb-07, In the current Proxy Mobile IPv6 (PMIPv6) proposals, the mobile nodes do not implement any mobility management protocol. This document proposes an enhancement to PMIPv6 protocol in order to improve Layer 3 handover performance through borrowing some ideas from FMIPv6 protocol and using IEEE 802.21 triggers. It proposes to use FMIP PAR-NAR signaling to establish a tunnel and PAR uses this tunnel to send MN's packets to NAR during handover. FMIP PAR-NAR signaling depends on the predictive and reactive modes of handover. "IS-IS Authentication with HMAC-SHS", Randall Atkinson, 2-Mar-07, This document describes how the NIST Secure Hash Standard family of algorithms are used for IS-IS authentication. "DHCPv6 Vendor-specific Message", Bernie Volz, 20-Feb-07, This document requests a vendor-specific DHCPv6 message assignment. It also requests that a range of options be reserved. This message and reserved options can be used for vendor specific and experimental purposes. "Fast Handovers for Mobile IPv6 Operation on Point-to-Point Links", Frank Xia, Behcet Sarikaya, 20-Feb-07, FMIPv6 standard currently assumes that the mobile nodes are connected to the access routers using a shared link and does not define the operation over Point-to-Point links. In this document we define FMIPv6 operation over the Point-to-Point links. A PAR advertises PrRtAdv including one or more aggregate prefixes of a NAR to an MN; The MN formulates it's provisional NCoAs with the aggregate prefix(es); The MN initiates FMIPv6 procedure including the provisional NCoAs. Once detecting provisional NCoAs of the MN, the NAR assigns a unique prefix called the dedicated prefix to MN and the MN configures it's final NCoAs. Both reactive and predictive modes of FMIPv6 are explained. "Public Key Cryptography Based User-to-User Authentication - (PKU2U)", Larry Zhu, 27-Feb-07, This document defines the public key cryptography based user-to-user authentication protocol - PKU2U. This mechanism provides security services in peer to peer networking environments without requiring a trusted third party. Furthermore, the binding of PKU2U for the Generic Security Service Application Program Interface (GSS-API) per RFC2743 is defined based on RFC4121. "Discovering the Local Location Information Server (LIS)", Martin Thomson, James Winterbottom, 20-Feb-07, A method is described for the discovery of a Location Information Server. The method consists of attempting to use a Dynamic Host Configuration Protocol (DHCP) option, followed by a URI-enabled NAPTR (U-NAPTR). DHCP options are defined for both IPv4 and IPv6 DHCP. This document also defines a U-NAPTR Application Service for a LIS, with a specific Application Protocol for the HTTP Enabled Location Delivery (HELD) protocol. "Considerations of provider-to-provider agreements for Internet-scale QoS", Pierre Levis, Mohammed Boucadair, 20-Feb-07, This memo analyzes provider-to-provider QoS agreements suited for a global QoS-enabled Internet. It defines terminology relevant to inter-domain QoS models. It introduces a new concept denoted by Meta-QoS-Class. This new concept drives and federates the way QoS inter-domain relationships are built. It opens up new perspectives for a QoS-enabled Internet that retains, as much as possible, the openness of the existing best-effort Internet. "E.212 ENUMService Type Definition", Edward Lewis, 20-Feb-07, This document registers the Enumservice "e212" using the URI scheme "tel:" as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice may be used to indicate International Mobile Subscriber Information with a telephone number. "E.212 Parameters for the "tel" URI", Edward Lewis, 20-Feb-07, Parameters are defined in the "tel" Uniform Resource Identifier (URI) to carry ITU E.212-related information. "The stale-if-error HTTP Cache-Control Extension", Mark Nottingham, 20-Feb-07, The stale-if-error HTTP Cache-Control extension improves availability of some kinds of cached content by allowing servers and clients to instruct caches to use stale responses when certain error conditions are encountered. "The stale-while-revalidate HTTP Cache-Control Extension", Mark Nottingham, 20-Feb-07, The stale-while-revalidate HTTP response Cache-Control extension allows servers to instruct shared caches to serve stale responses while validating them, to avoid latency in some situations. "MANET Autoconfiguration over Multilink Sites", Fred Templin, 21-Feb-07, Mobile Ad-hoc Networks (MANETs) consist of routers operating over multihop wireless links, and may or may not connect to other networks and/or the Internet. Routers in MANETs must have a way to automatically provision local and global-use IP addresses/prefixes. This document specifies mechanisms for MANET autoconfiguration that view the MANET as a multilink site. Both IPv4 and IPv6 are discussed. "MANET Autoconfiguration over Virtual Ethernets", Fred Templin, 21-Feb-07, Mobile Ad-hoc Networks (MANETs) consist of routers operating over multihop wireless links, and may or may not connect to other networks and/or the Internet. Routers in MANETs must have a way to automatically provision local and global-use IP addresses/prefixes. This document specifies mechanisms for MANET autoconfiguration that view the MANET as a virtual ethernet. Both IPv4 and IPv6 are discussed. "Hierarchical Mobility Anchor Points (HMAPs) for Network Localized Mobility Mangement (NETLMM)", Steven Russert, Fred Templin, 21-Feb-07, The Mobility Anchor Point (MAP) for Network Localized Mobility Management (NETLMM) is a single point of failure for the Localized Mobility Management Domain (LMMD) and a focal point for all mobile node (MN) traffic. These shortcomings can be addressed by distributing the MAP function equally among the Access Routers (ARs) in the LMMD and deploying hierarchically organized supporting nodes in the backhaul network. This document specifies a Hierarchical MAP (HMAP) and its use in operational delployments that support traffic distribution and fault tolerance. Solutions for both IPv4 and IPv6 are given. "Classifying Response Codes to Support Multiple Path Routing in the Session Initiation Protocol (SIP)", Dale Worley, 21-Feb-07, An increasing number of SIP architectures implement multiple path routing (MPR), which is the providing of more than one path for a call to reach a destination user agent (UA). To implement MPR well, the proxy which forks a request onto the paths needs to be able to determine if a fork that failed reached the destination UA and was rejected by the UA (and so an alternate path should not be tried), or if the fork failed before reaching the UA (and so an alternate path should be attempted). In order that the proxy can distinguish these two situations, response codes should unambiguously identify which of these situations applies. This Internet-Draft begins classifying the current usage of response codes, their implications for MPR, and possible improvements. "A TCP Test to Allow Senders to Identify Receiver Cheating", T Moncaster, 21-Feb-07, The honesty of TCP senders and receivers has become a major concern to the Internet community. Currently, TCP senders rely on receiver honesty so they can correctly react to network congestion. Such honesty cannot be taken for granted. Receivers may conceal dropped packets to prevent their flow being subject to a congestion response or may acknowledge data optimistically to get a higher bandwidth. This document introduces a simple two-stage test of receiver honesty. Once a receiver fails the first stage it can be subjected to the second stage test that conclusively proves cheating. The performance hit of the first stage is very slight compared to the second. So, although the first stage is not decisive, it selects which receivers are acting suspiciously enough to warrant the second stage. This specification does not modify the TCP protocol - the tests only require a change to sender implementations. "C2C-C Consortium Requirements for Usage of NEMO in VANETs", Roberto Baldessari, 23-Feb-07, Vehicular ad hoc Networks (VANETs), self-organized networks based on short-range wireless technologies, aim at improving road safety and providing comfort and entertainment applications. The Car2Car Communication Consortium is defining a European standard for inter- vehicle communication that adopts VANETs principles. This document describes the scope, use cases and requirements for a solution based on Network Mobility (NEMO) in VANETs as identified by the Consortium. "Protocol Model for TLS with EAP Authentication", Yoav Nir, 23-Feb-07, This document describes an extension to the TLS protocol to allow TLS clients to authenticate with legacy credentials using the Extensible Authentication Protocol (EAP). This work follows the example of IKEv2, where EAP has been added to the IKEv2 protocol to allow clients to use different credentials such as passwords, token cards, and shared secrets. When TLS is used with EAP, additional records are sent after the ChangeCipherSpec protocol message, effectively creating an extended handshake before the application layer data can be sent. Each EapMsg handshake record contains exactly one EAP message. Using EAP for client authentication allows TLS to be used with various AAA back-end servers such as RADIUS or Diameter. TLS with EAP may be used for securing a data connection such as HTTP or POP3, where the ability of EAP to work with backend servers can remove that burden from the application layer. This document is a protocol model, rather than a full protocol specification. "A BEEP Binding for the HELD Protocol", Martin Thomson, James Winterbottom, 23-Feb-07, A BEEP binding is described for HELD. This binding is more suitable than the basic HTTP binding in scenarios where multiple messages are sent between the same two parties. Discovery methods relating to this binding are described. "Digital Signature Methods for Location Dependability", Martin Thomson, James Winterbottom, 23-Feb-07, The dependability of location information is closely related to the degree of trust placed in the source of that information. This document describes techniques that can be used to mitigate the impact of falsifying location information. The application of digital signatures is described, relating these methods to the attacks that they address. "Label Switched Path (LSP) Dynamical Provisioning Performance Metrics in Generalized MPLS Networks", Guowu Xie, 23-Feb-07, Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising candidate technologies for the future data transmission network. The GMPLS has been developed to control and cooperate different kinds of network elements, such as conventional routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add- Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. Dynamic provisioning ability of these physically diverse devices differs from each other drastically. At the same time, the need for dynamically provisioned connections is increasing because optical networks are being deployed in metro area. As different applications have varied requirements in the provisioning performance of optical networks, it is imperative to define standardized metrics and procedures such that the performance of networks and application needs can be mapped to each other. This document provides a series of performance metrics to evaluate the dynamic LSP provisioning performance in GMPLS networks, specifically the dynamical LSP setup/release performance. These metrics can depict the features of the GMPLS network in LSP dynamic provisioning. "Client-Friendly Cross-Realm Model for Kerberos 5", Ken'ichi Kamada, Shoichi Sakane, 7-Mar-07, This document proposes a cross-realm transition model, which is friendly to resource-limited clients, for Kerberos Version 5. This model provides a way to move the cost of consecutive Ticket-Granting Service (TGS) exchanges from the clients to the Key Distribution Center (KDC) and a way to reduce the transition cost by generating a direct inter-realm relationship between two realms. The document itself does not specify any protocols, which need to be specified separately. "A Uniform Resource Identifier for Geographic Locations ('geo' URI)", Alexander Mayrhofer, Christian Spanring, 23-Feb-07, This document specifies an Uniform Resource Identifier (URI) for geographic locations using the 'geo' scheme name. A 'geo' URI provides latitude, longitude and optionally altitude of a location in a simple, human-readable form. The 'geo' URI is not tied to a specific application or protocol. "SIP Privacy Clarified", Mayumi Munakata, 23-Feb-07, This document defines the privacy mechanisms for the Session Initiation Protocol (SIP). Specifically, guidelines are provided for the creation of messages that do not divulge personal identity information. A "privacy service" logical role for intermediaries is defined to answer some privacy requirements that user agents cannot satisfy themselves. Finally, means are presented by which a user can request particular functions from a privacy service. "BGP Session Security Requirements", Michael Behringer, 23-Feb-07, The document "BGP security requirements" (draft-ietf-rpsec-bgpsecrec-07) specifies general security requirements for BGP. However, specific security requirements for single BGP sessions, i.e., the connection between two BGP peers, are only touched on briefly in the section "transport layer protection". This document expands on this particular aspect of BGP security, defining the security requirements between two BGP peers. Context of this document: RPSEC WG; Charter item: "Document security requirements for routing systems". "S2L Name Identification for Point-to-Multipoint TE LSPs", Zafar Ali, Robert Sawaya, 23-Feb-07, One of the management requirements for point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks is the ability to identify source-to-leaf (S2L) sub-lsp by name. This document provides a minor extension to RSVP-TE for P2MP TE LSPs [RSVP-TE- P2MP] to signal name for S2L sub-lsp. "Bootstrap Mechanisms for P2PSIP", Eric Cooper, 26-Feb-07, This document describes mechanisms that a peer can use to locate and establish a Peer Protocol connection to an admitting peer in order to join an overlay network. In the first mechanism, the joining peer uses multicast to locate a bootstrap peer; in the second, the node uses one or more bootstrap servers to locate a bootstrap peer; in both cases, the bootstrap peer then proxies the request by the joining peer on to the admitting peer. Each mechanism has its advantages and disadvantages, and a node can utilize both. "Vouch By Reference", Paul Hoffman, 26-Feb-07, This document describes the Vouch By Reference (VBR) protocol. VBR is a protocol for adding third-party certification to email. It permits independent third parties to certify the owner of a domain name that is associated with received mail. "Extensions to CT-KIP to support one- and two-pass key initialization", Magnus Nystroem, Salah Machani, 26-Feb-07, This document describes extensions to the Cryptographic Token Key Initialization Protocol (CT-KIP) to support one-pass (i.e. one message) and two-pass (i.e. one round-trip) cryptographic token key initialization. "Cryptographic Token Key Initialization Protocol (CT-KIP) Web Service Version 1.0 Revision 0", Andrea Doherty, Magnus Nystroem, 26-Feb-07, This document defines a SOAP-based Web Service interface intended for use by implementor's of the Cryptographic Token Key Initialization Protocol (CT-KIP) to support four-pass (i.e., two round-trip) cryptographic token key initialization. Reader familiarity with CT- KIP is required. "Authorizing Binding Mechanism to Reduce Binding Latency during Mobile IPv6 Handover Procedure", Pyung-Soo Kim, 26-Feb-07, In Mobile IPv6 based IEEE 802.16e wireless networks, to reduce authorizing binding latency, the return routability procedure and the binding update & acknowledgement procedure are defined newly with parameters specified by information on candidate networks where the mobile node can be attached newly, and cryptographic functions of authentication and encryption are also defined newly. The care-of address configuration and the authorizing binding are performed before actual handover for candidate networks where the mobile node can be attached newly. Therefore, the proposed mechanism can make fast authorizing binding, which can reduce binding latency between two nodes and thus enhance throughput degradation caused by the bidirectional tunneling. "A solution for vertical handover of multimedia sessions using SIP", Stefano Salsano, 26-Feb-07, This document proposes a solution for handling vertical handovers among different network technologies using SIP, fulfilling a set of requirements discussed in the document "Requirements for vertical handover of multimedia sessions using SIP" (draft-niccolini-sipping-siphandover-01). The solution requires a new header field (named "Handover") and a new parameter in the Via header field (named "MMID"). "Explicit PCN Marking", Jozef Babiarz, 26-Feb-07, In this document, we propose to the PCN WG for review, discussion and evaluation of a method for marking real-time packets to indicate that removal (preemption) of excess real-time traffic from the network is needed. First, we define the marking behavior in the interior node followed with a brief description of how this marking would work in the edge-to-edge and application-control deployment models with simulations results for different conditions and traffic mixes. Then, we discuss the simulation results for voice, both constant rate and variable rate with silence suppression, and variable rate MPEG-4 like video traffic with large and small number of flows at the congestion point. "Addressing Record-Route issues in Session Initiation Protocol (SIP)", Thomas Froment, Christophe Lebel, 26-Feb-07, A typical function of a Session Initiation Protocol (SIP) Proxy is to set a Record-Route header on initial requests in order to make subsequent requests pass through it. This header contains a SIP Uniform Resource Identifier (URI) indicating where and how the subsequent requests should be sent to reach the proxy. Like any SIP URI, it can contain sip or sips schemes, IPV4 or IPV6 addresses, and URI parameters that could influence the routing like different transport parameters (UDP, TCP, SCTP...), or a compression indication like "comp=sigcomp". When a proxy has to change some of those parameters between its incoming and outgoing interfaces (multi-homed proxies, transport switching, sip to sips or IPV4 to IPV6 scenarios...), the question arises on what should be put in Record- Route: it is just not possible to make one header having the characteristics of both sides at the same time. This document aims to clarify these scenarios and fix bugs already identified on this topic; it formally suggests the use of the double Record-Route technique as a replacement to the current RFC3261 text, which only describes Record-Route rewriting solution. "BGP/MPLS Traffic Blackhole Avoidance", Rajiv Asati, 26-Feb-07, In any BGP based MPLS network such as MPLS VPN [RFC4364], an ingress PE router would continue to attract traffic from the CE router by advertising the prefix reachability, even though the Label Switched Path (LSP) from the ingress PE router to the egress PE router may be broken. This causes the VPN traffic to be dropped inside the MPLS VPN network. This document proposes a framework to make BGP consider the MPLS path availability to the "NEXT_HOP" (i.e. egress PE router) during the BGP bestpath candidate selection process. This document also defines a local database for storing the MPLS path health information for one or more IP prefixes and its interaction with BGP. "Performance Evaluation of EF-ADMIT", Janet Gunn, 26-Feb-07, A new Differentiated Services Code Point (DSCP), EF-ADMIT, has been recommended for a class of real-time traffic conforming to the Expedited Forwarding (EF) Per Hop Behavior (PHB) and admitted using a strong Call Admission Control (CAC) procedure incorporating capacity assurance, as compared to a class of real-time traffic conforming to the EF PHB but not subject to strong CAC. This document presents modeling results demonstrating that EF-ADMIT traffic will experience low packet drop rates even when lack of strong CAC results in EF traffic experiencing high packet drop rates. The modeling shows the performance benefit is material at low to medium network access speeds (e.g., 256 Kb/s to 1.5 Mb/s), but relatively inconsequential at high access speeds (e.g., 45 Mb/s) and, by inference, backbone speeds (100Mb/s and higher) where more bandwidth headroom is assumed. Furthermore, mixing relatively long packets (e.g., 1500 byte video packets) with relatively short packets (e.g., 200 byte voice packets) in EF PHB causes significant degradation to short packet performance at low to medium access speeds. Finally, the results show that implementation can be effective utilizing either one queue with combined EF and EF-ADMIT flows, or two queues with one forEF-ADMIT flows and one for EF flows, with the choice of approach mostly a matter of policy. "Source-Specific Media Attributes in the Session Description Protocol (SDP)", Jonathan Lennox, 26-Feb-07, The Session Description Protocol provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session, but does not provide any mechanism to describe individual media sources within a media stream. This document defines a mechanism to describe RTP media sources, identified by their Synchronization Source Identifiers (SSRCs), in SDP, associate attributes with these sources, and express relationships among sources. It also defines a number of source-level attributes which can be used to describe properties of media sources. "Methodology for Benchmarking LDP Data Plane Convergence", Jay Karthik, 26-Feb-07, This document describes methodology which includes procedure and network setup, for benchmarking Label Distribution Protocol (LDP) [MPLS-LDP] Convergence. The proposed methodology is to be used for benchmarking LDP convergence independent of the underlying IGP used (OSPF or ISIS) and the LDP operating modes. The terms used in this document are defined in a companion draft [LDP-TERM]. "6xx-Class Responses Considered Harmful in the Session Initiation Protocol (SIP)", Dale Worley, 26-Feb-07, The specification of the Session Initiation Protocol (SIP) permits a user agent (UA) that receives a call to generate a response in the "6xx class" that not only rejects the call but also requires the termination of all attempts to route the call to alternative destinations. As the call may have reached the UA through multiple forwardings whose meanings cannot be known by the UA, the global termination of alternative routing can only rarely be correctly requested by the UA. Because such responses are almost never appropriate, ability of a UA to generate such responses is harmful, and all 6xx class responses should be replaced with 4xx class responses with similar meanings. However, there is no 4xx class response similar to "603 Decline", and so one needs to be created. "Quick-Start for DCCP", Gorry Fairhurst, Arjuna Sathiaseelan, 26-Feb-07, The Datagram Congestion Control Protocol (DCCP) is a transport protocol that allows the transmission of congestion-controlled, unreliable datagrams. It is intended for applications such as streaming media, Internet telephony, and on-line games. In DCCP, an application has a choice of congestion control mechanisms, each specified by a Congestion Control Identifier (CCID). This document specifies a framework for the use of the Experimental Quick-Start Mechanism by DCCP, and specific procedures for the use of Quick- Start with DCCP CCID-2 and CCID-3. "FCAST: Scalable Object Delivery on top of the ALC Protocol", Vincent Roca, 26-Feb-07, This document introduces the FCAST object (e.g. file) delivery application on top of the ALC reliable multicast protocols. FCAST is a highly scalable application that provides a reliable object delivery service. "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", Vladislav Marinov, Juergen Schoenwaelder, 26-Feb-07, This memo defines a Transport Model for the Simple Network Management Protocol which utilizes the Transport Layer Security (TLS) security protocol and the X.509 key management infrastructure. "Principles of Internet Host Configuration", Bernard Aboba, Dave Thaler, 26-Feb-07, This document describes basic principles of Internet host configuration. It covers issues relating to configuration of parameters that affect the Internet layer, as well as parameters affecting higher layer protocols. "Application Loss Pattern Metrics", Nagarjuna Venna, Kaynam Hedayat, 26-Feb-07, Using the one-way loss pattern metrics defined in RFC 3357, this document defines two new metrics Type-P-One-Way-Complete-Frame-Loss and Type-P-One-Way-Partial-Frame-Received to provide a better understanding of the affects of packet loss at the application level. The statistic Type-P-One-Way-Errored-Seconds is derived from the above metrics to compute the affect of packet loss at the application level. "RTCP XR - Report Block for IPTV Metrics", Nagarjuna Venna, Kaynam Hedayat, 26-Feb-07, This document defines a new report block for the Extended Report (XR) packet type of the RTP Control Protocol (RTCP) for use by IPTV applications. The report block supports monitoring of IPTV streams by providing a mechanism for IPTV clients to report on the performance of different aspects of the IPTV stream. "Response Codes Regarding URIs that Cannot Be Routed to a Destination in the Session Initiation Protocol (SIP)", Dale Worley, 26-Feb-07, The Session Initiation Protocol (SIP) provides a number of response codes which a SIP agent can use to indicate that it cannot find a suitable destination to which to send a request. Unfortunately, this set of response codes was not carefully designed, making it difficult in many cases for a proxy to select a response code that accurately reflects the proxy's knowledge about the request URI. This document describes these response codes and their current usage. "The requirement of P2PSIP Peer protocol", XingFeng Jiang, 26-Feb-07, In this draft, we present what P2PSIP should achieve - a distributed location service. Then we compare the differences between C/S SIP and P2P SIP and point out that some features which are not standardized in C/S SIP should be addressed in the P2P SIP case. After analyzing some problems, some requirements of Peer protocol are proposed. "GMPLS control of Ethernet", Don Fedyk, 26-Feb-07, Carrier Grade Ethernet transport solutions require the capability of flexible service provisioning and fast protection switching. Currently, Ethernet is being extended in IEEE to meet the scalability needs of transport networks. The IETF specified GMPLS to control transport networks. To enable integration of Ethernet based transport solutions the extension of GMPLS control plane for Ethernet is of value. This memo describes how a GMPLS control plane may be applied to the Provider Backbone Bridges Traffic Engineering (PBB-TE) amendment to 802.1Q and how GMPLS can be used to configure VLAN-aware Ethernet switches in order to establish Ethernet P2P and P2MP MAC switched paths and P2P/P2MP VID based trees. This document assumes any standard changes to IEEE data planes will be undertaken only in the IEEE. "Media Gateway Control Protocol Voiceband Data Package and General Purpose Media Descriptor Parameter Package", Joe Stone, 26-Feb-07, This document defines Media Gateway Control Protocol (MGCP) packages that enable a Call Agent to authorize and monitor the transition of a connection to and from voiceband data (VBD) with or without redundancy and FEC (forward error correction). Although the focus is on VBD, the General-Purpose Media Descriptor Parameter package can be used to authorize other modes of operation, not relevant to VBD, for a particular codec. In addition to the definition of these new packages, this document describes the use of the Media Format Parameter package and Fax package with VBD, redundancy and FEC. "SIP URI Service Discovery using DNS-SD", Jae Woo Lee, Henning Schulzrinne, 26-Feb-07, This document describes the Session Initiation Protocol Uniform Resource Identifier (SIP URI) advertisement for DNS-based Service Discovery (DNS-SD). Using this mechanism, a SIP user agent (UA) can communicate with another UA even when no SIP registrar is available, as in a wireless ad-hoc network for example. "IP Tunneling Optimization in a Mobile Environment", Wassim Haddad, 26-Feb-07, This memo introduces a simple tunneling optimization mechanism, which removes the need for inserting an additional header in the IP packet. The main goals are to minimize the packet size, provide a simpler protocol design and a better efficiency. "An Extension to Session Initiation Protocol (SIP) Events for Pausing and Resuming Notifications", Mohammad Vakil, 26-Feb-07, The Session Initiation Protocol (SIP) events framework enables a subscriber to receive asynchronous notification of various events from other SIP user agents. It defines mechanisms to create, refresh, terminate subscriptions. This framework also defines mechanism to fetch (poll) an event state of a resource without creating persistent subscriptions. There is no mechanism to temporarily pause the notifications, while still maintaining a subscription on the server. This lack of functionality sometime results in a lot of superfluous notification traffic, and put unnecessary load on the server. This draft defines an extension to SIP events that allows the subscriber to pause and un-pause notifications within an established (created) subscription dialog. "MANET Position and Mobility Signaling: Problem Statement", Jerome Haerri, 26-Feb-07, This document contains a problem statement and justification for position and mobility signaling in MANET protocols. "Diameter Applications Design Guidelines", Victor Fajardo, 26-Feb-07, The Diameter Base protocol provides rules on how to extend Diameter and to create new Diameter applications. This is a companion document to clarify these rules. This document does not intended to add, remove or change these rules, rather it helps protocol designers to extend Diameter. "RSA based AES-GCM Cipher Suites for TLS", Joseph Salowey, 26-Feb-07, This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS) authenticated encryption operation. GCM provides both confidentiality and data origin authentication, can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. This memo defines TLS ciphersuites that use AES-GCM with RSA. "VPLS Interoperability with Provider Backbone Bridges", Ali Sajassi, 26-Feb-07, The scalability of H-VPLS (either with MPLS or Ethernet access network) can be improved by incorporating Provider Backbone Bridge (PBB - - 802.1ah) functionality in PE devices. PBB is being worked on in IEEE as an amendment to 802.1Q to improve the scalability of MAC addresses and service instances in Provider Ethernet networks. This draft describes how IEEE 802.1ah functionality can be used in the H-VPLS access network to attain better scalability in terms of number of customer MAC addresses and number of service instances that can be supported. This draft also describes the scenarios and the mechanisms for incorporating PBB functionality within H-VPLS (with either MPLS or Ethernet access network) and interoperability between them. "Quality Measurement Requirements for Tunneling Protocols", Yoshimitsu Kikuchi, 27-Feb-07, This draft describes requirements to measure end-to-end qualities of tunnels passively and to monitor them via Simple Network Management Protocol (SNMP) [1]. This feature is necessary for Service Providers (SPs), especially, who provide transports to users using tunnels. In addition, the draft shows an example to measure Generic Routing Encapsulation (GRE) [2] [3] tunnels. "IP Mobility and Multi-homing Interactions and Architectural Considerations", Vidya Narayanan, 27-Feb-07, A number of protocols have been defined at the IETF to handle IP mobility and multi-homing - each of the defined protocols satisfies a different set of requirements - however, there is an overlap on some of the requirements and features among many of these protocols. In practice, a combination of the protocols are likely to be deployed in a system. There are various such combinations plausible, but some combinations are more realistic than others. This document analyzes the overall mobility and multi-homing architecture and highlights some key points to consider while deploying an architecture consisting of one or more of these protocols. The protocols considered in scope for this document include Mobile IPv4 (MIPv4), Mobile IPv6 (MIPv6), Hierarchical Mobile IPv6 (HMIPv6), Fast Mobile IPv6 (FMIPv6), Network-based Local Mobility Management (NetLMM), MOBIKE, Host Identity Protocol (HIP), and Shim6. "MANET Position and Mobility Signaling Format", Jerome Haerri, 27-Feb-07, This document describes a flexible TLV (type-length-value structure) for exchanging geolocalization and mobility information using the generalized MANET packet/message format. "Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE)", Seisho Yasukawa, Adrian Farrel, 27-Feb-07, The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs). This document examines the applicability of PCE to path computation P2MP TE LSPs in MPLS and GMPLS networks. It describes the motivation for using a PCE to compute these paths, and examines which of the PCE architectural models are appropriate. "Implementing Interactive Connectivity Establishment (ICE) in Lite Mode", Eric Rescorla, 27-Feb-07, Interactive Connectivity Establishment (ICE) is a technique for discovering a set of addresses which two peers can use to communicate, even in the face of topological obstacles such as NATs. Because the topologies in which ICE may be used are complex, a full ICE implementation is also fairly complex. Implementation which will only be deployed in settings where they have public addresses (e.g., SIP-PSTN gateways) can, however, be substantially simpler. This document describes a subset of ICE suitable for such implementations. "Proxy Shim6 (P-Shim6)", Marcelo Bagnulo, 5-Mar-07, This draft discusses extensions to the shim6 architecture to support shim6 proxies that would allow the provision of the following capabilities: o Provide Upper Layer Identifier portability. o Provide Traffic Engineering policy enforcement. o Off-load of the shim6 context management from the actual peers of the communication. "GMPLS RSVP-TE extension in support of bidirectional LSPs with", Attila Takacs, 27-Feb-07, GMPLS provides general connection control functionality supporting different network technologies. This memo specifies a further generalization to support bidirectional LSPs with asymmetric requirements. The extension improves the flexibility of bidirectional LSP establishment and at the same time simplifies the control and management of asymmetric services. "VLAN data model for NETCONF", Tomoyuki Iijima, 27-Feb-07, Data models are to be discussed within the NETCONF framework shortly. We devised data model of VLAN and moreover developed a network configuration application using the data model. This document introduces the data model which we developed so that it facilitates discussion of data model under which NETCONF protocol should run. "PMIPv6 Route Optimization Protocol", Alice Qin, 27-Feb-07, This document defines route optimization protocol for PMIPv6. Proxy home test, concurrent proxy care-of test and handover procedures are explained. Proxy mobile agent uses cryptographically generated home addresses so that no more home test is needed after the initial home test. Handover home keygen token is used during handover in order to eliminate home test for the next proxy mobile agent. A different route optimization protocol is defined for inter-proxy mobile agent operation if the correspondent node is not Mobile IPv6 enabled. "Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages", Vladislav Marinov, Juergen Schoenwaelder, 27-Feb-07, This memo defines a mapping from Simple Network Management Protocol (SNMP) notifications to SYSLOG notifications. "The Use of Galois/Counter Mode (GCM) Modes of Operation for Camellia and Its Use With IPsec", Masafumi Kanda, Akihiro Kato, 27-Feb-07, This document describes the use of the Camellia block ciper algorithm in Galois/Counter Mode (GCM) as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality and data origin authentication. "IPsec Gateway Failover and Redundancy Protocol", Lakshminath Dondeti, Vidya Narayanan, 27-Feb-07, IPsec gateways and servers maintaining SAs with large number of clients can quickly recover from failover using the protocols and procedures specified in this document. These techniques also facilitate IPsec clients to move from one gateway to another and resume operation without having to rerun IKEv2. The idea is to maintain IKEv2 and IPsec SA state at either the client or one or more backup servers to reduce the communication and computation overhead associated with reestablishing the SAs from scratch. Client to server SA state storage retrieval mechanisms and client-initiated or server-initiated failover recovery protocols are specified. This document, however, does not define an inter-gateway transport mechanism to transfer the state across entities at the backend. "NAT Traversal for dSIP", Eric Cooper, 27-Feb-07, This document shows how the algorithm for resource registration and lookup in a SIP-based peer-to-peer system can be implemented in the presence of NATs. More precisely, this document show how this algorithm can be generalized into a method of routing arbitrary SIP requests through overlays, and how this approach can be used to set up new connections between peers to use for additional SIP signaling. The document uses SIP to signal new dSIP connections, and uses Interactive Connectivity Establishment (ICE) to allow these connections to be established through NATs. "A Chord-based DHT for Resource Lookup in P2PSIP", Marcia Zangrilli, David Bryan, 27-Feb-07, This document describes how a structured peer-to-peer algorithm is used for resource lookup by a P2PSIP Peer Protocol. Specifically, this work describes how to integrate a DHT based on Chord with dSIP, a proposed P2PSIP Peer Protocol. This document extends the dSIP draft to provide one possible implementation of a pluggable DHT algorithm. "A Bamboo-based DHT for Resource Lookup in P2PSIP", Marcia Zangrilli, David Bryan, 27-Feb-07, This document describes how a structured peer-to-peer algorithm is used for resource lookup by a P2PSIP Peer Protocol. Specifically, this work describes how to integrate a DHT based on Bamboo with dSIP, a proposed P2PSIP Peer Protocol. This document extends the dSIP draft to provide one possible implementation of a pluggable DHT algorithm. This is early work to demonstrate how alternative DHT algorithms can be plugged into the dSIP protocol. Where appropriate, we compare the Bamboo DHT implementation to the Chord DHT implementation. "dSIP: A P2P Approach to SIP Registration and Resource Location", David Bryan, 27-Feb-07, This document outlines the motivation, requirements, and architectural design for a distributed Session Initiation Protocol (dSIP). dSIP is a Peer-to-Peer (P2P) based approach for SIP registration and resource discovery using distributed hash tables maintained with SIP messages. This design removes the need for central servers from SIP, while offering full backward compatibility with SIP, allowing reuse of existing clients, and allowing P2P enabled peers to communicate with conventional SIP entities. A basic introduction to the concepts of P2P is presented, backward compatibility issues addressed, and security considerations are discussed. dSIP is one possible implementation of the protocols being discussed for creation in the P2PSIP WG. In the context of the work being proposed, this draft represents a concrete proposal for the P2PSIP Peer Protocol, using SIP with extensions as the underlying protocol. In this architecture, no P2PSIP Client Protocol is needed, rather unmodified SIP is used for access by non-peers. "Authenticated Identity Extensions to dSIP", Bruse Lowekamp, James Deverick, 27-Feb-07, This document describes mechanisms to authenticate peer and resource identities within a distributed SIP overlay. It makes use of existing identity frameworks, modifying them as necessary to accommodate the specific needs of a peer-to-peer environment. "SASL Yet Another Password Mechanism", Kurt Zeilenga, 27-Feb-07, This document describes a password authentication mechanism, called YAP-SHA-256, for use in protocols support Simple Authentication and Security Layer (SASL) framework. The mechanism relies on security services provided by a lower layer, such as Transport Layer Security (TLS), to protect the authentication exchange, and subsequent application data exchange, from common attacks. The YAP-SHA-256 mechanism may be viewed as an alternative to other password-based SASL mechanism, such as PLAIN, CRAM-MD5, and DIGEST-MD5. "Authentication Extensions for the Dynamic Host Configuration Protocol", Richard Pruss, 27-Feb-07, This document defines Dynamic Host Configuration Protocol (DHCP) extensions that provide for a Challenge Handshake Authentication Protocol (CHAP) exchange in DHCP prior to configuration of the host. The primary applicability is within a Digital Subscriber Line (DSL) Broadband network environment in order to enable a smooth migration from the Point to Point Protocol (PPP). "Additional Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol", Kuntal Chowdhury, Tim Mortsolf, 27-Feb-07, The Internet Key Exchange (IKEv2) protocol defines a way to establish IPsec security association between two end points. Normally the protocol requires a single authentication step to complete the exchange and establish IPsec security association between the end points. However, there are situations were more than one authentication exchange is required potentially with different authenticating domains. It is also possible that multiple authentication steps are performed to authenticate the endpoints for different services with different traffic selectors. This document proposes an extension to IKEv2 protocol to achieve this goal with a single IKE SA. "Interaction of RBridges and 802 Protocols", Donald Eastlake 3rd, 27-Feb-07, This is a working document discussing the relationship of RBridges, that is, devices implementing the protocol being developed by the IETF TRILL working group, and various IEEE 802.1 amd 802.3 protocols. "NSIS Multihoming Support Issues", Hong Cheng, 27-Feb-07, The NSIS operation will be greatly affected by the multihoming development in IETF such as Monami6, Shim6, etc. Solutions from these groups introduce different architecture elements and assumptions to the network layer, and thus render the current NSIS protocols ineffective or irrelevant. This draft provides an analysis of the multhoming scenarios that have impacts on the NSIS operation. Requirements for NSIS multihoming support are derived from the discussions of the NSIS applicability in these scenarios. "Confidential Access Levels for the Session Initiation Protocol (SIP)", Jeff Hewett, 27-Feb-07, This specification defines a header for indicating the confidentiality level established between the involved parties. "Security Mechanisms for Peer to Peer SIP", Cullen Jennings, 27-Feb-07, This document describes an overview of some security mechanisms for P2P SIP. Specifically it discusses mechanisms that can be used to secure the stored data and the routing in the distributed storage. This draft is an very early draft to outline the possible solution space and far more details would be needed. This work is being discussed on the p2psip@ietf.org mailing list. "IRI recognition in Applications", Yoshiro Yoneya, 27-Feb-07, Nowadays access to the Internet is a part of daily life. Users see URIs written in various ways on various media, recognize them as "the Internet Addresses", and use them to access to the Internet. Many application programs recognize URIs automatically and make links to them, so the users can access to the URIs very easily. But, at this moment, most of application programs can't recognize Internationalized Domain Name (IDN) and Internationalized URI (IRI) correctly, so users will feel stress when using IDNs and IRIs. Utilization of the IDNs and the IRIs are getting higher. Therefore, improvement of the application programs are highly recommended. This document is intended to be an application developpers' guideline for recognizing and corresponding to IDNs/IRIs correctly. "New Session Initiation Protocol Resource-Priority Header Namespaces for the Defense Information Services Agency", James Polk, 27-Feb-07, This document creates additional Session Initiation Protocol Resource-Priority header namespaces, to be IANA registered. This document intends to update RFC 4412, as a Proposed Standard document if published by the RFC-Editor. "IP Mobility Protocols - Threat Analysis", Vidya Narayanan, Lakshminath Dondeti, 27-Feb-07, IP mobility protocols allow nodes to maintain a somewhat permanent IP address as they change points of attachment to the Internet. There are various levels and types of mobility management available for local and global mobility, and several protocols have been developed to support them. Even though each of the IP mobility management protocols may have its own set of scope and functions, analysis has shown that a generalized threat model is applicable. This document describes a threat model for IP mobility. "Security Requirements for IP Mobility Protocols", Vidya Narayanan, Lakshminath Dondeti, 27-Feb-07, This document describes security requirements to take into account in designing IP mobility protocols and deploying IP mobility services. We consider threat models applicable to different service models and deployment scenarios and provide guidance on prioritizing the security requirements. "Media Description for IKE in the Session Description Protocol (SDP)", Makoto Saito, Dan Wing, 27-Feb-07, This document extends the protocol identifier of SDP so that it could negotiate the use of IKE for media session in SDP offer/answer model. And it also specifies the method to generate VPN based on tunnel mode IPsec using self-signed certificate under the mechanism of comedia- tls. This document extends RFC 4572. In addition, it defines a new attribute "udp-setup", which is similar to "setup" attribute defined in RFC 4145, to enable endpoints to negotiate their roles in the IKE session. "Requirements and Implementation Options for the Multiple Line Appearance Feature using the Session Initiation Protocol (SIP)", Alan Johnston, 27-Feb-07, This document describes the requirements for implementation of a group telephony feature commonly known as Bridged Line Appearance (BLA) or Multiple Line Appearance, or Shared Call/Line Appearance (SCA). When implemented using the Session Initiation Protocol (SIP), it is referred to as Multiple Appearances. This feature is commonly offered in the IP Centrex services and IP-PBX offerings and is likely to be implemented on SIP IP telephones and SIP feature servers used in a business environment. This document lists requirements and compares implementation options for this feature. "TCP Reaction to ICMPv6 Error Messages", Tomohiro Fujisaki, Arifumi Matsumoto, 27-Feb-07, RFC1122 defines nodes TCP stack behavior for ICMPv4 error messages, but does not for ICMPv6. This document defines ICMPv6 message classification and node's TCP stack behavior for ICMPv6. "A NETCONF Datamodel for Diff-Serv QoS Control Configuration", Hideki Okita, 27-Feb-07, This memo proposes a NETCONF datamodel for Differentiated Service (Diff-Serv) QoS control and an XML Schema to define the model. This model contains functional elements on a Diff-Serv router and Traffic Data Path. In this model, each Traffic Data Path is represented as the combination of the functional elements. Network operators can configure Diff-Serv routers distributed in their provider network by this datamodel and NETCONF protocol. "UDP Usage Guidelines for Application Designers", Lars Eggert, 27-Feb-07, The User Datagram Protocol (UDP) provides a minimal, message-passing transport that has no inherent congestion control mechanisms. Because congestion control is critical to the stable operation of the Internet, applications and upper-layer protocols that choose to use UDP as a transport must employ mechanisms to prevent congestion collapse and establish some degree of fairness with concurrent traffic. This document provides guidelines on the use of UDP for the designers of such applications and upper-layer protocols. "Design Goals and Requirements for 6LoWPAN Mesh Routing", Dominik Kaspar, 27-Feb-07, This document defines the problem statement, design goals, and requirements for mesh routing in low-power wireless personal area networks (LoWPANs). "GMPLS Inter-Domain Routing in support of inter-domain links", Tomohiro Otani, 27-Feb-07, This draft states the problem of the current generalized multi- protocol label switching (GMPLS) routing in order to deal with inter- domain TE links for GMPLS inter-domain signaling. Since the GMPLS signaling protocol introduces bi-directional label switched path (LSP) creation mechanism, an ingress node (or a path computation element) searches for the bidirectional route in the traffic engineering database (TED). Considering the GMPLS inter-domain path creation, the TED contains only outgoing TE information of inter- domain links and will not be able to confirm the validity of the route. In order to solve this issue, we describe the GMPLS inter- domain routing requirement and mechanism in support of exchanging of inter-domain TE link information. "Avoiding Interactions of Quick-Start TCP and Flow Control", Michael Scharf, 27-Feb-07, This document describes methods to avoid interactions between the flow control of the Transmission Control Protocol (TCP) and the Quick-Start TCP extension. Quick-Start is an optional TCP congestion control mechanism that allows hosts to determine an allowed sending rate from feedback of routers along the path. With Quick-Start, data transfers can start with a potentially large congestion window. In order to fully utilize the data rate determined by Quick-Start, the sending host must not be limited by the TCP flow control, i. e., the amount of free buffer space advertised by the receive window. There are two potential interactions between Quick-Start and the TCP flow control: First, receivers might not provide sufficiently large buffer space after connection setup, or they may implement buffer allocation strategies that implicitly assume the slow-start behavior on the sender side. This document therefore provides guidelines for buffer allocation in hosts supporting the Quick-Start extension. Second, the TCP receive window scaling mechanism interferes with Quick-Start when being used in the initial three-way handshake connection setup. This document describes a simple solution to overcome this problem. "A Proposal for Scalable Internet Routing & Addressing", Dan Massey, 27-Feb-07, Our measurement studies of the global Internet routing system show that prefix de-aggregation has led to the DFZ routing table size growing at a rate which is much faster than the Internet itself. The main causes of prefix de-aggregation include user site multihoming and traffic engineering. We propose to move Internet service providers to a separate address space as an effective solution to the routing scalability problem. We discuss different means to provide the mapping service between user and provider address spaces and the pros and cons of each approach, as well as why we believe such an architectural change is necessary to solve the routing scalability problem. "Consideration of NETCONF Architecture", Rei Atarashi, 27-Feb-07, The NETwork CONFiguration (NETCONF) protocol has been designed to configure routers, switches, firewalls and other network devices. This document describes a high level description of the Netconf architecture and how the Netconf framework relates to other network management protocols and architectures. "Preferential Forwarding Status bit definition", Praveen Muley, 27-Feb-07, This document describes a mechanism for standby status signaling of redundant PWs between its termination points. A set of redundant PWs is configured between PE nodes in SS-PW applications, or between T-PE nodes in MS-PW applications. In order for the PE/T-PE nodes to indicate the preferred PW path to forward to one another, a new status bit is needed to indicate the preferential forwarding status of active or standby for each PW in the redundancy set. This draft specifies a new PW status bit for this purpose. "The Camellia-CMAC-96 and Camellia-CMAC-PRF-128 Algorithms and Its Use with IPsec", Akihiro Kato, 27-Feb-07, This memo specifies two new alogorithms. One is the usage of Cipher- based Message Authentication Code (CMAC) with Camellia block cipher on the authentication mechanism of the IPsec Encapsulating Security Payload and Authentication Header protocols. This algoritm is called Camellia-CMAC-96. Latter is a pseudo-random function based on CMAC with Camellia block cipher for Internet Key Exchange. This algoritm is called Camellia-CMAC-PRF-128. "Converting SNMP MIBs to SOA/Web Services Management Artifacts", Bob Natale, 27-Feb-07, This memo provides an overview of the rationale, objectives, and technical alternatives associated with a proposal to develop a standard methodology for converting SNMP MIBs to one or more artifacts more readily usable by SOA/Web Services management tools. "Goals and Requirements for IPv4 Support in PMIPv6", Sangjin Jeong, 27-Feb-07, The IETF NetLMM WG is developing standards of network-based mobility management in a localized domain. PMIPv6 architecture enables mobile nodes to roam without host-side mobility management protocol stack. Current PMIPv6 protocols mainly consider IPv6 and dual stack mobile nodes. It also states deployment scenario of PMIPv6 in IPv6 infrastructure. However, localized mobility management in IPv4 network is also problematic. Also, there still exist a lot of IPv4 MNs and these IPv4 MNs may visit PMIPv6 domain. This document discusses a few scenarios of IPv4 support in PMIPv6 domain and describes goals and requirements for IPv4 support in PMIPv6. "OSPFv2 Authentication with HMAC-SHS", Randall Atkinson, 2-Mar-07, This document describes how the NIST Secure Hash Standard family of algorithms can be used with OSPF version 2's built-in cryptographic authentication mechanism. This updates, but does not supercede, the cryptographic authentication mechanism specified in RFC-2328. "Tunnel Endpoint Discovery Problem Statement", Shu Yamamoto, 27-Feb-07, Tunnel Endpoint Discovery is an enhancement to the Softwire feature. Defining a dynamic tunnel endpoint map allows you to be able to dynamically determine a Tunnel Broker peer; however, only the receiving client has this ability. This document frets out the problem scope as well as the motivation for specifying such a feature within the Softwire protocol. "Carrying a Contract Identifier in the PCE communication Protocol (PCEP)", Jean-Louis Le Roux, 7-Mar-07, The Path Computation Element (PCE) based architecture can be used for computing Traffic Engineered Label Switched Paths (TE LSP) that traverse multiple Autonomous Systems (AS) in MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. This may require communication between PCEs in each AS, based upon on the PCE communication Protocol (PCEP). When ASes belong to distinct service providers, a per-service negotiation and activation procedure may be required before starting PCE based path computation. For the sake of illustration, the IPSphere Forum (IPSF) is currently specifying an architecture so as to automate the negotiation and activation of such an inter-provider TE LSP service. The result of such negotiation is a per-service contract identifier that needs to be carried in PCEP, so that PCEs can apply inter-provider path computation policies. For that purpose, this draft defines an extension to the PCEP protocol so as to carry a contract ID in request messages. "SDP Attributes for OMA BCAST Service and Content Protection", Lakshminath Dondeti, Anja Jerichow, 27-Feb-07, This document provides descriptions of SDP attributes used by the Open Mobile Alliance's Broadcast Service and Content Protection specification. "OSPFv3 Automated Group Keying Requirements", Ya Liu, 27-Feb-07, RFC4552 describes how to provide authentication/confidentiality to OSPFv3 using IPsec. It specifies that same IPsec SA parameters be configured for both inbound and outbound SAs to provide the "one to many" security for multicast OSPFv3 communications over broadcast links (e.g., Ethernet). Manual keying is specified as the mandatory and default group key management solution. However, issues of scalability and security exist with manual keying. It is better to replace manual keying with automated group key management. This document discusses the requirements on OSPFv3 automated group key management, assuming that the centralized group key management architecture introduced in [RFC4046] is used. "Encoding of Objective Functions in Path Computation Element (PCE) communication and discovery protocols", Jean-Louis Le Roux, 27-Feb-07, The computation of one or a series of Traffic Engineering Label Switched Paths (TE LSP) in MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks, is subject to a set of one or more specific optimization criteria(s), referred to as an objective function (e.g. minimum cost path, widest path, etc.). A Path Computation Element (PCE) may support one or multiple objective functions, and it is desired for a Path Computation Client (PCC) to automatically discover the set of objective functions supported by a PCE. Furthermore, it may be useful for a PCC to specify in a path computation request the required objective function used by the PCE to compute a TE LSP or a set of TE LSPs. Thus the aim of this document is to define extensions to the PCE Discovery (PCED) TLV carried within the IS-IS Router Capability TLV and the OSPF Router Information LSA so as to allow a PCC to discover the set of objective functions supported by a PCE. Extensions to the PCE communication Protocol (PCEP) are also specified allowing a PCC to indicate in a path computation request the required objective function and a PCE to indicate in a path computation reply the objective function actually applied. The definition of objective functions is beyond the scope of this document and will be covered in separate documents. "PCE communication protocol(PCEP) Management Information Base", Emile Stephan, Kiran Koushik, 27-Feb-07, This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Path Computation Element communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. "A XMLTemplate for editing and sharing MIB module items", Emile Stephan, 27-Feb-07, This memo presents a basic solution for editing SMI objects in XML. Based on this approach it specifies a XML template for specifing SMI objects and proposes a common framework for translating SMI objects definitions to other datamodel. Finally it introduces some connections with XML oriented Internet management "The Peer Protocol for P2PSIP Networks", Jani Hautakorpi, Gonzalo Camarillo, 28-Feb-07, This document describes the P2PSIP Peer Protocol that is used between the peers in P2PSIP networks. The described Peer Protocol is not an entirely new protocol, it is a combination of the new SIP method, LOCSER, and the well-defined, XML-based body. Note: At the current moment, the purpose of this document is just to present a relatively high level abstraction from the Peer Protocol, rather than give a very detailed description. "Message Session Relay Protocol Adaptation for Interactive Connectivity Establishment (ICE)", Aki Niemi, 28-Feb-07, This memo defines an alternate rendezvous mechanism for the Message Session Relay Protocol (MSRP) using Interactive Connectivity Establishment (ICE). "A context mechanism for controlling caching of HTTP responses", Yngve Pettersen, 28-Feb-07, A common problem for sensitive web services is informing the client, in a reliable fashion, when a password protected resource is no longer valid because the user is logged out of the service. This is, in particular, considered a potential security problem by some sensitive services, such as online banking, when the user navigates the client's history list, which is supposed to display the resource as it was when it was loaded, not as it is at some later point in time. This document presents a method for collecting such sensitive resources into a group, a Cache Context, which permits the server to invalidate all the resources belonging in the group either by direct action, or according to some expiration policy. The context can be configured to invalidate not just the resources, but also specific cookies, HTTP authentication credentials and HTTP over TLS session information. "Analysis of MANET and NEMO", Teco Boot, 28-Feb-07, This document provides an overview of MANET and NEMO characteristics. It is claimed that MANET suits small mobile network topologies, providing optimal paths for communication within a MANET cloud. It is also claimed that NEMO suits small, mobile networks, providing sub-optimal paths to all Internet connected nodes. MANET and NEMO technology shortcoming are described, to be addressed in the MANET and NEMO workgroups or elsewhere within the IETF. "The Hash Exchange Authentication SASL Mechanism", Dave Cridland, Alexey Melnikov, 28-Feb-07, This memo defines and discusses a SASL mechanism that is based on the exchange of hashes. It does not require the storage of a plaintext equivalent on the server, is simple to implement, and provides a reasonable level of security. "Security requirements in P2PSIP", Marcin Matuszewski, 28-Feb-07, This document is an analysis of security threats in the Peer-to-Peer SIP reference model proposed in the P2PSIP concepts and terminology for P2PSIP document. Typical security ontology is used as classification for the threats. The main security goals for the architecture and its components are presented. "Things To Be Considered for RFC 3484 Revision", Arifumi Matsumoto, Tomohiro Fujisaki, 28-Feb-07, RFC 3484 has several known descriptions to be modified mainly because of the deprecation of IPv6 site-local unicast address and the coming of ULA. This document covers these essential points to be modified and also possible useful changes to be included in the revision of RFC 3484. "Network In Node Advertisement", Pascal Thubert, 28-Feb-07, The Internet is evolving to become a more ubiquitous network, driven by the low prices of wireless routers and access points and by the users' requirements of connectivity anytime and anywhere. For that reason, a cloud of nodes connected by wireless technology is being created at the edge of the Internet. This cloud is called a MANEMO Fringe Stub (MFS). It is expected that networking in the MFS will be highly unmanaged and ad-hoc, but at the same time will need to offer excellent service availability. The NEMO Basic Support protocol could be used to provide global reachability for a mobile access network within the MFS and the Tree-Discovery mechanism could be used to avoid the formation of loops in this highly unmanaged structure. Since Internet connectivity in mobile scenarios can be costly, limited or unavailable, there is a need to enable local routing between the Mobile Routers within a portion of the MFS. This form of local routing is useful for Route Optimization (RO) between Mobile Routers that are communicating directly in a portion of the MFS. NINA is the second of a 2-passes routing protocol; a first pass, Tree Discovery, builds a loop-less structure -a tree-, and the second pass, NINA, exposes the Mobile Network Prefixes (MNPs) up the tree. The protocol operates as a multi-hop extension of Neighbor Discovery (ND), to populate TD-based trees with prefixes, and establish routes towards the MNPs down the tree, from the root-MR towards the MR that owns the prefix, whereas the default route is oriented towards the root-MR. The NINA protocol introduces a new option in the ND Neighbor Advertisement (NA), the Network In Node Option (NINO). An NA with NINO(s) is called a NINA (Network In Node Advertisement). NINA is designed for a hierarchical model where an embedded network is abstracted as a Host for the upper level of network abstraction. With NINA, a Mobile Router presents its sub-tree to its parent as an embedded network and hides the inner topology and movements. "DTLS as a Transport Layer for RADIUS", Alan DeKok, 28-Feb-07, The RADIUS protocol [RFC2865] has limited support for protocol level authentication and encryption. RADIUS packets contain attributes sent "in the clear", although some attributes can have "hidden" content. Packets may be replayed verbatim by an attacker, and the client-server authentication could be better. This document proposes DTLS as the solution to these problems, and details how this proposal is backwards-compatible wih existing RADIUS solutions. "ssmping Protocol", Stig Venaas, 28-Feb-07, ssmping is a tool that is used to check whether one can receive SSM, as well as obtaining some additional information. ssmping requires both a client and a server supporting the ssmping protocol to work. We here specify this protocol. "Fast Handover with Stream Control Transmission Protocol (SCTP) on Single-home nodes", Michio Honda, 28-Feb-07, Providing transport layer mobility is one of the features of SCTP [RFC2960]. By using Dynamic Address Reconfiguration extension, SCTP can accomplish handover between different subnets. However, due to some issues in the current SCTP, serious performance degradation will happen during the handover process. The problem arises especially when a mobile node has only one network interface. This document describes the issues of current SCTP handover mechanism and proposes three functions to achieve smooth and fast handover. "Initializing a DNS Resolver with Priming Queries", Peter Koch, 28-Feb-07, This document describes the initial queries a DNS resolver is supposed to emit to initialize its cache with a current NS RRSet for the root zone as well as the necessary address information. "Anti-SPIT : A Document Format for Expressing Anti-SPIT Authorization Policies", Hannes Tschofenig, 28-Feb-07, SPAM, defined as sending unsolicited messages to someone in bulk, might be a problem on SIP open-wide deployed networks. The responsibility for filtering or blocking calls can belong to different elements in the call flow and may depend on various factors. This document defines an authorization based policy language that allows end users to upload anti-SPIT policies to intermediaries, such as SIP proxies. These policies mitigate unwanted SIP communications. It extends the Common Policy authorization framework with additional conditions and actions. The new conditions match a particular Session Initiation Protocol (SIP) communication pattern based on a number of attributes. The range of attributes includes information provided, for example, by SIP itself, by the SIP identity mechanism, by information carried within SAML assertions. "Quality of Service Parameters for RADIUS and Diameter", Jouni Korhonen, Hannes Tschofenig, 28-Feb-07, This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within RADIUS and Diameter. The payloads used to carry these QoS parameters are opaque for the AAA client and the AAA server itself and interpreted by the respective Resource Management Function. "Quality of Service Attributes for Diameter", Jouni Korhonen, 28-Feb-07, This document extends the functionality of the Diameter Base protocol and Diameter NASREQ with respect to their ability to convey Quality of Service information as part of the QoSFilterRule Attribute Value Pair (AVP). "The Problem Statements for NEMO in NetLMM domains", Dominik Kaspar, Joo-Chul Lee, 28-Feb-07, The NetLMM protocol provides local mobility to the mobile node without requiring any modification of mobile node. The NetLMM domain provides this service by maintaining forwarding state for the mobile node's prefix. In case that the mobile node is a mobile router in the home network the NetLMM domain may not have the forwarding state for the mobile network prefix, so it can't forward packets from nodes within the mobile network, that is to say, existing NetLMM protocols do not consider mobile routers enough. "Identifier / Locator Separation: Exploration of the Design Space (ILSE)", Pekka Nikander, 28-Feb-07, Implementing the so called identifier / locator separation may have far-reaching consequences to the Internet architecture, depending very much on how exactly it is implemented. That is, here as in many other cases, the devil lies very much in the details. In this document, we attempt to outline the various aspects of the design space. We briefly discuss six main aspects: identifiers, dynamic traffic management, end-to-end issues, security, economics, and deployment. In this initial version of the document, we still lack many details. This document is a reaction to the problem statement effort at the Amsterdam IAB Routing and Addressing Workshop (RAWS). "Proxying Approach to SHIM6 and HIP (PASH)", Pekka Nikander, Kristian Slavov, 28-Feb-07, This document describes an incremental, network-based method for deploying SHIM6 or HIP based identifier / locator separation, called Proxying Approach to SHIM6 and HIP (PASH). This mechanism requires no changes to host stacks and, when deployed with routable Endpoint IDentifiers (EID), no changes to existing database infrastructures. The proposed protocol can be implemented in a relatively small number of routers, and deployed independently by ISPs. At the same time, it allows the network to gradually evolve towards full, host-based SHIM6 and/or HIP support, thereby making possible the larger architectural benefits that the network-based "jack-up" approaches provide. This proposal has been on the mental roadmaps within the HIP community for a number of years, but is properly documented only now as a result of the problem statement effort at the Amsterdam IAB Routing and Addressing Workshop (RAWS). "Use Cases and signaling requirements for Point-to-Multipoint PW", Frederic JOUNAY, 28-Feb-07, This document provides some use cases advocating for the definition of a unidirectional Point-to-Multipoint Pseudowire (P2MP PW). Based on these use cases it also presents a set of requirements for the set up and maintenance of P2MP PW, proposed as guidelines for possible solutions. "LDP Extensions for Leaf-initiated Point-to-Multipoint Pseudowire", Frederic JOUNAY, 28-Feb-07, This document provides a solution to extend LDP signaling in order to allow set up and maintenance of Point-to-Multipoint Pseudowire (P2MP PW). Such an extension of existing point to point Pseudowire is made necessary by new applications. The document deals with the leaf- initiated P2MP PW setup and maintenance. The processing for setting up a P2MP MS-PW is built on the processing for setting up a P2MP LSP with LDP. "A ROHC Profile for RTCP (ROHC-RTCP)", Carsten Bormann, 28-Feb-07, This document specifies a ROHC (Robust Header Compression) profile for compression of RTCP packets. The profile, called ROHC-RTCP, provides efficient and robust compression of RTCP packets, including frequently used RTCP features. ROHC-RTCP is intended to be used in conjunction with ROHC profiles for the compression of RTP headers such as RFC 3905 and ROHCv2, making use of context replication (RFC 4164) where appropriate. In particular, ROHC-RTCP is intended to remove the need for standardization of special-purpose variants of RTCP for applications just because these also need to work over low-speed links. "Infrastructure aspects to media security", Vesa Lehtovirta, 28-Feb-07, This document discusses some infrastructure aspects that should be considered in the media security requirements work. "LDP Extensions for Source-initiated Point-to-Multipoint Pseudowire", Frederic JOUNAY, 28-Feb-07, This document provides a solution to extend Label Distribution Protocol (LDP) signaling in order to allow set up and maintenance of Point-to-Multipoint Pseudowire (P2MP PW). Such an extension of existing point to point Pseudowire is made necessary by new applications. The document deals with the source-initiated P2MP PW setup and maintenance. "Considerations about Multicast BGP/MPLS Standardization", Thomas Morin, 28-Feb-07, The current proposal for multicast in BGP/MPLS includes multiple alternative mechanisms for some of the required building blocks of the solution. The aim of this document is to leverage requirements to identify the key elements and help move forward solution design, toward the definition of a standard having a well defined set of mandatory procedures. The different proposed alternative mechanisms are examined in the light of requirements identified for multicast in L3VPNs, and suggestions are made about which of these mechanisms standardization should favor. Issues related to existing deployments of early implementations are also addressed. "Network-Based Localised Mobility Management Protocol (NBLM)", Henrik Levkowetz, Phil Roberts, 28-Feb-07, This document specifies an Internet protocol that allows mobile nodes to move around in a local mobility domain, changing their point of attachment within the domain, but without ever being aware at the IP layer that their point of attachment has changed, and maintaining seamless communication in the presence of such changes. It defines two protocol entities, a Mobile Access Gateway and a Local Mobility Anchor, and a set of messages between them, that together make these mobility events transparent to the mobile nodes at the IP layer, as long as they remain within the local mobility domain. "Problem Statement and Requirements on a 3-Party Key Distribution Protocol for Handover Keying", Yoshihiro Ohba, 6-Mar-07, The HOKEY WG is developing solutions for optimizations as well as security key hierarchy specifications for handovers. The key derivation specifications all draw from a trust relationship that is created as a result of a "2-party" EAP authentication between a peer and a backend server, while distributing the resulting keys to third parties other than the peer and the backend server. This document describes problem statement and requirements on a three-party key distribution protocol for handover keyings. "IP Mobility and Policy Control", Jouni Korhonen, 28-Feb-07, The IETF has developed many IP Mobility protocols, some of which have been successfully deployed. There has also been work done on enabling fast and efficient handovers at L3 and extensions to access control protocols to enable fast handovers. One aspect that has not been considered so far is the policies that a user is subjected to when accessing a subscribed network. These policies, defined by the network operator, have a significant impact on the user's mobility experience. This document aims to provide a discussion document on policy control and IP Mobility in controlled operator networks. "A method for network initiated partial session transfers", Aartse Tuijn, Dennis Bijwaard, 28-Feb-07, This document describes a SIP-based method for network initiated partial session transfers that works together with terminal initiated partial session transfers. It uses the Mobile Node Control Mode for terminal initiated partial session transfers and it extends this method to support network initiated partial session transfers. "SAVA Testbed and Experiences to Date", Jianping Wu, 28-Feb-07, This draft describes the testbed installed at Tsinghua University and other Universities in China attached to the CERNET-II IPv6 backbone, some SAVA testing that has been carried out on that network and some preliminary results of that testing. "Diff-Serv Aware Class Type Object for Path Computation Element Communication Protocol", Siva Sivabalan, 28-Feb-07, This document specifies a CLASSTYPE object to support Diff-Serve Aware Traffic Engineering (DS-TE) where path computation is performed with an aid of Path Computation Element (PCE). "Mtrace6: Traceroute Facility for IPv6 Multicast", Hitoshi Asaeda, Tatsuya Jinmei, 28-Feb-07, Multicast traceroute requires a special packet type and implementation on the part of routers. This document describes the IPv6 multicast traceroute facility. The main aim of this document is to clarify the difference between IPv4 multicast traceroute [5] and IPv6 multicast traceroute. "Motivation for Benchmarking BFD Protocol Implementations", Esa Salahuddin, Jay Karthik, 28-Feb-07, This document describes the motivation for benchmarking the Bidirectional Forwarding Detection (BFD) protocol. The BFD protocol is a relatively new protocol intended to detect failures in the bidirectional path between two network elements, with potentially very low latency [BFD, BFD-GEN]. The BFD protocol is being implemented by several vendors and is being deployed extensively by the service providers. Hence, it is imperative that common understanding is established for performance and conformance benchmarks as well as interoperability. This draft seeks to generate interest on this topic in the working group. If there is sufficient interest on this topic, drafts that address the Methodology and Terminology for the BFD protocol could be proposed; before BMWG could make this an official working group item. "IPsec Extensions to Support Header Compression over IPsec (HCoIPsec)", Emre Ertekin, 28-Feb-07, Integrating Header Compression with IPsec (HCoIPsec) offers the combined benefits of IP security services and efficient bandwidth utilization. Before this can be realized, however, several extensions to the Security Policy Database (SPD), the Security Association Database (SAD), and the IPsec process are required. This document describes the IPsec extensions required to enable HCoIPsec. "Conference event package extensions for the XCON framework", Suresh Srinivasan, Roni Even, 28-Feb-07, This document extends the notification mechanism defined in the conference event package [2] to suit the specific needs of the XCON framework [1] and the XCON data model [3]. The document registers a new MIME-subtype for this purpose. Support for this new data format may be negotiated using Accept header semantics (as defined in RFC 3261). "Label Distribution Protocol Extensions for Half-Duplex Multipoint-to-Multipoint Label Switched Paths", Frank Brockners, 28-Feb-07, This document describes a mechanism to construct Label Switched Paths (LSP) over MPLS using an extended version of the Label Distribution Protocol (LDP) between a set of clients and servers. This communication mechanism has the capability that servers can communicate with other servers and clients, whereas clients can only communicate with servers but not with other clients. "6lowpan Management Information Base", Ki-Hyung Kim, 28-Feb-07, This draft defines a portion of the Management Information Base (MIB), the lowpan MIB for use with network management protocols. In particular it defines objects for monitoring functions related to a 6lowpan entity. "An approach to Call Park/Retrieve using SIP", Michael Procter, 1-Mar-07, Call Park and Call Retrieve are useful telephony services that are normally found on traditional PBXs. Implementing these services using the Session Initiation Protocol (SIP) in the way described in the SIP Service Examples draft [1] is straightforward, but suffers from a useability problem when implemented using SIP User Agents resembling traditional business telephones. This draft discusses a simple extension to cater for this style of endpoint. "Media Independent Pre-authentication supporting fast-handoff in PMIPv6", Kenichi Taniuchi, 1-Mar-07, This document describes a proactive mechanism to provide fast- handover involving PMIPv6. In particular, it describes how one can achieve fast handoff for PMIPv6 using Media-independent Pre- Authentication (MPA) technique. It discusses the need for a fast- handoff for PMIPv6 environment. It then describes how MPA techniques could be used during different steps involving both intra-domain and inter-domain handoff for PMIPv6. MPA-based fast-handover takes advantage of the pre-authentication mechanism so that the mobile can perform the access authentication while in the previous local mobility (PMA) domain and thus would be able to complete many of the handoff related operations while still in the previous network. "CUBIC for Fast Long-Distance Networks", Injong Rhee, 1-Mar-07, CUBIC is an extension to the current TCP standards. The protocol differs from the current TCP standards only in the congestion window adjustment function in the sender side. In particular, it uses a cubic function instead of a linear window increase of the current TCP standards to improve scalability and stability under fast and long distance networks. BIC-TCP, a predecessor of CUBIC, has been a default TCP adopted by Linux since year 2005 and has already been deployed globally and in use for several years by the Internet community at large. CUBIC is using a similar window growth function as BIC-TCP and is designed to be less aggressive and fairer to TCP in bandwidth usage than BIC-TCP while maintaining the strengths of BIC- TCP such as stability, window scalability and RTT fairness. Through extensive testing in various Internet scenarios, we believe that CUBIC is safe for deployment and testing in the global Internet. The intent of this document is to provide the protocol specification of CUBIC for a third party implementation and solicit the community feedback through experimentation on the performance of CUBIC. We expect this document to be eventually published as an experimental RFC. "Enrolled User Policy Profiles Attribute", Mark Wahl, 1-Mar-07, This document defines an attribute of a user identity which contains a list of the identifiers of enrollment policy profiles for that user. This attribute is generated by an identity provider that manages the user's identity. An encoding of the attribute is defined for transport in the Lightweight Directory Access Protocol (LDAP), in the Security Assertion Markup Language (SAML), the OpenID Attribute Exchange Protocol, and as an Information Card claim. "Elimination of Proxy NDP from Home Agent Operations", Ryuji Wakikawa, Aramoto Masafumi, 1-Mar-07, This document summarizes operations of home agent without using the proxy NDP. The Proxy NDP is mainly used to intercept packets by a Home Agent on Mobile IPv6 and NEMO. "The NANO Draft (Scene Scenario for Mobile Routers and MNP in RA)", Alexandru Petrescu, Christophe Janneteau, 1-Mar-07, This short NANO draft proposes scenarios for using Mobile Routers at fixed scenes. The routers connect by their egress interfaces and need to allow their Local Fixed Nodes to communicate directly. What if the Mobile Network Prefixes are stored in special Router Advertisements sent by each Mobile Router on their egress interface. What are the issues and can it work. "Mobile IPv6 Make Before Break", Robert Jaksa, 1-Mar-07, This draft documents the use of MCoA (Multiple Care-of Address) method defined in [4] in order to facilitate a Make Before Break within the Mobile IPv6 protocol [1] . This draft is intended to document the usage of MCoA for achieving Make Before Break behavior. The current base Mobile IPv6 specification [1] doesn't include MCoA. With that draft currently under consideration it is possible to use these extensions for MBB. "Problem Statement for Common Interface Support in Localized Mobility Management", Daniel Corujo, 1-Mar-07, This memo is a problem statement on the use of link events for enhanced handover control in network based localized mobility management. Starting from existing solutions for fast link detection the document aims at discussing possibilities for a layer 2.5 interface between MN and AR for handover control. The document also presents a set of considerations and identifies conditions where a layer 2.5 based interface offers significant advantages compared to a pure layer three solution. "ICMP Type 11 Code 0 Enhancement", Alan Watkins, 8-Mar-07, When performing a traceroute, it would be useful to know where packets are trying to go when they cannot be routed. ICMP Type 11 Code 0 packets could be used to provide this information, and the traceroute facility could report this information. "Using LDAP Over IPC Mechanisms", Howard Chu, 1-Mar-07, When both the LDAP client and server reside on the same machine, communication efficiency can be greatly improved using host- specific IPC mechanisms instead of a TCP session. Such mechanisms can also implicitly provide the client's identity to the server for extremely lightweight authentication. This document describes the implementation of LDAP over Unix IPC that has been in use in OpenLDAP since January 2000, including the URL format used to specify an IPC session. "NETCONF Monitoring Schema", Sharon Chisholm, Hector Trevino, 1-Mar-07, This document defines Netconf content via XML Schema to be used to monitor the Netconf protocol. It provides information about Netconf sessions and subscriptions. "BFD for Multipoint Networks", Dave Katz, David Ward, 1-Mar-07, This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks. Comments on this draft should be directed to rtg- bfd@ietf.org. "LHIP Lightweight Authentication Extension for HIP", Tobias Heer, 2-Mar-07, This document specifies the Lightweight authentication extension for the Host Identifier Protocol (LHIP). The goal of LHIP is to reduce the computational requirements of the Host Identifier Protocol (HIP), thus, making its benefits, such as end-host mobility and multihoming, accessible to CPU-restricted devices. LHIP reduces the computational cost of establishing, updating, and closing a HIP association by providing an alternative way of signing and verifying HIP control packets which is based on computationally inexpensive hash function computations and hash chains. However, LHIP does not provide nor does it aim at providing the same level of security as HIP does. Especially, host authentication and payload encryption are not possible. The LHIP extensions in this draft specify also mechanisms for dynamic transitioning between lightweight and full HIP associations on the fly. "Security Framework for MPLS and GMPLS Networks", Luyuan Fang, 2-Mar-07, This document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks (MPLS and GMPLS are described in [RFC3031] and [RFC3945]). This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document gives emphasis to RSVP-TE and LDP security considerations, as well as Inter-AS and Inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers. "MIP type decision in netlmm workgroup", Yuankui Zhao, 2-Mar-07, Currently, this comes from the policy associated with that mobile. But a MS maybe has the MIP capability.We need a flag to know if a MS need Proxy MIP capability.This document explains how we can define a flag in dhcp option to state that a MS wish or doesn't wish to have the Proxy MIP capability. "DHCP option for MIP type Decision", Yuankui Zhao, 2-Mar-07, Dynamic Host Configuration Protocol is used as the trigger of network to distinguish if a MS need the proxy mip capability.But a MS maybe has the MIP capability.We need a flag to know if a MS need or require Proxy MIP capability.This document explains we can define a flag in dhcp option to state that a MS wish or doesn't wish to have the Proxy MIP capability. "QoS policies for heterogeneous access network environment", Aranda Gutierrez, 2-Mar-07, This document discusses policy concepts for management of Quality of Services (QoS) of applications in heterogeneous Internet environment. A framework is given for definitions of policies for configuration and automated adaptation of network resources, application transport parameters and QoS measurement scenarios dependent on the capabilities of heterogeneous access networks. Currently, the IETF QoS policy work is aimed at "specifying and representing policies that administer, manage and control access to network QoS resources" based on DiffServ and IntServ technologies [5]. To enhance this model, policies for management of QoS of heterogeneous network infrastructures are proposed in this document. Based on the capabilities of heterogeneous access networks, the QoS policies for heterogeneous environment allow dynamic configuration and adaptation of network resource reservations, application transport parameters and QoS measurement scenarios. The policies are defined for different actors, such as users, application service providers and network operators. The hierarchical policy management is based on rules specifying adaptation of parameters of policies of actors with hierarchical relationships. "Preliminary LISP Threat Analysis", Marcelo Bagnulo, 5-Mar-07, This document performs a preliminary threat analysis on the Locator/ID Separation Protocol (LISP) as defined in draft- farinacci- lisp-00.txt. "Vehicle Info Event Package", Vishal Singh, 28-Feb-07, This document defines a new SIP event package for updating and retrieving status information of vehicles. The information can include the vehicle's status and diagnostic information distributed by vehicle telematics systems. This event package is useful for fleet management and vehicle tracking applications. The event package is called as vehicle-info event package and is applicable for all types of vehicles like cars, buses, ships and air crafts. However, this document focuses on automobiles. Next Steps in Signaling (nsis) ------------------------------ "NSLP for Quality-of-Service Signaling", Jukka Manner, 8-Mar-07, This specification describes the NSIS Signaling Layer Protocol (NSLP) for signaling QoS reservations in the Internet. It is in accordance with the framework and requirements developed in NSIS. Together with GIST, it provides functionality similar to RSVP and extends it. The QoS NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. It is simplified by the elimination of support for multicast flows. This specification explains the overall protocol approach, design decisions made and provides examples. It specifies object, message formats and processing rules. "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", Martin Stiemerling, 7-Mar-07, This memo defines the NSIS Signaling Layer Protocol (NSLP) for Network Address Translators (NATs) and firewalls. This NSLP allows hosts to signal on the data path for NATs and firewalls to be configured according to the needs of the application data flows. It enables hosts behind NATs to obtain a public reachable address and hosts behind firewalls to receive data traffic. The overall architecture is given by the framework and requirements defined by the Next Steps in Signaling (NSIS) working group. The network scenarios, the protocol itself, and examples for path-coupled signaling are given in this memo. "GIST: General Internet Signalling Transport", Henning Schulzrinne, Robert Hancock, 1-Mar-07, This document specifies protocol stacks for the routing and transport of per-flow signalling messages along the path taken by that flow through the network. The design uses existing transport and security protocols under a common messaging layer, the General Internet Signalling Transport (GIST), which provides a common service for diverse signalling applications. GIST does not handle signalling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path. The combination of GIST and the lower layer transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signalling" framework. "QoS NSLP QSPEC Template", Jerry Ash, 16-Feb-07, The QoS NSLP protocol is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or DiffServ. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC. This document defines a template for the QSPEC including a number of QSPEC parameters. The QSPEC parameters provide a common language to be re-used in several QOSMs and thereby aim to ensure the extensibility and interoperability of QoS NSLP. The node initiating the NSIS signaling adds an initiator QSPEC, which indicates the QSPEC parameters that must be interpreted by the downstream nodes less the reservation fails, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path. "Applicability Statement of NSIS Protocols in Mobile Environments", Sung-Hyuck Lee, 7-Mar-07, Mobility of an IP-based node affects routing paths, and as a result, can have a significant effect on the protocol operation and state management. This draft discusses the effects mobility can cause to the NSIS protocol suit, and how the protocols operate in different scenarios, with mobility management protocols. "RMD-QOSM - The Resource Management in Diffserv QOS Model", Attila Bader, 5-Mar-07, This document describes an NSIS QoS Model for networks that use the Resource Management in Diffserv (RMD) concept. RMD is a technique for adding admission control and preemption function to Differentiated Services (Diffserv) networks. The RMD QoS Model allows devices external to the RMD network to signal reservation requests to edge nodes in the RMD network. The RMD Ingress edge nodes classify the incoming flows into traffic classes and signals resource requests for the corresponding traffic class along the data path to the Egress edge nodes for each flow. Egress nodes reconstitute the original requests and continue forwarding them along the data path towards the final destination. In addition, RMD defines notification functions to indicate overload situations within the domain to the edge nodes. "GIST State Machine", Hannes Tschofenig, 7-Mar-07, This document describes the state machines for the General Internet Signaling Transport (GIST). The states of GIST nodes for a given flow and their transitions are presented in order to illustrate how GIST may be implemented. "Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS Classes", Jerry Ash, 15-Nov-06, This draft describes a QoS-NSLP QoS model (QOSM) based on ITU-T Recommendation Y.1541 QoS signaling requirements. Y.1541 specifies 6 standard QoS classes, and the Y.1541-QOSM extensions include "NSIS Operation Over IP Tunnels", Charles Shen, 7-Mar-07, This draft presents an NSIS operation over IP tunnel scheme using QoS NSLP as the NSIS signaling application. Both sender-initiated and receiver-initiated NSIS signaling modes are discussed. The scheme creates individual or aggregate tunnel sessions for end-to-end sessions traversing the tunnel. Packets belonging to qualified end- to-end sessions are mapped to corresponding tunnel sessions and assigned special flow IDs to be distinguished from the rest of the tunnel traffic. Tunnel endpoints keep the association of the end-to- end and tunnel session mapping, so that adjustment in one session can be reflected in the other. "General Internet Signaling Transport (GIST) over SCTP", Xiaoming Fu, 6-Mar-07, The General Internet Signaling Transport (GIST) protocol currently uses TCP or TLS over TCP for connection mode operation. This document describes the usage of GIST over the Stream Control Transmission Protocol (SCTP). The use of SCTP can take advantage of features provided by SCTP, namely streaming-based transport, support of multiple streams to avoid head of line blocking, and the support of multi-homing to provide network level fault tolerance. Additionally, the support for the Partial Reliability Extension of SCTP is discussed. Network Time Protocol (ntp) --------------------------- "Network Time Protocol Version 4 Protocol And Algorithms Specification", Jack Burbank, 18-Jan-07, The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This memorandum describes Version 4 of the NTP (NTPv4), introducing several changes from Version 3 of NTP (NTPv3) described in RFC 1305, including the introduction of a modified protocol header to accomodate Internet Protocol Version 6. NTPv4 also includes optional extensions to the NTPv3 protocol,including a dynamic server discovery mechanism. "Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4)", Heiko Gerstung, 7-Mar-07, The Network Time Protocol (NTP) is used in networks of all types and sizes for time synchronization of servers, workstations and other networked equipment. As time synchronization is more and more a mission critical service, standardized means for monitoring and management of this subsystem of a networked host are required to allow operators of such a service to setup a monitoring system that is platform- and vendor-independant. This RFC draft provides a standardized collection of data objects for monitoring the NTP service of such a network participant and it is part of the NTP Version 4 standardization effort. An Open Specification for Pretty Good Privacy (openpgp) ------------------------------------------------------- "OpenPGP Message Format", Jon Callas, 10-May-06, This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. Open Pluggable Edge Services (opes) ----------------------------------- "Integrity, privacy and security in OPES for SMTP", Martin Stecher, 7-Feb-07, The Open Pluggable Edge Services (OPES) framework is application agnostic. Application specific adaptations extend that framework. Previous work has focused on HTTP and work for SMTP is in progress. These protocols differ fundamentally in the way data flows and it turns out that existing OPES requirements and IAB considerations for OPES need to be reviewed with regards to how well they fit for SMTP adaptation. This document analyzes aspects about the integrity of SMTP and mail message adaptation by OPES systems and privacy and security issues when the OPES framework is adapted to SMTP and lists requirements that must be considered when creating the "SMTP adaptation with OPES" document. The intent of this document is to capture this information before the current OPES working group shuts down. This is to provide input for subsequent working groups or individual contributors that may pick up the OPES/SMTP work at a later date. Operational Security Capabilities for IP Network Infrastructure (opsec) ----------------------------------------------------------------------- "Framework for Operational Security Capabilities for IP Network Infrastructure", George Jones, 5-Mar-07, This document outlines work to be done and documents to be produced by the Operational Security Capabilities (OPSEC) Working Group. The goal of the working group is to codify knowledge gained through operational experience about feature sets that are needed to securely deploy and operate managed network elements providing transit services at the data link and IP layers. The intent is to provide clear, concise documentation of capabilities necessary for operating networks securely, to assist network operators in communicating their requirements to vendors, and to provide vendors with input that is useful for building more secure devices. The working group will produce a list of capabilities appropriate for large Internet Service Provider (ISP) and Enterprise Networks. This work is intended to refine [RFC3871]. "Security Best Practices Efforts and Documents", Chris Lonvick, David Spak, 22-Dec-06, This document provides a snapshot of the current efforts to define or apply security requirements in various Standards Developing Organizations (SDO). "Filtering and Rate Limiting Capabilities for IP Network Infrastructure", Christopher Morrow, 1-Mar-07, [I-D.ietf-opsec-current-practices] lists operator practices related to securing networks. This document lists filtering and rate limiting capabilities needed to support those practices. Capabilities are limited to filtering and rate limiting packets as they enter or leave the device. Route filters and service specific filters (e.g. SNMP, telnet) are not addressed. Capabilities are defined without reference to specific technologies. This is done to leave room for deployment of new technologies that implement the capability. Each capability cites the practices it supports. Current implementations that support the capability are cited. Special considerations are discussed as appropriate listing operational and resource constraints, limitations of current implementations, trade-offs, etc. "Service Provider Infrastructure Security", Darrel Lewis, 10-Sep-06, This RFC describes best current practices for implementing Service Provider network infrastructure protection for network elements. This RFC complements and extends RFC 2267 and RFC 3704. RFC 2267 provides guidelines for filtering traffic on the ingress to service provider networks. RFC 3704 expands the recommendations described in RFC 2267 to address operational filtering guidelines for single and multi-homed environments. The focus of those RFCs is on filtering packets on ingress to a network, regardless of destination, if those packets have a spoofed source address, or if the source address fall within "reserved" address space. Deployment of RFCs 2267 and 3704 has limited the effects of denial of service attacks by dropping ingress packets with spoofed source addresses, which in turn offers other benefits by ensuring that packets coming into a network originate from validly allocated and consistent sources. This document focuses solely on traffic destined to elements of the the network infrastructure itself. This document presents techniques that, together with network edge ingress filtering and RFC 2267 and RFC 3704, provides a defense in depth approach for infrastructure protection. This document does not present recommendations for protocol validation (i.e. "sanity checking") nor does it address guidelines for general security configuration. "Routing Control Plane Security Capabilities", Yuping Zhao, 26-Feb-07, The document lists the security capabilities needed for the routing control plane of an IP infrastructure to support the practices defined in Operational Security Current Practices. In particular this includes capabilities for route filtering, for authentication of routing protocol packets, and for ensuring resource availability for control functions. "Logging Capabilities for IP Network Infrastructure", Patrick Cain, George Jones, 2-Mar-07, This document lists logging capabilities originally defined in RFC3871 [RFC3871] and needed to support current operational practices, including those described in the Operational Security Current Practices document[RFC4778] Logging is defined as the delivery of messages about the device, the data passing through the device, or the device's interaction with another device. This document may be used in conjunction with the other capabilities documents to operate a secure networking environment. Capabilities are defined without reference to specific technologies. This is done to leave room for deployment of new technologies that implement the capability. Each capability cites the practices it supports. Current implementations that support the capability are cited. Special considerations are discussed as appropriate listing operational and resource constraints, limitations of current implementations, trade-offs, etc. Open Shortest Path First IGP (ospf) ----------------------------------- "OSPF Link-local Signaling", Alex Zinin, 12-Jan-07, OSPF is a link-state intra-domain routing protocol. OSPF routers exchange information on a link using packets that follow a well- defined fixed format. The format is not flexible enough to enable new features which need to exchange arbitrary data. This memo describes a backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. "Traffic Engineering Extensions to OSPF version 3", Kunihiro Ishiguro, 3-Jan-07, This document describes extensions to OSPFv3 to support intra-area Traffic Engineering (TE). This document extends OSPFv2 TE to handle IPv6 networks. A new TLV and several new sub-TLVs are defined to support IPv6 networks. "Extensions to OSPF for Advertising Optional Router Capabilities", Acee Lindem, 13-Feb-07, It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This draft proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities. A new Router Information (RI) Link State Advertisement (LSA) is proposed for this purpose. In OSPFv2, the RI LSA will be implemented with a new opaque LSA type ID. In OSPFv3, the RI LSA will be implemented with a new LSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or AS). "Support of address families in OSPFv3", Sina Mirtorabi, 29-Sep-06, This document describes a mechanism for supporting multiple address families in OSPFv3 using multiple instances. It maps an address family (AF) to an OSPFv3 instance using the Instance ID field in the OSPFv3 packet header. This approach is fairly simple and minimizes extensions to OSPFv3 for supporting multiple AF's. "OSPF Multi-Area Adjacency", Sina Mirtorabi, 27-Jun-06, This memo documents an extension to OSPF to allow a single physical link to be shared by multiple areas. This is necessary to allow the link to be considered an intra-area link in multiple areas. This would create an intra-area path to the corresponding areas sharing the same link. "Multi-Topology (MT) Routing in OSPF", Peter Psenak, 22-Jan-07, This draft describes an extension to Open Shortest Path First (OSPF) in order to define independent IP topologies called Multi-Topologies (MTs). The Multi-Topologies extension can be used for computing different paths for unicast traffic, multicast traffic, different classes of service based on flexible criteria, or an in-band network management topology. An optional extension to exclude selected links from the default topology is also described. "OSPFv3 Graceful Restart", Padma Pillay-Esnault, Acee Lindem, 8-May-06, This memo describes the OSPFv3 graceful restart. For OSPFv3, graceful restart is identical to OSPFv2 except for the differences described in this memo. These differences include the format of the grace Link State Advertisements (LSA) and other considerations. "OSPF for IPv6", Dennis Ferguson, 20-Dec-06, This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. Changes between OSPF for IPv4 and this document include the following. Addressing semantics have been removed from OSPF packets and the basic LSAs. New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload. Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible. All of OSPF for IPv4's optional capabilities, including demand circuit support, Not-So-Stubby Areas (NSSAs), and the multicast extensions to OSPF (MOSPF) are also supported in OSPF for IPv6. "IANA Considerations for OSPF", Bill Fenner, Kireeti Kompella, 5-Mar-07, This memo creates a number of OSPF registries and provides guidance to IANA for assignment of code points within these registries. "The OSPF Opaque LSA Option", Lou Berger, 8-Dec-06, This memo defines enhancements to the OSPF protocol to support a new class of link-state advertisements (LSA) called Opaque LSAs. Opaque LSAs provide a generalized mechanism to allow for the future extensibility of OSPF. Opaque LSAs consist of a standard LSA header followed by application-specific information. The information field may be used directly by OSPF or by other applications. Standard OSPF link-state database flooding mechanisms are used to distribute Opaque LSAs to all or some limited portion of the OSPF topology. This document replaces [RFC2370], and adds to it a mechanism to enable an OSPF router to validate AS-scope opaque LSAs originated outside of the router's OSPF area. "OSPF Database Exchange Summary List Optimization", Richard Ogier, 3-Jan-07, This document describes a backward compatible optimization for the Database Exchange process in OSPFv2 and OSPFv3. In this optimization, a router does not list an LSA in Database Description packets sent to a neighbor, if the same or a more recent instance of the LSA was listed in a Database Description packet already received from the neighbor. This optimization reduces Database Description overhead by about 50% in large networks. This optimization does not affect synchronization, since it only omits unnecessary information from Database Description packets. "OSPF Version 2 MIB for Multi-Topology (MT) Routing", Namita Rawat, 24-Jan-07, This memo defines an extension to the Open Shortest Path First version 2 Management Information Base (OSPFv2 MIB) for use with network management protocols in the Internet community. In particular it describes objects and lists considerations for the management of OSPF Multi-Topology routing. At present, the OSPF Multi-Topology extensions are defined within a standards track internet draft [6]. Protocol for carrying Authentication for Network Access (pana) -------------------------------------------------------------- "Protocol for Carrying Authentication for Network Access (PANA)", Dan Forsberg, 5-Mar-07, This document defines the Protocol for Carrying Authentication for Network Access (PANA), a network-layer transport for Extensible Authentication Protocol (EAP) to enable network access authentication between clients and access networks. PANA protocol specification covers the client-to-network access authentication part of an overall secure network access framework, which additionally includes other protocols and mechanisms for service provisioning, access control as a result of initial authentication, and accounting. "PANA Enabling IPsec based Access Control", Mohan Parthasarathy, 14-Jul-05, PANA (Protocol for carrying Authentication for Network Access) is a protocol for authenticating clients to the access network using IP based protocols. The PANA protocol authenticates the client and also establishes a PANA security association between the PANA client and PANA authentication agent at the end of a successful authentication. This document discusses the details for establishing an IPsec security association using the PANA security association for enabling IPsec based access control. "Protocol for Carrying Authentication for Network Access (PANA) Framework", Prakash Jayaraman, 23-Aug-06, This document defines the general PANA framework functional elements, high-level call flow, and deployment environments. Path Computation Element (pce) ------------------------------ "Path Computation Element (PCE) communication Protocol (PCEP)", Jean-Louis Le Roux, JP Vasseur, 5-Mar-07, This document specifies the Path Computation Element communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized (GMPLS) Traffic Engineering. The PCEP protocol is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. "PCC-PCE Communication Requirements for Inter-Layer Traffic Engineering", Eiji Oki, 5-Mar-07, The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers. PCE is a candidate solution for such requirements. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in "PCE Communication Protocol Generic Requirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements for inter-layer traffic engineering. "PCE Communication Protocol (PCECP) Specific Requirements for Inter-Area Multi Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering", Jean-Louis Le Roux, 29-Dec-06, For scalability purposes a network may comprise multiple Interior Gateway Protocol (IGP) areas. An inter-area Traffic Engineered-Label Switched Path (TE-LSP) is an LSP that transits through at least two IGP areas. In a multi-area network, topology visibility remains local to a given area, and a head-end Label Switching Router (LSR) cannot compute an inter-area shortest constrained path. One key application of the Path Computation Element (PCE) based architecture is the computation of inter-area TE-LSP paths. The PCE Communication Protocol (PCECP) is used to communicate computation requests from Path Computation Clients (PCC) to PCEs, and to return computed paths in responses. This document lists a detailed set of PCECP specific requirements for support of inter-area TE-LSP path computation. It complements the generic requirements for a PCE Communication Protocol. "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", Eiji Oki, 5-Mar-07, A network may comprise multiple layers. It is important to globally optimize network resource utilization, taking into account all layers, rather than optimizing resource utilization at each layer independently. This allows better network efficiency to be achieved through a process that we call inter-layer traffic engineering. The Path Computation Element (PCE) can be a powerful tool to achieve inter-layer traffic engineering. This document describes a framework for applying the PCE-based architecture to inter-layer Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) traffic engineering. It provides suggestions for the deployment of PCE in support of multi-layer networks. This document also describes network models where PCE performs inter-layer traffic engineering, and the relationship between PCE and a functional component called the Virtual Network Topology Manager (VNTM). "Policy-Enabled Path Computation Framework", Igor Bryskin, 2-Mar-07, The PCE architecture [RFC4655] introduces the concept of policy in the context of path computation. This document provides additional details on policy within the PCE Architecture and also provides context for the support of PCE Policy. This document introduces the use of the Policy Core Information Model (PCIM) as a framework for supporting path computation policy. This document also provides representative scenarios for the support of PCE Policy. "Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)", Nabil Bitar, 26-Oct-06, Multiprotocol Label Switching Traffic Engineered (MPLS-TE) LabelSwitched Paths (LSPs) may be established wholly within an Autonomous System (AS) or may cross AS boundaries. The Path Computation Element (PCE) is a component that is capable of computing paths for MPLS-TE LSPs. The PCE Communication Protocol(PCECP) is defined to allow communication between Path Computation Clients (PCCs) and PCEs, and between PCEs. The PCECP is used to request paths and to supply computed paths in responses. Generic requirements for the PCECP are set out in "Path Computation Element(PCE) Communication Protocol Generic Requirements", RFC 4657. This document extends those requirements to cover the use of PCECP in support of inter-AS MPLS-TE. "A Backward Recursive PCE-based Computation (BRPC) procedure to compute shortest inter-domain Traffic Engineering Label Switched Paths", JP Vasseur, 2-Mar-07, The ability to compute shortest constrained Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains (where a domain is referred to as a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems) has been identified as a key requirement . This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) in order to compute such inter-domain shortest constrained paths along a determined sequence of domains, using a backward recursive path computation technique while preserving confidentiality across domains, which is sometimes required when domains are managed by different Service Providers. "IS-IS protocol extensions for Path Computation Element (PCE) Discovery", Jean-Louis Le Roux, 13-Feb-07, There are various circumstances where it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCE), along with some of information that can be used for PCE selection. When the PCE is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to discover PCEs consists of using IGP flooding. For that purpose this document defines extensions to the Intermediate System to Intermediate System (IS-IS) routing protocol for the advertisement of PCE Discovery information within an IS-IS area or within the entire IS-IS routing domain. "OSPF protocol extensions for Path Computation Element (PCE) Discovery", Jean-Louis Le Roux, 13-Feb-07, There are various circumstances where it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCE), along with some of information that can be used for PCE selection. When the PCE is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to discover PCEs consists of using IGP flooding. For that purpose, this document defines extensions to the Open Shortest Path First (OSPF) routing protocol for the advertisement of PCE Discovery information within an OSPF area or within the entire OSPF routing domain. "Definitions of Managed Objects for Path Computation Element Discovery", Emile Stephan, 8-Mar-07, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing Path Computation Elements Discovery. "Definitions of Textual Conventions for Path Computation Element", Emile Stephan, 7-Mar-07, 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 Textual Conventions to represent commonly used Path Computation Element (PCE) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in PCE related MIB modules to avoid duplicating conventions. "Inclusion of Manageability Sections in PCE Working Group Drafts", Adrian Farrel, 1-Mar-07, It has often been the case that manageability considerations have been retrofitted to protocols after they have been speicified, standardized, implemented, and deployed. This is sub-optimal. Similarly, new protocols or protocol extensions are frequently designed without due consideration of manageability requirements. This document specifies the recommendation for all new Internet-Drafts in the PCE Working Group to include a "Manageability Considerations" section, and gives guidance on what that section should contain. Protocol Independent Multicast (pim) ------------------------------------ "Bi-directional Protocol Independent Multicast (BIDIR-PIM)", Mark Handley, 23-Feb-07, This document discusses Bi-directional PIM, a variant of PIM Sparse-Mode that builds bi-directional shared trees connecting multicast sources and receivers. Bi-directional trees are built using a fail-safe Designated Forwarder (DF) election mechanism operating on each link of a multicast topology. With the assistance of the DF, multicast data is natively forwarded from sources to the Rendezvous-Point and hence along the shared tree to receivers without requiring source-specific state. The DF election takes place at RP discovery time and provides the route to the RP thus eliminating the requirement for data-driven protocol events. "Bootstrap Router (BSR) Mechanism for PIM", Nidhi Bhaskar, 13-Feb-07, This document specifies the Bootstrap Router (BSR) mechanism for the class of multicast routing protocols in the PIM (Protocol Independent Multicast) family that use the concept of a Rendezvous Point as a means for receivers to discover the sources that send to a particular multicast group. BSR is one way that a multicast router can learn the set of group-to-RP mappings required in order to function. The mechanism is dynamic, largely self-configuring, and robust to router failure. "Protocol Independent Multicast MIB", James Lingard, 2-Mar-07, 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 used for managing the Protocol Independent Multicast (PIM) protocols (PIM-SM, BIDIR-PIM and PIM-DM). This document is part of work in progress to obsolete RFC 2934, and is to be preferred where the two documents overlap. This document does not obsolete RFC 2934. "The RPF Vector TLV", IJsbrand Wijnands, 26-Oct-06, This document describes a use of the PIM Join Attribute as defined in draft-ietf-pim-join-attributes[I-D.ietf-pim-join-attributes] which enables PIM to build multicast trees through an MPLS-enabled network, even if that network's IGP does not have a route to the source of the tree. "Format for using TLVs in PIM messages", A Boers, 25-Oct-06, This document describes a generic TLV attribute encoding format to be added to PIM join messages. "PIM Bootstrap Router MIB", Bharat Joshi, Raina Bijlani, 9-Feb-07, This document 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 used for managing the Bootstrap Router (BSR) mechanism for PIM. "Security Issues in PIM-SM Link-local Messages", John Atwood, Salekul Islam, 16-Oct-06, This document outlines the security issues for the link-local messages in the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol. It provides mechanisms to authenticate the PIM-SM link local messages using the IP security (IPsec) Authentication Header (AH). "Last-hop Threats to Protocol Independent Multicast (PIM)", Pekka Savola, James Lingard, 17-Oct-06, An analysis of security threats has been done for some parts of the multicast infrastructure, but the threats specific to the last-hop ("Local Area Network") attacks by hosts on the PIM routing protocol have not been well described in the past. This memo aims to fill that gap. Profiling Use of PKI in IPSEC (pki4ipsec) ----------------------------------------- "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", Brian Korver, 23-Feb-07, IKE and PKIX certificate profile both provide frameworks that must be profiled for use in a given application. This document provides a profile of IKE and PKIX that defines the requirements for using PKI technology in the context of IKE/IPsec. The document complements protocol specifications such as IKEv1 and IKEv2, which assume the existence of public key certificates and related keying materials, but which do not address PKI issues explicitly. This document addresses those issues. The intended audience is implementors of PKI for IPsec. "Requirements for an IPsec Certificate Management Profile", Chistopher Bonatti, 15-Nov-06, This informational document describes and identifies the requirements for transactions to handle Public Key Certificate (PKC) lifecycle transactions between Internet Protocol Security (IPsec) Virtual Private Network (VPN) Systems using Internet Key Exchange (IKE) (versions 1 and 2) and Public Key Infrastructure (PKI) Systems. These requirements are designed to meet the needs of enterprise scale IPsec VPN deployments. It is intended that a standards track profile of a management protocol will be created to address many of these requirements. Public-Key Infrastructure (X.509) (pkix) ---------------------------------------- "Server-based Certificate Validation Protocol (SCVP)", Ambarish Malpani, 15-Jan-07, SCVP allows a client to delegate certificate path construction and certificate path validation to a server. The path construction or validation (e.g., making sure that none of the certificates in the path are revoked) is performed according to a validation policy, which contains one or more trust anchors. It allows simplification of client implementations and use of a set of predefined validation policies. "Certificate Management Messages over CMS", Michael Myers, Jim Schaad, 3-Mar-06, This document defines the base syntax for CMC, a Certificate Management protocol using CMS (Cryptographic Message Syntax). This protocol addresses two immediate needs within the Internet PKI community: 1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Crytpography 2. The need in S/MIME (Secure MIME) for a certificate enrollment protocol for DSA-signed certificates with Diffie-Hellman public keys. CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition. "Certificate Management over CMS (CMC) Transport Protocols", Jim Schaad, Michael Myers, 16-May-06, This document defines a number of transport mechanisms that are used to move CMC (Certificate Managment over CMS (Cryptographic Message Syntax)) messages. The transport mechanisms described in this document are: HTTP, file, mail and TCP. "CMC Complience Document", Michael Myers, Jim Schaad, 6-Mar-06, This document provides a set of compliance statements about the CMC (Certificate Management over CMS) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents. This document provides the information needed to make a compliant version of CMC "Additional Algorithms and Identifiers for use of Elliptic Curve Cryptography with PKIX", Daniel R. L. Brown, 5-Oct-06, This document gives additional algorithms and associated ASN.1 identifiers for elliptic curve cryptography (ECC) used with the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (PKIX). The algorithms and identifiers here are consistent with both ANSI X9.62-2005 and X9.63-2001, and shall be consistent with the forthcoming revisions of these documents. Consistency shall also be maintained with SEC1 and SEC2, and any revisions or successors of such documents. "Lightweight OCSP Profile for High Volume Environments", Ryan Hurst, Alex Deacon, 20-Feb-07, This specification defines a profile of the Online Certificate Status Protocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) PKI environments and/or in PKI environments that require a lightweight solution to minimize communication bandwidth and client side processing. "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", Dave Cooper, 23-Feb-07, This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model are provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. "Internet X.509 Public Key Infrastructure Subject Alternative Name for expression of service name", Stefan Santesson, 12-Dec-06, This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name extension which allows a certificate subject to be associated with the service name and domain name components of a DNS Service Resource Record. Path MTU Discovery (pmtud) -------------------------- "Packetization Layer Path MTU Discovery", Matt Mathis, John Heffner, 7-Dec-06, This document describes a robust method for Path MTU Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets. This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP based Path MTU Discovery for IP versions 4 and 6, respectively. Packet Sampling (psamp) ----------------------- "A Framework for Packet Selection and Reporting", Nick Duffield, 5-Jan-05, This document specifies a framework for the PSAMP (Packet Sampling) protocol. The functions of this protocol are to select packets from a stream according to a set of standardized reports, form a stream of reports on the selected packets, and to export that stream to a collector. This framework details the components of this architecture, then describes some generic requirements, motivated the dual aims of ubiquitous deployment and utility of the reports for applications. Detailed requirements for selection, reporting and export are described, along with configuration of the PSAMP functions. "Sampling and Filtering Techniques for IP Packet Selection", Tanja Zseby, 7-Jul-05, This document describes Sampling and Filtering techniques for IP packet selection. It provides a categorization of schemes and defines what parameters are needed to describe the most common selection schemes. Furthermore it shows how techniques can be combined to build more elaborate packet Selectors. The document provides the basis for the definition of information models for configuring selection techniques in Measurement Processes and for reporting the technique in use to a Collector. "Packet Sampling (PSAMP) Protocol Specifications", Benoit Claise, 26-Oct-06, This document specifies the export of packet information from a PSAMP Exporting Process to a PSAMP Collecting Process. For export of packet information the IP Flow Information eXport (IPFIX) protocol is used, as both the IPFIX and PSAMP architecture match very well and the means provided by the IPFIX protocol are sufficient. The document specifies in detail how the IPFIX protocol is used for PSAMP export of packet information. "Information Model for Packet Sampling Exports", Thomas Dietz, 26-Oct-06, This memo defines an information model for the Packet Sampling (PSAMP) protocol. It is used by the PSAMP protocol for encoding sampled packet data and information related to the sampling process. As the PSAMP protocol is based on the IPFIX protocol, this information model is an extension to the IPFIX information model. Pseudowire Emulation Edge to Edge (pwe3) ---------------------------------------- "Pseudo Wire (PW) Management Information Base", David Zelig, 7-Feb-07, This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Pseudo Wire Edge-to-Edge services carried over a general Packet Switched Network. "Pseudo-Wire (PW) over MPLS PSN Management Information Base", David Zelig, Thomas Nadeau, 5-Mar-07, This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a MIB module for PW operation over Multi-Protocol Label Switching (MPLS) Label Switch Router (LSR). "Definitions for Textual Conventions and for Managing Pseudo-Wires over PSN", Thomas Nadeau, 8-Feb-07, This memo defines a Management Information Base (MIB) module which contains Textual Conventions (TCs) to represent commonly-used Pseudo Wire (PW) management information. The intent is that these TCs will be imported and used in PW-related MIB modules that would otherwise define their own representations. "SONET/SDH Circuit Emulation over Packet (CEP)", Andrew Malis, 28-Dec-06, This document provides encapsulation formats and semantics for emulating SONET/SDH circuits and services over MPLS. "SONET/SDH Circuit Emulation Service Over Packet (CEP) Management Information Base Using SMIv2", Thomas Nadeau, 23-Oct-06, This memo defines an experimental 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 SONET/SDH circuits over a Packet Switch Network (PSN). "Ethernet Pseudo-Wire (PW) Management Information Base", David Zelig, Thomas Nadeau, 28-Feb-07, This memo defines an experimental 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 of Ethernet Pseudo-Wire (PW) services. "Pseudo Wire Virtual Circuit Connectivity Verification (VCCV)", Thomas Nadeau, 5-Mar-07, This document describes Virtual Circuit Connection Verification (VCCV) which provides a control channel that is associated with a Pseudowire (PW), as well as the corresponding operations and management functions such as connectivity verification to be used over that control channel. VCCV applies to all supported access circuit and transport types currently defined for PWs. "Managed Objects for ATM over Packet Switched Network (PSN)", Thomas Nadeau, 13-Feb-07, This memo defines an experimental 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 ATM Pseudowire (PW) carrying ATM cells over Packet Switch Network (PSN) as defined in the PWE3 [ATMENCAP]and [ATMTRANS]. "Structure-aware TDM Circuit Emulation Service over Packet Switched Network (CESoPSN)", Sasha Vainshtein, 16-May-06, This document describes a method for encapsulating structured (NxDS0) Time Division Multiplexed (TDM)signals as pseudo-wires over packet- switching networks (PSN). In this regard, it complements similar work for structure-agnostic emulation of TDM bit-streams [PWE3-SAToP]. "TDM over IP", Yakov Stein, 5-Dec-06, TDM over IP (TDMoIP) is a structure-aware method for transporting Time Division Multiplexed (TDM) signals as pseudowires (PWs). By ensuring TDM structure integrity, TDMoIP is able to better withstand network degradations. As TDM signaling and individual channels are visible, it is possible to use mechanisms that exploit or manipulate these to conceal packet loss or conserve bandwidth. "Managed Objects for TDM over Packet Switched Network (PSN)", Orly Nicklass, 13-Feb-07, 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 pseudo wire encapsulation for structured or unstructured TDM (T1, E1, T3, E3) circuits over a Packet Switch Network (PSN). "Pseudo Wire (PW) OAM Message Mapping", Thomas Nadeau, 6-Mar-07, This document specifies the mapping of defect states between a Pseudo Wire and the Attachment Circuits (AC) of the end-to-end emulated service. This document covers the case whereby the ACs and the PWs are of the same type in accordance to the PWE3 architecture [RFC3985] such that a homogenous PW service can be constructed. "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", Matthew Bocci, Luca Martini, 15-Jan-07, This document describes the necessary requirements to allow a service provider to extend the reach of pseudowires across multiple domains. These domains can be autonomous systems under one provider administrative control, IGP areas in one autonomous system, different autonomous systems under the administrative control of two or more "Segmented Pseudo Wire", Luca Martini, 6-Mar-07, This document describes how to connect pseudo wires (PW) between two distinct PW control planes or PSN domains. The PW control planes may belong to independent autonomous systems, or the PSN technology is heterogeneous, or a PW might need to be aggregated at a specific PSN point. The PW packet data units are simply switched from one PW to another without changing the PW payload. "Control Protocol Extensions for Setup of TDM Pseudowires", Sasha Vainshtein, Yakov Stein, 5-Oct-06, This document defines extension to the PWE3 control protocol [RFC4447] and PWE3 IANA allocations [RFC4446] required for setup of TDM pseudowires. "Dynamic Placement of Multi Segment Pseudo Wires", Florin Balus, 25-Oct-06, There is a requirement for service providers to be able to extend the reach of pseudo wires (PW) across multiple Packet Switched Network domains. A Multi-Segment PW is defined as a set of two or more contiguous PW segments that behave and function as a single point- to-point PW. This document describes extensions to the PW control protocol to dynamically place the segments of the multi segment pseudo wire among a set of Provider Edge (PE) routers. "An Architecture for Multi-Segment Pseudo Wire Emulation Edge-to-Edge", Matthew Bocci, Stewart Bryant, 22-Oct-06, This document describes an architecture for extending pseudowire emulation across multiple packet switched network segments. Scenarios are discussed where each segment of a given edge-to-edge emulated service spans a different provider's PSN, and where the emulated service originates and terminates on the same providers PSN, but may pass through several PSN tunnel segments in that PSN. It presents an architectural framework for such multi-segment pseudowires, defines terminology, and specifies the various protocol elements and their functions. "Wildcard Pseudowire Type", Luca Martini, George Swallow, 17-Oct-06, Pseudowire signaling requires that the Pseudowire Type (PW Type) be identical in both directions. For certain applications the configuration of the PW Type is most easily accomplished by configuring this information at just one PW endpoint. In any form of LDP-based signaling, each PW endpoint must initiate the creation of a unidirectional LSP. In order to allow the initiation of these two LSPs to remain independent, a means of allowing the PW endpoint lacking a priori knowledge of the PW Type to initiate the creation of an LSP is needed. This document defines a Wildcard PW Type to satisfy this need. "AII Types for Aggregation", Chris Metz, 7-Feb-07, The signaling protocols used to establish point-to-point pseudowires include type-length-value (TLV) fields that identify pseudowire endpoints called attachment individual identifiers (AII). This document defines AII structures in the form of new AII type-length- value fields that support AII aggregation for improved scalability and VPN autodiscovery. It is envisioned that this would be useful in large inter-domain virtual private wire service networks where pseudowires are established between selected local and remote PE nodes based on customer need. "Encapsulation Methods for Transport of Fibre Channel frames Over MPLS Networks", Moran Roth, 20-Oct-06, A Fibre Channel Pseudowire (PW) is used to carry Fibre Channel frames over an MPLS network. This enables service providers to offer "emulated" Fibre Channel services over existing MPLS networks. This document specifies the encapsulation of Fibre Channel PDUs within a pseudowire. It also specifies the procedures for using a PW to provide a Fibre Channel service. "Pseudowire Congestion Control Framework", Stewart Bryant, 2-Feb-07, Given that pseudowires may be used to carry non-TCP data flows, it is necessary to provide pseudowire-specific congestion control procedures. These procedures should ensure that pseudowire traffic is "TCP-compatible", as defined in RFC 2914. This document attempts to lay out the issues which must be considered when defining such procedures. RADIUS EXTensions (radext) -------------------------- "RADIUS Attributes for Filtering and Redirection", Paul Congdon, 6-Mar-07, This document defines the NAS-Traffic-Rule and Acct-NAS-Traffic- Rule attributes within Remote Authentication Dial In User Service (RADIUS) that is based on and extends on the filtering capability defined by Diameter's NAS-Filter-Rule Attribute Value Pair (AVP) described in RFC 4005, and the IPFilterRule syntax defined in RFC 3588. "RADIUS Delegated-IPv6-Prefix Attribute", Joseph Salowey, Ralph Droms, 19-Oct-06, This document defines a RADIUS (Remote Authentication Dial In User Service) attribute that carries an IPv6 prefix that is to be delegated to the user. This attribute is usable within either RADIUS or Diameter. "RADIUS Filter Rule Attribute", Paul Congdon, 17-Jan-07, This document provides detailed description of IPv6 deployment and integration methods and scenarios in wireless broadband access networks in coexistence with deployed IPv4 services. In this document we will discuss main components of IPv6 IEEE 802.16 access network and its differences from IPv4 IEEE 802.16 networks and how IPv6 is deployed and integrated in each of the IEEE 802.16 technologies using tunneling mechanisms and native IPv6. "RADIUS Extension for Digest Authentication", Baruch Sterman, 2-Jan-07, This document defines an extension to the Remote Authentication Dial- In User Service (RADIUS) protocol to enable support of Digest Authentication, for use with HTTP-style protocols like the Session Initiation Protocol (SIP) and HTTP. "Common RADIUS Implementation Issues and Suggested Fixes", David Nelson, Alan DeKok, 14-Feb-07, This document describes common issues seen in RADIUS implementations and suggests some fixes. Where applicable, ambiguities and errors in previous RADIUS specifications are clarified. "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", Murtaza Chiba, 22-Jan-07, This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. Remote Direct Data Placement (rddp) ----------------------------------- "A Remote Direct Memory Access Protocol Specification", Renato Recio, 10-Sep-06, This document defines a Remote Direct Memory Access Protocol (RDMAP) that operates over the Direct Data Placement Protocol (DDP protocol). RDMAP provides read and write services directly to applications and enables data to be transferred directly into Upper Layer Protocol (ULP) buffers without intermediate data copies. It also enables a kernel bypass implementation. "Direct Data Placement over Reliable Transports", Hemal Shah, 26-Sep-06, The Direct Data Placement protocol provides information to Place the incoming data directly into an upper layer protocol's receive buffer without intermediate buffers. This removes excess CPU and memory utilization associated with transferring data through the intermediate buffers. "Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP)", Caitlin Bestler, Lode Coene, 22-Jun-06, This document describes the applicability of Remote Direct Memory Access Protocol (RDMAP) and the Direct Data Placement Protocol (DDP). It compares and contrasts the different transport options over IP that DDP can use, provides guidance to ULP developers on choosing between available transports and/or how to be indifferent to the specific transport layer used, compares use of DDP with direct use of the supporting transports, and compares DDP over IP transports with non-IP transports that support RDMA functionality. " Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation", Caitlin Bestler, Randall Stewart, 15-Sep-06, This document specifies an Adaptation Layer to provide a Lower Layer Protocol (LLP) service for Direct Data Placement (DDP) using the Stream Control Transmission Protocol (SCTP). "Marker PDU Aligned Framing for TCP Specification", Paul Culley, 9-Oct-06, MPA (Marker Protocol data unit Aligned framing) is designed to work as an "adaptation layer" between TCP and the Direct Data Placement [DDP] protocol, preserving the reliable, in-order delivery of TCP, while adding the preservation of higher-level protocol record boundaries that DDP requires. MPA is fully compliant with applicable TCP RFCs and can be utilized with existing TCP implementations. MPA also supports integrated implementations that combine TCP, MPA and DDP to reduce buffering requirements in the implementation and improve performance at the system level. "DDP/RDMAP Security", Jim Pinkerton, 23-Jun-06, This document analyzes security issues around implementation and use of the Direct Data Placement Protocol(DDP) and Remote Direct Memory Access Protocol (RDMAP). It first defines an architectural model for an RDMA Network Interface Card (RNIC), which can implement DDP or RDMAP and DDP. The document reviews various attacks against the resources defined in the architectural model and the countermeasures that can be used to protect the system. Attacks are grouped into those that can be mitigated by using secure communication channels across the network, attacks from Remote Peers, and attacks from Local Peers. Attack categories include spoofing, tampering, information disclosure, denial of service, and elevation of privilege. Reliable Multicast Transport (rmt) ---------------------------------- "Raptor Forward Error Correction Scheme for Object Delivery", Michael Luby, 1-Mar-07, This document describes a Fully-Specified FEC scheme, corresponding to FEC Encoding ID 1, for the Raptor forward error correction code and its application to reliable delivery of data objects. Raptor is a fountain code, i.e., as many encoding symbols as needed can be generated by the encoder on-the-fly from the source symbols of a source block of data. The decoder is able to recover the source block from any set of encoding symbols only slightly more in number than the number of source symbols. The Raptor code described here is a systematic code, meaning that all the source symbols are among the encoding symbols that can be generated. "Forward Error Correction (FEC) Building Block", Mark Watson, 23-Feb-07, This document describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for bulk data transfer over IP multicast. This document defines a framework for the definition of the information that needs to be communicated in order to use an FEC code for bulk data transfer, in addition to the encoded data itself, and for definition of formats and codes for communcation of that information. Both information communicated with the encoded data itself and information that needs to be communicated 'out-of-band' are considered. The procedures for specifying new FEC codes, defining the information communication requirements associated with those codes and registering them with the Internet Assigned Numbers Authority (IANA) are also described. The requirements on Content Delivery Protocols which wish to use FEC codes defined within this framework are also defined. The companion document titled, "The Use of Forward Error Correction (FEC) in Reliable Multicast" describes some applications of FEC codes for delivering content. This document obsoletes RFC3452. "Layered Coding Transport (LCT) Building Block", Michael Luby, 23-Feb-07, Layered Coding Transport (LCT) provides transport level support for reliable content delivery and stream delivery protocols. LCT is specifically designed to support protocols using IP multicast, but also provides support to protocols that use unicast. LCT is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content. This document obsoletes RFC3451 "Asynchronous Layered Coding (ALC) Protocol Instantiation", Michael Luby, 23-Feb-07, This document describes the Asynchronous Layered Coding (ALC) protocol, a massively scalable reliable content delivery protocol. Asynchronous Layered Coding combines the Layered Coding Transport (LCT) building block, a multiple rate congestion control building block and the Forward Error Correction (FEC) building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. This document obsoletes RFC3450. "Basic Forward Error Correction (FEC) Schemes", Mark Watson, 23-Feb-07, This document provides FEC Scheme specifications according to the RMT FEC Building Block for the Compact No-Code FEC Scheme, the Small Block, Large Block and Expandable FEC Scheme, the Small Block Systematic FEC Scheme and the Compact FEC Scheme. "FLUTE - File Delivery over Unidirectional Transport", Toni Paila, 29-Jan-07, This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. "Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC) Schemes", Vincent Roca, 27-Dec-06, This document describes two Fully-Specified FEC Schemes, LDPC- Staircase and LDPC-Triangle, and their application to the reliable delivery of objects on packet erasure channels. These systematic FEC codes belong to the well known class of ``Low Density Parity Check'' (LDPC) codes, and are large block FEC codes in these sense of RFC3453. "Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol", Brian Adamson, 8-Mar-07, This document describes the messages and procedures of the Negative- acknowledgment (NACK) Oriented Reliable Multicast (NORM) protocol. This protocol is designed to provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal "a priori" coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher level transport protocols to utilize its service in different ways. The protocol leverages the use of FEC-based repair and other IETF reliable multicast transport (RMT) building blocks in its design. "Multicast Negative-Acknowledgment (NACK) Building Blocks", Brian Adamson, 27-Sep-06, This document discusses the creation of reliable multicast protocols utilizing negative-acknowledgment (NACK) feedback. The rationale for protocol design goals and assumptions are presented. Technical challenges for NACK-based (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of reliable multicast protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. "Reed-Solomon Forward Error Correction (FEC)", Jerome Lacan, 27-Dec-06, This document describes a Fully-Specified FEC scheme for the Reed- Solomon forward error correction code and its application to the reliable delivery of data objects on the packet erasure channel. Reed-Solomon codes belong to the class of Maximum Distance Separable (MDS) codes, i.e. they enable a receiver to recover the k source symbols from any set of k received symbols. The implementation described here is compatible with the implementation from Luigi Rizzo. Robust Header Compression (rohc) -------------------------------- "RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)", Ghyslain Pelletier, 2-Feb-07, This document specifies a ROHC (Robust Header Compression) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, provides efficient and robust compression of TCP headers, including frequently used TCP options such as SACK (Selective Acknowledgments) and Timestamps. ROHC-TCP works well when used over links with significant error rates and long round-trip times. For many bandwidth-limited links where header compression is essential, such characteristics are common. "Formal Notation for Robust Header Compression (ROHC-FN)", Ghyslain Pelletier, Robert Finking, 12-Dec-06, This document defines ROHC-FN (RObust Header Compression - Formal Notation): a formal notation to specify field encodings for compressed formats when defining new profiles within the ROHC framework. ROHC-FN offers a library of encoding methods that are often used in ROHC profiles and can thereby help simplifying future profile development work. "Implementer's Guide for SigComp", Abigail Surtees, 4-Jan-07, This document describes common misinterpretations and some ambiguities in the Signaling Compression Protocol (SigComp), and offers guidance to developers to resolve any resultant problems. SigComp defines a scheme for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP). This document (if approved) clarifies and corrects text in the following updated RFCs: RFC 3320, RFC 3321, RFC 3485. "Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)", Zhigang Liu, 5-Mar-07, This document describes some specifics that apply when Signaling Compression (SigComp) is applied to the Session Initiation Protocol (SIP), such as default minimum values of SigComp parameters, compartment and state management, and a few issues on SigComp over TCP. Any implementation of SigComp for use with SIP must conform to this document, in addition to SigComp and support of the SIP and Session Description Protocol (SDP) static dictionary. "Integration of Header Compression over IPsec Security Associations", Emre Ertekin, 26-Feb-07, IP Security (IPsec) [IPSEC] provides various security services for IP traffic. However, the benefits of IPsec come at the cost of increased overhead. This document outlines a framework for integrating Header Compression (HC) over IPsec (HCoIPsec). By compressing the inner headers of IP packets, HCoIPsec proposes to reduce the amount of overhead associated with the transmission of traffic over IPsec Security Associations (SAs). "The RObust Header Compression (ROHC) Framework", Lars-Erik Jonsson, 30-Nov-06, The RObust Header Compression (ROHC) protocol provides an efficient, flexible and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics. The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095. To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework separately, and thus replaces the framework specification of RFC 3095. "RObust Header Compression Version 2 (RoHCv2): Profiles for RTP, UDP, IP, ESP and UDP Lite", Ghyslain Pelletier, Kristofer Sandlund, 7-Sep-06, This document specifies ROHC (Robust Header Compression) profiles that efficiently compress RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), RTP/UDP-Lite/IP (User Datagram Protocol Lite), UDP/IP, UDP-Lite/IP, IP and ESP/IP (Encapsulating Security Payload) headers. This specification update the profiles defined in RFC 3095, RFC 3843 and RFC 4019 to their second version (RoHCv2 profiles). The profiles herein thus supersede their earlier definition, but they do not obsolete them. The RoHCv2 specification introduce a number of simplifications to the rules and algorithms that govern the behavior of the compression endpoints. It also defines robustness mechanisms that may be used by a compressor implementation to increase the probability of decompression success when packets can be lost and/or reordered on the ROHC channel. Finally, the RoHCv2 profiles define its own specific set of packet formats, using the ROHC formal notation. "IKEv2 Extensions to Support Header Compression over IPsec (HCoIPsec)", Rohan Jasani, 26-Feb-07, When using Header Compression (HC) schemes (e.g. ROHC [ROHC]) in conjunction with IPsec [IPSEC] (i.e. [HCOIPSEC]) a mechanism is needed to negotiate ROHC configuration parameters between end-points prior to operation. Internet Key Exchange (IKE) is a mechanism which can be leveraged to handle these negotiations. This document specifies extensions to Internet Key Exchange (IKEv2 [IKEV2]) that will allow ROHC and its associated configuration parameters to be negotiated for IPsec security associations (SAs). Routing Protocol Security Requirements (rpsec) ---------------------------------------------- "BGP Security Requirements", Blaine Christian, Tony Tauber, 14-Feb-07, The security of BGP, the Border Gateway Protocol, is critical to the proper operation of large-scale internetworks, both public and private. While securing the information transmitted between two BGP speakers is a relatively easy technical matter, securing BGP, as a routing system, is more complex. This document describes a set of requirements for securing BGP, including communications between BGP speakers, and the routing information carried within BGP. Reliable Server Pooling (rserpool) ---------------------------------- "Architecture for Reliable Server Pooling", Michael Tuexen, 15-Nov-06, This document describes an architecture and protocols for the management and operation of server pools supporting highly reliable applications, and for client access mechanisms to a server pool. "Comparison of Protocols for Reliable Server Pooling", John Loughney, 21-Nov-06, This document compares protocols that may be applicable for the Reliable Server Pooling problem space. This document discusses the usage and applicability of these protocols for the Reliable Server Pooling architecture. "Aggregate Server Access Protocol (ASAP)", Randall Stewart, 11-Jan-07, Aggregate Server Access Protocol (ASAP) in conjunction with the Endpoint Handlespace Redundancy Protocol (ENRP) [8] provides a high availability data transfer mechanism over IP networks. ASAP uses a handle-based addressing model which isolates a logical communication endpoint from its IP address(es), thus effectively eliminating the binding between the communication endpoint and its physical IP address(es) which normally constitutes a single point of failure. In addition, ASAP defines each logical communication destination as a pool, providing full transparent support for server-pooling and load sharing. It also allows dynamic system scalability - members of a server pool can be added or removed at any time without interrupting the service. ASAP is designed to take full advantage of the network level redundancy provided by the Stream Transmission Control Protocol (SCTP) RFC2960 [4]. Each transport protocol, other than SCTP, MUST have an accompanying transport mapping document. It should be noted that ASAP messages passed between PE's and ENRP servers MUST use the SCTP transport protocol. The high availability server pooling is gained by combining two protocols, namely ASAP and ENRP, in which ASAP provides the user interface for pool handle to address translation, load sharing management, and fault management while ENRP defines the high availability pool handle translation service. "Endpoint Handlespace Redundancy Protocol (ENRP)", Randall Stewart, 5-Jan-07, Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work in conjunction with the Aggregate Server Access Protocol (ASAP) to accomplish the functionality of the Reliable Server Pooling (Rserpool) requirements and architecture. Within the operational scope of Rserpool, ENRP defines the procedures and message formats of a distributed, fault-tolerant registry service for storing, bookkeeping, retrieving, and distributing pool operation and membership information. "Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters", Randall Stewart, 19-Oct-06, This document details the parameters of the Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) protocols defined within the Reliable Server Pooling (RSERPOOL) architecture. "Threats Introduced by Rserpool and Requirements for Security in response to Threats", Maureen Stillman, 16-Nov-06, Rserpool is an architecture and set of protocols for the management and access to server pools supporting highly reliable applications and for client access mechanisms to a server pool. This Internet draft describes security threats to the Rserpool architecture and presents requirements for security to thwart these threats. "Reliable Server Pooling Policies", Michael Tuexen, Thomas Dreibholz, 7-Mar-07, This document describes server pool policies for Reliable Server Pooling including considerations for implementing them at ENRP servers and pool users. "An Overview of Reliable Server Pooling Protocols", Peter Lei, 17-Oct-06, The Reliable Server Pooling effort (abbreviated "RSerPool"), provides an application-independent set of services and protocols for building fault tolerant and highly available client/server applications. This document provides an overview of the protocols and mechanisms in the reliable server pooling suite. Routing Area Working Group (rtgwg) ---------------------------------- "The Generalized TTL Security Mechanism (GTSM)", Vijay Gill, 31-Jan-07, The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify whether the packet was originated by an adjacent node on a connected link has been used in many recent protocols. This document generalizes this technique. This document obsoletes RFC 3682. "IP Fast Reroute Framework", Mike Shand, Stewart Bryant, 20-Oct-06, This document provides a framework for the development of IP fast-reroute mechanisms which provide protection against link or router failure by invoking locally determined repair paths. Unlike MPLS Fast-reroute, the mechanisms are applicable to a network employing conventional IP routing and forwarding. An essential part of such mechanisms is the prevention of packet loss caused by the loops which normally occur during the re-convergence of the network following a failure. "Basic Specification for IP Fast-Reroute: Loop-free Alternates", Alia Atlas, Alex Zinin, 5-Mar-07, This document describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS/LDP networks in the event of a single failure, whether link, node or shared risk link group (SRLG). The goal of this technology is to reduce the micro-looping and packet loss that happens while routers converge after a topology change due to a failure. Rapid failure repair is achieved through use of precalculated backup next-hops that are loop- free and safe to use until the distributed network convergence process completes. "Loop-free convergence using oFIB", Pierre Francois, 12-Dec-06, This draft describes a mechanism for use in conjunction with link state routing protocols which prevents the transient loops which would otherwise occur during topology changes. It does this by correctly sequencing the FIB updates on the routers. This mechanism can be used in the case of non-urgent link or node shutdowns and restarts or link metric changes. It can also be used in conjunction with a FRR mechanism which converts a sudden link or node failure into a non-urgent topology change. This is possible where a complete repair path is provided for all affected destinations. After a non-urgent topology change, each router computes a rank that defines the time at which it can safely update its FIB. A method for accelerating this loop-free convergence process by the use of completion messages is also described. "IP Fast Reroute Using Not-via Addresses", Stewart Bryant, 13-Dec-06, This draft describes a mechanism that provides fast reroute in an IP network through encapsulation to "not-via" addresses. A single level of encapsulation is used. The mechanism protects unicast, multicast and LDP traffic against link, router and shared risk group failure, regardless of network topology and metrics. "A Framework for Loop-free Convergence", Stewart Bryant, Mike Shand, 13-Dec-06, This draft describes mechanisms that may be used to prevent or to suppress the formation of micro-loops when an IP or MPLS network undergoes topology change due to failure, repair or management action. Simple Authentication and Security Layer (sasl) ----------------------------------------------- "Using Digest Authentication as a SASL Mechanism", Alexey Melnikov, 5-Mar-07, This specification defines how HTTP Digest Authentication (RFC 2617) can be used as a Simple Authentication and Security Layer (SASL, RFC 4422) mechanism for any protocol that has a SASL profile. It is intended both as an improvement over CRAM-MD5 (RFC 2195) and as a convenient way to support a single authentication mechanism for web, mail, LDAP, and other protocols. "The CRAM-MD5 SASL Mechanism", Lyndon Nerenberg, 7-Mar-07, This document defines a simple challenge-response authentication mechanism, using a keyed MD5 digest, for use with the Simple Authentication and Security Layer (SASL). "Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family", Simon Josefsson, 1-Mar-07, This document describes how to use a Generic Security Service Application Program Interface (GSS-API) mechanism in the the Simple Authentication and Security Layer (SASL) framework. This is done by defining a new SASL mechanism family, called GS2. This mechanism family offers a number of improvements over the previous SASL/GSS-API mechanism: it is more general, uses fewer messages for the authentication phase in some cases, and supports a SASL-specific notion of channel binding. See for more information. Secure Shell (secsh) -------------------- "Secure Shell Public-Key Subsystem", Joseph Galbraith, 6-Oct-06, Secure Shell defines a user authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration. The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user. A public key may also be associated with various restrictions, including a mandatory command or subsystem. Site Multihoming by IPv6 Intermediation (shim6) ----------------------------------------------- "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", Jari Arkko, Iljitsch van Beijnum, 13-Dec-06, This document specifies how the level 3 multihoming shim protocol (SHIM6) detects failures between two communicating hosts. It also specifies an exploration protocol for switching to another pair of interfaces and/or addresses between the same hosts if a failure occurs and an operational pair can be found. "Applicability Statement for the Level 3 Multihoming Shim Protocol (Shim6)", Marcelo Bagnulo, Joe Abley, 25-Oct-06, This document discusses the applicability of the shim6 IPv6 protocol element and associated support protocols to provide site multihoming capabilities in IPv6. "Hash Based Addresses (HBA)", Marcelo Bagnulo, 19-Oct-06, This memo describes a mechanism to provide a secure binding between the multiple addresses with different prefixes available to a host within a multihomed site. The main idea is that information about the multiple prefixes is included within the addresses themselves. This is achieved by generating the interface identifiers of the addresses of a host as hashes of the available prefixes and a random number. Then, the multiple addresses are generated by prepending the different prefixes to the generated interface identifiers. The result is a set of addresses, called Hash Based Addresses (HBAs), that are inherently bound. "Level 3 multihoming shim protocol", Marcelo Bagnulo, Erik Nordmark, 6-Dec-06, The SHIM6 protocol is a layer 3 shim for providing locator agility below the transport protocols, so that multihoming can be provided for IPv6 with failover and load sharing properties, without assuming that a multihomed site will have a provider independent IPv6 address prefix which is announced in the global IPv6 routing table. The hosts in a site which has multiple provider allocated IPv6 address prefixes, will use the shim6 protocol specified in this document to setup state with peer hosts, so that the state can later be used to failover to a different locator pair, should the original one stop working. "Default Locator-pair selection algorithm for the SHIM6 protocol", Marcelo Bagnulo, 23-Oct-06, In this note, we present a locator-pair selection mechanism for the shim6 protocol. The presented mechanism provides an ordered list of available locator-pairs that can be used for outgoing traffic. "Ingress filtering compatibility for IPv6 multihomed sites", Christian Huitema, Marcelo Bagnulo, 9-Oct-06, The note presents a set of mechanisms to provide ingress filtering compatibility for legacy hosts in IPv6 multihomed sites. "Socket Application Program Interface (API) for Multihoming Shim", Miika Komu, 8-Mar-07, This document specifies a socket API for the multihoming shim layer. The API aims to enable interactions between the applications and the multihoming shim layer for advanced locator management and access to information about failure detection and path exploration. This document is based on an assumption that a multhomed host is equipped with a conceptual sublayer (here after "shim") inside the IP layer that maintains mappings between identifiers and locators. Examples of the shim are SHIM6 and HIP. Secure Inter-Domain Routing (sidr) ---------------------------------- "A Profile for X.509 PKIX Resource Certificates", Geoff Huston, 26-Feb-07, This document defines a standard profile for X.509 certificates for the purposes of supporting validation of assertions of "right-to-use" of an Internet Number Resource (IP Addresses and Autonomous System Numbers). This profile is used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of- use" of the IP addresses and AS numbers that are described in the associated Resource Certificate. "Certificate Policy (CP) for the Internet IP Address and AS Number (PKI)", Karen Seo, 27-Feb-07, This document describes the certificate policy for a PKI used to support improved routing security. Each organization that allocates IP addresses or Autonomous System (AS) numbers to an organization will, in parallel, issue a certificate reflecting this allocation. These certificates will enable verification that the holder of the associated private key has been allocated the resources indicated in the certificate, and is the current, unique holder of these resources. The PKI in which the certificates issued under this policy are employed, in conjunction with ancillary digitally signed data structures, will provide critical inputs for routing security mechanisms, e.g., generation of route filters by ISPs. "Template for an Internet Registry's Certification Practice Statement (CPS) for the Internet IP Address and AS Number (PKI)", Stephen Kent, 1-Mar-07, This document contains a template to be used for creating a Certification Practice Statement (CPS) for an Internet Registry (e.g., NIR or RIR) that is part of the Internet IP Address and Autonomous System (AS) Number Public Key Infrastructure (PKI). "Template for an Internet Service Provider's Certification Practice Statement (CPS) for the Internet IP address and AS Number PKI", Dennis Kong, 6-Mar-07, This document contains a template to be used for creating a Certification Practice Statement (CPS) for a Local Internet Registry (LIR) or Internet Service Provider (ISP) that is part of the Internet IP Address and Autonomous System (AS) Number Public Key Infrastructure (PKI). "A Profile for Route Origin Authorizations (ROA)", Stephen Kent, Dennis Kong, 28-Feb-07, This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to that address block. "An Infrastructure to Support Secure Internet Routing", Russ Barnes, Stephen Kent, 28-Feb-07, This document describes an architecture for an infrastructure to support secure Internet routing. The foundation of this architecture is a public key infrastructure (PKI) that represents the allocation hierarchy of IP address space and Autonomous System Numbers; certificates from this PKI are used to verify signed objects that authorize autonomous systems to originate routes for specified IP address prefixes. The data objects that comprise the PKI, as well as other signed objects necessary for secure routing, are stored and disseminated through a distributed repository system. This document also describes at a high level how this architecture can be used to add security features to common operations such as IP address space allocation and route filter construction. Sieve Mail Filtering Language (sieve) ------------------------------------- "Sieve Extension: Variables", Kjetil Homme, 20-Dec-05, In advanced mail filtering rule sets, it is useful to keep state or configuration details across rules. This document updates the Sieve filtering language (RFC 3028) with an extension to support variables. The extension changes the interpretation of strings, adds an action to store data in variables, and supplies a new test so that the value of a string can be examined. "SIEVE Email Filtering: Spamtest and Virustest Extensions", Cyrus Daboo, 13-Jul-06, The SIEVE email filtering language "spamtest", "spamtestplus" and "virustest" extensions permit users to use simple, portable commands for spam and virus tests on email messages. Each extension provides a new test using matches against numeric "scores". It is the responsibility of the underlying SIEVE implementation to do the actual checks that result in proper input to the tests. "Sieve Email Filtering: Body Extension", Philip Guenther, Jutta Degener, 26-Feb-07, This document defines a new command for the "Sieve" email filtering language that tests for the occurrence of one or more strings in the body of an email message. "Sieve Email Filtering: Editheader Extension", Philip Guenther, Jutta Degener, 6-Mar-07, This document defines two new actions for the "Sieve" email filtering language that add and delete email header fields. "SIEVE Email Filtering: IMAP flag Extension", Alexey Melnikov, 12-May-06, Recent discussions have shown that it is desirable to set different IMAP (RFC 3501) flags on message delivery. This can be done, for example, by a Sieve interpreter that works as a part of a Mail Delivery Agent. This document describes an extension to the Sieve mail filtering language for setting IMAP flags. The extension allows to set both IMAP system flags and IMAP keywords. "Sieve Email Filtering -- Subaddress Extension", Ken Murchison, 16-Jun-06, On email systems that allow for 'subaddressing' or 'detailed addressing' (e.g., "ken+sieve@example.org"), it is sometimes desirable to make comparisons against these sub-parts of addresses. This document defines an extension to the Sieve mail filtering language that allows users to compare against the user and detail sub-parts of an address. "Sieve Extension: Relational Tests", Wolfgang Segmuller, Barry Leiba, 28-Dec-05, This document describes the RELATIONAL extension to the Sieve mail filtering language defined in RFC 3028. This extension extends existing conditional tests in Sieve to allow relational operators. In addition to testing their content, it also allows for testing of the number of entities in header and envelope fields. "Sieve Email Filtering: Vacation Extension", Tim Showalter, Ned Freed, 5-Mar-07, This document describes an extension to the Sieve email filtering language for an autoresponder similar to that of the Unix "vacation" command for replying to messages. Various safety features are included to prevent problems such as message loops. "Sieve: An Email Filtering Language", Tim Showalter, Philip Guenther, 15-Feb-07, This document describes a language for filtering email messages at time of final delivery. It is designed to be implementable on either a mail client or mail server. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system. It is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black box Internet Message Access Protocol (IMAP) servers, as the base language has no variables, loops, or ability to shell out to external programs. "The SIEVE mail filtering language - reject extension", Matthew Elvey, Alexey Melnikov, 19-Oct-06, This memo updates the definition the SIEVE mail filtering language (RFC <<3028bis>>) "reject" extension, originally defined in RFC 3028. A Joe-job is a spam run forged to appear as though it came from an innocent party, who is then generally flooded by the bounces, Message Disposition Notifications (MDNs) and messages with complaints. The original Sieve "reject" action defined in RFC 3028 required use of MDNs for rejecting messages, thus contributing to the flood of Joe-job spam to victims of Joe-jobs. This document updates the definition of "reject" to require rejecting messages during the SMTP transaction (instead of accepting them and then sending MDNs back to the alleged sender) wherever possible, thereby reducing the problem. "Sieve Extension: Notifications", Alexey Melnikov, 21-Feb-07, Users go to great lengths to be notified as quickly as possible that they have received new mail. Most of these methods involve polling to check for new messages periodically. A push method handled by the final delivery agent gives users quicker notifications and saves server resources. This document does not specify the notification method but it is expected that using existing instant messaging infrastructure such as XMPP, or SMS messages will be popular. This draft describes an extension to the Sieve mail filtering language that allows users to give specific rules for how and when notifications should be sent. "Sieve Notification Mechanism: mailto", Barry Leiba, Michael Haardt, 8-Mar-07, This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent by electronic mail. "Sieve Notification Mechanism: xmpp", Peter Saint-Andre, Alexey Melnikov, 6-Mar-07, This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over the Extensible Messaging and Presence Protocol (XMPP), also known as Jabber. "SIEVE Email Filtering: MIME part Tests, Iteration, Replacement and Enclosure", Tony Hansen, Cyrus Daboo, 24-Oct-06, The SIEVE email filtering language has no way to examine individual MIME parts or any way to manipulate those individual parts. However, being able to filter based on MIME content is important. This document defines extensions for these needs. Signaling Transport (sigtran) ----------------------------- "SUA Implementor's guide", Lode Coene, John Loughney, 10-Nov-06, This document contains a compilation of all defects found up until the publication date for SUA [RFC3868] [1]. These defects may be of an editorial or technical nature. This document may be thought of as a companion document to be used in the implementation of SUA to clarify errors in the original SUA document. This document updates RFC3868 and text within this document supersedes the text found in RFC3868. SIP for Instant Messaging and Presence Leveraging Extensions (simple) --------------------------------------------------------------------- "The Message Session Relay Protocol", Ben Campbell, 26-Feb-07, This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol. "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", Jonathan Rosenberg, 13-Oct-06, This specification defines the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP allows a client to read, write and modify application configuration data, stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP. "Extensible Markup Language (XML) Formats for Representing Resource Lists", Jonathan Rosenberg, 9-Feb-05, In multimedia communications, presence and instant messaging systems, there is a need to define Uniform Resource Identifiers (URIs) that represent services which are associated with a group of users. One example is a resource list service. If a user sends a Session Initiation Protocol (SIP) SUBSCRIBE message to the URI representing the resource list service, the server will obtain the state of the users in the associated group, and provide it to the sender. To facilitate definition of these services, this specification defines two Extensible Markup Language (XML) documents. One document contains service URIs, along with their service definition and a reference to the associated group of users. The second document contains the user lists which are referenced from the first. Both documents can be created and managed with the XML Configuration Access Protocol (XCAP). " Session Initiation Protocol (SIP) extension for Partial Notification of Presence Information", Mikko Lonnfors, 27-Feb-07, By default, presence delivered using the Presence Event Package for the Session Initiation Protocol (SIP) is represented in the Presence Information Data Format (PIDF). A PIDF document contains a set of elements, each representing a different aspect of the presence being reported. When any subset of the elements change, even just a single element, a new document containing the full set of elements is delivered. This memo defines an extension allowing delivery of only the presence data that has actually changed. "Presence Information Data format (PIDF) Extension for Partial Presence", Mikko Lonnfors, 15-Nov-06, The Presence Information Document Format (PIDF) specifies the baseline XML based format for describing presence information. One of the characteristic of the PIDF is that the document always needs to carry all presence information available for the presentity. In some environments where low bandwidth and high latency links can exist it is often beneficial to limit the amount of transported information over the network. This document introduces a new MIME type which enables transporting of either only the changed parts or the full PIDF based presence information. "Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF)", Mikko Lonnfors, Krisztian Kiss, 31-Jul-06, Presence Information Data Format (PIDF) defines a common presence data format for Common Profile for Presence (CPP) compliant Presence protocols. This memo defines an extension to represent SIP User Agent capabilities in the Presence Information Document Format (PIDF) compliant presence documents. "Presence Authorization Rules", Jonathan Rosenberg, 1-Mar-07, Authorization is a key function in presence systems. Authorization policies, also known as authorization rules, specify what presence information can be given to which watchers, and when. This specification defines an Extensible Markup Language (XML) document format for expressing presence authorization rules. Such a document can be manipulated by clients using the XML Configuration Access Protocol (XCAP), although other techniques are permitted. "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents", Markus Isomaki, 22-Oct-04, This document describes a usage of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) for manipulating the contents of Presence Information Data Format (PIDF) based presence document. It is mainly intended to be used in Session Initiation Protocol (SIP) based presence systems, where the Event State Compositor can use the XCAP-manipulated presence document as one of the inputs based on which it builds the overall presence state for the presentity. "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", Cullen Jennings, 29-Dec-06, Two separate models for conveying instant messages have been defined. Page-mode messages stand alone and are not part of a SIP (Session Initiation Protocol) session, whereas Session-mode messages are set up as part of a session using the SIP protocol. MSRP (Message Session Relay Protocol) is a protocol for near real-time, peer-to- peer exchanges of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP. This document introduces the notion of message relay intermediaries to MSRP and describes the extensions necessary to use them. "Publication of Partial Presence Information", Mikko Lonnfors, 7-Feb-07, The Session Initiation Protocol (SIP) Extension for Event State Publication describes a mechanism with which a presence user agent is able to publish presence information to a presence agent. Using the Presence Information Data Format (PIDF), each presence publication contains full state, regardless of how much of that information has actually changed since the previous update. As a consequence, updating a sizeable presence document with small changes bears a considerable overhead and is therefore inefficient. Especially with low bandwidth and high latency links, this can constitue a considerable burden to the system. This memo defines a solution that aids in reducing the impact of those constraints and increases transport efficiency by introducing a mechanism that allows for publication of partial presence information. "An Extensible Markup Language (XML) Document Format for Indicating A Change in XML Configuration Access Protocol (XCAP) Resources", Jonathan Rosenberg, 8-Mar-07, This specification defines a document format that can be used to indicate that a change has occurred in a document managed by the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). This format indicates the document that has changed and its former and new entity tags. It also can indicate the specific change that was made in the document, using an XML patch format. XCAP diff documents can be delivered to clients using a number of means, including a Session Initiation Protocol (SIP) event package. "An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors", Jari Urpalainen, 8-Mar-06, Extensible Markup Language (XML) documents are widely used as containers for the exchange and storage of arbitrary data in today's systems. Updates to this data require transporting of the entire XML document between hosts, unless there's a mechanism that allows exchanging only the updates of XML documents. This document describes an XML patch framework utilizing XML Path language (XPath) selectors. These selector values and updated new data content constitute the basis of patch operations described in this document. In addition to them, with basic , and directives a set of patches can then be applied to update an existing XML document. "Instant Message Disposition Notification", Eric Burger, Hisham Khartabil, 7-Feb-07, Instant Messaging (IM) refers to the transfer of messages between users in real-time. This document provides a mechanism whereby endpoints can request Instant Message Disposition Notifications (IMDN), including delivery, processing and read notifications, for page-mode instant messages. The Common Profile for Instant Messaging (CPIM) data format specified in RFC 3862 is extended with new header fields that enable endpoints to request IMDNs. A new message format is also defined to convey IMDNs. This document also describes how SIP entities behave using this extension. "Problem Statement for SIP/SIMPLE", Avshalom Houri, 27-Feb-07, The document analyses the traffic that is generated due to presence subscriptions between domains. It is shown that the amount of traffic can be extremely big. In addition to the very large traffic the document also analyses the affects of a large presence system on the memory footprint and the CPU load. Several suggested optimization to the SIMPLE protocol are analysed with the possible impact on the load. Session Initiation Protocol (sip) --------------------------------- "Management Information Base for the Session Initiation Protocol (SIP)", Dave Walker, 18-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 a set of managed objects that are used to manage Session Initiation Protocol (SIP) entities, which include User Agents, Proxy, Redirect and Registrar servers. "Connection Reuse in the Session Initiation Protocol (SIP)", Rohan Mahy, 19-Oct-06, When SIP entities use a connection oriented protocol to send a request, they typically originate their connections from an ephemeral port. The SIP protocol includes mechanisms which ensure that responses to a request, and new requests sent in the original direction reuse an existing connection. However, new requests sent in the opposite direction are unlikely to reuse the existing connection. For TLS transports, this will frequently cause a pair of SIP entities to use one connection for requests sent in each direction, resulting in potential scaling and performance problems. This document proposes that a TLS connection, once opened, can be used to send requests in either direction. Unfortunately, TCP connections cannot be shared in the same manner due to the risk of service hijacking. This document proposes an alternate way to perform TCP connection reuse. "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 8-Mar-07, Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI that can be used by anyone on the Internet to route a call to that specific UA instance. A URI that routes to a specific UA instance is called a Globally Routable UA URI (GRUU). This document describes an extension to SIP for obtaining a GRUU from a registrar and for communicating a GRUU to a peer within a dialog. "Session Initiation Protocol Location Conveyance", James Polk, Brian Rosen, 13-Feb-07, This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The extension covers end to end conveyance as well as location-based routing, where proxy servers make routing decisions based on the location of the UAC. "End-to-middle Security in the Session Initiation Protocol (SIP)", Kumiko Ono, Shinya Tachimoto, 7-Mar-07, Some services provided by intermediaries depend on their ability to inspect a message body in the Session Initiation Protocol (SIP). When sensitive information is included in the message body, a SIP User Agent (UA) needs to protect it from other intermediaries than those that the UA agreed to disclose it to. This document proposes a mechanism for securing information passed between an end user and intermediaries using S/MIME. It also proposes mechanisms for a UA to discover intermediaries which need to inspect an S/MIME-secured message body, or to receive the message body with data integrity This specification is approved at the proposed standards level due to the IANA registration requirements. Is is of sufficient quality for that level, however, the use of this mechanism in this specification are considered experimental. "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", Cullen Jennings, Rohan Mahy, 6-Mar-07, The Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections and send asynchronous UDP datagrams to User Agents in order to deliver requests. However, many practical considerations, such as the existence of firewalls and Network Address Translators (NATs), prevent servers from connecting to User Agents in this way. This specification defines behaviors for User Agents, registrars and proxy servers that allow requests to be delivered on existing connections established by the User Agent. It also defines keep alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections. "Requesting Answering Modes for the Session Initiation Protocol (SIP)", Dean Willis, Andrew Allen, 5-Mar-07, This document defines two SIP extension header fields and associated option tags that can be used in INVITE requests to convey the requester's preference for user-interface handling related to answering of that request. The first header, "Answer-Mode", expresses a preference as to whether the target node's user interface waits for user input before accepting the request or instead accepts the request without waiting on user input. The second header, "Priv- Answer-Mode" is similar to the first, except that it requests administrative-level access and has consequent additional authentication and authorization requirements. These behaviors have applicability to applications such as Push-to-Talk and to diagnostics like loop-back. Usage of each header field in a response to indicate how the request was handled is also defined. "Rejecting Anonymous Requests in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 1-Mar-07, The Session Initiation Protocol (SIP) allows for users to make anonymous calls. However, users receiving such calls have the right to reject them because they are anonymous. SIP has no way to indicate to the caller that the reason for call rejection was that the call was anonymous. Such an indication is useful to allow the call to be retried without anonymity. This specification defines a new SIP response code for this purpose. "Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies", Robert Sparks, 23-Oct-06, This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address a security vulnerability identified in SIP proxy behavior. This vulnerability enables an attack against SIP networks where a small number of legitimate, even authorized, SIP requests can stimulate massive amounts of proxy-to-proxy traffic. This document strengthens loop-detection requirements on SIP proxies when they fork requests (that is, forward a request to more than one destination). It also corrects and clarifies the description of the loop-detection algorithm such proxies are required to implement. "Connected Identity in the Session Initiation Protocol (SIP)", John Elwell, 27-Feb-07, This document provides a means for a Session Initiation Protocol (SIP) User Agent (UA) that receives a dialog-forming request to supply its identity to the peer UA by means of a request in the reverse direction and for that identity to be signed by an Authentication Service. Because of retargeting of a dialog-forming request (changing the value of the Request-URI), the UA that receives it (the User Agent Server, UAS) can have a different identity from that in the To header field. The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in the Public Switched Telephone Network (PSTN) behind a gateway. This document normatively updates RFC 3261 (SIP). "Certificate Management Service for The Session Initiation Protocol (SIP)", Cullen Jennings, 6-Mar-07, This draft defines a Credential Service that allows Session Initiation Protocol (SIP) User Agents (UAs) to use a SIP package to discover the certificates of other users. This mechanism allows user agents that want to contact a given Address-of-Record (AOR) to retrieve that AOR's certificate by subscribing to the Credential Service, which returns an authenticated response containing that certificate. The Credential Service also allows users to store and retrieve their own certificates and private keys. "SIP SAML Profile and Binding", Hannes Tschofenig, 26-Oct-06, This document specifies a Session Initiation Protocol (SIP) profile of Security Assertion Markup Language (SAML) as well as a SAML SIP binding. The defined SIP SAML Profile composes with the mechanisms defined in the SIP Identity specification and satisfy requirements presented in "Trait-based Authorization Requirements for the Session Initiation Protocol (SIP)". "A Hitchhiker's Guide to the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 8-Mar-07, The Session Initiation Protocol (SIP) is the subject of numerous specifications that have been produced by the IETF. It can be difficult to locate the right document, or even to determine the set of Request for Comments (RFC) about SIP. This specification serves as a guide to the SIP RFC series. It lists the specifications under the SIP umbrella, briefly summarizes each, and groups them into categories. "A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 27-Nov-06, The Session Initiation Protocol (SIP) supports communications across many media types, including real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including amplification, and DoS (Denial of Service) attacks. This document identifies a framework for consent- based communications in SIP. "Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, 26-Jan-07, This document specifies a way to create subscription to a list of resources in SIP. This is achieved by including the list of resources in the body of a SUBSCRIBE request. Instead of having a subscriber send a SUBSCRIBE request for each resource individually, the subscriber defines the resource list, subscribes to it, and gets notifications about changes in the resources' state using a single SUBSCRIBE dialog. "Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)", Miguel Garcia-Martin, Gonzalo Camarillo, 8-Jan-07, This document specifies a mechanism that allows a SIP User Agent Client (UAC) to request a SIP URI-list (Uniform Resource Identifier list) service to send a SIP MESSAGE request to a set of destinations. The client sends a SIP MESSAGE request that includes the payload along with the URI-list to the MESSAGE URI-list service, which sends a similar MESSAGE request to each of the URIs included in the list. "Referring to Multiple Resources in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, 8-Jan-07, This document defines extensions to the SIP REFER method so that this method can be used to refer servers to multiple resources. These extensions include the use of pointers to Uniform Resource Identifier (URI)-lists in the Refer-To header field and the "multiple-refer" SIP option-tag. "Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, Alan Johnston, 26-Jan-07, This document describes how to create a conference using SIP URI-list services. In particular, it describes a mechanism that allows a user agent client to provide a conference server with the initial list of participants using an INVITE-contained URI-list. "Extensions to the Session Initiation Protocol (SIP) User Agent Profile Delivery Change Notification Event Package for the Extensible Markup Language Language Configuration Access Protocol (XCAP)", Daniel Petrie, 16-Oct-06, The SIP User Agent profile delivery framework describes how a User Agent can retrieve its data using a variety of protocols and defines a SIP event package for notifications of changes to those profiles. This document extends that event package to support XCAP (XML Configuration Access Protocol). "A Framework for Session Initiation Protocol (SIP) Session Policies", Volker Hilt, 13-Feb-07, Proxy servers play a central role as an intermediary in the Session Initiation Protocol (SIP) as they define and impact policies on call routing, rendezvous, and other call features. This document specifies a framework for SIP session policies that provides a standard mechanism by which a proxy can define or influence policies on sessions, such as the codecs or media types to be used. It defines a model, an overall architecture and new protocol mechanisms for session policies. "Guidelines for the use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", Francois Audet, 5-Mar-07, This document providing clarifications and guidelines concerning the use of SIPS URI scheme in the Session Initiation Protocol (SIP). It does not make normative changes to SIP. This document also provides discussion of possible future steps in specification, and the pros and cons of making such changes. "Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 8-Mar-07, This specification defines a media feature tag and an option tag for use with the Session Initiation Protocol (SIP). The media feature tag allows a UA to communicate to its registrar that it supports ICE. The option tag allows a User Agent (UA) to require support for ICE in order for a call to proceed. Session Initiation Proposal Investigation (sipping) --------------------------------------------------- "Session Initiation Protocol Service Examples", Alan Johnston, 24-Jan-07, This document gives examples of Session Initiation Protocol (SIP) services. This covers most features offered in so-called IP Centrex offerings from local exchange carriers and PBX (Private Branch Exchange) features. Most of the services shown in this document are implemented in the SIP User Agents, although some require the assistance of a SIP Proxy. Some require some extensions to SIP including the REFER, SUBSCRIBE, and NOTIFY methods and the Replaces and Join header fields. These features are not intended to be an exhaustive set, but rather show implementations of common features likely to be implemented on SIP IP telephones in a business environment. "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", Rohan Mahy, 7-Mar-07, This document defines a framework and requirements for multi-party usage of SIP. To enable discussion of multi-party features and applications we define an abstract call model for describing the media relationships required by many of these. The model and actions described here are specifically chosen to be independent of the SIP signaling and/or mixing approach chosen to actually setup the media relationships. In addition to its dialog manipulation aspect, this framework includes requirements for communicating related information and events such as conference and session state, and session history. This framework also describes other goals that embody the spirit of SIP applications as used on the Internet. "Best Current Practices for NAT Traversal for SIP", Chris Boulton, 2-Mar-07, Traversal of the Session Initiation Protocol (SIP) and the sessions it establishes through Network Address Translators (NAT) is a complex problem. Currently there are many deployment scenarios and traversal mechanisms for media traffic. This document aims to provide concrete recommendations and a unified method for NAT traversal as well as documenting corresponding call flows. "Session Initiation Protocol Call Control - Transfer", Robert Sparks, 19-Oct-06, This document describes providing Call Transfer capabilities in the Session Initiation Protocol (SIP). SIP extensions such as REFER and Replaces are used to provide a number of transfer services including blind transfer, consultative transfer, and attended transfer. This work is part of the SIP multiparty call control framework. "A Framework for Session Initiation Protocol User Agent Profile Delivery", Dan Petrie, Sumanth Channabasappa, 6-Mar-07, This document defines a framework to enable configuration of Session Initiation Protocol (SIP) User Agents in SIP deployments. The framework provides a means to deliver profile data that User Agents need to be functional, automatically and with minimal (preferably none) User and Administrative intervention. The framework describes how SIP User Agents can discover sources, request profiles and receive notifications related to profile modifications. As part of this framework, a new SIP event package is defined for notification of profile changes. The framework provides for multiple data retrieval options, without requiring or defining retrieval protocols. The framework does not include specification of the profile data within its scope. "A Framework for Application Interaction in the Session Initiation Protocol (SIP)", Jonathan Rosenberg, 20-Jul-05, This document describes a framework for the interaction between users and Session Initiation Protocol (SIP) based applications. By interacting with applications, users can guide the way in which they operate. The focus of this framework is stimulus signaling, which allows a user agent to interact with an application without knowledge of the semantics of that application. Stimulus signaling can occur to a user interface running locally with the client, or to a remote user interface, through media streams. Stimulus signaling encompasses a wide range of mechanisms, ranging from clicking on hyperlinks, to pressing buttons, to traditional Dual Tone Multi Frequency (DTMF) input. In all cases, stimulus signaling is supported through the use of markup languages, which play a key role in this framework. "Framework for Transcoding with the Session Initiation Protocol (SIP)", Gonzalo Camarillo, 1-Dec-06, This document defines a framework for transcoding with SIP. This framework includes how to discover the need for transcoding services in a session and how to invoke those transcoding services. Two models for transcoding services invocation are discussed: the conference bridge model and the third party call control model. Both models meet the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing, and speech-impaired individuals. "Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services", Gonzalo Camarillo, Adam Roach, 24-Sep-06, This document describes the need for SIP URI-list services and provides requirements for their invocation. Additionaly, it defines a framework for SIP URI-List services, which includes security considerations applicable to these services. "Framework for real-time text over IP using the Session Initiation Protocol (SIP)", Arnoud Van Wijk, Guido Gybels, 30-Aug-06, This document lists the essential requirements for real-time Text- over-IP (ToIP) and defines a framework for implementation of all required functions based on the Session Initiation Protocol (SIP) and the Real-Time Transport Protocol (RTP). This includes interworking between Text-over-IP and existing text telephony on the PSTN and other networks. "The Session Initiation Protocol (SIP) and Spam", Cullen Jennings, Jonathan Rosenberg, 28-Feb-07, Spam, defined as the transmission of bulk unsolicited messages, has plagued Internet email. Unfortunately, spam is not limited to email. It can affect any system that enables user to user communications. The Session Initiation Protocol (SIP) defines a system for user to user multimedia communications. Therefore, it is susceptible to spam, just as email is. In this document, we analyze the problem of spam in SIP. We first identify the ways in which the problem is the same and the ways in which it is different from email. We then examine the various possible solutions that have been discussed for email and consider their applicability to SIP. "The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model", Gonzalo Camarillo, 6-Jun-06, This document describes how to invoke transcoding services using the conference bridge model. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing and speech-impaired individuals. "IPv6 Transition in the Session Initiation Protocol (SIP)", Gonzalo Camarillo, 10-Sep-06, This document describes how IPv4 Session Initiation Protocol (SIP) user agents can communicate with IPv6 SIP user agents (and vice versa) at the signaling layer as well as exchange media once the session has been successfully set up. Both single- and dual-stack (i.e., an IPv4-only and an IPv4/IPv6) user agents are considered. "Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUUs)", Paul Kyzivat, 23-Oct-06, RFC 3680 defines a Session Initiation Protocol (SIP) event package for registration state. This package allows a watcher to learn about information stored by a SIP registrar, including its registered contact. However, the registered contact is frequently unreachable and thus not useful for watchers. The Globally Routable User Agent URI (GRUU), defined in RFC YYYY [3], is a URI that is capable of reaching a particular contact. However this URI is not included in the document format defined in RFC 3680. This specification defines an extension to the registration event package to include GRUUs assigned by the registrar. "A User Agent Profile Data Set for Media Policy", Volker Hilt, 1-Mar-07, This specification defines a document format for the media properties of Session Initiation Protocol (SIP) sessions such as codecs or media types used. This format is based on XML and extends the Schema for SIP User Agent Profile Data Sets. It can be used to describe the media properties of a specific SIP session and to express media- related policies that can be applied to different SIP sessions. "Multiple Dialog Usages in the Session Initiation Protocol", Robert Sparks, 20-Feb-07, Several methods in the Session Initiation Protocol can create an association between endpoints known as a dialog. Some of these methods can also create a different, but related, association within an existing dialog. These multiple associations, or dialog usages, require carefully coordinated processing as they have independent life-cycles, but share common dialog state. Processing multiple dialog usages correctly is not completely understood. What is understood is difficult to implement. This memo argues that multiple dialog usages should be avoided. It discusses alternatives to their use and clarifies essential behavior for elements that cannot currently avoid them. This is an informative document and makes no normative statements of any kind. "Session Initiation Protocol Package for Voice Quality Reporting Event", Amy Pendleton, 27-Feb-06, This document defines a SIP event package that enables the collection and reporting of metrics that measure the quality for Voice over Internet Protocol (VoIP) sessions. "Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists", Miguel Garcia-Martin, Gonzalo Camarillo, 8-Dec-06, In certain types of multimedia communications, a Session Initiation Protocol (SIP) request is distributed to a group of SIP User Agents (UAs). The sender sends a single SIP request to a server which further distributes the request to the group. This SIP request contains a list of Uniform Resource Identifiers (URIs), which identify the recipients of the SIP request. This URI-list is expressed as a resource list XML document. This specification defines an XML extension to the XML resource list format that allows the sender of the request to qualify a recipient with a copy control level similar to the copy control level of existing e-mail systems. "A Session Initiation Protocol (SIP) Event Package for Session-Specific Session Policies.", Volker Hilt, Gonzalo Camarillo, 1-Feb-07, This specification defines a Session Initiation Protocol (SIP) event package for session-specific policies. This event package enables user agents to subscribe to session policies for a SIP session and to receive notifications if these policies change. "The Session Initiation Protocol (SIP) Pending Additions Event Package", Gonzalo Camarillo, 27-Nov-06, This document defines the SIP Pending Additions event package. This event package is used by SIP relays to inform user agents about the consent-related status of the entries to be added to a resource list. "A Document Format for Requesting Consent", Gonzalo Camarillo, 27-Nov-06, This document defines an Extensible Markup Language (XML) format for a permission document used to request consent. A permission document written in this format is used by a relay to request the permission, of a specific recipient, to perform a particular routing translation. "Requirements from SIP (Session Initiation Protocol) Session Border Control Deployments", Jani Hautakorpi, 21-Feb-07, This documents describes functions implemented in Session Initiation Protocol (SIP) intermediaries known as Session Border Controllers (SBCs). The goal of this document is to describe the commonly provided functions of SBCs. A special focus is given to those practices that are viewed to be in conflict with SIP architectural principles. This document also explores the underlying requirements of network operators that have led to the use of these functions and practices in order to identify protocol requirements and determine whether those requirements are satisfied by existing specifications or additional standards work is required. "Requirements for Management of Overload in the Session Initiation Protocol", Jonathan Rosenberg, 28-Nov-06, Overload occurs in Session Initiation Protocol (SIP) networks when proxies and user agents have insuffient resources to complete the processing of a request. SIP provides limited support for overload handling through its 503 response code, which tells an upstream element that it is overloaded. However, numerous problems have been identified with this mechanism. This draft summarizes the problems with the existing 503 mechanism, and provides some requirements for a solution. "Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6)", Vijay Gurbani, 8-Mar-07, This informational document provides examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" the code of a SIP implementation that parses IPv6 addresses. "SIP (Session Initiation Protocol) Usage of Offer/Answer Model", Takuya Sawada, Paul Kyzivat, 1-Dec-06, SIP utilizes offer/answer model to establish and update multimedia sessions. The descriptions on how to use offer/answer in SIP are dispersed in the multiple RFCs. This document summarizes all the current usage of offer/answer model in SIP communication. "Examples call flow in race condition on Session Initiation Protocol", Miki Hasebe, 8-Mar-07, This document gives examples of the Session Initiation Protocol (SIP) call flows in race condition. Call flows in race condition are confusing, and this document shows the best practice to handle them. The elements in these call flows include SIP User Agents and SIP Proxies. Call flow diagrams and message details are shown. S/MIME Mail Security (smime) ---------------------------- "CMS Symmetric Key Management and Distribution", Sean Turner, 14-Jan-03, This document describes a mechanism to manage (i.e., setup, distribute, and rekey) keys used with symmetric cryptographic algorithms. Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms. The mechanisms use the Cryptographic Message Syntax (CMS) protocol [2] and Certificate Management Message over CMS (CMC) protocol [3] to manage the symmetric keys. Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key. This mechanism has been developed to support S/MIME Mail List Agents (MLAs). "ESS Update: Adding CertID Algorithm Agility", Jim Schaad, 17-Jan-07, In the original Enhanced Security Services for S/MIME document (RFC 2634), a structure for cryptographically linking the certificate to be used in validation with the signature was introduced, this structure was hardwired to use SHA-1. This document allows for the structure to have algorithm agility and defines a new attribute for this purpose. "Cryptographic Message Syntax (CMS) Multiple Signer Clarification", Russ Housley, 14-Feb-07, This document updates the Cryptographic Message Syntax (CMS), which is published in RFC 3852. This document clarifies the proper handling of the SignedData protected content type when more than one digital signature is present. "Identity-based Encryption Architecture", Mark Schertler, 6-Mar-07, This document describes the security architecture required to implement identity-based encryption, a public-key encryption technology that uses a user's identity to generate their public key. "Using the Boneh-Franklin and Boneh-Boyen identity-based encryption algorithms with the Cryptographic Message Syntax (CMS)", Luther Martin, Mark Schertler, 5-Mar-07, This document describes the conventions for using the Boneh-Franklin (BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in the Cryptographic Message Syntax (CMS) to encrypt content encryption keys. Object identifiers and the convention for encoding a recipient's identity are also defined. "Multiple Signatures in S/MIME", Sean Turner, 19-Dec-06, CMS SignedData includes the SignerInfo structure to convey per- signer information. SignedData supports multiple signers and multiple signature algorithms per-signer with multiple SignerInfo structures. If a signer attaches more than one SignerInfo, there are concerns that an attacker could perform a downgrade attack by removing the SignerInfo(s) with the 'stronger' algorithm(s). This document defines a signed attribute, its generation rules, and its processing rules to allow signers to convey multiple SignerInfo while protecting against downgrade attacks. Additionally, this attribute may assist during periods of algorithm migration. "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", Russ Housley, 14-Feb-07, This document describes an additional content type for the Cryptographic Message Syntax (CMS). The authenticated-enveloped-data content type is intended for use with authenticated encryption modes. All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped-data content type. "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)", Russ Housley, 22-Jan-07, This document specifies the conventions for using the AES-CCM and the AES-GCM authenticated encryption algorithms with the Cryptographic Message Syntax (CMS) authenticated-enveloped-data content type. Softwires (softwire) -------------------- "Softwire Problem Statement", Xing Li, 31-May-06, The Softwires Working Group is specifying the standardization of discovery, control and encapsulation methods for connecting IPv4 networks across IPv6-only networks and IPv6 networks across IPv4-only networks in a way that will encourage multiple, inter-operable vendor implementations. At the highest level, the Softwires Working Group is tasked to identify, and extend where necessary, standard protocols to support a selected set of "IPv4/IPv6" and "IPv6/IPv4" transition problems. This document describes the specific problems ("Hubs and Spokes" and "Mesh") that will be solved as part of a solution phase following the completion of this document, within a relatively tight "time-to-market" as requested by operators at IETF 63. Some individual requirements (and non-requirements) are also identified in this document at times in order to better describe the specific scope for a given problem definition. "Softwires Hub & Spoke Deployment Framework with L2TPv2", Bill Storer, 15-Feb-07, This document describes the framework of the Softwire "Hub and Spoke" solution with Layer 2 Tunneling Protocol (L2TPv2), and the implementation details specified in this document should be followed to achieve inter-operability among different vendor implementations. "Softwire Security Analysis and Requirements", Shu Yamamoto, 23-Oct-06, This document provides the security Guidelines for the Softwire "Hubs and Spokes" and "Mesh" solutions. Together with the discussion of the Softwire deployment scenarios, the vulnerability to the security attacks is analyzed to provide the security protection mechanism such as authentication, integrity and confidentiality to the softwire control and data packets. Speech Services Control (speechsc) ---------------------------------- "Media Resource Control Protocol Version 2 (MRCPv2)", Daniel Burnett, Saravanan Shanmugham, 8-Mar-07, The MRCPv2 protocol allows client hosts to control media service resources such as speech synthesizers, recognizers, verifiers and identifiers residing in servers on the network. MRCPv2 is not a "stand-alone" protocol - it relies on a session management protocol such as the Session Initiation Protocol (SIP) to establish the MRCPv2 control session between the client and the server, and for rendezvous and capability discovery. It also depends on SIP and SDP to establish the media sessions and associated parameters between the media source or sink and the media server. Once this is done, the MRCPv2 protocol exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server. Session PEERing for Multimedia INTerconnect (speermint) ------------------------------------------------------- "SPEERMINT Terminology", Dave Meyer, 20-Sep-06, This document defines the terminology that is to be used in describing Session PEERing for Multimedia INTerconnect (SPEERMINT). "SPEERMINT Requirements for SIP-based VoIP Interconnection", Jean-Francois Mule, 25-Oct-06, This document describes high-level guidelines and general requirements for Session PEERing for Multimedia INTerconnect. It also defines a minimum set of requirements applicable to session peering for Voice over IP interconnects. It is intended to become best current practices based on the use cases discussed in the speermint working group. "SPEERMINT Peering Architecture", Reinaldo Penno, 20-Oct-06, This document defines the SPEERMINT peering architecture, its functional components and peering interface functions. "SPEERMINT Routing Architecture Message Flows", Reinaldo Penno, 25-Sep-06, This draft provides the message flows associated with the SPEERMINT, SIP Peering and Multimedia Interconnect, routing architecture. This document provides examples of many different message flows relative to varying peering scenarios. "Use of DNS SRV and NAPTR Records for SPEERMINT", Tom Creighton, Gaurav Khandpur, 6-Nov-06, The objective of this document is to specify the Best Current Practice (BCP) adopted by a service provider providing multimedia communication services such as Voice over Internet Protocol(VoIP) in order to locate another service provider to peer with in the context of Session PEERing for Multimedia INTerconnect. "Presence & IM Use Cases", Avshalom Houri, 28-Feb-07, The document describes several use cases of peering between two or more service providers that provide real time collaboration services and presence and IM in particular. These service providers create a peering relationship between themselves thus enabling their users to collaborate with users on other communities. The target of the document is to help understanding the requirements for peering between domains with regard to real time services "VoIP SIP Peering Use Cases", Adam Uzelac, 2-Mar-07, This document will capture the VoIP use case for SIP Peering. It is a consolidation of other Speermint use cases and will focus exclusively on VoIP. Security Issues in Network Event Logging (syslog) ------------------------------------------------- "Signed syslog Messages", John Kelsey, 11-Dec-06, This document describes a mechanism to add origin authentication, message integrity, replay resistance, message sequencing, and detection of missing messages to the transmitted syslog messages. This specification draws upon the work defined in RFC xxxx, "The syslog Protocol", however it may be used atop any message delivery mechanism, even that defined in RFC 3164, "The BSD syslog Protocol", or in the RAW mode of RFC 3195, "The Reliable Delivery of syslog". "Syslog Management Information Base", Glenn Keeni, 5-Mar-07, This memo defines a portion of the Management Information Base (MIB), the Syslog MIB, for use with network management protocols in the Internet community. In particular, the Syslog MIB will be used to monitor and control syslog applications. "The syslog Protocol", Rainer Gerhards, 30-Nov-06, This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way. This document has been written with the anticipated original design goals for traditional syslog in mind. The reason for a new layered specification has arisen because standardization efforts for reliable, and secure syslog extensions suffer from the lack of a standards-track and transport independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport. "Transmission of syslog messages over UDP", Anton Okmianski, 26-Nov-06, This document describes the transport for syslog messages over UDP/ IPv4 or UDP/IPv6. The syslog protocol layered architecture provides for support of any number of transport mappings. However, for interoperability purposes, syslog protocol implementers are required to support this transport mapping. "TLS Transport Mapping for Syslog", Fuyou Miao, Ma Yuzhi, 4-Dec-06, This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of Syslog messages. This document describes the security threats to Syslog and how TLS can be used to counter such threats. TCP Maintenance and Minor Extensions (tcpm) ------------------------------------------- "Improving TCP's Robustness to Blind In-Window Attacks", Anantha Ramaiah, 23-Feb-07, TCP has historically been considered protected against spoofed packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32 bit sequence number(s). A combination of increasing window sizes and applications using a longer term connections (e.g. H-323 or Border Gateway Protocol [RFC4271]) have left modern TCP implementation more vulnerable to these types of spoofed packet injection attacks. Many of these long term TCP applications tend to have predictable IP addresses and ports which makes it far easier for the 4-tuple to be guessed. Having guessed the 4-tuple correctly, an attacker can inject a RST, SYN or DATA segment into a TCP connection by carefully crafting the sequence number of the spoofed segment to be in the current receive window. This can cause the connection to either abort or possibly cause data corruption. This document specifies small modifications to the way TCP handles inbound segments that can reduce the chances of a successful attack. "Defending TCP Against Spoofing Attacks", Joseph Touch, 26-Feb-07, Recent analysis of potential attacks on core Internet infrastructure indicates an increased vulnerability of TCP connections to spurious resets (RSTs), sent with forged IP source addresses (spoofing). TCP has always been susceptible to such RST spoofing attacks, which were indirectly protected by checking that the RST sequence number was inside the current receive window, as well as via the obfuscation of TCP endpoint and port numbers. For pairs of well-known endpoints often over predictable port pairs, such as BGP or between web servers and well-known large-scale caches, increases in the path bandwidth- delay product of a connection have sufficiently increased the receive window space that off-path third parties can brute-force generate a viable RST sequence number. The susceptibility to attack increases with the square of the bandwidth, thus presents a significant vulnerability for recent high-speed networks. This document addresses this vulnerability, discussing proposed solutions at the transport level and their inherent challenges, as well as existing network level solutions and the feasibility of their deployment. This document focuses on vulnerabilities due to spoofed TCP segments, and includes a discussion of related ICMP spoofing attacks on TCP connections. "TCP User Timeout Option", Lars Eggert, Fernando Gont, 8-Mar-07, The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. This document specifies a new TCP option - the TCP User Timeout Option - that allows one end of a TCP connection to advertise its current user timeout value. This information allows the other end to adapt its user timeout accordingly. Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity. "Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets", Aleksandar Kuzmanovic, 23-Oct-06, This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC 3168 only specified setting an ECN-Capable codepoint on data packets, and not on SYN and SYN/ACK packets. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmit timeout, this document is specifying the use of ECN for the SYN/ACK packet itself, when sent in response to a SYN packet with the two ECN flags set in the TCP header, indicating a willingness to use ECN. Setting TCP SYN/ACK packets as ECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmit timeout for a connection that has not yet started placing a load on the network. The sender of the SYN/ACK packet must respond to an ECN mark by reducing its initial congestion window from two, three, or four segments to one segment, reducing the subsequent load from that connection on the network. "TCP Congestion Control", Mark Allman, 15-Feb-07, This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. "TCP's Reaction to Soft Errors", Fernando Gont, 25-Jan-07, This document discusses the problem of long delays between connection establishment attempts that may arise in a number of scenarios, including one in which dual stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. Additionally, this document describes a non-standard, but widely implemented modification to TCP's reaction to ICMP "soft errors" that can help overcome this problem. "ICMP attacks against TCP", Fernando Gont, 25-Oct-06, This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP) and other similar protocols. It proposes several counter-measures to eliminate or minimize the impact of these attacks. "TCP SYN Flooding Attacks and Common Mitigations", Wesley Eddy, 8-Mar-07, This document describes TCP SYN flooding attacks, which have been well-known to the community for several years. Various countermeasures against these attacks, and the trade-offs of each, are described. This document archives explanations of the attack and common defense techniques for the benefit of TCP implementers and administrators of TCP servers or networks. Transport Layer Security (tls) ------------------------------ "Using SRP for TLS Authentication", Dave Taylor, 18-Dec-06, This memo presents a technique for using the Secure Remote Password protocol as an authentication method for the Transport Layer Security protocol. "Using OpenPGP keys for TLS authentication", Nikos Mavroyanopoulos, 28-Aug-06, This memo proposes extensions to the TLS protocol to support the OpenPGP key format. The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol. "The TLS Protocol Version 1.2", Tim Dierks, Eric Rescorla, 7-Mar-07, This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. "Clientside interoperability experiences for the SSL and TLS protocols", Yngve Pettersen, 18-Oct-06, This document presents a number of problems encountered when implementing TLS 1.0, TLS 1.1 and TLS Extensions for clients, and their consequences. The problems include servers that refuse to connect with clients supporting newer versions of the protocol, or that do not handle such negotiation properly. Another problem encountered is the incorrect use of values in the protocol messages. Transparent Interconnection of Lots of Links (trill) ---------------------------------------------------- "RBridges: Base Protocol Specification", Radia Perlman, 5-Mar-07, RBridges allow for optimal pair-wise forwarding with zero configuration, safe forwarding even during periods of temporary loops, and the ability to cut down on ARP/ND and IP multicast traffic. They achieve these goals by replacing the Spanning Tree protocol with IS-IS. The design also supports VLANs, and allows forwarding tables to be based on RBridge destinations (rather than endnode destinations), which allows internal forwarding tables to be substantially smaller than in conventional bridge systems. "Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement", Joseph Touch, Radia Perlman, 23-Oct-06, Current Ethernet (802.1) link layers use custom routing protocols that have a number of challenges. The routing protocols need to strictly avoid loops, even temporary loops during route propagation, because of the lack of header loop detection support. Routing tends not to take full advantage of alternate paths, or even non- overlapping pairwise paths (in the case of spanning trees). The convergence of these routing protocols and stability under link changes and failures is also of concern. This document addresses these concerns and suggests that they are related to the need to be able to apply modern network layer routing protocols at the link layer. This document assumes that solutions would not address issues of scalability beyond that of existing bridged (802.1D) links, but that a solution would be backward compatible with 802.1D, including hubs, bridges, and their existing plug-and-play capabilities. This document is a work in progress; we invite you to participate on the mailing list at http://www.postel.org/rbridge "The Architecture of an RBridge Solution to TRILL", Eric Gray, 8-Mar-07, RBridges are link layer (L2) devices that use routing protocols as a control plane. They combine several of the benefits of the link layer with network layer routing benefits. RBridges use existing link state routing (without requiring configuration) to improve RBridge to RBridge aggregate throughput. RBridges also provide support for IP multicast and IP address resolution optimizations. They are intended to be applicable to similar L2 network sizes as conventional bridges and are intended to be backward compatible with those bridges as both ingress/egress and transit. They also support VLANs (although this generally requires configuration) and otherwise attempt to retain as much 'plug and play' as is already available in existing bridges. This document proposes an RBridge system as a solution to the TRILL problem. It also defines the RBridge architecture, defines its terminology, and describes basic components and desired behavior. One or more separate documents specify the protocols and mechanisms that satisfy the architecture presented herein. "TRILL Routing Requirements in Support of RBridges", Eric Gray, 1-Feb-07, RBridges provide the ability to have an entire domain, with multiple physical links, look to IP like a single subnet. The design allows for zero configuration of switches within an RBridge domain, optimal pair-wise routing, safe forwarding even during periods of temporary loops, and potential additional advantages as well. The design also supports VLANs, allows forwarding tables to be based on destinations within the RBridge domain (rather than station destinations, allowing internal forwarding tables to be smaller than in conventional bridge systems). The intent is to re-uses one or more existing routing protocols to accomplish these goals. This document lays out the background and specific requirements of potential routing protocols to be considered for use in this design. In particular, this document defines what is needed to accomodate this design using IS-IS (or OSPF) as a basis for RBridge protocols. Transport Area Working Group (tsvwg) ------------------------------------ "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", Randall Stewart, 28-Feb-07, This document describes extensions to the Stream Control Transmission Protocol (SCTP) [RFC2960] that provides a method to reconfigure IP address information on an existing association. "Sockets API Extensions for Stream Control Transmission Protocol (SCTP)", Randall Stewart, 12-Dec-06, This document describes a mapping of the Stream Control Transmission Protocol SCTP into a sockets API. The benefits of this mapping include compatibility for TCP applications, access to new SCTP features and a consolidated error and event notification scheme. "TCP Extended Statistics MIB", Matt Mathis, 5-Mar-07, This draft describes extended performance statistics for TCP. They are designed to use TCP's ideal vantage point to diagnose performance problems in both the network and the application. If a network based application is performing poorly, TCP can determine if the bottleneck is in the sender, the receiver or the network itself. If the bottleneck is in the network, TCP can provide specific information about its nature. "Authenticated Chunks for Stream Control Transmission Protocol (SCTP)", Michael Tuexen, 28-Feb-07, This document describes a new chunk type, several parameters and procedures for SCTP. This new chunk type can be used to authenticate SCTP chunks by using shared keys between the sender and receiver. The new parameters are used to establish the shared keys. "Aggregation of RSVP Reservations over MPLS TE/DS-TE Tunnels", Francois Le Faucheur, 19-Sep-06, RFC 3175 specifies aggregation of RSVP end-to-end reservations over aggregate RSVP reservations. This document specifies aggregation of RSVP end-to-end reservations over MPLS Traffic Engineering (TE) tunnels or MPLS Diffserv-aware MPLS Traffic Engineering (DS-TE) Tunnels. This approach is based on RFC 3175 and simply modifies the corresponding procedures for operations over MPLS TE tunnels instead of aggregate RSVP reservations. This approach can be used to achieve admission control of a very large number of flows in a scalable manner since the devices in the core of the network are unaware of the end-to-end RSVP reservations and are only aware of the MPLS TE tunnels. "Security Attacks Found Against SCTP and Current Countermeasures", Randall Stewart, 19-Oct-06, Stream Control Transmission Protocol defined in RFC 2960 is a multi- homed transport protocol. As such, unique security threats exists that are addressed in various ways within the protocol itself. This document attempts to detail the known security threats and their countermeasures as detailed in the current version of the SCTP Implementors guide RFC 4460. It is hoped that this information will provide some useful background information for many of the newest requirements spelled out in the SCTP Implementors guide. "QoS Signaling in a Nested Virtual Private Network", Fred Baker, Pratik Bose, 6-Feb-07, Some networks require communication between an interior and exterior portion of a VPN or through a concatenation of such networks resulting in a nested VPN, but have sensitivities about what information is communicated across the boundary, especially while providing quality of service to communications with different precedence. This note seeks to outline the issues and the nature of the proposed solutions based on the framework for Integrated Services operation over DiffServ networks as described in RFC 2998 . "Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations", Francois Le Faucheur, 14-Feb-07, RFC3175 defines aggregate Resource ReSerVation Protocol (RSVP) reservations allowing resources to be reserved in a Diffserv network for a given Per Hop Behavior (PHB), or given set of PHBs, from a given source to a given destination. RFC3175 also defines how end-to- end RSVP reservations can be aggregated onto such aggregate reservations when transiting through a Diffserv cloud. There are situations where multiple such aggregate reservations are needed for the same source IP address, destination IP address and PHB (or set of PHBs). However, this is not supported by the aggregate reservations defined in RFC3175. In order to support this, the present document defines a more flexible type of aggregate RSVP reservations, referred to as generic aggregate reservation. Multiple such generic aggregate reservations can be established for a given PHB (or set of PHBs) from a given source IP address to a given destination IP address. The generic aggregate reservations may be used to aggregate end-to-end RSVP reservations. This document also defines the procedures for such aggregation. The generic aggregate reservations may also be used end- to-end directly by end-systems attached to a Diffserv network. "Padding Chunk and Parameter for SCTP", Michael Tuexen, 17-Oct-06, This document defines a padding chunk and a padding parameter and describes the required receiver side procedures. The padding chunk is used to pad an SCTP packet to an arbitrary size. The padding parameter is used to pad an SCTP INIT chunk to an arbitrary size. "Aggregation of DiffServ Service Classes", Kwok Ho Chan, 8-Mar-07, In the core of a high capacity network, service differentiation is still needed to support applications' utilization of the network. Applications with similar traffic characteristics and performance requirements are mapped into diffserv service classes based on end- to-end behavior requirements of the applications as indicated by Diffserv Service Classes [5]. However, some network segments may be configured in such a way that a single forwarding treatment may satisfy the traffic characteristics and performance requirements of two or more service classes. In these cases, it may be desirable to aggregate two or more Diffserv Service Classes [5] into a single forwarding treatment. This document provides guidelines for the aggregation of Diffserv Service Classes [5] into forwarding treatments. "Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services", Francois Le Faucheur, 8-Mar-07, An Emergency Telecommunications Service (ETS) requires the ability to provide an elevated probability of session establishment to an authorized user in times of network congestion (typically, during a crisis). When supported over the Internet Protocol suite, this may be facilitated through a network layer admission control solution, which supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for emergency services, or they may be shared with other sessions. "An EF DSCP for Capacity-Admitted Traffic", Fred Baker, 15-Dec-06, This document requests a DSCP from the IANA for a class of real-time traffic conforming to the Expedited Forwarding Per Hop Behavior and admitted using a CAC procedure involving authentication, authorization, and capacity admission, as compared to a class of real-time traffic conforming to the Expedited Forwarding Per Hop Behavior but not subject to capacity admission or subject to very coarse capacity admission. One of the reasons behind this is the need for classes of traffic that are handled under special policies, such as the non-preemptive Emergency Telecommunication Service, the US DoD's Assured Service (which is similar to MLPP), or e-911. These do not need separate DSCPs or separate PHBs that are separate from each other, but they need a traffic class from which they can deterministically obtain their service requirements from including SLA matters. "RSVP Extensions for Path-Triggered RSVP Receiver Proxy", Francois Le Faucheur, 28-Feb-07, RSVP signaling can be used to make end-to-end resource reservations in an IP network in order to guarantee the QoS required by certain flows. With conventional RSVP, both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are many use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable. Where the receiver is not RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy thereby performing RSVP signaling on behalf of the receiver. This allows resource reservations to be established on the segment of the end-to-end path from the sender to the RSVP Receiver Proxy. However, as discussed in the companion document presenting RSVP Proxy Approaches, RSVP extensions are needed to facilitate operations with an RSVP Receiver Proxy whose signaling is triggered by receipt of RSVP Path messages from the sender. This document specifies these extensions. "RSVP Proxy Approaches", Francois Le Faucheur, 28-Feb-07, RSVP signaling can be used to make end-to-end resource reservations in an IP network in order to guarantee the QoS required by certain flows. With conventional RSVP, both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are many use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable. This document presents RSVP Proxy behaviors allowing RSVP routers to perform RSVP signaling on behalf of a receiver or a sender that is not RSVP-capable. This allows resource reservations to be established on parts of the end- to-end path. This document reviews conceptual approaches for deploying RSVP Proxies and discusses how those can synchronize RSVP reservations with application requirements. This document also points out where extensions to RSVP (or to other protocols) may be needed for deployment of a given RSVP Proxy approach. However, such extensions are outside the scope of this document. Finally, practical use cases for RSVP Proxy are described. "Specifying New Congestion Control Algorithms", Sally Floyd, Mark Allman, 6-Mar-07, The IETF's standard congestion control schemes have been widely shown to be inadequate for various environments (e.g., high-speed networks). Recent research has yielded many alternate congestion control schemes ([RFC3649], [HTCP], [FAST], [BIC], [CompoundTCP], [XCP], and many more). Using these new congestion control schemes in the global Internet has possible ramifications to both the traffic using the new congestion control and to traffic using the currently standardized congestion control. Therefore, the IETF must proceed with caution when dealing with alternate congestion control proposals. The goal of this document is to provide guidance for considering alternate congestion control algorithms within the IETF. Usenet Article Standard Update (usefor) --------------------------------------- "Netnews Article Format", Charles Lindsey, 9-Jan-07, This document specifies the syntax of Netnews articles in the context of the "Internet Message Format" (RFC 2822) and "Multipurpose Internet Mail Extensions (MIME)" (RFC 2045). This document obsoletes RFC 1036, providing an updated specification to reflect current practice and incorporating incremental changes specified in other documents. "Netnews Architecture and Protocols", Russ Allbery, Charles Lindsey, 4-Jan-07, This document defines the architecture of Netnews systems and specifies the correct manipulation and interpretation of Netnews articles by software which originates, distributes, stores, and displays them. It also specifies the requirements that must be met by any protocol used to transport and serve Netnews articles. Backward compatibility has been a major goal of this endeavour, but where this standard and earlier documents or practices conflict, this standard should be followed. In most such cases, current practice is already compatible with these changes. A companion Best Current Practice document [USEAGE], addressing requirements which are present for Social rather than Normative reasons is in preparation. IPv6 Operations (v6ops) ----------------------- "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful", Sebastien Roy, 17-Jan-06, This document describes the historical and background information behind the removal of the "on-link assumption" from the conceptual host sending algorithm defined in Neighbor Discovery for IP Version 6 (IPv6). According to the algorithm as originally described, when a host's default router list is empty, the host assumes that all destinations are on-link. This is particularly problematic with IPv6-capable nodes that do not have off-link IPv6 connectivity (e.g., no default router). This document describes how making this assumption causes problems, and describes how these problems outweigh the benefits of this part of the conceptual sending algorithm. "IPv6 Enterprise Network Analysis - IP Layer 3 Focus", Jim Bound, 11-Dec-06, This document analyzes the transition to IPv6 in enterprise networks focusing on IP Layer 3. These networks are characterized as a network that has multiple internal links, one or more router connections, to one or more Providers, and is managed by a network operations entity. The analysis will focus on a base set of transition notational networks and requirements expanded from a previous Enterprise Scenarios document. Discussion is provided on a focused set of transition analysis required for the enterprise to transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) network and node environment, within the enterprise. Then a set of transition mechanisms are recommended for each notational network. "Local Network Protection for IPv6", Gunter Van de Velde, 11-Jan-07, Although there are many perceived benefits to Network Address Translation (NAT), its primary benefit of "amplifying" available address space is not needed in IPv6. In addition to NAT's many serious disadvantages, there is a perception that other benefits exist, such as a variety of management and security attributes that could be useful for an Internet Protocol site. IPv6 was designed with the intention of making NAT unnecessary, and this document shows how Local Network Protection (LNP) using IPv6 can provide the same or more benefits without the need for address translation. "IPv6 Transition/Co-existence Security Considerations", Elwyn Davies, 27-Oct-06, The transition from a pure IPv4 network to a network where IPv4 and IPv6 co-exist brings a number of extra security considerations that need to be taken into account when deploying IPv6 and operating the dual-protocol network and the associated transition mechanisms. This document attempts to give an overview of the various issues grouped into three categories: o issues due to the IPv6 protocol itself, o issues due to transition mechanisms, and o issues due to IPv6 deployment. "Using IPsec to Secure IPv6-in-IPv4 Tunnels", Pekka Savola, 17-Jan-07, This document gives guidance on securing manually configured IPv6-in- IPv4 tunnels using IPsec in Transport Mode. No additional protocol extensions are described beyond those available with the IPsec framework. "Recommendations for Filtering ICMPv6 Messages in Firewalls", Elwyn Davies, Janos Mohacsi, 14-Feb-07, In networks supporting IPv6 the Internet Control Message Protocol version 6 (ICMPv6) plays a fundamental role with a large number of functions, and a correspondingly large number of message types and options. ICMPv6 is essential to the functioning of IPv6 but there are a number of security risks associated with uncontrolled forwarding of ICMPv6 messages. Filtering strategies designed for the corresponding protocol, ICMP, in IPv4 networks are not directly applicable, because these strategies are intended to accommodate a useful auxiliary protocol that may not be required for correct functioning. This document provides some recommendations for ICMPv6 firewall filter configuration that will allow propagation of ICMPv6 messages that are needed to maintain the functioning of the network but drop messages which are potential security risks. "IPv6 Deployment Scenarios in 802.16 Networks", Myung-Ki Shin, 16-Feb-07, This document provides detailed description of IPv6 deployment and integration methods and scenarios in wireless broadband access networks in coexistence with deployed IPv4 services. In this document we will discuss main components of IPv6 IEEE 802.16 access network and its differences from IPv4 IEEE 802.16 networks and how IPv6 is deployed and integrated in each of the IEEE 802.16 technologies using tunneling mechanisms and native IPv6. "IPv6 Unicast Address Assignment Considerations", Gunter Van de Velde, 5-Mar-07, One fundamental aspect of any IP communications infrastructure is its addressing plan. With its new address architecture and allocation policies, the introduction of IPv6 into a network means that network designers and operators need to reconsider their existing approaches to network addressing. Lack of guidelines on handling this aspect of network design could slow down the deployment and integration of IPv6. This document aims to provide the information and recommendations relevant to planning the addressing aspects of IPv6 deployments. The document also provides IPv6 addressing case studies for both an enterprise and an ISP network. "IPv6 Routing Policies Guidelines", Marc Blanchet, 27-Feb-07, Guidelines on how to manage and filter IPv6 routes are needed for operators of networks, either providers or enterprises. It describes IPv6 routes from the protocol point of view. It does not discuss operational or policy issues such as the maximum length of prefixes to filter. This document is a followup on RFC2772 work but for the production IPv6 Internet. RFC2772 is obsoleted. "IPv6 Implications for Network Scanning", Tim Chown, 8-Mar-07, The 128 bits of IPv6 address space is considerably bigger than the 32 bits of address space of IPv4. In particular, the IPv6 subnets to which hosts attach will by default have 64 bits of host address space. As a result, traditional methods of remote TCP or UDP network scanning to discover open or running services on a host will potentially become less feasible, due to the larger search space in the subnet. In addition automated attacks, such as those performed by network worms, may be hampered. This document discusses this property of IPv6, and describes related issues for site administrators of IPv6 networks to consider, which may be of importance when planning site address allocation and management strategies. While traditional network scanning probes (whether by individuals or automated via network worms) may become less common, administrators should be aware of other methods attackers may use to discover IPv6 addresses on a target network, and be aware of appropriate measures to mitigate them. "IPv6 Campus Transition Scenario Description and Analysis", Tim Chown, 16-Oct-06, In this document we consider and analyse the specific scenario of IPv6 transition and deployment in a large department of a university campus network. The department is large enough to operate its own instances of all the conventional university services including (for example) web, DNS, email, filestore, interactive logins, and remote and wireless access. The scenario is a dual-stack one, i.e. transition to IPv6 means deploying IPv6 in the first instance (and probably for some time) alongside IPv4. This analysis identifies the available components for IPv6 transition, while validating the applicability of the IPv6 Enterprise Network Scenarios informational text. It focuses on the network elements of the transition, rather than the application elements. "Requirements for the address selection mechanisms", Arifumi Matsumoto, 21-Feb-07, RFC3484 defines source and destination address selection algorithms that are commonly deployed in current popular OSs. Meanwhile, there is a possibility to provide multiple addresses in one physical network. In such a multi-prefix environment, end-hosts could encounter some troubles in the communication because of default use of the RFC3484 mechanism. Some mechanism for the address selection problems are proposed including RFC3484 policy table distribution and RFC3484-update. This document describes the requirements for these address selection mechanisms. "Problem Statement of Default Address Selection in Multi-prefix Environment: Operational Issues of RFC3484 Default Rules", Arifumi Matsumoto, 10-Nov-06, One physical network can carry multiple logical networks. Moreover, we can use multiple physical networks at the same time in a host. In that environment, end-hosts might have multiple IP addresses and be required to use them selectively. Without an appropriate source/ destination address selection mechanism, the host will experience some trouble in the communication. RFC 3484 defines both the source and destination address selection algorithms, but the multi-prefix environment considered here needs additional rules beyond the default operation. This document describes the possible problems that end- hosts could encounter in an environment with multiple logical networks. "Reasons to Move NAT-PT to Historic Status", Cedric Aoun, Elwyn Davies, 21-Feb-07, This document discusses issues with the specific form of IPv6-IPv4 protocol translation mechanism implemented by the Network Address Translator - Protocol Translator (NAT-PT) defined in RFC 2766. These issues are sufficiently serious that recommending RFC 2766 as a general purpose transition mechanism is no longer desirable, and this document recommends that the IETF should reclassify RFC 2766 from Proposed Standard to Historic status. Virtual Router Redundancy Protocol (vrrp) ----------------------------------------- "Virtual Router Redundancy Protocol for IPv6", Robert Hinden, John Cruz, 5-Mar-07, This memo defines the Virtual Router Redundancy Protocol (VRRP) for IPv6. It is version three (3) of the protocol. It is based on the original version of VRRP (version 2) for IPv4 that is defined in RFC2338. VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. The advantage gained from using VRRP for IPv6 is a quicker switch over to back up routers than can be obtained with standard IPv6 Neighbor Discovery [ND] mechanisms. "Definitions of Managed Objects for the VRRP over IPv4 and IPv6", Kalyan Tata, 15-Dec-06, This specification defines a Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol for both IPv4 and IPv6 as defined in RFC 3768 and RFC xxxx ( RFC-editor, this is currently draft-ietf-vrrp-ipv6-spec-07.txt). This memo obsoletes RFC 2787. WWW Distributed Authoring and Versioning (webdav) ------------------------------------------------- "HTTP Extensions for Distributed Authoring - WebDAV", Lisa Dusseault, 16-Feb-07, WebDAV consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance). RFC2518 was published in February 1999, and this specification makes minor revisions mostly due to interoperability experience. "Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)", Geoffrey Clemm, 8-Feb-07, This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource. Servers are required to insure the integrity of any bindings that they allow to be created. Widget Description Exchange Service (widex) ------------------------------------------- "Widget Description Exchange Service (WIDEX) Requirements", Vlad Stirbu, Dave Raggett, 9-Jan-07, This document defines functional requirements for a framework and a protocol used to support XML-based user interfaces, where the user interface and application logic may be on different machines, and coupled via an exchange of XML DOM events and update/mutation operations. Centralized Conferencing (xcon) ------------------------------- "A Framework and Data Model for Centralized Conferencing", Mary Barnes, 23-Jan-07, This document defines the framework for Centralized Conferencing. The framework allows participants using various call signaling protocols, such as SIP, H.323, Jabber and PSTN, to exchange media in a centralized unicast conference. The Centralized Conferencing Framework defines logical entities and naming conventions, along with a conferencing data model. The framework also outlines a set of conferencing protocols, which are complementary to the call signaling protocols, for building advanced conferencing applications. The framework binds all the defined components together for the benefit of builders of conferencing systems. "Connection Establishment in the Binary Floor Control Protocol (BFCP)", Gonzalo Camarillo, 5-Mar-07, This document specifies how a Binary Floor Control Protocol (BFCP) client establishes a connection to a BFCP floor control server outside the context of an offer/answer exchange. Client and server authentication are based on Transport Layer Security (TLS). "Conference Information Data Model for Centralized Conferencing (XCON)", Oscar Novo, 2-Mar-07, This document defines an Extensible Markup Language (XML)-based conference information data model for centralized conferencing (XCON). A conference object, which can be manipulated using a conference control protocol, at a conference server represents a particular instantiation of this data model. The conference information data model defined in this document is an extension of (and thus, compatible with) the model specified in the Session Initiation Protocol (SIP) Event Package for Conference State.