16ng 6lowpan 6man adslmib alto ancp autoconf avt behave bfd bliss bmwg btns calsify capwap ccamp csi dccp dhc dime dispatch dkim dnsext dnsop drinks eai ecrit emu enum fecframe forces geopriv grow hip hokey httpbis idnabis idr ipdvb ipfix ippm ipsecme isis isms keyprov kitten krb-wg l2tpext l2vpn l3vpn ledbat lemonade lisp ltans ltru manet mboned mediactrl mext mif mip4 mipshop mmusic morg mpls mptcp msec multimob nea netconf netext netlmm netmod nfsv4 nsis ntp oauth opsawg opsec ospf p2psip pana pce pcn pim pkix pmol pppext pwe3 radext rmt rohc roll rtgwg sasl savi shim6 sidr sieve simple sipclf sipcore smime softwire speechsc speermint storm syslog tcpm tictoc tls trill tsvwg v6ops vcarddav vrrp vwrap xcon xmpp yam IP over IEEE 802.16 Networks (16ng) ----------------------------------- Charter Last Modified: 2009-10-05 Current Status: Active Chairs: Gabriel Montenegro Soohong Daniel Park Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Tech Advisors: Maximilian Riegel Dave Thaler Secretary: Jihoon Lee Mailing Lists: General Discussion: 16ng@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/16ng Archive: http://www.ietf.org/mail-archive/web/16ng Description of Working Group: Broadband Wireless Access Networks address the inadequacies of low bandwidth wireless communication for user requirements such as high quality data/voice service, wide coverage, etc. The IEEE 802.16 Working Group on Broadband Wireless Access Standards develops standards and recommended practices to support the development and deployment of Broadband Wireless Metropolitan Area Networks. A particularity of IEEE 802.16 is that it does not include a rigid upper edge MAC service interface. Instead, it provides multiple "convergence sublayers (CS)" with the assumption that the choice and configuration of the upper edge will be done in accordance with the needs of a specific deployment environment (which might be DSL replacement, mobile access, 802.11 or CDMA backhaul etc.). Specifically, immediately subsequent to network entry, an 802.16 subscriber station has no capability whatsoever for data (as opposed to management) connectivity. Especially, in IP CS case, the criteria by which the Base Station (or other headend elements) sets up the 802.16 MAC connections for data transport are not part of the 802.16 standard, and depend on the type of data services being offered (e.g., the set up of link layer connections will be different for IPv4 and IPv6 services). Additionally - as IEEE 802.16 is a point-to-multipoint network - an 802.16 subscriber station is not capable of multicasting (e.g., for neighbor discovery, ARP, IP multicasting services, etc.) or direct communication to the other nodes attached to the same Base Station within the same subnet (prefix). Unlike 3G or xDSL technologies, IEEE 802.16 is not part of an end-to- end system definition. Currently, the WiMAX Forum, and, in particular, its NWG (Network Working Group) is defining a network architecture based on IEEE 802.16. The principal objective of the 16ng working group is to specify the operation of IPv4 and IPv6 over IEEE 802.16, taking into account the IPv4, IPv6 and Ethernet Convergence Sublayers. The working group may issue recommendations to IEEE 802.16 and WiMax aiming at improving support for IP. The scope of this working group is as follows (WG Deliverables); - Produce "16ng Problem Statement, Goal and Requirement" to identify the specific gaps in the 802.16 MAC for IPv4/IPv6 support, describe possible network models (ie. point-to-point, broadcast etc.), and provide 16ng related terminology to be used for the base guideline while defining solution frameworks. [Informational RFC] - Produce "IPv6 over IEEE 802.16 Networks in conjunction with IPv6 CS" to define IPv6 operation including the transmission of IPv6 over IEEE 802.16 link, Neighbor Discovery Protocol, Stateful (DHCPv6) and Stateless Address Configuration, Broadcast, Multicast, etc. [Proposed Standard RFC] - Produce "IPv6 over IEEE 802.16 Networks in conjunction with Ethernet CS" to define IPv6 operation including the transmission of IPv6 over IEEE 802.16 link, Neighbor Discovery Protocol, Stateful (DHCPv6) and Stateless Address Configuration, Broadcast, Multicast, etc. [Proposed Standard RFC] - Produce "IPv4 over IEEE 802.16 Networks in conjunction with IPv4 CS" to define IPv4 operation including the transmission of IPv4 over IEEE 802.16 links, ARP operation, Stateful Address Configuration (DHCPv4), Broadcast, Multicast, etc [Proposed Standard RFC] - Produce "IPv4 over IEEE 802.16 Networks in conjunction with Ethernet CS" to define IPv4 operation including the transmission of IPv4 over IEEE 802.16 links, ARP operation, Stateful Address Configuration (DHCPv4), Broadcast, Multicast, etc [Proposed Standard RFC] - Produce "IP deployment over IEEE 802.16 Networks" to illustrate the IP deployment scenarios including IP CS and Ethernet CS considerations over IEEE 802.16 networks based on the WiMAX and WiBro. [Informational RFC] This working group will take dual stack operation into account in its specifications, and reuse existing specifications whenever reasonable and possible. The ability to negotiate the used Convergence Sublayer is required, as no single mandatory CS can be specified for the clients. Work based on the Ethernet CS needs to take into account interoperability with existing hosts and other devices that employ Ethernet, to allow bridging. 16ng will not initially consider other work items than the ones listed above; however, other related work may occur in other WGs, and 16ng will participate and help such efforts. Goals and Milestones: Done - Working Group Last Call on 16ng problem statement, goal and requirement Done - Working Group Last Call on IPv6 over IPv6 CS transmission over IEEE 802.16 networks Done - Working Group Last Call on IPv6 subnet model analysis Done - Submit IPv6 over IPv6 CS transmission over IEEE 802.16 networks to IESG for publication as Proposed Standard RFC Done - Submit IPv6 subnet model analysis to IESG for publication as Informational RFC Done - Submit 16ng problem statement, goal and requirement to IESG for publication as Informational RFC Done - Working Group Last Call on IP over Ethernet CS transmission over IEEE 802.16 networks Done - Review on draft-ietf-mipshop-fh80216e to be ready to IESG in conjunction with MIPSHOP WG Done - Working Group Last Call on IPv4 over IPv4 CS transmission over IEEE 802.16 networks Done - Submit IPv4 over IPv4 CS transmission over IEEE 802.16 networks to IESG for publication as Proposed Standard RFC Done - Re-submit IP over Ethernet CS transmission over IEEE 802.16 networks to IESG for publication as Proposed Standard RFC (initial IESG submission was: 24-Jun-08) Internet-Drafts: - Analysis of IPv6 Link Models for 802.16 based Networks [draft-ietf-16ng-ipv6-link-model-analysis-04] (17 pages) - IP over 802.16 Problem Statement and Goals [draft-ietf-16ng-ps-goals-05] (14 pages) - Transmission of IPv6 via the IPv6 CS over IEEE 802.16 Networks [draft-ietf-16ng-ipv6-over-ipv6cs-12] (22 pages) - Transmission of IP over Ethernet over IEEE 802.16 Networks [draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-13] (20 pages) - Transmission of IPv4 packets over IEEE 802.16's IP Convergence Sublayer [draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-06] (14 pages) Requests for Comments: RFC4968: Analysis of IPv6 Link Models for 802.16 Based Networks (17 pages) RFC5121: Transmission of IPv6 via the IPv6 CS over IEEE 802.16 Networks (22 pages) RFC5154: IP over IEEE 802.16 Problem Statement and Goals (14 pages) RFC5692: Transmission of IP over Ethernet over IEEE 802.16 Networks (21 pages) IPv6 over Low power WPAN (6lowpan) ---------------------------------- Charter Last Modified: 2009-04-13 Current Status: Active Chairs: Carsten Bormann Geoffrey Mulligan Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion: 6lowpan@lists.ietf.org To Subscribe: 6lowpan-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/6lowpan/current/maillist.html Description of Working Group: Background/Introduction: Well-established fields such as control networks, and burgeoning ones such as "sensor" (or transducer) networks, are increasingly being based on wireless technologies. Most (but certainly not all) of these nodes are amongst the most constrained that have ever been networked wirelessly. Extreme low power (such that they will run potentially for years on batteries) and extreme low cost (total device cost in single digit dollars, and riding Moore's law to continuously reduce that price point) are seen as essential enablers towards their deployment in networks with the following characteristics: * Significantly more devices than current local area networks * Severely limited code and ram space (e.g., highly desirable to fit the required code--MAC, IP and anything else needed to execute the embedded application--in, for example, 32K of flash memory, using 8-bit microprocessors) * Unobtrusive but very different user interface for configuration (e.g., using gestures or interactions involving the physical world) A chief component of these devices is wireless communication technology. In particular, the IEEE 802.15.4 standard is very promising for the lower (physical and link) layers. As for higher layer functions, there is considerable interest from non-IETF groups in using IP technology. The IEEE 1451.5 standard for wireless transducers has a chapter for 6LoWPAN and the ISA SP100 standard for wireless industrial networks has adopted 6LoWPAN for their network layer. This working group is expected to coordinate and interact with such groups. Description of Working Group: ----------------------------- The Working Group has completed two RFCs: "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" (RFC4919) that documents and discusses the problem space and "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" (RFC4944) which defines the format for the adaptation between IPv6 and 802.15.4. The Working Group will generate the necessary documents to ensure interoperable implementations of 6LoWPAN networks and will define the necessary security and management protocols and constructs for building 6LoWPAN networks, paying particular attention to protocols already available. 6lowpan will work closely with the Routing Over Low power and Lossy networks (roll) working group which is developing IPv6 routing solutions for low power and lossy networks (LLNs). Work Items: ----------- 1. Produce "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations" to define limited extensions to IPv6 Neighbor Discovery [RFC4861] for use specifically in low-power networks. This document (or documents) will define how to bootstrap a 6LoWPAN network and explore ND optimizations such as reusing the structure of the 802.15.4 network (e.g., by using the coordinators), and reduce the need for multicast by having devices talk to coordinators (without creating a single point-of-failure, or changing the semantics of the IPv6 ND multicasts). This document or documents will be a proposed standard. 2. Produce "6LoWPAN Improved Header Compression" to describe mechanisms to allow enhancements to the 6LoWPAN headers. Specifically this document will describe compression of addresses that are not link-local. Additionally this document may include other enhancements or optimizations of the HC1 or HC2 6LoWPAN headers. This document will be a proposed standard. 3. Produce "6LoWPAN Architecture" to describe the design and implementation of 6LoWPAN networks. This document will cover the concepts of "Mesh Under" and "Route Over", 802.15.4 design issues such as operation with sleeping nodes, network components (both battery- and line-powered), addressing, and IPv4/IPv6 network connections. This document will be informational. 4. As a separate Internet Draft, "6LoWPAN Routing Requirements" will describe 6LoWPAN-specific requirements on routing protocols used in 6LoWPANs, addressing both the "route-over" and "mesh-under" approach. This document will be created and owned by this working group but is expected to be reviewed by the ROLL WG. This document will be informational. 5. Produce "Use Cases for 6LoWPAN" to define, for a small set of applications with sufficiently unique requirements, how 6LoWPANs can solve those requirements, and which protocols and configuration variants can be used for these scenarios. The use cases will cover protocols for transport, application layer, discovery, configuration and commissioning. This document will be informational. 6. Produce "6LoWPAN Security Analysis" to define the threat model of 6LoWPANs, to document suitability of existing key management schemes and to discuss bootstrapping/installation/commissioning/setup issues. This document will be referenced from the "security considerations" of the other 6LoWPAN documents. This document will be informational. The working group will continue to reuse existing protocols and mechanisms whenever reasonable and possible. Non-milestone work items: ------------------------- The Working Group will keep two running, often-respun documents: -- implementers guide, collecting clarifying information based on input from implementers, in particular as it becomes available from interoperability events. -- interoperability guide, providing information for interoperability events, such as temporary interoperability testing strategies or information about test harnesses used for interoperability testing. Both documents will be WG documents, but their disposition is not decided at this point (one example for such a document became RFC 4815 after five years of maintenance and 22 revisions). Goals and Milestones: Done - Working group last call on draft-ietf-lowpan-goals-assumptions-xx.txt Done - Submit draft-ietf-lowpan-goals-assumptions-xx.txt to IESG for consideration of publication as Informational Done - Working Group Last Call on draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt Done - Submit draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt to IESG for consideration of publication as Proposed Standard Aug 2008 - Submit Improved Header Compression document to IESG for consideration as a proposed standard Aug 2008 - Submit Security Analysis document to IESG for consideration as an Informational RFC Sep 2008 - Submit Architecture document to IESG for consideration as an Informational RFC Sep 2008 - Submit Routing Requirements document to IESG for consideration as an Informational RFC Nov 2008 - Submit Bootstrapping and ND Optimizations document to IESG to be considered as a Proposed Standard Dec 2008 - Submit Use Case document to IESG as an Informational RFC Internet-Drafts: - Transmission of IPv6 Packets over IEEE 802.15.4 Networks [draft-ietf-6lowpan-format-14] (31 pages) - 6LoWPAN: Overview, Assumptions, Problem Statement and Goals [draft-ietf-6lowpan-problem-09] (13 pages) - Compression Format for IPv6 Datagrams in 6LoWPAN Networks [draft-ietf-6lowpan-hc-06] (20 pages) - Design and Application Spaces for 6LoWPANs [draft-ietf-6lowpan-usecases-04] (30 pages) - 6LoWPAN Neighbor Discovery [draft-ietf-6lowpan-nd-07] (61 pages) - Problem Statement and Requirements for 6LoWPAN Routing [draft-ietf-6lowpan-routing-requirements-04] (32 pages) Requests for Comments: RFC4919: IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals (13 pages) RFC4944: Transmission of IPv6 Packets over IEEE 802.15.4 Networks (31 pages) IPv6 Maintenance (6man) ----------------------- Charter Last Modified: 2008-12-16 Current Status: Active Chairs: Robert Hinden Brian Haberman Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: ipv6@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipv6 Archive: http://www.ietf.org/mail-archive/web/ipv6 Description of Working Group: The 6man working group is responsible for the maintenance, upkeep, and advancement of the IPv6 protocol specifications and addressing architecture. It is not chartered to develop major changes or additions to the IPv6 specifications. The working group will address protocol limitations/issues discovered during deployment and operation. It will also serve as a venue for discussing the proper location for working on IPv6-related issues within the IETF. The working group's work items are as follows: o Complete work on RA Flags Option o Complete work on RH0 Deprecation o Complete work on IPv6 over PPP Compression Negotiation o Complete work on Centrally Allocated Unique Local Addresses (ULA-C) All new work items not listed above require the approval of the working group and the sponsoring Area Director before they will be taken on by the working group. Goals and Milestones: Done - Submit RH0 Deprecation specification to IESG as a Proposed Standard Jan 2008 - Submit PPP Compression Negotiation specification to IESG as a Proposed Standard Mar 2008 - Determine way forward for ULA-C specification Internet-Drafts: - Centrally Assigned Unique Local IPv6 Unicast Addresses [draft-ietf-ipv6-ula-central-02] (11 pages) - Negotiation for IPv6 datagram compression using IPv6 Control Protocol [draft-ietf-ipv6-compression-nego-v2-03] (8 pages) - IPv6 Node Requirements RFC 4294-bis [draft-ietf-6man-node-req-bis-03] (21 pages) - Reserved IPv6 Interface Identifiers [draft-ietf-6man-reserved-iids-04] (12 pages) - Solution approaches for address-selection problems [draft-ietf-6man-addr-select-sol-02] (20 pages) - IPv6 Subnet Model: the Relationship between Links and Subnet Prefixes [draft-ietf-6man-ipv6-subnet-model-05] (11 pages) - Handling of overlapping IPv6 fragments [draft-ietf-6man-overlap-fragment-03] (7 pages) - A Recommendation for IPv6 Address Text Representation [draft-ietf-6man-text-addr-representation-01] (14 pages) - IANA Allocation Guidelines for the IPv6 Routing Header [draft-ietf-6man-iana-routing-header-00] (3 pages) - Considerations for IPv6 Address Selection Policy Changes [draft-ietf-6man-addr-select-considerations-00] (18 pages) Requests for Comments: RFC5172: Negotiation for IPv6 datagram compression using IPv6 Control Protocol (8 pages) * Obsoletes RFC2472 RFC5453: Reserved IPv6 Interface Identifiers (12 pages) ADSL MIB (adslmib) ------------------ Charter Last Modified: 2009-08-24 Current Status: Active Chairs: Michael Sneed Menachem Dodge Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Tech Advisor: Randy Presuhn Editors: Faye Ly Greg Bathrick Bob Ray Rajesh Abbi Scott Baillie Menachem Dodge Clay Sikes Moti Morgenstern Umberto Bonollo Mailing Lists: General Discussion: adslmib@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/adslmib Archive: http://www.ietf.org/mail-archive/web/adslmib/current/maillist.html Description of Working Group: The working group will define: 1. A set of managed objects to be used for management of newer versions of Digital Subscriber Line (xDSL) as defined in ITU-T Recommendation G.997.1 (02/2006). 2. A set of managed objects to handle the bonding of xDSL lines according to the ITU-T Recommendations G.998.1 (ATM), G.998.2 (Ethernet) and G.998.3 (TDIM). A common MIB module will be developed to handle the common objects and three specific MIB modules will be developed to handle the three separate layer-2 technologies. Use will be made of the ifStack and ifInvStack Tables defined in RFC 2863 and RFC 2864 respectively. Use will also be made of the ifAvailableStack and ifInvAvailableStack tables as defined by the Hubmib WG. The MIB modules defined by this group will be generated using SMIv2, will be consistent with the SNMP management framework, and will describe the relationship of the objects defined to existing MIBs such as those described in other work products of this Working Group, the interfaces MIB, the Ethernet MIB modules and the AToM MIB. The working group will consider the input of the DSL forum and the ITU in the definition of these MIBs. Goals and Milestones: Done - Submit Internet-Draft to cover subscriber equipment Done - Meet at Chicago IETF to review Internet-Drafts Done - Submit Internet-Draft to IESG for consideration as Proposed Standard. Done - Meet at Oslo IETF to review new Internet-Drafts and discuss implementation experience on initial MIB Done - Submit supplementary Internet-Draft to IESG for consideration as Proposed Standard. Done - Produce Internet-Draft covering HDSL2 management objects. Done - Submit updated HDSL2/SHDSL Internet-Draft Done - Complete WG last call for HDSL2/SHDSL management objects Done - Collect implementation reports for ADSL MIB Done - Submit HDSL2/SHDSL MIB to IESG for consideration as Proposed Standard Done - Submit initial Internet-Draft VDSL MIB Done - Complete WG last call on VDSL MIB Done - Submit updated VDSL MIB Internet-Draft Done - Submit final VDSL MIB Internet-Draft Done - Submit VDSL MIB to IESG for consideration as Proposed Standard Done - New WG I-Ds for the LCS MCM and SCM MIB modules Done - Initial WG Internet-Draft covering ADSL2 management objects Done - Integrate working group changes and produce revised draft Done - Complete WG last call on ADSL2 MIB Done - Submit ADSL2 MIB to IESG for consideration as Proposed Standard Done - Re-charter or close down Done - Initial WG Internet-Draft covering VDSL2 management objects Done - Inform the ITU-T and DSL Forum that work on the VDSL2 MIB has begun Done - Integrate working group changes and produce revised VDSL2 MIB draft Done - Post Initial Drafts of all the xDsl Bonding MIB drafts Done - Post Vdsl2 draft version 03 Done - Post Vdsl2 draft version 04. Dec 2007 - Complete the work on all the four G.Bond documents. Jan 2008 - Working Group Last Call on all the G. Bond documents. Done - Complete Thorough Working Group Reviews of the Vdsl2 draft and produce version 05. Feb 2008 - Early MIB Doctor Review of all G.Bond documents. Done - Working Group Last Call for the Vdsl2 document. Done - Early MIB Doctor Reviews of the Vdsl2 draft. Mar 2008 - Make Corrections to the G.Bond drafts following the review. Apr 2008 - Working Group Last Call for G.Bond documents following corrections. Done - Make Correction to the draft following the review. May 2008 - Present the four G. Bond documents to the IESG. Done - Working Group Last Call for the Vdsl2 document following corrections. Done - Present the Vdsl2 document to the IESG. Internet-Drafts: - Definitions of Managed Objects for the ADSL Lines [draft-ietf-adslmib-adsllinemib-10] (113 pages) - Definitions of Extension Managed Objects for Asymmetric Digital Subscriber Lines [draft-ietf-adslmib-adslext-12] (36 pages) - Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2) [draft-ietf-adslmib-vdsl2-08] (215 pages) - Definitions of Managed Objects for HDSL2 and SHDSL Lines [draft-ietf-adslmib-hdsl2-12] (61 pages) - Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL) [draft-ietf-adslmib-vdsl-13] (68 pages) - High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals [draft-ietf-adslmib-hc-tc-08] (10 pages) - Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Single Carrier Modulation (SCM) Line Coding [draft-ietf-adslmib-vdsl-ext-scm-09] (18 pages) - Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding [draft-ietf-adslmib-vdsl-ext-mcm-07] (23 pages) - Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines [draft-ietf-adslmib-gshdslbis-12] (76 pages) - Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2) [draft-ietf-adslmib-adsl2-09] (166 pages) - xDSL multi-pair bonding (G.Bond) MIB [draft-ietf-adslmib-gbond-mib-03] (66 pages) - Ethernet-based xDSL multi-pair bonding (G.Bond/Ethernet) MIB [draft-ietf-adslmib-gbond-eth-mib-01] (23 pages) - xDSL multi-pair bonding using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB [draft-ietf-adslmib-gbond-tdim-mib-02] (49 pages) - ATM-Based xDSL Bonded Interfaces MIB [draft-ietf-adslmib-gbond-atm-mib-00] (17 pages) Requests for Comments: RFC2662: Definitions of Managed Objects for the ADSL Lines (115 pages) RFC3276: Definitions of Managed Objects for HDSL2 and SHDSL Lines (66 pages) * OBSOLETED BY RFC4319 RFC3440: Definitions of Extension Managed Objects for Asymmetric Digital Subscriber Lines (36 pages) RFC3705: High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals (10 pages) RFC3728: Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL) (68 pages) RFC4069: Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Single Carrier Modulation (SCM) Line Coding (18 pages) RFC4070: Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding (23 pages) RFC4319: Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines (76 pages) * Obsoletes RFC3276 RFC4706: Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2) (166 pages) RFC5650: Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2) (215 pages) Application-Layer Traffic Optimization (alto) --------------------------------------------- Charter Last Modified: 2009-04-22 Current Status: Active Chairs: Jon Peterson Vijay Gurbani Enrico Marocco Applications Area Directors: Lisa Dusseault Alexey Melnikov Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion: alto@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/alto Archive: http://www.ietf.org/mail-archive/web/alto/current/maillist.html Description of Working Group: A significant part of the Internet traffic today is generated by peer-to-peer (P2P) applications used for file sharing, real-time communications, and live media streaming. P2P applications exchange large amounts of data, often uploading as much as downloading. In contrast to client/server architectures, P2P applications often must choose one or more suitable candidates from a selection of peers offering the same resource or service. One of the advantages of P2P systems comes from redundancy in resource availability. This requires choosing among a list of peers, yet applications have at best incomplete information to help the selection, e.g., topology of the network. Applications can sometimes obtain network information dynamically or measure link performance with respect to particular peers, but even when this is an option it takes time. The application cannot always start out with an optimal arrangement of peers, thus risking at least temporary poor performance and excessive cross-domain traffic. Providing more information for use in peer selection can improve P2P performance and lower ISP costs. The Working Group will design and specify an Application-Layer Traffic Optimization (ALTO) service that will provide applications with information to perform better-than-random initial peer selection. ALTO services may take different approaches at balancing factors such as maximum bandwidth, minimum cross-domain traffic, lowest cost to the user, etc. The WG will consider the needs of BitTorrent, tracker-less P2P, and other applications, such as content delivery networks (CDN) and mirror selection. The WG will focus on the following items: - A "problem statement" document providing a description of the problem and a common terminology. - A requirements document. This document will list requirements for the ALTO service, identifying, for example, types of information P2P applications may need for optimizing their choices. - A request/response protocol for querying the ALTO service to obtain information useful for peer selection, and a format for requests and responses If the requirements analysis identifies the need to allow clients to delegate third-parties to query the ALTO service on their behalf, the WG will ensure that the protocol provides a mechanism to assert the consent of the delegating client. - A document defining core request and response formats and semantics to communicate network preferences to applications. Since ALTO services may be run by entities with different level of knowledge about the underlying network, such preferences may have different representations. Initially the WG will consider: IP ranges to prefer and to avoid, ranked lists of the peers requested by the client, information about topological proximity and approximate geographic locations. Other usages will be considered as charter additions once the work for the initial services has been completed. - In order to query the ALTO server, clients must first know one or more ALTO servers that might provide useful information. The WG will look at service discovery mechanisms that are in use, or defined elsewhere (e.g. based on DNS SRV records or DHCP options). If such discovery mechanisms can be reused, the WG will produce a document to specify how they may be adopted for locating such servers. However, a new, general-purpose service discovery mechanism is not in scope. When the WG considers standardizing information that the ALTO server could provide, the following criteria are important to ensure real feasibility. - Can the ALTO service realistically discover that information? - Is the distribution of that information allowed by the operators of that service? - Is it information that a client will find useful? - Can a client get that information without excessive privacy concerns (e.g. by sending large lists of peers)? - Is it information that a client cannot find easily some other way? After these criteria are met, the importance of the data will be considered for prioritizing standardization work, for example the number of operators and clients that are likely to be able to provide or use that particular data. In any case, this WG will not propose standards on how congestion is signaled, remediated, or avoided, and will not deal with information representing instantaneous network state. Such issues belong to other IETF areas and will be treated accordingly by the specific area. This WG will focus solely on the communication protocol between applications and ALTO servers. Note that ALTO services may be useful in client-server environments as well as P2P environments, although P2P environments are the first focus. If, in the future, the IETF considers changes to other protocols for actually implementing ALTO services (e.g. application-layer protocols for Internet coordinate systems, routing protocol extensions for ISP-based solutions), such work will be done in strict coordination with the appropriate WGs. Issues related to the content exchanged in P2P systems are also excluded from the WG's scope, as is the issue dealing with enforcing the legality of the content. Goals and Milestones: Apr 2009 - Working Group Last Call for problem statement Jun 2009 - Submit problem statement to IESG as Informational Aug 2009 - Working Group Last Call for requirements document Oct 2009 - Submit requirements document to IESG as Informational Jan 2010 - Working Group Last Call for request/response protocol Jan 2010 - Working Group Last Call for usage document for communicating network preferences Mar 2010 - Submit request/response protocol to IESG as Proposed Standard Mar 2010 - Submit usage document to IESG as Proposed Standard May 2010 - Working Group Last Call of discovery mechanism Jul 2010 - Submit discovery mechanism to IESG as Proposed Standard Aug 2010 - Dissolve or re-charter Internet-Drafts: - Application-Layer Traffic Optimization (ALTO) Problem Statement [draft-ietf-alto-problem-statement-05] (15 pages) - Application-Layer Traffic Optimization (ALTO) Requirements [draft-ietf-alto-reqs-02] (26 pages) Requests for Comments: RFC5693: Application-Layer Traffic Optimization (ALTO) Problem Statement (15 pages) Access Node Control Protocol (ancp) ----------------------------------- Charter Last Modified: 2009-10-13 Current Status: Active Chairs: Matthew Bocci Wojciech Dec Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Tech Advisor: Dan Romascanu Mailing Lists: General Discussion: ancp@ietf.org To Subscribe: ancp-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/ancp/current/maillist.html Description of Working Group: Purpose: The purpose of the ANCP WG is to standardize an IP-based Access Node Control Protocol (ANCP) for use in service provider Digital Subscriber Line (DSL) and Passive Optical Network (PON) access and aggregation networks. ANCP operates between an Access Node (AN) and Network Access Server (NAS). Necessary Terminology: Access Node (AN) - Network device, usually located at a service provider central office or street cabinet, that terminates access loop connections from Subscribers. In DSL, this is often referred to as a Digital Subscriber Line Access Multiplexer (DSLAM). In PON, this is usually comprised of an Optical Network Termination (ONT) / Optical Network Unit (ONU) and an Optical Line Termination (OLT). Network Access Server (NAS) - Network device which aggregates multiplexed Subscriber traffic from a number of Access Nodes. The NAS plays a central role in per-subscriber policy enforcement and QoS. This is often referred to as a Broadband Network Gateway (BNG) or Broadband Remote Access Server (BRAS). A detailed definition of the NAS is given in RFC2881. Goals: ANCP is intended to address the requirement for a bidirectional, IP- based, control protocol that operates across multiple types (i.e., Ethernet, ATM) of DSL and PON access and aggregation networks. The goal of an ANCP message exchange is to convey status and control information between one or more ANs and one or more NASs without going through intermediate element managers. The ANCP WG will address the following four use-cases: 1. Dynamic Access Loop Attributes Various queuing and scheduling mechanisms are used in access networks to avoid congestion while dealing with multiple flows and distinct QoS profiles. Communicating the access-loop status, attributes and current DSL synchronization rate between the AN and Subscriber up to the NAS is desirable, particularly when the NAS is providing QoS for individual flows and subscribers. ANCP will provide a mechanism to communicate dynamic access-loop attributes from the AN to the NAS. 2. Access Loop Configuration In additional to reporting Access Loop characteristics from the AN to the NAS, ANCP will allow a NAS to send loop-specific configuration information to an AN based on the results of subscriber authentication and authorization (e.g., after AAA responses have been received at the NAS). 3. Remote Connectivity Test Traditional DSL access and aggregation networks employ point-to-point ATM circuits between the AN and NAS for each subscriber, allowing troubleshooting of the local loop from the NAS via ATM OAM tools. With the increasing deployment of Ethernet in the access and aggregation network, operators require consistent methods to test and troubleshoot connectivity for mixed Ethernet and ATM access networks (including the local loop). ANCP will allow a remote procedure for a local loop connectivity test to be triggered from the NAS with results communicated back to the NAS. 4. Multicast When multicast replication for subscriber-bound traffic is performed at the AN, it offloads the network between the AN and NAS. However, a subscriber's policy and configuration for multicast traffic may only be known at the NAS. ANCP will provide a mechanism to communicate the necessary information exchange between the AN and NAS so as to allow the AN to perform subscriber bound multicast group replication in line with the subscriber's policy and configuration, and also allow the NAS to follow each subscriber's multicast group membership. Non-Goals: ANCP is an IP-based protocol that operates between the AN and NAS. It will not address setup or configuration of circuits or connections in the access and aggregation network itself. The focus of this WG is on one very specific application space. While the design of the protocol must be general as to not preclude other uses in the future should a need arise, it is not a goal of this WG to address specific requirements outside of service provider broadband (such as xDSL, xPON) access and aggregation networks. Security: The ANCP working group will provide a threat analysis and address the associated security aspects of the control protocol. Resiliency and Scalability: A graceful restart mechanism will be defined to enable the protocol to be resilient to network failures between the AN and NAS. Scalability at the NAS is of primary concern, as it may be aggregating traffic from a large number of ANs, which in turn may be serving a large number of Subscribers. ANCP traffic should not become a denial of service attack on the NAS control plane. Format of messages, pacing, transport over UDP or TCP, etc. will be considered with this in mind. For reasons of aggregation network scalability, some use cases require that aspects of NAS or AN functionality may be distributed in nodes in the aggregation network. In these cases, ANCP can run between these nodes. Deliverables: The working group will define a basic framework and requirements document intended for Informational publication, focusing on the four use-cases outlined in this charter. This document will include a security threat analysis and associated requirements. The WG will then investigate and define a solution for an IP based control protocol meeting these requirements. There are early interoperable implementations of an ANCP-like protocol which are based on an extended subset of the GSMPv3 protocol. This running code will be the the starting point for the working group solution, and will be abandoned only if the WG determines it is not adequate to meet requirements going forward. Coordination with other Working Groups or Organizations: The working group will coordinate with the ADSL MIB working group so the management framework and MIB modules are consistent for DSL access environments. The working group will re-use, as far as possible, standard MIB modules that have already been defined. The remote connectivity test use case may require coordination with ITU-T Ethernet OAM and PON work and with IEEE 802.1ag. Goals and Milestones: Done - Accept WG I-D for ANCP Framework and Requirements Done - Accept WG I-D for Access Node Control Protocol (ANCP) Done - Accept WG ID for Security Threats analysis Done - Accept WG I-D for ANCP MIB Done - Security Threats Analysis last call Done - Framework and Requirements last call Done - Accept WG I-D for ANCP Multicast Extensions Nov 2009 - Accept WG I-D for ANCP applicability to PON Jan 2010 - Access Node Control Protocol (ANCP) Last Call Jan 2010 - ANCP MIB Last Call Jan 2010 - ANCP Multicast Extensions last call Apr 2010 - ANCP applicability to PON last call Jul 2010 - Re-charter or conclude Working Group Internet-Drafts: - Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks [draft-ietf-ancp-framework-12] (55 pages) - Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) [draft-ietf-ancp-security-threats-08] (18 pages) - Protocol for Access Node Control Mechanism in Broadband Networks [draft-ietf-ancp-protocol-07] (58 pages) - Access Node Control Protocol (ANCP) MIB module for Access Nodes [draft-ietf-ancp-mib-an-04] (36 pages) - Additional Multicast Control Extensions for ANCP [draft-ietf-ancp-mc-extensions-01] (91 pages) No Requests for Comments Ad-Hoc Network Autoconfiguration (autoconf) ------------------------------------------- Charter Last Modified: 2009-04-02 Current Status: Active Chairs: Ryuji Wakikawa Thomas Clausen Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: autoconf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf Archive: http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html Description of Working Group: In order to communicate among themselves, ad hoc nodes (refer to RFC 2501) need to configure their network interface(s) with local addresses that are valid within an ad hoc network. Ad hoc nodes may also need to configure globally routable addresses, in order to communicate with devices on the Internet. From the IP layer perspective, an ad hoc network presents itself as a L3 multi-hop network formed over a collection of links. The main purpose of the AUTOCONF WG is to describe the addressing model for ad hoc networks and how nodes in these networks configure their addresses. It is required that such models do not cause problems for ad hoc-unaware parts of the system, such as standard applications running on an ad hoc node or regular Internet nodes attached to the ad hoc nodes. This group's effort may include the development of new protocol mechanisms, should the existing IP autoconfiguration mechanisms be found inadequate. However, the first task of the working group is to describe one practical addressing model for ad hoc networks. Once this sole work item is completed, the group can be rechartered to work on additional issues. Goals and Milestones: Done - Submit an initial 'MANET architecture' WG document Done - Submit an initial 'terminology and problem statement' WG document Done - Submit 'MANET architecture' document to IESG for publication as an informational RFC Apr 2009 - Submit initial draft on addressing model in ad hoc networks Sep 2009 - Submit addressing model draft to IESG as Informational or close WG Internet-Drafts: - Mobile Ad hoc Network Architecture [draft-ietf-autoconf-manetarch-07] (20 pages) - Address Autoconfiguration for MANET: Terminology and Problem Statement [draft-ietf-autoconf-statement-04] (22 pages) - IP Addressing Model in Ad Hoc Networks [draft-ietf-autoconf-adhoc-addr-model-00] (7 pages) No Requests for Comments Audio/Video Transport (avt) --------------------------- Charter Last Modified: 2009-05-01 Current Status: Active Chairs: Tom Taylor Roni Even Real-time Applications and Infrastructure Area Directors: Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Cullen Jennings Mailing Lists: General Discussion: avt@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/avt Archive: http://www.ietf.org/mail-archive/web/avt/index.html Description of Working Group: The Audio/Video Transport Working Group was formed to specify a protocol for real-time transmission of audio and video over unicast and multicast UDP/IP. This is the Real-time Transport Protocol, RTP, together with its associated profiles and payload formats. The current aims of the working group are: - to review and revise existing payload formats to advance those which are useful to Draft Standard, and to declare others as Historic. Milestones will be established as a champion for each payload format is identified. - to develop payload formats for new media codecs, and to document best-current practices in payload format design. The group continues to be precluded from work on codecs themselves because of overlap with the other standards bodies, and because the IETF does not have the ability to effectively review new codecs. An exception was made for the freeware iLBC codec on a highly experimental basis, but acceptance of new codec work is unexpected and subject to rechartering. - to complete the forward error correction work to update RFC 2733 in the form of the ULP payload format - to extend RTP to work with Source-Specific Multicast sessions with unicast feedback - to provide a framing mechanism for RTP over TCP and TLS - in collaboration with the MPLS and ROHC WGs, to develop a solution for header compression of RTP across MPLS networks that avoid decompression and compression at each MPLS node. - to develop a new RTP profile for the combination of the SRTP profile and the Extended RTP Profile for RTCP-based Feedback (RTP/SAVPF) - to maintain and enhance the SRTP Profile, with review and input from the Security Area - to develop a new RTP profile for usage of TFRC (RFC 3448) with RTP over UDP to allow application developers to gain experience with TCP friendly congestion control. - to develop a MIB for RTCP XR (RFC 3611). - to update the RTP MIB, including aligning it with RFC 3550. - to clarify how RTP is used for media in conferencing with centralised nodes performing relay, translation or mixing of media. - to develop the mechanisms needed for efficient control of media and its encoding process in RTP based conferencing, both over multicast and transport containing relays, translators and mixers. An example of such a mechanism is a method to request a full intra coded frame of video. This would be used to allow joining participants to receive video immediately after joining instead of waiting for the next intra coded frame. It also allows mixers to perform switching between media sources without the need to re-encode the media. - to develop a solution for carrying media meta data, specifically SMPTE timestamps, to enhance the media stream. Such transport may be done in either RTP or RTCP depending on which is most suitable. The WG may consider if a generalized mechanism should be developed to enable future types of meta data to be easier to include. - to develop two new metric blocks for the RTCP XR (RFC 3611) framework to provide information on the media quality experienced by the receiver of RTP flows. One metrics block is for high resolution measurements of audio and speech quality. A second one for providing information on the quality of video. The timescale to complete this second block and the included metrics are highly dependable on the development of standardized subjective metrics for video quality. The WG will consider what metrics that are available and if they should be included or not. The metrics blocks shall not duplicate signalling information anyway necessary for the establishment of the session. - to specify how the RFC 3550 requirement on RTCP senders to always send compound packets can be relaxed to allow for non-compound packets. The specification need to define under which criteria non-compound RTCP packets may be sent while maintaining the functionality that motivated the usage of compound RTCP packets and keep the bandwidth within specified limits. The longer term goals of the working group are to advance the SRTP Profile, the Extended RTP Profile for RTCP-based Feedback, the Compressed RTP framework, and the RTP MIB to Draft Standard. The group has no plans to develop new RTP profiles beyond those listed above, but will consider rechartering to produce profile level extensions if appropriate. Goals and Milestones: Done - Review DCCP including prototypes and API; feedback to DCCP WG Done - Initial draft requirements for ECRTP over MPLS; discuss with MPLS WG Done - Submit iLBC payload format for Proposed Standard Done - Submit iLBC codec specification for Experimental Done - Advance RTP specification and A/V profile to Full Standard Done - Submit RTP/SAVPF profile for Proposed Standard Done - Submit ULP Payload Format for Proposed Standard Done - Finished investigation of advanced FEC codes for RTP, update plan Done - Submit SMTPE Timestamping of Media for Proposed Standard Done - Submit Codec Control Messages for Proposed Standard Done - Submit Multiplexing of RTCP and RTP on the same port for Proposed Standard Done - Submit RTCP/SSM draft for Proposed Standard Done - Submit draft on Enhancing RTP header extensions for proposed standard Done - Submit RTP Payload Format for ITU-T Recommendation G.711.1 for Proposed Standard Done - Submit RTP payload format for mU-law EMbedded Codec for Low-delay IP communication (UEMCLIP) speech codec for Proposed Standard Done - Submit Transmission Time offsets in RTP streams for Proposed Standard Done - Submit RTP Payload Format for Adaptive TRansform Acoustic Coding (ATRAC) Family for Proposed Standard Done - Submit RTP Payload Format for JPEG 2000 Video Streams for Proposed Standard Done - Submit Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Header Recovery for Proposed Standard Done - Submit RTP Payload Format for the Speex Codec for Proposed Standard Done - Submit G.729.1 RTP Payload Format update: DTX support for Proposed Standard Done - Submit RTP Payload Format for ITU-T Recommendation G.722.1 for Proposed Standard Done - Submit draft on Mechanisms to keep NAT bindings for RTP flows alive for BCP Done - Submit The SEED Cipher Algorithm and Its Use with the Secure Real-time Transport Protocol (SRTP) for Proposed Standard Done - Submit RTP Payload Format for Elementary Streams with MPEG Surround multi-channel audio for Proposed Standard Done - Submit Support for reduced size RTCP, opportunities and consequences Oct 2008 - Submit RTCP XR High Resolution Audio Metrics for Proposed Standard Oct 2008 - Submit Parameters for Static Macroblocks and Aspect Ratio in the RTP Payload Format for H.264 Video for Proposed Standard Oct 2008 - Submit RTP Payload Format for H.264 RCDO Video for Proposed Standard Oct 2008 - Submit RTP Payload Format for SPIRIT IP-MR Speech Codec Software for Proposed Standard Oct 2008 - Submit RTP Payload Format for SVC Video for Proposed Standard Nov 2008 - Submit RTCP XR Video Metrics block for Proposed Standard Nov 2008 - Submit Guidelines for Extending the RTP Control Protocol (RTCP) for Informational Done - Submit Post-Repair Loss RLE Report Block Type for RTCP XR for Proposed Standard Nov 2008 - Submit draft explaining why SRTP need not be mandatory for media transport, for Informational Nov 2008 - Submit RTP Payload Format for H.264 Video for Proposed Standard Dec 2008 - Submit SRTP for Draft Standard Dec 2008 - Submit Forward-shifted RTP Redundancy Payload Support for Proposed Standard Dec 2008 - Submit RTP Payload Format for DV (IEC 61834) Video for Proposed Standard Done - Submit RTP Payload Format for G.719 audio for Proposed Standard Dec 2008 - Submit in band keying mechanism for SRTP draft for Proposed Standard Feb 2009 - Submit How to Write an RTP Payload Format for Informational Mar 2009 - Submit update of RTP MIB for Proposed or Draft Standard Mar 2009 - Submit RTCP XR MIB for Proposed Standard Mar 2009 - Submit RTP/AVPF for Draft Standard Mar 2009 - Submit EVBR/G.718 payload draft for Proposed Standard Dec 2010 - Submit RTP Payload Format for MIDI for Proposed Standard Internet-Drafts: - Issues in Designing a Transport Protocol for Audio and Video Conferences and other Multiparticipant Real-Time Applications [draft-ietf-avt-issues-01] (64 pages) - RTP: A Transport Protocol for Real-Time Applications [draft-ietf-avt-rtp-09] (77 pages) - Media Encodings [draft-ietf-avt-encodings-02] (7 pages) - RTP Profile for Audio and Video Conferences with Minimal Control [draft-ietf-avt-profile-08] (18 pages) - RTP payload format for H.261 video streams [draft-ietf-avt-h261-04] (14 pages) - RTP Payload Format of Sun's CellB Video Encoding [draft-ietf-avt-cellb-09] (8 pages) - RTP Payload Format for JPEG-compressed Video [draft-ietf-avt-jpeg-04] (15 pages) - RTP Payload Format for MPEG1/MPEG2 Video [draft-ietf-avt-mpeg-03] (10 pages) - RTP usage with Layered Multimedia Streams [draft-speer-avt-layered-video-05] (5 pages) - RTP Payload Format for H.263 Video Streams [draft-ietf-avt-rtp-payload-04] (11 pages) - RTP Payload for Redundant Audio Data [draft-ietf-avt-rtp-redundancy-01] (10 pages) - RTP Payload Format for Bundled MPEG [draft-civanlar-bmpeg-03] (7 pages) - Compressing IP/UDP/RTP Headers for Low-Speed Serial Links [draft-ietf-avt-crtp-06] (22 pages) - Alternatives for Enhancing RTCP Scalability [draft-aboba-rtpscale-02] (10 pages) - Real-Time Transport Protocol Management Information Base [draft-ietf-avt-rtp-mib-14] (35 pages) - RTP Profile for Audio and Video Conferences with Minimal Control [draft-ietf-avt-profile-new-13] (45 pages) - RTP Payload Format for MPEG1/MPEG2 Video [draft-ietf-avt-mpeg-new-02] (15 pages) - RTP Payload Format for QuickTime Media Streams [draft-ietf-avt-qt-rtp-00] (15 pages) - RTP Payload Format for BT.656 Video Encoding [draft-tynan-rtp-bt656-03] (9 pages) - RTP Payload for DTMF Digits [draft-ietf-avt-dtmf-01] (6 pages) - An RTP Payload Format for Generic Forward Error Correction [draft-ietf-avt-fec-09] (24 pages) - Options for Repair of Streaming Media [draft-ietf-avt-info-repair-03] (11 pages) - RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+) [draft-ietf-avt-rtp-h263-video-02] (10 pages) - RTP Payload Format for JPEG-compressed Video [draft-ietf-avt-jpeg-new-02] (25 pages) - New Results in RTP Scalability [draft-ietf-avt-byerecon-00] (10 pages) - Guidelines for Writers of RTP Payload Format Specifications [draft-ietf-avt-rtp-format-guidelines-05] (9 pages) - RTP: A Transport Protocol for Real-Time Applications [draft-ietf-avt-rtp-new-12] (107 pages) - RTP Payload Format for X Protocol Media Streams [draft-ietf-avt-X11-new-00] (16 pages) - The Role of DMIF in Support of RTP MPEG-4 Payloads [draft-ietf-avt-rtp-mpeg4-dmif-01] (11 pages) - RTP Payload Format for MPEG-4 Streams [draft-ietf-avt-rtp-mpeg4-03] (11 pages) - An RTP Payload Format for User Multiplexing [draft-ietf-avt-aggregation-00] (10 pages) - RTP Payload for Redundant Audio Data [draft-ietf-avt-redundancy-revised-00] (11 pages) - Sampling of the Group Membership in RTP [draft-ietf-avt-rtpsample-07] (11 pages) - User Multiplexing in RTP payload between IP Telephony Gateways [draft-ietf-avt-mux-rtp-00] (17 pages) - Issues and Options for RTP Multiplexing [draft-ietf-avt-muxissues-00] (27 pages) - An RTP Payload Format for Reed Solomon Codes [draft-ietf-avt-reedsolomon-00] (12 pages) - GeRM: Generic RTP Multiplexing [draft-ietf-avt-germ-00] (8 pages) - RTP Payload format for Interleaved Media [draft-ietf-avt-interleaving-01] (6 pages) - RTP Payloads for Telephone Signal Events [draft-ietf-avt-telephone-tones-00] (11 pages) - RTP Payload Format for DV Format Video [draft-ietf-avt-dv-video-04] (12 pages) - RTP Interoperability Statement [draft-ietf-avt-rtp-interop-08] (8 pages) - RTP Testing Strategies [draft-ietf-avt-rtptest-06] (22 pages) - RTP Payload Format for MPEG-2 and MPEG-4 AAC Streams [draft-ietf-avt-rtp-mpeg2aac-02] (10 pages) - RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals [draft-ietf-avt-tones-07] (29 pages) - Multiplexing Scheme for RTP Flows between Access Routers [draft-ietf-avt-multiplexing-rtp-01] (13 pages) - MIME Type Registration of RTP Payload Formats [draft-ietf-avt-rtp-mime-06] (36 pages) - SDP Bandwidth Modifiers for RTCP Bandwidth [draft-ietf-avt-rtcp-bw-05] (7 pages) - RTP Payload for Text Conversation [draft-ietf-avt-rtp-text-05] (9 pages) - RTP Payload Format for Real-Time Pointers [draft-ietf-avt-pointer-02] (5 pages) - RTP Payload Format for 12-bit DAT, 20- and 24-bit Linear Sampled Audio [draft-ietf-avt-dv-audio-04] (16 pages) - A More Loss-Tolerant RTP Payload Format for MP3 Audio [draft-ietf-avt-rtp-mp3-06] (0 pages) - RTP Audio/Video Profile Interoperability Statement [draft-ietf-avt-profile-interop-06] (7 pages) - Registration of parityfec MIME types [draft-ietf-avt-fecmime-02] (9 pages) - RTP payload format for MPEG-4 Audio/Visual streams [draft-ietf-avt-rtp-mpeg4-es-06] (18 pages) - RTP Payload for Comfort Noise [draft-ietf-avt-rtp-cn-06] (8 pages) - Extension of RTP payload Type for Multiple Program MPEG Transport Stream [draft-ietf-avt-rtp-mp2t-04] (0 pages) - RTP Payload Format for MPEG-4 with Flexible Error Resiliency [draft-ietf-avt-mpeg4streams-04] (18 pages) - Tunneling Multiplexed Compressed RTP ('TCRTP') [draft-ietf-avt-tcrtp-09] (22 pages) - RTP Payload Format for ITU-T Recommendation G.722.1 [draft-ietf-avt-rtp-g7221-01] (7 pages) - RTP Payload Format for SMPTE 292M Video [draft-ietf-avt-smpte292-video-08] (12 pages) - Enhanced Compressed RTP (CRTP) for links with high delay,packet loss and reordering [draft-ietf-avt-crtp-enhance-07] (0 pages) - RTP Profile for RTCP-based Retransmission Request for Unicast session. [draft-ietf-avt-rtprx-00] (10 pages) - RTP payload format and file storage format for the Adoptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) audio codecs [draft-ietf-avt-rtp-amr-13] (41 pages) - RTP Payload Format for Generic Forward Error Correction [draft-ietf-avt-ulp-24] (43 pages) - RTP Payload Formats to Enable Multiple Selective Retransmission [draft-ietf-avt-rtp-selret-05] (29 pages) - An RTP Payload Format for EVRC Speech [draft-ietf-avt-evrc-08] (17 pages) - An RTP Payload Format for Erasure-Resilient Transmission of Progressive Multimedia Streams [draft-ietf-avt-uxp-07] (29 pages) - The Secure Real-time Transport Protocol [draft-ietf-avt-srtp-10] (56 pages) - RTP Payload Format for MPEG-4 Streams [draft-ietf-avt-mpeg4-multisl-04] (56 pages) - Extended RTP Profile for RTCP-based Feedback(RTP/AVPF) [draft-ietf-avt-rtcp-feedback-12] (52 pages) - RTP Payload Format for 3GPP Timed Text [draft-ietf-avt-rtp-3gpp-timed-text-16] (59 pages) - RTP Payload Format for Transport of MPEG-4 Elementary Streams [draft-ietf-avt-mpeg4-simple-09] (41 pages) - Definition of Events For Channel-Oriented Telephony Signalling [draft-ietf-avt-rfc2833biscas-06] (26 pages) - RTP Payload Format for Phoneme/Facial Animation Paameter (PFAP) Streams [draft-ietf-avt-rtp-pfap-00] (13 pages) - RTP Payload Format for ETSI ES 201 108 Distributed Speech Recognition Encoding [draft-ietf-avt-dsr-05] (10 pages) - RTP Payload Format for H.261 Video Streams [draft-ietf-avt-rfc2032-bis-14] (24 pages) - RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders SMV [draft-ietf-avt-evrc-smv-03] (20 pages) - RTP Payload Format for MIDI [draft-ietf-avt-mwpp-midi-rtp-08] (101 pages) - RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback [draft-ietf-avt-rtcpssm-19] (59 pages) - RTP Retransmission Payload Format [draft-ietf-avt-rtp-retransmission-13] (32 pages) - RTP Payload for Interleaved Audio [draft-ietf-avt-rtp-interleave-00] (9 pages) - RTP Payload Format for JPEG 2000 Video Streams [draft-ietf-avt-rtp-jpeg2000-21] (37 pages) - RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals [draft-ietf-avt-rfc2833bis-16] (57 pages) - RTP Payload Format for AC-3 Audio [draft-ietf-avt-rtp-ac3-08] (11 pages) - Internet Low Bit Rate Codec [draft-ietf-avt-ilbc-codec-06] (174 pages) - RTP Control Protocol Extended Reports (RTCP XR) [draft-ietf-avt-rtcp-report-extns-07] (53 pages) - RTP Payload Format for Uncompressed Video [draft-ietf-avt-uncomp-video-07] (19 pages) - A More Loss-Tolerant RTP Payload Format for MP3 Audio [draft-ietf-avt-rfc3119bis-06] (0 pages) - RTP payload Format for H.264 Video [draft-ietf-avt-rtp-h264-12] (75 pages) - RTP Payload Format for iLBC Speech [draft-ietf-avt-rtp-ilbc-06] (13 pages) - RTP Payload Format for ITU-T Rec. H.263 Video [draft-ietf-avt-rfc2429-bis-10] (37 pages) - RTP payload format for a 64 kbit/s transparent call [draft-ietf-avt-rtp-clearmode-06] (5 pages) - RTP Payload Format for MPEG1/MPEG2 [draft-ietf-avt-mpeg1and2-mod-00] (15 pages) - G.729.1 RTP Payload Format update: DTX support [draft-ietf-avt-rfc4749-dtx-update-04] (9 pages) - RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Standard ES 202 050 Distributed Speech Recognition Encoding [draft-ietf-avt-dsr-es202050-01] (11 pages) - Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF) [draft-ietf-avt-profile-savpf-13] (18 pages) - RTP Payload Format for MIDI [draft-ietf-avt-rtp-midi-format-16] (181 pages) - An Implementation Guide for RTP MIDI [draft-ietf-avt-rtp-midi-guidelines-16] (40 pages) - Framing RTP and RTCP Packets over Connection-Oriented Transport [draft-ietf-avt-rtp-framing-contrans-07] (11 pages) - RTP Payload for Text Conversation [draft-ietf-avt-rfc2793bis-10] (19 pages) - Registration of the text/red MIME Sub-Type [draft-ietf-avt-text-red-06] (6 pages) - RTP Payload for Text Conversation interleaved in an audio stream [draft-ietf-avt-audio-t140c-01] (19 pages) - RTP Payload Formats for European Telecommunications Standardsv Institute (ETSI) European Standard ES 202 050, ES 202 211, and ES 202 212 Distributed Speech Recognition Encoding [draft-ietf-avt-rtp-dsr-codecs-04] (19 pages) - Requirements for Header Compression over MPLS [draft-ietf-avt-hc-mpls-reqs-04] (10 pages) - Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec [draft-ietf-avt-rtp-vmr-wb-12] (29 pages) - RTP Payload Format for Extended AMR Wideband (AMR-WB+) Audio Codec [draft-ietf-avt-rtp-amrwbplus-08] (38 pages) - RTP with TCP Friendly Rate Control [draft-ietf-avt-tfrc-profile-10] (12 pages) - RTP Payload Format for H.263 using RFC2190 to Historic status [draft-ietf-avt-rfc2190-to-historic-07] (9 pages) - RTP Payload Format for BroadVoice Speech Codecs [draft-ietf-avt-rtp-bv-05] (14 pages) - RTP Payload Format for Adaptive TRansform Acoustic Coding (ATRAC) Family [draft-ietf-avt-rtp-atrac-family-25] (35 pages) - RTP Control Protocol Extended Reports (RTCP XR) VoIP Metrics Management Information Base [draft-ietf-avt-rtcp-xr-mib-06] (41 pages) - Storage File Format for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec [draft-ietf-avt-vmr-wb-file-format-00] (0 pages) - RTP Timestamp Frequency for Variable Rate Audio Codecs [draft-ietf-avt-variable-rate-audio-00] (6 pages) - RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs [draft-ietf-avt-rtp-amr-bis-07] (58 pages) - MIME type registration for RTP Payload format for H.224 [draft-ietf-avt-mime-h224-06] (13 pages) - Definition of Events For Modem, FAX, and Text Telephony Signals [draft-ietf-avt-rfc2833bisdata-09] (51 pages) - Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Header Recovery [draft-ietf-avt-rtp-jpeg2000-beam-12] (33 pages) - RTCP XR - Video Metrics Report Blocks [draft-ietf-avt-rtcpxr-video-02] (0 pages) - A No-Op Payload Format for RTP [draft-ietf-avt-rtp-no-op-04] (12 pages) - Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Extension Audio Codec [draft-ietf-avt-rtp-vmr-wb-extension-03] (0 pages) - Media Type Registration of RTP Payload Formats [draft-ietf-avt-rfc3555bis-06] (12 pages) - Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences [draft-ietf-avt-rfc3555bis-part2-03] (29 pages) - RTP Payload Format for the Speex Codec [draft-ietf-avt-rtp-speex-08] (22 pages) - Protocol Extensions for Header Compression over MPLS [draft-ietf-avt-hc-over-mpls-protocol-09] (32 pages) - A General Mechanism for RTP Header Extensions [draft-ietf-avt-rtp-hdrext-16] (17 pages) - Associating Time-codes with RTP streams [draft-ietf-avt-smpte-rtp-16] (20 pages) - RTP Payload Format for ITU-T Recommendation G.722.1 [draft-ietf-avt-rfc3047-bis-10] (17 pages) - RTP Payload Format for Video Codec 1 (VC-1) [draft-ietf-avt-rtp-vc1-07] (34 pages) - RTP Payload Format for Uncompressed Video: Additional Colour Sampling Modes [draft-ietf-avt-uncomp-video-ext-02] (5 pages) - RTP payload format for the G.729.1 audio codec [draft-ietf-avt-rtp-g729-scal-wb-ext-08] (15 pages) - Enhancements to RTP Payload Formats for EVRC Family Codecs [draft-ietf-avt-compact-bundled-evrc-12] (22 pages) - RTP Payload Format for E-AC-3 Audio [draft-ietf-avt-rtp-eac3-02] (18 pages) - RTP Payload Format for Vorbis Encoded Audio [draft-ietf-avt-rtp-vorbis-10] (25 pages) - Real-time Transport Protocol (RTP) MIB Version 2 [draft-ietf-avt-mib-rtp-bis-01] (32 pages) - How to Write an RTP Payload Format [draft-ietf-avt-rtp-howto-07] (54 pages) - Transmission Time offsets in RTP streams [draft-ietf-avt-rtp-toffset-08] (16 pages) - The use of AES-192 and AES-256 in Secure RTP [draft-ietf-avt-srtp-big-aes-02] (20 pages) - Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) [draft-ietf-avt-avpf-ccm-11] (69 pages) - RTP Topologies [draft-ietf-avt-topologies-08] (23 pages) - Multiplexing RTP Data and Control Packets on a Single Port [draft-ietf-avt-rtp-and-rtcp-mux-07] (15 pages) - RTP Payload Format for ITU-T Recommendation G.711.1 [draft-ietf-avt-rtp-g711wb-04] (15 pages) - RTP Payload Format for SVC Video [draft-ietf-avt-rtp-svc-20] (103 pages) - RTP Payload Format for MIDI [draft-ietf-avt-rfc4695-bis-06] (182 pages) - RTP payload format for Enhanced Variable Rate Wideband Codec (EVRC-WB) and media subtype updates for EVRC-B codec [draft-ietf-avt-rtp-evrc-wb-10] (37 pages) - RTCP HR - High Resolution VoIP Metrics Report Blocks [draft-ietf-avt-rtcphr-03] (45 pages) - Parameters for Static Macroblocks and Aspect Ratio in the RTP Payload Format for H.264 Video [draft-ietf-avt-rtp-h264-params-01] (9 pages) - RTP Payload Format for DV (IEC 61834) Video [draft-ietf-avt-rfc3189bis-04] (17 pages) - RTP payload format for mU-law EMbedded Codec for Low-delay IP communication (UEMCLIP) speech codec [draft-ietf-avt-rtp-uemclip-07] (24 pages) - Application Mechanism for maintaining alive the Network Address Translator (NAT) mappings associated to RTP flows. [draft-ietf-avt-app-rtp-keepalive-06] (10 pages) - Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP) [draft-ietf-avt-dtls-srtp-07] (26 pages) - RTCP XR - Audio Metrics Report Block [draft-ietf-avt-rtcpxr-audio-01] (0 pages) - RTCP XR - MPEG Transport Metrics Report Block [draft-ietf-avt-rtcpxr-mpts-00] (0 pages) - The SEED Cipher Algorithm and Its Use with the Secure Real-time Transport Protocol (SRTP) [draft-ietf-avt-seed-srtp-14] (13 pages) - Forward-shifted RTP Redundancy Payload Support [draft-ietf-avt-forward-shifted-red-02] (13 pages) - Support for Reduced-Size RTCP, Opportunities and Consequences [draft-ietf-avt-rtcp-non-compound-10] (17 pages) - RTP Payload Format for H.264 RCDO Video [draft-ietf-avt-rtp-h264-rcdo-03] (18 pages) - RTP Payload Format for IP-MR Speech Codec draft-ietf-avt-rtp-ipmr-10.txt [draft-ietf-avt-rtp-ipmr-10] (19 pages) - Guidelines for Extending the RTP Control Protocol (RTCP) [draft-ietf-avt-rtcp-guidelines-02] (17 pages) - RTP Payload Format for Elementary Streams with MPEG Surround multi- channel audio [draft-ietf-avt-rtp-mps-04] (13 pages) - RTP Payload format for G.719 [draft-ietf-avt-rtp-g719-05] (28 pages) - Post-Repair Loss RLE Report Block Type for RTCP XR [draft-ietf-avt-post-repair-rtcp-xr-06] (10 pages) - Why RTP Does Not Mandate a Single Security Mechanism [draft-ietf-avt-srtp-not-mandatory-03] (10 pages) - RTP Payload Format for H.264 Video [draft-ietf-avt-rtp-rfc3984bis-08] (105 pages) - Unicast-Based Rapid Acquisition of Multicast RTP Sessions [draft-ietf-avt-rapid-acquisition-for-rtp-04] (48 pages) - RTP payload format for G.718 speech/audio [draft-ietf-avt-rtp-g718-02] (32 pages) - RTCP XR Report Block for Burst/Gap Loss metric Reporting [draft-ietf-avt-rtcp-xr-burst-gap-loss-02] (17 pages) - RTCP XR Report Block for Burst/Gap Discard metric Reporting [draft-ietf-avt-rtcp-xr-burst-gap-discard-02] (17 pages) - RTCP XR Report Block for Post-Repair Loss metric Reporting [draft-ietf-avt-rtcp-xr-postrepair-loss-02] (14 pages) - RTCP XR Report Block for Packet Delay Variation Metric Reporting [draft-ietf-avt-rtcp-xr-pdv-03] (15 pages) - RTCP XR Report Block for Measurement Identity [draft-ietf-avt-rtcp-xr-meas-identity-02] (13 pages) - RTCP XR Report Block for Loss Concealment metric Reporting [draft-ietf-avt-rtcp-xr-loss-conceal-02] (15 pages) - RTCP XR Report Block for Jitter Buffer Metric Reporting [draft-ietf-avt-rtcp-xr-jb-02] (13 pages) - RTCP XR Report Block for Discard metric Reporting [draft-ietf-avt-rtcp-xr-discard-02] (14 pages) - RTCP XR Report Block for Delay metric Reporting [draft-ietf-avt-rtcp-xr-delay-02] (14 pages) - RTCP XR Report Block for Concealed Seconds metric Reporting [draft-ietf-avt-rtcp-xr-concsec-02] (16 pages) - RTCP XR Report Block for QoE Metrics Reporting [draft-ietf-avt-rtcp-xr-qoe-00] (7 pages) - RTCP XR Report Block for Signal Level Metrics Reporting [draft-ietf-avt-rtcp-xr-siglevel-00] (9 pages) - Rapid Synchronisation of RTP Flows [draft-ietf-avt-rapid-rtp-sync-06] (21 pages) - RTP Payload format for GSM-HR [draft-ietf-avt-rtp-gsm-hr-02] (18 pages) - AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) [draft-ietf-avt-srtp-aes-gcm-00] (17 pages) Requests for Comments: RFC1889: RTP: A Transport Protocol for Real-Time Applications (75 pages) * OBSOLETED BY RFC3550 RFC1890: RTP Profile for Audio and Video Conferences with Minimal Control (18 pages) * OBSOLETED BY RFC3551 RFC2035: RTP Payload Format for JPEG-compressed Video (16 pages) * OBSOLETED BY RFC2435 RFC2032: RTP payload format for H.261 video streams (11 pages) * OBSOLETED BY RFC4587 RFC2038: RTP Payload Format for MPEG1/MPEG2 Video (11 pages) * OBSOLETED BY RFC2250 RFC2029: RTP Payload Format of Sun's CellB Video Encoding (6 pages) RFC2190: RTP Payload Format for H.263 Video Streams (12 pages) RFC2198: RTP Payload for Redundant Audio Data (10 pages) RFC2250: RTP Payload Format for MPEG1/MPEG2 Video (16 pages) * Obsoletes RFC2038 RFC2343: RTP Payload Format for Bundled MPEG (8 pages) RFC2354: Options for Repair of Streaming Media (12 pages) RFC2429: RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+) (17 pages) RFC2431: RTP Payload Format for BT.656 Video Encoding (10 pages) RFC2435: RTP Payload Format for JPEG-compressed Video (27 pages) * Obsoletes RFC2035 RFC2508: Compressing IP/UDP/RTP Headers for Low-Speed Serial Links (24 pages) RFC2733: An RTP Payload Format for Generic Forward Error Correction (26 pages) * OBSOLETED BY RFC5109 RFC2736: Guidelines for Writers of RTP Payload Format Specifications (10 pages) RFC2762: Sampling of the Group Membership in RTP (12 pages) RFC2793: RTP Payload for Text Conversation (10 pages) * OBSOLETED BY RFC4103 RFC2833: RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals (30 pages) * OBSOLETED BY RFC4733 RFC2862: RTP Payload Format for Real-Time Pointers (7 pages) RFC2959: Real-Time Transport Protocol Management Information Base (31 pages) RFC3009: Registration of parityfec MIME types (10 pages) * OBSOLETED BY RFC5109 RFC3016: RTP payload format for MPEG-4 Audio/Visual streams (21 pages) RFC3047: RTP Payload Format for ITU-T Recommendation G.722.1 (8 pages) * OBSOLETED BY RFC5577 RFC3119: A More Loss-Tolerant RTP Payload Format for MP3 Audio (19 pages) * OBSOLETED BY RFC5219 RFC3158: RTP Testing Strategies (22 pages) RFC3189: RTP Payload Format for DV Format Video (13 pages) RFC3190: RTP Payload Format for 12-bit DAT, 20- and 24-bit Linear Sampled Audio (17 pages) RFC3267: RTP payload format and file storage format for the Adoptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) audio codecs (49 pages) * OBSOLETED BY RFC4867 RFC3389: RTP Payload for Comfort Noise (8 pages) RFC3497: RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video (12 pages) RFC3550: RTP: A Transport Protocol for Real-Time Applications (104 pages) * Obsoletes RFC1889 * Updated by RFC5506 RFC3551: RTP Profile for Audio and Video Conferences with Minimal Control (44 pages) * Obsoletes RFC1890 RFC3555: MIME Type Registration of RTP Payload Formats (45 pages) * Updated by RFC3625 * OBSOLETED BY RFC4855 * OBSOLETED BY RFC4856 RFC3556: Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth (8 pages) RFC3557: RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Standard ES 201 108 Distributed Speech Recognition Encoding (15 pages) RFC3558: RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders SMV (23 pages) * Updated by RFC4788 RFC3545: Enhanced Compressed RTP (CRTP) for links with High Delay,Packet Loss and Reordering (22 pages) RFC3611: RTP Control Protocol Extended Reports (RTCP XR) (53 pages) RFC3640: RTP Payload Format for Transport of MPEG-4 Elementary Streams (41 pages) * Updated by RFC5691 RFC3711: The Secure Real-time Transport Protocol (56 pages) * Updated by RFC5506 RFC3951: Internet Low Bit Rate Codec (174 pages) RFC3952: RTP Payload Format for iLBC Speech (13 pages) RFC3984: RTP payload Format for H.264 Video (75 pages) RFC4040: RTP payload format for a 64 kbit/s transparent call (5 pages) RFC4060: RTP Payload Formats for European Telecommunications Standardsv Institute (ETSI) European Standard ES 202 050, ES 202 211, and ES 202 212 Distributed Speech Recognition Encoding (19 pages) RFC4102: Registration of the text/red MIME Sub-Type (6 pages) RFC4103: RTP Payload for Text Conversation (19 pages) * Obsoletes RFC2793 RFC4175: RTP Payload Format for Uncompressed Video (19 pages) * Updated by RFC4421 RFC4184: RTP Payload Format for AC-3 Audio (11 pages) RFC4247: Requirements for Header Compression over MPLS (10 pages) RFC4170: Tunneling Multiplexed Compressed RTP (TCRTP) (22 pages) RFC4298: RTP Payload Format for BroadVoice Speech Codecs (14 pages) RFC4348: Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec (29 pages) * Updated by RFC4424 RFC4351: Real-Time Transport Protocol (RTP) Payload for Text Conversation Interleaved in an Audio Stream (19 pages) RFC4352: RTP Payload Format for the Extended Adaptive Multi-Rate Wideband (AMR-WB+) Audio Codec (38 pages) RFC4396: RTP Payload Format for 3rd Generation Partnership Project (3GPP) Timed Text (59 pages) RFC4421: RTP Payload Format for Uncompressed Video: Additional Colour Sampling Modes (5 pages) * Updates RFC4175 RFC4425: RTP Payload Format for Video Codec 1 (VC-1) (34 pages) RFC4424: Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Extension Audio Codec (0 pages) * Updates RFC4348 RFC4573: MIME Type Registration for RTP Payload Format for H.224 (13 pages) RFC4585: Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) (52 pages) * Updated by RFC5506 RFC4571: Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport (11 pages) RFC4588: RTP Retransmission Payload Format (32 pages) RFC4598: Real-time Transport Protocol (RTP) Payload Format for Enhanced AC-3 (E-AC-3) Audio (18 pages) RFC4587: RTP Payload Format for H.261 Video Streams (24 pages) * Obsoletes RFC2032 RFC4749: RTP Payload Format for the G.729.1 Audio Codec (15 pages) * Updated by RFC5459 RFC4696: An Implementation Guide for RTP MIDI (40 pages) RFC4695: RTP Payload Format for MIDI (181 pages) RFC4734: Definition of Events For Modem, FAX, and Text Telephony Signals (51 pages) RFC4733: RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals (57 pages) * Obsoletes RFC2833 * Updated by RFC5244 RFC4788: Enhancements to RTP Payload Formats for EVRC Family Codecs (22 pages) * Updates RFC3558 * Updated by RFC5188 RFC4628: RTP Payload Format for H.263 using RFC2190 to Historic status (9 pages) RFC4629: RTP Payload Format for ITU-T Rec. H.263 Video (37 pages) RFC4855: Media Type Registration of RTP Payload Formats (12 pages) * Obsoletes RFC3555 RFC4856: Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences (29 pages) * Obsoletes RFC3555 RFC4867: RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs (58 pages) * Obsoletes RFC3267 RFC4901: Protocol Extensions for Header Compression over MPLS (32 pages) RFC5109: RTP Payload Format for Generic Forward Error Correction (43 pages) * Obsoletes RFC2733 * Obsoletes RFC3009 RFC5117: RTP Topologies (23 pages) RFC5219: A More Loss-Tolerant RTP Payload Format for MP3 Audio (0 pages) * Obsoletes RFC3119 RFC5188: RTP payload format for Enhanced Variable Rate Wideband Codec (EVRC-WB) and media subtype updates for EVRC-B codec (37 pages) * Updates RFC4788 RFC5104: Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) (69 pages) RFC5124: Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF) (18 pages) RFC5244: Definition of Events For Channel-Oriented Telephony Signalling (23 pages) * Updates RFC4733 RFC5285: A General Mechanism for RTP Header Extensions (17 pages) RFC5215: RTP Payload Format for Vorbis Encoded Audio (26 pages) RFC5372: Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Header Recovery (33 pages) RFC5371: RTP Payload Format for JPEG 2000 Video Streams (37 pages) RFC5391: RTP Payload Format for ITU-T Recommendation G.711.1 (14 pages) RFC5404: RTP Payload Format for G.719 (27 pages) RFC5459: G.729.1 RTP Payload Format Update: Discontinuous Transmission (DTX) Support (7 pages) * Updates RFC4749 RFC5484: Associating Time-Codes with RTP Streams (13 pages) RFC5450: Transmission Time offsets in RTP streams (16 pages) RFC5506: Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences (17 pages) * Updates RFC3550 * Updates RFC3711 * Updates RFC4585 RFC5574: RTP Payload Format for the Speex Codec (14 pages) RFC5577: RTP Payload Format for ITU-T Recommendation G.722.1 (11 pages) * Obsoletes RFC3047 RFC5584: RTP Payload Format for Adaptive TRansform Acoustic Coding (ATRAC) Family (30 pages) RFC5691: RTP Payload Format for Elementary Streams with MPEG Surround multi- channel audio (13 pages) * Updates RFC3640 RFC5686: RTP Payload Format for mU-law EMbedded Codec for Low-delay IP communication (UEMCLIP) speech codec (24 pages) Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- Charter Last Modified: 2009-10-13 Current Status: Active Chairs: Dave Thaler Dan Wing Transport Area Directors: Magnus Westerlund Lars Eggert Transport Area Advisor: Magnus Westerlund Mailing Lists: General Discussion: behave@ietf.org To Subscribe: behave-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/behave Description of Working Group: The behavior of NATs varies from one implementation to another. As a result it is very difficult for applications to predict or discover the behavior of these devices. Predicting and/or discovering the behavior of NATs is important for designing application protocols and NAT traversal techniques that work reliably in existing networks. This situation is especially problematic for end-to-end applications where one or both end-points are behind a NAT, such as multiuser games, interactive multimedia and P2P download. The working group documents best current practices to enable NATs to function in as deterministic a fashion as possible. The NAT behavior practices will be application independent. This has already completed for UDP, TCP, DCCP, Multicast and ICMP. It continues with SCTP and any additional protocol deemed necessary to handle. The WG has documented approaches for characterizing and testing NAT devices. BEHAVE will develop protocol-independent toolkits usable by application protocols for NAT traversal. The WG has already produced an update of the binding discovery protocol STUN. It will now produce a relay protocol that focuses on security and is usable with both IPv4 and IPv6, and capable of relaying between the two IP versions. Due to the WG's experience with translators and their behavior it has been given the following tasks to help encourage migration to IPv6. To support deployments where communicating hosts require using different address families (IPv4 or IPv6), address family translation is needed to establish communication. In BEHAVE's specification work on this topic it will coordinate with the V6ops WG on requirements and operational considerations. "An IPv4 network" or "an IPv6 network" in the descriptions below refer to a network with a clearly identifiable administrative domain (e.g., an enterprise campus network, a mobile operator's cellular network, a residential subscriber network, etc.). It will also be that network that deploys the necessary equipment for translation. The BEHAVE WG will design solutions for the following six translation scenarios; other scenarios are out of scope: 1. An IPv6 network to IPv4 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv6 host towards an IPv4 host. The translator function is intended to service a specific IPv6 network of arbitary size. Port translation is necessary on the IPv4 side for efficient IPv4 address usage. 2. IPv6 Internet to an IPv4 network, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv6 host towards an IPv4 host. The translator function is intended to service a specific IPv4 network using either private or public IPv4 addresses. This scenario has different constraints compared to (1), e.g. the IPv4 hosts that are to be reachable over IPv6 can be enumerated. Therefore, the WG should attempt to design a simpler solution with less impact on applications. 3. An IPv4 network to IPv6 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv4 network using either public or private IPv4 address space. 4. IPv4 Internet to an IPv6 network, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv6 network where selected IPv6 hosts and services are to be reachable. 5. An IPv6 network to an IPv4 network, i.e., perform translation between IPv6 and IPv4 for packets in uni- or bi-directional flows that are initiated from an IPv6 host towards an IPv4 host. The translation function is intended to service a specific IPv6 network of arbitrary size and a specific IPv4 network of arbitrary size (neither of which are the Internet). 6. An IPv4 network to an IPv6 network, i.e., perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translation function is intended to service a specific IPv6 network of arbitrary size and a specific IPv4 network of arbitrary size (neither of which are the Internet). All translation solutions shall be capable of handling flows using TCP, UDP, DCCP, and SCTP, unless they prevent a timely completion of the work item. The parts of ICMP that can be translated are also required to work across a translation solution. Additional protocols directly on top of IP may be supported. Translation mechanisms must handle IP fragmentation. The translators should support multicast traffic and its control traffic (IGMP and MLD) across them, both Single Source Multicast (SSM) and Any Source Multicast (ASM). However, the WG may determine that it becomes too complex or too difficult to realize with maintained functionality, for some or all cases of multicast functionality. Translation mechanisms cannot transparently support protocols that embed network addresses within their protocol messages without application level gateways (ALGs). Because ALGs have security issues (like blocking usage of TLS), are error prone and brittle, and hinder application development, the usage of ALGs in the defined translators should be avoided. Instead application developers will need to be aware and use mechanisms that handle the address family translation. ALGs may be considered only for the most crucial of legacy applications. DNS is a crucial part in making a large number of applications work across a translator. Thus the solution to the above translation cases shall include recommendations for DNS. If additional DNS functionality is needed, it may be developed. Any DNS extensions must be developed together with the DNSEXT WG, including issuing a joint WG last call for any documents. The WG needs to determine the best method for providing address space to a translator in the different deployment cases and documenting the pros and cons of the suggested approaches. The WG is to seek input from the Routing, Operations and Internet areas. Solutions may solve more than one of the cases, however timely delivery is more important than a unified solution. Goals and Milestones: Done - Submit BCP that defines unicast UDP behavioral requirements for NATs to IESG Done - Submit a BCP that defines TCP behavioral requireents for NATs to IESG Done - Submit a BCP that defines ICMP behavioral requirements for NATs to IESG Done - Submit informational that discusses current NAT traversal techniques used by applications Done - Submit BCP that defines multicast UDP Done - Submit revision of RFC 3489 to IESG behavioral requirements for NATs to IESG Done - Submit informational document for rfc3489bis test vectors Done - Submit experimental document that describes how an application can determine the type of NAT it is behind Done - Submit BCP document for DCCP NAT behavior Done - Determine relative prioritization of the four translation cases. Documented in IETF74 minutes. Done - Determine what solutions(s) and components are needed to solve each of the four cases. Create new milestones for the solution(s) and the components. Documented in IETF74 minutes. Sep 2009 - Submit to IESG: relaying of a TCP bytestream (std) Done - Submit to IESG: relay protocol (std) Done - Submit to IESG: TURN-URI document (std) Dec 2009 - Submit to IESG: SCTP NAT behavior (BCP) Dec 2009 - Submit to IESG: IPv6 relay protocol (std) Dec 2009 - Submit to IESG: framework for IPv6/IPv4 translation (info) Dec 2009 - Submit to IESG: stateless IPv6/IPv4 translation (std) Dec 2009 - Submit to IESG: stateful IPv6/IPv4 translation (std) Dec 2009 - Submit to IESG: DNS rewriting for IPv6/IPv4 translation (std) Jan 2010 - Submit to IESG: FTP ALG for IPv6/IPv4 translation (std) Jan 2010 - Submit to IESG: IPv6 prefix for IPv6/IPv4 translator (std) Mar 2010 - Submit to IESG: large scale NAT requirements (BCP) Internet-Drafts: - Test vectors for STUN [draft-ietf-behave-stun-test-vectors-04] (11 pages) - Session Traversal Utilities for NAT (STUN) [draft-ietf-behave-rfc3489bis-19] (51 pages) - NAT Behavioral Requirements for Unicast UDP [draft-ietf-behave-nat-01] (24 pages) - NAT Behavioral Requirements for Unicast UDP [draft-ietf-behave-nat-udp-09] (29 pages) - IP Multicast Requirements for a Network Address (and port) Translator (NAT) [draft-ietf-behave-multicast-13] (17 pages) - NAT Behavioral Requirements for TCP [draft-ietf-behave-tcp-09] (21 pages) - Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) [draft-ietf-behave-turn-16] (81 pages) - Traversal Using Relays around NAT (TURN) Extension for IPv6 [draft-ietf-behave-turn-ipv6-07] (13 pages) - NAT Behavioral Requirements for ICMP protocol [draft-ietf-behave-nat-icmp-13] (27 pages) - State of Peer-to-Peer(P2P) Communication Across Network Address Translators(NATs) [draft-ietf-behave-p2p-state-07] (32 pages) - NAT Behavior Discovery Using STUN [draft-ietf-behave-nat-behavior-discovery-08] (31 pages) - Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations [draft-ietf-behave-turn-tcp-05] (13 pages) - Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol [draft-ietf-behave-dccp-06] (11 pages) - Stream Control Transmission Protocol (SCTP) Network Address Translation [draft-ietf-behave-sctpnat-02] (24 pages) - Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers [draft-ietf-behave-turn-uri-03] (14 pages) - IP/ICMP Translation Algorithm [draft-ietf-behave-v6v4-xlate-03] (24 pages) - DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers [draft-ietf-behave-dns64-02] (30 pages) - NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers [draft-ietf-behave-v6v4-xlate-stateful-02] (40 pages) - Framework for IPv4/IPv6 Translation [draft-ietf-behave-v6v4-framework-03] (30 pages) - IPv6 Addressing of IPv4/IPv6 Translators [draft-ietf-behave-translator-addressing-01] (24 pages) - IPv6 Addressing of IPv4/IPv6 Translators [draft-ietf-behave-address-format-01] (15 pages) Requests for Comments: RFC4787: Network Address Translation (NAT) Behavioral Requirements for Unicast UDP (29 pages) RFC5135: IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) (17 pages) RFC5128: State of Peer-to-Peer(P2P) Communication Across Network Address Translators(NATs) (32 pages) RFC5382: NAT Behavioral Requirements for TCP (21 pages) RFC5389: Session Traversal Utilities for NAT (STUN) (51 pages) * Obsoletes RFC3489 RFC5508: NAT Behavioral Requirements for ICMP (29 pages) RFC5597: Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol (9 pages) Bidirectional Forwarding Detection (bfd) ---------------------------------------- Charter Last Modified: 2008-07-21 Current Status: Active Chairs: David Ward Jeffrey Haas Routing Area Directors: Ross Callon Adrian Farrel Routing Area Advisor: Ross Callon Tech Advisor: Dave Katz Mailing Lists: General Discussion: rtg-bfd@ietf.org To Subscribe: rtg-bfd-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/rtg-bfd/ Description of Working Group: The BFD Working Group is chartered to specify a protocol for bidirectional forwarding detection (BFD), as well as extensions to be used within the scope of BFD and IP routing, or protocols such as MPLS that are based on IP routing, in a way that will encourage multiple, inter-operable vendor implementations. BFD is a protocol intended to detect faults in the bidirectional path between two forwarding engines, including physical interfaces, subinterfaces, 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. An additional goal is to provide a single mechanism that can be used for liveness detection over any media, at any protocol layer, with a wide range of detection times and overhead, to avoid a proliferation of different methods. Important characteristics of BFD include: - Simple, fixed-field encoding to facilitate implementations in hardware - Independence of the data protocol being forwarded between two systems. BFD packets are carried as the payload of whatever encapsulating protocol is appropriate for the medium and network. - Path independence: BFD can provide failure detection on any kind of path between systems, including direct physical links, virtual circuits, tunnels, MPLS LSPs, multihop routed paths, and unidirectional links (so long as there is some return path, of course.) - Ability to be bootstrapped by any other protocol that automatically forms peer, neighbor or adjacency relationships to seed BFD endpoint discovery. At this time the WG is chartered to complete the following work items (additional items will require rechartering): 1. Develop the base BFD protocol specification and submit it to the IESG for publication as a Proposed Standard 2. Document BFD encapsulation and usage profile for single-hop IPv4 and IPv6 adjacencies (e.g, physical links and IP/GRE tunnels for static routes, IS-IS, OSPFv2, OSPFv3, single-hop BGP) and submit the specification to the IESG for publication as a Proposed Standard. 3. Document BFD encapsulation and usage profile for MPLS LSPs and submit the specification to the IESG for publication as a Proposed Standard. 4. Develop the MIB module for BFD and submit it to the IESG for publication as a Proposed Standard. 5. Document BFD encapsulation and usage profile for multi-hop IPv4 and IPv6 adjacencies (e.g. OSPF virtual links and iBGP sessions) and submit the specification to the IESG for publication as a Proposed Standard. Topics for Possible Future Work: 1. Document BFD directly over 802.3 in close collaboration and synchronization with the IEEE. Goals and Milestones: Aug 2004 - Submit the base protocol specification to the IESG to be considered as a Proposed Standard. Aug 2004 - Submit BFD encapsulation and usage profile for single-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Aug 2004 - Submit BFD encapsulation and usage profile for MPLS LSPs to the IESG to be considered as a Proposed Standard Nov 2004 - Submit BFD MIB to the IESG to be considered as Proposed Standard. Feb 2005 - Submit BFD encapsulation and usage profile for multi-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Internet-Drafts: - BFD Management Information Base [draft-ietf-bfd-mib-07] (31 pages) - BFD For MPLS LSPs [draft-ietf-bfd-mpls-07] (13 pages) - Bidirectional Forwarding Detection [draft-ietf-bfd-base-09] (49 pages) - BFD for Multihop Paths [draft-ietf-bfd-multihop-08] (7 pages) - BFD for IPv4 and IPv6 (Single Hop) [draft-ietf-bfd-v4v6-1hop-10] (7 pages) - Generic Application of BFD [draft-ietf-bfd-generic-05] (18 pages) - BFD for Multipoint Networks [draft-katz-ward-bfd-multipoint-03] (29 pages) No Requests for Comments Basic Level of Interoperability for SIP Services (bliss) -------------------------------------------------------- Charter Last Modified: 2009-09-25 Current Status: Active Chairs: Shida Schubert Scott Lawrence <> Real-time Applications and Infrastructure Area Directors: Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Robert Sparks Tech Advisor: Jonathan Rosenberg Mailing Lists: General Discussion: bliss@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/bliss Archive: http://www.ietf.org/mail-archive/web/bliss Description of Working Group: The focus of the group is to facilitate effective feature interoperability for features sharing common functional primitives utilizing SIP in heterogeneous network environments as noted below. SIP's approach to supporting more advanced features and applications has been to specify a number of primitive operations, including refer, dialog replacement and joining, and event packages, and then to allow those primitives to be combined in many ways to realize different features. This approach avoids the need for standardized definitions of a feature, which can severely limit innovation and broad applicability. While this approach brings great flexibility and generality, it complicates interoperability. Without any kind of standardized definition of a particular feature, each implementation creates its own definition and corresponding set of call flows and primitives used to realize this feature. In practice, this has resulted in a poor track record for interoperability for more advanced features which make assumptions on supported SIP extensions and behaviors from other elements. The problem is exacerbated by the desire for these features to work across many types of SIP endpoints, including SIP hardphones, softphones, and gateways to the PSTN and other VoIP networks including non-centralized environments, and for the desire to work across domain boundaries and to interwork with the PSTN, when applicable. The focus will not be on rigorous definition of what the specific feature is and exactly how it works. Rather, the focus will be on documenting the variations that exist in the wild sharing common interop problems, figuring out a minimum baseline requirement for a UA and servers (minimum set of primitives etc.), defining minimum levels of functionality and functional primitives required to realize a broad class of related features, and on interoperating with other elements which might implement one of those features in different ways. The BLISS working group will coordinate closely with the SIP and SIPPING working groups. Like SIPPING, its role is to focus on applications of the SIP protocol and not on core extensions to SIP itself. The difference between SIPPING and BLISS, is that BLISS is focused on a particular type of SIP application - call features, and in particular, advanced call features requiring non-trivial call control. SIP applications such as configuration, presence, SIP extensions for IM, and session policy are clearly out of scope for BLISS and remain the sole province of SIPPING. Of course, any features considered by BLISS will support the full range of multimedia supported by SIP - audio, video, text, messaging, and so on. The BLISS working group will focus on resolving interpretability issues on four functional primitives as an initial milestone. Summary for each of the functional primitives are as follows. A "Problem Statement" document will also be charted as the first deliverable of this working group. This document will describe the problem this working group is trying to address, the criteria to be met for items to be accepted and a template for documenting a draft for this working group. Line Sharing Description: this covers the functionality required for multiple UA instances to be able to see and utilize sessions made to/from either one. It covers a range of features including: * multiple call appearances * call suspend/resume * retrieve * conference across appearances Parking Description: this covers functionality required to move calls from one instance to another without pre-arranged knowledge of the set of instances on which the call is to be shared. Basically a dynamic version of line sharing in a sense. It would cover features including: * park * parked retrieval * directed park * directed pickup Automated Handling Description: this covers functionality required for a user to indicate, asynchronously from the time of a call, what the handling of a future call should be. It covers the rules on who implements the processing and how it is signaled. Covers features including: * DND * CFU * CFNA Call Queuing Description: this covers functionality required to queue a call when the callee is not available, handling of a queue and notifying when callee is ready to receive a call. Covers features including: * CCBS * CCNR Guiding principles for this working group work will include: - Identify functional primitives with interoperability issues, based on an analysis of variations of features sharing same or similar functional primitives within heterogeneous network(s). Provide a clear description of any interoperability problems that are identified by documenting the variations that exist in the wild for features that is already implemented. - Document minimum baseline requirements relevant to the functional requirements for addressing the interoperability issue. Criteria to consider: * who is responsible for invoking? * who is responsible for implementing? * how does the functional primitive interact with multiple media types? * how does the functional primitive work between administrative domains? - Initiate analysis of the pros and cons of key approaches to addressing the requirements. - Where the requirements can be satisfied within the capabilities of the current standards, produce BCPs [and appropriate call-flows] to document the best approach. - Where normal event packages or SIP uri parameter is all what's needed to prevent interoperability issues, appropriate extensions and its usage would be defined and documented. - Where extensions to standards are required beyond what's mentioned above, bring the analysis, requirements and need for new extensions to the appropriate working group (SIP, SIPPING or SIMPLE). - As in the SIPPING charter, the security of all the deliverables will be of special importance. *Deliverable may attempt to... 1. Define a single approach to solve the problem. 2. Allow variations but mandate support for more than one mechanism. 3. Demonstrate that interoperability is possible even when entities provide the feature with the functional primitive differently. Goals and Milestones: Apr 2008 - Submit Problem Statement to the IESG as Informational RFC Apr 2008 - Submit Automated Handling to the IESG as BCP Aug 2008 - Submit Parking to the IESG as BCP Aug 2008 - Submit Call Queing to the IESG as BCP Oct 2008 - Submit Line Sharing to the IESG as BCP Internet-Drafts: - Basic Level of Interoperability for Session Initiation Protocol (SIP) Services (BLISS) Problem Statement [draft-ietf-bliss-problem-statement-05] (20 pages) - Call Completion for Session Initiation Protocol (SIP) [draft-ietf-bliss-call-completion-05] (30 pages) - An Analysis of Automatic Call Handling Implementation Issues in the Session Initiation Protocol (SIP) [draft-ietf-bliss-ach-analysis-05] (19 pages) - Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR) [draft-ietf-bliss-shared-appearances-04] (65 pages) - Implementing Call Park and Retrieve using the Session Initiation Protocol (SIP) [draft-ietf-bliss-call-park-extension-01] (19 pages) No Requests for Comments Benchmarking Methodology (bmwg) ------------------------------- Charter Last Modified: 2009-10-19 Current Status: Active Chair: Al Morton Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Ronald Bonica Mailing Lists: General Discussion: bmwg@ietf.org To Subscribe: bmwg-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/bmwg/index.html Description of Working Group: The major goal of the Benchmarking Methodology Working Group is to make a series of recommendations concerning the measurement of the performance characteristics of various internetworking technologies; further, these recommendations may focus on the systems or services that are built from these technologies. Each recommendation will describe the class of equipment, system, or service being addressed; discuss the performance characteristics that are pertinent to that class; clearly identify a set of metrics that aid in the description of those characteristics; specify the methodologies required to collect said metrics; and lastly, present the requirements for the common, unambiguous reporting of benchmarking results. To better distinguish the BMWG from other measurement initiatives in the IETF, the scope of the BMWG is limited to technology characterization using simulated stimuli in a laboratory environment. Said differently, the BMWG does not attempt to produce benchmarks for live, operational networks. Moreover, the benchmarks produced by this WG shall strive to be vendor independent or otherwise have universal applicability to a given technology class. Because the demands of a particular technology may vary from deployment to deployment, a specific non-goal of the Working Group is to define acceptance criteria or performance requirements. An ongoing task is to provide a forum for discussion regarding the advancement of measurements designed to provide insight on the operation inter-networking technologies. In addition to its current work plan, the BMWG is explicitly tasked to develop benchmarks and methodologies for the following technologies: * MPLS Forwarding: Develop specific methods to characterize the latency and forwarding performance of MPLS devices, extending the fundamental recommendations of RFC 1242 and RFC 2544 to this networking technology. * SIP Networking Devices: Develop new terminology and methods to characterize the key performance aspects of network devices using SIP, including the signaling plane scale and service rates while considering load conditions on both the signaling and media planes. This work will be harmonized with related SIP performance metric definitions prepared by the PMOL working group. Goals and Milestones: Done - Expand the current Ethernet switch benchmarking methodology draft to define the metrics and methodologies particular to the general class of connectionless, LAN switches. Done - Edit the LAN switch draft to reflect the input from BMWG. Issue a new version of document for comment. If appropriate, ascertain consensus on whether to recommend the draft for consideration as an RFC. Done - Take controversial components of multicast draft to mailing list for discussion. Incorporate changes to draft and reissue appropriately. Done - Submit workplan for initiating work on Benchmarking Methodology for LAN Switching Devices. Done - Submit workplan for continuing work on the Terminology for Cell/Call Benchmarking draft. Done - Submit initial draft of Benchmarking Methodology for LAN Switches. Done - Submit Terminology for IP Multicast Benchmarking draft for AD Review. Done - Submit Benchmarking Terminology for Firewall Performance for AD review Done - Progress ATM benchmarking terminology draft to AD review. Done - Submit Benchmarking Methodology for LAN Switching Devices draft for AD review. Done - Submit first draft of Firewall Benchmarking Methodology. Done - First Draft of Terminology for FIB related Router Performance Benchmarking. Done - First Draft of Router Benchmarking Framework Done - Progress Frame Relay benchmarking terminology draft to AD review. Done - Methodology for ATM Benchmarking for AD review. Done - Terminology for ATM ABR Benchmarking for AD review. Done - Terminology for FIB related Router Performance Benchmarking to AD review. Done - Firewall Benchmarking Methodology to AD Review Done - First Draft of Methodology for FIB related Router Performance Benchmarking. Done - First draft Net Traffic Control Benchmarking Methodology. Done - Methodology for IP Multicast Benchmarking to AD Review. Done - Resource Reservation Benchmarking Terminology to AD Review Done - First I-D on IPsec Device Benchmarking Terminology Done - EGP Convergence Benchmarking Terminology to AD Review Done - Resource Reservation Benchmarking Methodology to AD Review Done - Net Traffic Control Benchmarking Terminology to AD Review Done - IGP/Data-Plane Terminology I-D to AD Review Done - IGP/Data-Plane Methodology and Considerations I-Ds to AD Review Done - Hash and Stuffing I-D to AD Review Done - IPv6 Benchmarking Methodology to AD Review Done - IPsec Device Benchmarking Terminology to IESG Review Done - IPsec Device Benchmarking Methodology to IESG Review Dec 2008 - Net Traffic Control Benchmarking Methodology to AD Review. Dec 2008 - Router Accelerated Test Terminology to IESG Review Dec 2008 - Router Accelerated Test Methodology to IESG Review Feb 2009 - Terminology For Protection Benchmarking to AD Review Feb 2009 - Methodology For Protection Benchmarking to AD Review Done - Methodology for MPLS Forwarding to AD Review Jun 2009 - Terminology for SIP Device Benchmarking to IESG Review Jun 2009 - Methodology for SIP Device Benchmarking to IESG Review Dec 2009 - Router Accelerated Test Method for EBGP to IESG Review Dec 2009 - Router Accelerated Test Method for Operational Security to IESG Review Jul 2010 - Basic BGP Convergence Benchmarking Methodology to AD Review. Internet-Drafts: - Benchmarking Terminology for Network Interconnection Devices [draft-ietf-bmwg-terms-02] (0 pages) - Benchmarking Methodology for Network Interconnect Devices [draft-ietf-bmwg-methodology-03] (23 pages) - Benchmarking Methodologies for Overall Network Performance [draft-ietf-bmwg-overallperf-00] (6 pages) - Benchmarking Methodology for Ethernet Switches [draft-ietf-bmwg-ethernet-switches-01] (13 pages) - Benchmarking Terminology for LAN Switching Devices [draft-ietf-bmwg-lanswitch-07] (25 pages) - Terminology for Cell/Call Benchmarking [draft-ietf-bmwg-call-04] (29 pages) - Connectivity [draft-ietf-bmwg-ippm-connect-00] (9 pages) - Terminology for IP Multicast Benchmarking [draft-ietf-bmwg-mcast-09] (15 pages) - Benchmarking Terminology for Firewall Performance [draft-ietf-bmwg-secperf-09] (23 pages) - Benchmarking Methodology for LAN Switching Devices [draft-ietf-bmwg-mswitch-05] (34 pages) - Terminology for Frame Relay Benchmarking [draft-ietf-bmwg-fr-term-06] (24 pages) - Methodology for IP Multicast Benchmarking [draft-ietf-bmwg-mcastm-15] (31 pages) - Terminology for ATM Benchmarking [draft-ietf-bmwg-atm-term-01] (29 pages) - Methodology for ATM Benchmarking [draft-ietf-bmwg-atm-method-03] (168 pages) - Terminology for ATM ABR Benchmarking [draft-ietf-bmwg-atm-term-abr-03] (18 pages) - Terminology for Forwarding Information Base (FIB) based Router Performance [draft-ietf-bmwg-fib-term-04] (13 pages) - Framework for Router Benchmarking [draft-ietf-bmwg-rtr-framework-00] (8 pages) - Benchmarking Methodology for Firewall Performance [draft-ietf-bmwg-firewall-08] (30 pages) - Terminology for Benchmarking Network-layer Traffic Control Mechanisms [draft-ietf-bmwg-dsmterm-14] (32 pages) - Benchmarking Terminology for Resource Reservation Capable Routers [draft-ietf-bmwg-benchres-term-09] (22 pages) - Benchmarking Methodology for Routers Supporting Resource Reservation [draft-ietf-bmwg-benchres-method-00] (15 pages) - Terminology for Benchmarking BGP Device Convergence in the Control Plane [draft-ietf-bmwg-conterm-07] (35 pages) - Benchmarking Methodology for Basic BGP Convergence [draft-ietf-bmwg-bgpbas-01] (16 pages) - Methodology for Forwarding Information Base (FIB) based Router Performance [draft-ietf-bmwg-fib-meth-03] (13 pages) - OSPF Benchmarking Terminology and Concepts [draft-ietf-bmwg-ospfconv-term-11] (10 pages) - Benchmarking Basic OSPF Single Router Control Plane Convergence [draft-ietf-bmwg-ospfconv-intraarea-11] (16 pages) - Considerations When Using Basic OSPF Convergence Benchmarks [draft-ietf-bmwg-ospfconv-applicability-08] (12 pages) - Terminology for Benchmarking IPsec Devices [draft-ietf-bmwg-ipsec-term-12] (46 pages) - Benchmarking Methodology for Link-State IGP Data Plane Route Convergence [draft-ietf-bmwg-igp-dataplane-conv-meth-19] (36 pages) - Terminology for Benchmarking Link-State IGP Data Plane Route Convergence [draft-ietf-bmwg-igp-dataplane-conv-term-19] (28 pages) - Considerations for Benchmarking Link-State IGP Data Plane Route Convergence [draft-ietf-bmwg-igp-dataplane-conv-app-18] (6 pages) - Terminology for Accelerated Stress Benchmarking [draft-ietf-bmwg-acc-bench-term-13] (27 pages) - Framework for Accelerated Stress Benchmarking [draft-ietf-bmwg-acc-bench-framework-00] (7 pages) - Methodology Guidelines for Accelerated Stress Benchmarking [draft-ietf-bmwg-acc-bench-meth-09] (13 pages) - Hash and Stuffing: Overlooked Factors in Network Device Benchmarking [draft-ietf-bmwg-hash-stuffing-09] (34 pages) - Methodology for Benchmarking Accelerated Stress with Operational EBGP Instabilities [draft-ietf-bmwg-acc-bench-meth-ebgp-00] (9 pages) - Methodology for Benchmarking Accelerated Stress with Operational Security [draft-ietf-bmwg-acc-bench-meth-opsec-00] (7 pages) - Methodology for Benchmarking IPsec Devices [draft-ietf-bmwg-ipsec-meth-05] (41 pages) - Methodology for Benchmarking Network-layer Traffic Control Mechanisms [draft-ietf-bmwg-dsmmeth-02] (13 pages) - Benchmarking Terminology for Protection Performance [draft-ietf-bmwg-protection-term-07] (28 pages) - Methodology for benchmarking MPLS protection mechanisms [draft-ietf-bmwg-protection-meth-06] (29 pages) - IPv6 Benchmarking Methodology for Network Interconnect Devices [draft-ietf-bmwg-ipv6-meth-06] (19 pages) - MPLS Forwarding Benchmarking Methodology for IP Flows [draft-ietf-bmwg-mpls-forwarding-meth-07] (31 pages) - Terminology for Benchmarking Session Initiation Protocol (SIP) Networking Devices [draft-ietf-bmwg-sip-bench-term-01] (34 pages) - Methodology for Benchmarking SIP Networking Devices [draft-ietf-bmwg-sip-bench-meth-01] (18 pages) Requests for Comments: RFC1242: Benchmarking Terminology for Network Interconnection Devices (12 pages) RFC1944: Benchmarking Methodology for Network Interconnect Devices (30 pages) * OBSOLETED BY RFC2544 RFC2285: Benchmarking Terminology for LAN Switching Devices (25 pages) RFC2432: Terminology for IP Multicast Benchmarking (16 pages) RFC2544: Benchmarking Methodology for Network Interconnect Devices (31 pages) * Obsoletes RFC1944 RFC2647: Benchmarking Terminology for Firewall Performance (26 pages) RFC2761: Terminology for ATM Benchmarking (32 pages) RFC2889: Benchmarking Methodology for LAN Switching Devices (35 pages) RFC3116: Methodology for ATM Benchmarking (128 pages) RFC3133: Terminology for Frame Relay Benchmarking (24 pages) RFC3134: Terminology for ATM ABR Benchmarking (16 pages) RFC3222: Terminology for Forwarding Information Base (FIB) based Router Performance (15 pages) RFC3511: Benchmarking Methodology for Firewall Performance (34 pages) RFC3918: Methodology for IP Multicast Benchmarking (31 pages) RFC4098: Terminology for Benchmarking BGP Device Convergence in the Control Plane (35 pages) RFC4063: Considerations When Using Basic OSPF Convergence Benchmarks (12 pages) RFC4062: OSPF Benchmarking Terminology and Concepts (10 pages) RFC4061: Benchmarking Basic OSPF Single Router Control Plane Convergence (16 pages) RFC4689: Terminology for Benchmarking Network-layer Traffic Control Mechanisms (32 pages) RFC4814: Hash and Stuffing: Overlooked Factors in Network Device Benchmarking (34 pages) RFC4883: Benchmarking Terminology for Resource Reservation Capable Routers (22 pages) RFC5180: IPv6 Benchmarking Methodology for Network Interconnect Devices (19 pages) RFC5695: MPLS Forwarding Benchmarking Methodology for IP Flows (27 pages) Better-Than-Nothing Security (btns) ----------------------------------- Charter Last Modified: 2009-02-11 Current Status: Active Chairs: Julien Laganier Love Hornquist Astrand Security Area Directors: Tim Polk Pasi Eronen Security Area Advisor: Tim Polk Mailing Lists: General Discussion: btns@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/btns Archive: http://www.ietf.org/mail-archive/web/btns/current/maillist.html Description of Working Group: Current Internet Protocol security protocol (IPsec) and Internet Key Exchange protocol (IKE) present somewhat of an all-or-nothing alternative; these protocols provide protection from a wide array of possible threats, but are sometimes not deployed because of the need for pre-existing credentials. There is significant interest in providing anonymous (unauthenticated) keying for IPsec to create security associations (SAs) with peers who do not possess authentication credentials that can be validated. Examples of such credentials include self-signed certificates or "bare" public keys. This mode would protect against passive attacks but would be vulnerable to active attacks. The primary purpose of this working group is to specify extensions to the IPsec architecture, and possibly extensions or profiles of IKE, so that IPsec will support creation of unauthenticated SAs. The goal of the resulting RFCs is to enable and encourage simpler and more rapid deployment of IPsec in contexts where use of unauthenticated SAs is deemed appropriate, to enable and encourage the use of network security where it has been difficult to deploy--notably, to enable simpler, more rapid deployment. Any IKE and IPsec extensions/profiles developed in this WG must not undermine the security facilities already defined for IPsec. Specifically, the access control facilities that are central to IPsec must not be degraded when unauthenticated SAs are employed concurrently with authenticated SAs in the same IPsec implementation. Two related problems emerged during the discussion of this problem. First, there is a desire in the KITTEN, RDDP, NFSv4 and potentially other working groups to make use of unauthenticated IPsec SAs, and later cryptographically bind these SAs to applications, which perform their own authentication. The specification of how this binding is performed for IPsec and the specification of how the binding interacts with application authentication protocols are out of scope for this working group. However, interactions between this cryptographic channel binding and IPsec (e.g., the PAD, SPD, SAD, etc.) are expected to be similar to those for the unauthenticated mode with no binding. To avoid duplication of effort, This working group needs to consider how to support channel bindings when developing extensions to IPsec, specifically the PAD and SPD elements. Secondly, BTNS and the channel bindings work both encourage IPsec to be used to secure higher layer protocols. As such we need to determine what information these higher layer protocols need from IPsec. Two proposals are under discussion for providing unauthenticated SA support for IPsec: bare RSA keys transported by IKE and self-signed certificates transported by IKE. The WG has the following specific goals: a) Develop an informational framework document to describe the motivation and goals for having security protocols that support anonymous keying of security associations in general, and IPsec and IKE in particular b) Develop an informational applicability statement, describing a set of threat models with relaxed adversary capability assumptions, to characterize the contexts in which use of unauthenticated SAs is appropriate c) If necessary, specify standards-track IKE extensions or profiles that support one or both of the bare RSA keys or self-signed certificates d) Specify standards-track extensions to the SPD and PAD to support unauthenticated SAs for IPsec and cryptographic channel bindings for IPsec e) Develop an informational document describing the interfaces that IPsec implementations should provide to allow IPsec SAs to be used to secure higher layer protocols The final goal is expected to complement work going on elsewhere in establishing best current practice for higher layer protocols secured by IPsec. Goals and Milestones: Done - Confirm on mailing list whether SPD and/or PAD extensions are needed (d) Done - First version of problem and applicability statement (a+b) Done - First version of SPD and/or PAD extensions draft (if needed) Done - First version of IKE extensions draft (if needed) Done - WG LC on problem and applicability statement (a+b) Done - First version of IPsec interfaces draft (e) Done - Submit problem and applicability statement to IESG (a+b) Feb 2007 - WG LC on IKE extensions (c) Done - WG LC on SPD and/or PAD extensions (d) Mar 2007 - Submit IKE extensions to the IESG Done - Submit SPD and/or PAD extensions to the IESG Oct 2007 - WG LC on IPsec interfaces draft Nov 2007 - Submit IPsec interfaces draft to the IESG Nov 2007 - Recharter or close the WG Internet-Drafts: - Problem and Applicability Statement for Better Than Nothing Security (BTNS) [draft-ietf-btns-prob-and-applic-08] (30 pages) - Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec [draft-ietf-btns-core-08] (16 pages) - IPsec Channels: Connection Latching [draft-ietf-btns-connection-latching-12] (30 pages) - Requirements for an IPsec API [draft-ietf-btns-ipsec-apireq-00] (11 pages) - An abstract interface between applications and IPsec [draft-ietf-btns-abstract-api-02] (23 pages) - C-Bindings for IPsec Application Programming Interfaces [draft-ietf-btns-c-api-05] (15 pages) - IPsec End-Point Channel Bindings and API [draft-ietf-btns-channel-binding-api-01] (8 pages) Requests for Comments: RFC5387: Problem and Applicability Statement for Better Than Nothing Security (BTNS) (30 pages) RFC5386: Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec (16 pages) RFC5660: IPsec Channels: Connection Latching (31 pages) Calendaring and Scheduling Standards Simplification (calsify) ------------------------------------------------------------- Charter Last Modified: 2008-04-23 Current Status: Active Chairs: Eliot Lear Aki Niemi Applications Area Directors: Lisa Dusseault Alexey Melnikov Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion: ietf-calsify@osafoundation.org To Subscribe: http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Archive: http://lists.osafoundation.org/pipermail/ietf-calsify/ Description of Working Group: The Calendaring and Scheduling standards, defined in RFC's 2445, 2446, and 2447 were released in November 1998, and further described in RFC 3283. They were designed to progress the level of interoperability between dissimilar calendaring and scheduling systems. The Calendaring and Scheduling Core Object Specification, iCalendar, succeeded in establishing itself as the common format for exchanging calendaring information across the Internet. On the other hand, only basic interoperability has been achieved between different scheduling systems. The Calsify working group is chartered to: (1) Revise the Calendaring and Scheduling Standards to advance the state of interoperable calendaring and scheduling by addressing the known interoperability issues, errata, and problems found based on implementation experience. (2) Clarify the registration process for iCalendar extensions (i.e., the current core object specification only provides a template to register new properties). (3) Provide a means to ease transition from, and to co-exist with, the earlier iCalendar standards to the new ones. Proposing an XML representation or transformation of iCalendar objects is out of the scope of this working group. Depending on the results of the update process on the standards documents the working group will consider whether advancing the documents to draft standard is appropriate. If we decide to move the documents to draft status, milestones may get changed and/or added to allow for any additional work necessary to advance the documents. Goals and Milestones: Done - Submit iCalendar bis draft 00, with formatting changes from RFC2445. Done - Submit iTIP bis draft 00 Done - Submit iMIP bis draft 00 Done - Submit updated version of rfc2447bis draft Done - Submit updated version of rfc2446bis draft Done - Submit updated version of rfc2445bis draft Done - Working Group Last Call on rfc2445bis draft Jun 2007 - Submit rfc2445bis draft to IESG Jun 2007 - Working Group Last Call on rfc2446bis draft Jun 2007 - Working Group Last Call on rfc2447bis draft Jul 2007 - Submit rfc2446bis to IESG Jul 2007 - Submit rfc2447bis to IESG Internet-Drafts: - iCalendar Message-Based Interoperability Protocol (iMIP) [draft-ietf-calsify-rfc2447bis-07] (22 pages) - iCalendar Transport-Independent Interoperability Protocol (iTIP) [draft-ietf-calsify-2446bis-10] (135 pages) - Internet Calendaring and Scheduling Core Object Specification (iCalendar) [draft-ietf-calsify-rfc2445bis-11] (189 pages) Requests for Comments: RFC5545: Internet Calendaring and Scheduling Core Object Specification (iCalendar) (189 pages) * Obsoletes RFC2445 Control And Provisioning of Wireless Access Points (capwap) ----------------------------------------------------------- Charter Last Modified: 2008-08-21 Current Status: Active Chairs: Margaret Wasserman Mahalingam Mani Dorothy Gellert Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Tech Advisors: David Borman Scott Kelly Bob O'Hara Charles Clancy Mailing Lists: General Discussion: capwap@frascone.com To Subscribe: http://lists.frascone.com/mailman/listinfo/capwap Archive: http://lists.frascone.com/pipermail/capwap Description of Working Group: The original CAPWAP WG charter included drafting a problem statement and a taxonomy of architectures. The new charter of the CAPWAP WG proposes building upon the original charter and developing a CAPWAP protocol to provide interoperability among WLAN backend architectures. The intent of the CAPWAP protocol is to facilitate control, management and provisioning of WLAN Termination Points (WTPs) specifying the services, functions and resources relating to 802.11 WLAN Termination Points in order to allow for interoperable implementations of WTPs and ACs. The revised CAPWAP WG will reference two classes of the Centralized WLAN Architecture family, namely the Local MAC and the Split MAC, as described in the CAPWAP Architecture Taxonomy draft. The protocol will define the CAPWAP control plane including the primitives to control data access. An effective Centralized CAPWAP Architecture impacts how WLAN data traffic is managed over the backend network. This implies the abilitiy to control how data is forwarded by negotiating existng data encapsulation mechanisms and specifying data payload formats in order to ensure interoperability between CAPWAP vendors. No other specifications of the CAPWAP data plane are within the scope of this charter. The CAPWAP WG will strive for extensibility in the protocol design to favor future applicability to other access technologies, especially IEEE 802.16. While accommodation of any access technology other than IEEE 802.11 is not required for successful completion, there are clear deployment advantages if a wide range of access technologies are accommodated. In summary, the primary goals of the group will be: 1. Defining a set of Objectives based on the architecture taxonomy work that lists the requirements for an interoperable CAPWAP protocol. In addition, the WG will incorporate requirements derived from the inputs provided by Enterprise and (hotspot) Providers based on the WLAN deployment challenges addressed by CAPWAP architecture. This document will: a. include objectives to address problems described in the CAPWAP Problem statement document b. Describe each objective, its benefit to the protocol and how it satisfies the problem statement. c. Prioritize and classify the objectives into 3 categories: i. Mandatory and Accepted ii. Desirable iii. Rejected d. Undergo review in IEEE 802 as needed This should result in the first WG Last Call for Objectives draft. To avoid requirements bloat and stalemate, the WG has a hard deadline on the Objectives phase. The WG MUST reach WG consensus on the objectives draft by Feb 2005. This is for several reasons: * We must send this for review to IEEE at that time. * We must have a reasonably stable set of objectives so that candidate submissions are aware of the objectives to be met. The 2nd WG Last Call (in April) for the objectives draft is to ensure that the WG has consensus on any changes that may result from IEEE and expert review. So it is not the intention that the WG keeps adding new Objectives after Feb 2005. If the WG cannot reach consensus on the Objectives draft by the May 2005 milestone to the IESG, the WG will close. 2. Evaluating a set of candidate proposals that include existing IETF protocols and any proposals leading to the selection of a protocol on which to base the CAPWAP standard. 3. Developing a CAPWAP protocol standard that meets the Mandatory and Accepted objectives from the Evaluation draft and contains the minimal set of feature needed to control and provision WLAN Access Points. Specifically The CAPWAP protocol document will address the following considerations: a. Architecture b. Operations c. Security d. Network Management e. Scalability f. Performance 4. A MIB Document to support the CAPWAP protocol. In addition, the CAPWAP WG will maintain its Liaison with the IEEE to ensure consistency of its work with the IEEE 802.11 Standard. Deliverables: * Objectives/Criteria Document for CAPWAP protocol * Protocol evaluation and base protocol selection document * CAPWAP Protocol standard * MIB support standard Goals and Milestones: Done - Last call for problem statement draft. Done - Discuss last call comments for problem statement at IETF 59. Done - Last Call for architecture description document. Done - Submit problem statement to IESG for publication approval. Done - Architecture document to expert review. Done - Stable Architecture document for review/sync-up with IEEE 802 Done - Discuss results of IEEE 802 review/sync-up Done - Issue first Internet-Draft of CAPWAP Objectives document Done - Submit CAPWAP Objectives to IEEE/IETF experts review Done - First WGLC for CAPWAP Objectives Draft Done - Deadline to submit candidate protocol proposals to the WG Done - Second WGLC for CAPWAP Objectives Draft Done - Issue first Internet-Draft of CAPWAP Evaluation draft Done - Submit CAPWAP Evaluation draft to IESG as Information RFC Done - Submit CAPWAP Objectives draft to IESG as Informational RFC Done - Issue first Internet Draft of CAPWAP protocol Done - Issue first CAPWAP protocol 802.11bindings Jan 2007 - Issue first Internet-Draft of 802.11 Binding MIB Jan 2007 - Issue first Internet-Draft of CAPWAP Base MIB Feb 2007 - First WGLC for CAPWAP Base Protocol Feb 2007 - First WGLC for 802.11 Binding Mar 2007 - CAPWAP Specs to IEEE 802.11 for Review Apr 2007 - WGLC for CAPWAP Base MIB Apr 2007 - WGLC for CAPWAP 802.11 Binding MIB May 2007 - Receive results of IEEE 802.11 Review May 2007 - Final WGLC for CAPWAP Base Protocol May 2007 - Final WGLC for 802.11 Binding Jul 2007 - CAPWAP Base Protocol to IESG Jul 2007 - CAPWAP 802.11 Binding to IESG Sep 2007 - CAPWAP Base MIB to the IESG Sep 2007 - CAPWAP 802.11 Binding MIB to IESG Internet-Drafts: - CAPWAP Problem Statement [draft-ietf-capwap-problem-statement-03] (9 pages) - Architecture Taxonomy for Control and Provisioning of Wireless Access Points(CAPWAP) [draft-ietf-capwap-arch-07] (44 pages) - CAPWAP Tunneling Protocol (CTP) [draft-singh-capwap-ctp-02] (41 pages) - Objectives for Control and Provisioning of Wireless Access Points (CAPWAP) [draft-ietf-capwap-objectives-05] (35 pages) - LWAPP Self Evaluation [draft-calhoun-capwap-lwapp-objectives-comparison-01] (32 pages) - Evaluation of Wireless LAN Control Protocol (WiCoP) [draft-govindan-capwap-wicop-evaluation-00] (19 pages) - Evaluation of CAPWAP Tunneling Protocol (CTP) [draft-francisco-capwap-ctp-evaluation-01] (15 pages) - SLAPP Evaluation [draft-narasimhan-capwap-slapp-evaluation-00] (25 pages) - Evaluation of Candidate CAPWAP Protocols [draft-ietf-capwap-eval-01] (34 pages) - CAPWAP Protocol Specification [draft-ietf-capwap-protocol-specification-16] (165 pages) - CAPWAP Protocol Binding for IEEE 802.11 [draft-ietf-capwap-protocol-binding-ieee80211-13] (83 pages) - CAPWAP Threat Analysis for IEEE 802.11 Deployments [draft-ietf-capwap-threat-analysis-05] (34 pages) - CAPWAP Access Controller DHCP Option [draft-ietf-capwap-dhc-ac-option-03] (12 pages) - CAPWAP Protocol Base MIB [draft-ietf-capwap-base-mib-06] (76 pages) - CAPWAP Protocol Binding MIB for IEEE 802.11 [draft-ietf-capwap-802dot11-mib-05] (25 pages) Requests for Comments: RFC3990: CAPWAP Problem Statement (9 pages) RFC4118: Architecture Taxonomy for Control and Provisioning of Wireless Access Points(CAPWAP) (44 pages) RFC4565: Evaluation of Candidate Control and Provisioning of Wireless Access Points (CAPWAP) Protocols (34 pages) RFC4564: Objectives for Control and Provisioning of Wireless Access Points (CAPWAP) (35 pages) RFC5418: Control And Provisioning of Wireless Access Points (CAPWAP) Threat Analysis for IEEE 802.11 Deployments (34 pages) RFC5417: Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller DHCP Option (12 pages) RFC5416: Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11 (83 pages) RFC5415: Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification (165 pages) Common Control and Measurement Plane (ccamp) -------------------------------------------- Charter Last Modified: 2009-06-15 Current Status: Active Chairs: Lou Berger Deborah Brungard Routing Area Directors: Ross Callon Adrian Farrel Routing Area Advisor: Adrian Farrel Secretary: Daniel King Mailing Lists: General Discussion: ccamp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ccamp Archive: http://www.ietf.org/mail-archive/web/ccamp/current/maillist.html Description of Working Group: Organizational Overview The CCAMP working group coordinates the work within the IETF defining a common control plane and a separate common measurement plane for physical path and core tunneling technologies of Internet and telecom service providers (ISPs and SPs), e.g. O-O and O-E-O optical switches, TDM Switches, Ethernet Switches, ATM and Frame Relay switches, IP encapsulation tunneling technologies, and MPLS in cooperation with the MPLS WG. In this context, measurement refers to the acquisition and distribution of attributes relevant to the setting up of tunnels and paths. CCAMP WG work scope includes: - Definition of protocol-independent metrics and parameters (measurement attributes) for describing links and paths that are required for routing and signaling. These will be developed in conjunction with requests and requirements from other WGs to ensure overall usefulness. - Definition of protocol(s) and extensions to them required for link and path attribute measurement. Link Management Protocol (LMP) is included here. - Functional specification of extensions for routing (OSPF, ISIS) and signalling (RSVP-TE) required for path establishment. Protocol formats and procedures that embody these extensions will be done jointly with the WGs supervising those protocols. - Definition of the mechanisms required to determine the route and properties of an established path (tunnel tracing). - Definition of management objects (e.g. as part of MIB modules) and OAM techniques relevant to the protocols and extensions specified within the WG. - Work on traffic-engineering GMPLS mechanisms and protocol extensions to support source-controlled and explicitly-routed Ethernet data paths for Ethernet data planes that are already approved by an Standards Development Organization (SDO) with responsibility for the Ethernet data plane. It is expected that the primary SDO in this case is the IEEE. Note that the specification or modification of Ethernet data planes is out of scope. - Work on GMPLS mechanisms and protocol extensions to support the transport profile of MPLS (MPLS-TP) in cooperation with the MPLS, L2VPN, and PWE3 Working Group and in coordination with the requirements expressed jointly by the IETF and ITU-T. CCAMP WG currently works on the following tasks: - Define how the properties of network resources gathered by a measurement protocol can be distributed in existing routing protocols, such as OSPF and IS-IS. CCAMP defines the generic description of the properties and how they are distributed in OSPF. The specifics of distribution within IS-IS are being addressed in the ISIS WG. - Define signaling and routing mechanisms and extensions to allow path and tunnel setup and maintenance across multiple domains, where a domain may be an IGP area, an Autonomous System, or any other region of topological visibility. To this end, work cooperatively with the PCE and MPLS WGs. - Define abstract link and path properties needed for link and path protection. Specify signalling mechanisms for path protection, diverse routing and fast path restoration. Ensure that multi-layer path protection and restoration functions are achievable using the defined signalling, routing, and measurement protocols, either separately or in combination. - Identify which requirements for signaling and routing for Automatically Switched Optical Network (ASON) are not currently met by protocols defined in CCAMP; based on these, define mechanisms to address these requirements. - Produce extensions to the CCAMP WG protocols and RFCs necessary to create an MPLS Transport Profile (MPLS TP). The work on the MPLS TP will be coordinated between the MPLS, L2VPN, PWE3, and CCAMP working groups that are jointly chartered to do MPLS TP work. In doing this work, the WG will work closely with at least the following other WGs: MPLS, L2VPN, PWE3, ISIS, OSPF, IDR, L1VPN and PCE. The WG will also cooperate with the ITU-T and the IEEE 802.1. Goals and Milestones: Done - Post strawman WG goals and charter Done - Identify and document a limited set of candidate solutions for signalling and for measurement. Among candidate control solutions to be considered are the existing GMPLS drafts. Done - Build appropriate design teams Done - Submit WG document defining path setup portions of common control plane protocol Done - Submit WG document defining common measurement plane protocol Done - Submit LMP MIB to IESG Done - Submit GMPLS MIBs to IESG Done - Submit protection & restoration documents to IESG Done - Submit ASON signaling requirements doc to IESG Done - Produce CCAMP WG document for multi-area/AS signaling and routing Done - Produce CCAMP WG document for generic tunnel tracing protocol Done - Submit ASON routing requirements doc to IESG Done - Submit revised charter and milestones to IESG for IESG consideration of more detailed deliverables and determination of usefulness of continuation of WG Done - First version WG I-D for Advertising TE Node Capabilities in ISIS and OSPF Done - First version WG I-D for Automatic discovery of MPLS-TE mesh membership Done - Submit ASON Routing evaluation I-D for IESG review Done - Cross-WG review of I-D for Advertising TE Node Capabilities in ISIS and OSPF Done - First version WG I-D MPLS to GMPLS migration strategies Done - Submit RSVP-TE extensions for inter-domain signaling I-D for IESG review Done - Submit Per-domain path computation signaling I-D for IESG review Done - First version of WG I-D for ASON Routing solutions Done - First version WG I-D Requirements for Multi-Layer and Multi-Region Networks Done - First version WG I-D for Evaluation of existing protocols for MLN/MRN Done - Submit GMPLS signaling in support of Call Management I-D for IESG review Done - Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF for IESG review Done - First version WG I-D for Protocol solutions for MLN/MRN Done - First version of WG I-D for OSPF-TE/GMPLS MIB module Done - First version WG Informational I-D for Analysis of inter-domain issues for disjoint and protected paths Done - Submit GMPLS/ASON lexicography I-D for IESG review Done - Submit LSP Stitching I-D for IESG review Done - First version WG I-D MPLS-GMPLS interworking requirements and solutions Done - Submit I-D for Automatic discovery of MPLS-TE mesh membership for IESG review Done - First version WG I-D GMPLS OAM Requirements Done - Submit GMPLS routing and signaling interoperability advice I-D for IESG review Done - Submit MPLS to GMPLS migration strategies I-D for IESG review Done - Submit Requirements for Multi-Layer and Multi-Region Networks I-D for IESG review Done - Submit MPLS-GMPLS interworking requirements and solutions I-D for IESG review Done - Submit Evaluation of existing protocols for MLN/MRN for IESG review Done - Submit Informational I-D for Analysis of inter-domain issues for disjoint and protected paths for IESG review Done - First version WG I-Ds for GMPLS source-controlled and explicitly-routed Ethernet networks Aug 2008 - First version of Working Group draft providing Control Plane Framework for MPLS-TP Sep 2008 - Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review Oct 2008 - First version of Working Group draft defining RSVP-TE extensions for MPLS-TP Done - Submit ASON Routing solutions I-D for IESG review Dec 2008 - Submit GMPLS OAM Requirements I-D for IESG review Jan 2009 - Submit protocol extensions for GMPLS source-controlled and explicitly-routed Ethernet networks for IESG review Feb 2009 - Submit Protocol solutions for MLN/MRN I-D for IESG review Mar 2009 - Submit Control Plane Framework for MPLS-TP for IESG review Jun 2009 - Submit RSVP-TE extensions for MPLS-TP for IESG review Jun 2009 - Recharter or close Working Group Internet-Drafts: - Node ID based RSVP Hello: A Clarification Statement [draft-ietf-ccamp-rsvp-node-id-based-hello-04] (7 pages) - Generalized MPLS - Signaling Functional Description [draft-ietf-mpls-generalized-signaling-09] (34 pages) - Generalized MPLS Signaling - CR-LDP Extensions [draft-ietf-mpls-generalized-cr-ldp-07] (24 pages) - Generalized MPLS Signaling - RSVP-TE Extensions [draft-ietf-mpls-generalized-rsvp-te-09] (42 pages) - Generalized Multiprotocol Label Switching Extensions for SONET and SDH Control [draft-ietf-ccamp-gmpls-sonet-sdh-09] (21 pages) - Generalized Multi-Protocol Label Switching Architecture [draft-ietf-ccamp-gmpls-architecture-08] (58 pages) - Link Management Protocol (LMP) [draft-ietf-ccamp-lmp-11] (77 pages) - Routing Extensions in Support of Generalized Multi-Protocol Label Switching [draft-ietf-ccamp-gmpls-routing-10] (25 pages) - OSPF Extensions in Support of Generalized Multi-Protocol Label Switching [draft-ietf-ccamp-ospf-gmpls-extensions-13] (12 pages) - Generalized Multiprotocol Label Switching Extensions to Control Non-Standard SONET and SDH Features [draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03] (14 pages) - Link Management Protocol Management Information Base [draft-ietf-ccamp-lmp-mib-11] (83 pages) - TITLE: Optical Link Interface Requirements [draft-ietf-ccamp-oli-reqts-00] (13 pages) - Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems [draft-ietf-ccamp-lmp-wdm-04] (16 pages) - Framework for GMPLS-based Control of SDH/SONET Networks [draft-ietf-ccamp-sdhsonet-control-06] (31 pages) - Generalized MPLS Signaling - Implementation Survey [draft-ietf-ccamp-gmpls-signaling-survey-03] (101 pages) - Generalized MPLS (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control [draft-ietf-ccamp-gmpls-g709-10] (22 pages) - Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management [draft-ietf-ccamp-gmpls-tc-mib-12] (9 pages) - Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base [draft-ietf-ccamp-gmpls-te-mib-17] (59 pages) - Generalized Multiprotocol Label Switching (GMPLS)Label Switching Router (LSR) Management Information Base [draft-ietf-ccamp-gmpls-lsr-mib-16] (42 pages) - Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) [draft-ietf-ccamp-gmpls-recovery-terminology-07] (20 pages) - Tracing Requirements for Generic Tunnels [draft-ietf-ccamp-tracereq-05] (9 pages) - SONET/SDH Encoding for Link Management Protocol (LMP) Test messages [draft-ietf-ccamp-lmp-test-sonet-sdh-05] (15 pages) - Generalize Multiprotocol Label Switching(GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model [draft-ietf-ccamp-gmpls-overlay-06] (12 pages) - Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) [draft-ietf-ccamp-gmpls-recovery-analysis-06] (42 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification [draft-ietf-ccamp-gmpls-recovery-functional-05] (20 pages) - Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON) [draft-ietf-ccamp-gmpls-ason-reqts-08] (14 pages) - Exclude Routes - Extension to RSVP-TE [draft-ietf-ccamp-rsvp-te-exclude-route-07] (26 pages) - Generalized MPLS (GMPLS) RSVP-TE Signalling in support of Automatically Switched Optical Network (ASON) [draft-ietf-ccamp-gmpls-rsvp-te-ason-04] (40 pages) - Requirements for Generalized MPLS (GMPLS) Routing for Automatically Switched Optical Network (ASON) [draft-ietf-ccamp-gmpls-ason-routing-reqts-06] (19 pages) - Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE [draft-ietf-ccamp-crankback-07] (35 pages) - GMPLS Signaling Procedure For Egress Control [draft-ietf-ccamp-gmpls-egress-control-04] (6 pages) - GMPLS - Communication of Alarm Information [draft-ietf-ccamp-gmpls-alarm-spec-07] (20 pages) - RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery [draft-ietf-ccamp-gmpls-recovery-e2e-signaling-05] (36 pages) - Generic Tunnel Tracing Protocol (GTTP) Specification [draft-ietf-ccamp-tunproto-01] (36 pages) - GMPLS Based Segment Recovery [draft-ietf-ccamp-gmpls-segment-recovery-04] (25 pages) - A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering [draft-ietf-ccamp-inter-domain-framework-07] (21 pages) - Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) loosely routed Label Switch Path (LSP) [draft-ietf-ccamp-loose-path-reopt-03] (14 pages) - A Transport Network View of the Link Management Protocol [draft-ietf-ccamp-transport-lmp-03] (17 pages) - Extensions to GMPLS RSVP Graceful Restart [draft-ietf-ccamp-rsvp-restart-ext-10] (24 pages) - A Per-domain path computation method for establishing Inter-domain Traffic Engineering (TE) Label Switched Paths (LSPs) [draft-ietf-ccamp-inter-domain-pd-path-comp-07] (23 pages) - Inter domain Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering - RSVP-TE extensions [draft-ietf-ccamp-inter-domain-rsvp-te-08] (22 pages) - A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within The Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture [draft-ietf-ccamp-gmpls-ason-lexicography-07] (18 pages) - Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE) [draft-ietf-ccamp-lsp-stitching-07] (19 pages) - Evaluation of existing Routing Protocols against ASON routing requirements [draft-ietf-ccamp-gmpls-ason-routing-eval-04] (0 pages) - Use of Addresses in Generalized Multi-Protocol Label Switching (GMPLS) Networks [draft-ietf-ccamp-gmpls-addressing-09] (22 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control [draft-ietf-ccamp-rfc3946bis-02] (24 pages) - Routing extensions for discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) mesh membership [draft-ietf-ccamp-automesh-05] (16 pages) - IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities [draft-ietf-ccamp-te-node-cap-06] (13 pages) - Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) [draft-ietf-ccamp-gmpls-mln-reqs-12] (27 pages) - Evaluation of existing GMPLS Protocols against Multi Layer and Multi Region Networks (MLN/MRN) [draft-ietf-ccamp-gmpls-mln-eval-07] (23 pages) - Link Management Protocol (LMP) Management Information Base (MIB) [draft-ietf-ccamp-rfc4327bis-02] (81 pages) - Ethernet Traffic Parameters [draft-ietf-ccamp-ethernet-traffic-parameters-09] (14 pages) - Traffic Engineering Database Management Information Base in support of GMPLS [draft-ietf-ccamp-gmpls-ospf-mib-01] (22 pages) - Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in support of Calls [draft-ietf-ccamp-gmpls-rsvp-te-call-05] (30 pages) - Procedures for Dynamically Signaled Hierarchical Label Switched Paths [draft-ietf-ccamp-lsp-hierarchy-bis-07] (29 pages) - Framework for MPLS-TE to GMPLS migration [draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-06] (19 pages) - OSPFv2 Routing Protocols Extensions for ASON Routing [draft-ietf-ccamp-gmpls-ason-routing-ospf-09] (29 pages) - Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks [draft-ietf-ccamp-mpls-graceful-shutdown-12] (10 pages) - draft-ietf-ccamp-gmpls-vcat-lcas-08.txt [draft-ietf-ccamp-gmpls-vcat-lcas-08] (21 pages) - Traffic Engineering Database Management Information Base in support of MPLS-TE/GMPLS [draft-ietf-ccamp-gmpls-ted-mib-06] (27 pages) - Requirements for the Conversion Between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network [draft-ietf-ccamp-pc-and-sc-reqs-07] (11 pages) - Interworking Requirements to Support operation of MPLS-TE over GMPLS Networks [draft-ietf-ccamp-mpls-gmpls-interwork-reqts-05] (13 pages) - Analysis of Inter-domain Label Switched Path (LSP) Recovery [draft-ietf-ccamp-inter-domain-recovery-analysis-06] (25 pages) - OSPF Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering [draft-ietf-ccamp-ospf-interas-te-extension-07] (19 pages) - Description of the RSVP-TE Graceful Restart Procedures [draft-ietf-ccamp-gr-description-05] (19 pages) - OAM Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Networks [draft-ietf-ccamp-gmpls-oam-requirements-00] (13 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) [draft-ietf-ccamp-gmpls-mln-extensions-08] (22 pages) - ISIS Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering [draft-ietf-ccamp-isis-interas-te-extension-05] (20 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework [draft-ietf-ccamp-gmpls-ethernet-arch-06] (21 pages) - Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE [draft-ietf-ccamp-rfc4420bis-04] (22 pages) - GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) [draft-ietf-ccamp-asymm-bw-bidir-lsps-03] (15 pages) - Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks [draft-ietf-ccamp-lsp-dppm-10] (53 pages) - Data Channel Status Confirmation Extensions for the Link Management Protocol [draft-ietf-ccamp-confirm-data-channel-status-07] (16 pages) - RSVP Extensions for Path Key Support [draft-ietf-ccamp-path-key-ero-05] (14 pages) - RSVP-TE Signaling Extension For Management Plane To Control Plane LSP Handover In A GMPLS Enabled Transport Network. [draft-ietf-ccamp-pc-spc-rsvpte-ext-04] (19 pages) - Generalized Multiprotocol Label Switching (GMPLS) control of Ethernet PBB-TE [draft-ietf-ccamp-gmpls-ethernet-pbb-te-03] (19 pages) - Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching [draft-ietf-ccamp-gmpls-ether-svcs-04] (16 pages) - Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 User-Network Interface (UNI) [draft-ietf-ccamp-gmpls-mef-uni-03] (10 pages) - Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) [draft-ietf-ccamp-wavelength-switched-framework-02] (37 pages) - Document: draft-ietf-ccamp-gmpls-g-694-lambda-labels-04.txt [draft-ietf-ccamp-gmpls-g-694-lambda-labels-04] (15 pages) - Service Provider Requirements for Ethernet control with GMPLS [draft-ietf-ccamp-ethernet-gmpls-provider-reqs-02] (20 pages) - Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions [draft-ietf-ccamp-gmpls-dcsc-channel-ext-02] (11 pages) - Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks [draft-ietf-ccamp-rwa-info-05] (18 pages) - Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks [draft-ietf-ccamp-rwa-wson-encode-03] (36 pages) - Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) [draft-ietf-ccamp-rwa-wson-framework-04] (46 pages) - OAM Configuration Framework and Requirements for GMPLS RSVP-TE [draft-ietf-ccamp-oam-configuration-fwk-02] (24 pages) - GMPLS RSVP-TE Extensions for Ethernet OAM Configuration [draft-ietf-ccamp-rsvp-te-eth-oam-ext-02] (19 pages) - A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments [draft-ietf-ccamp-wson-impairments-01] (35 pages) Requests for Comments: RFC3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description (34 pages) * Updated by RFC4201 * Updated by RFC4328 * Updated by RFC4872 RFC3472: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions (23 pages) * Updated by RFC4201 * Updated by RFC3468 RFC3473: Generalized Multi-Protocol Label Switching (GMPLS)Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions (42 pages) * Updated by RFC4003 * Updated by RFC4201 * Updated by RFC4420 * Updated by RFC4783 * Updated by RFC4874 * Updated by RFC4873 * Updated by RFC4974 * Updated by RFC5063 * Updated by RFC5151 * Updated by RFC5420 RFC3609: Tracing Requirements for Generic Tunnels (9 pages) RFC3945: Generalized Multi-Protocol Label Switching Architecture (58 pages) RFC3946: Generalized Multiprotocol Label Switching Extensions for SONET and SDH Control (21 pages) * OBSOLETED BY RFC4606 RFC4003: GMPLS Signaling Procedure For Egress Control (6 pages) * Updates RFC3473 RFC4139: Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON) (14 pages) RFC4202: Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) (25 pages) RFC4203: OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (12 pages) * Updates RFC3630 RFC4204: Link Management Protocol (LMP) (77 pages) RFC4207: Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages (15 pages) RFC4208: Generalize Multiprotocol Label Switching(GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model (12 pages) RFC4209: Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems (16 pages) RFC4258: Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON) (19 pages) RFC4257: Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks (31 pages) RFC4328: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control (22 pages) * Updates RFC3471 RFC4327: Link Management Protocol (LMP) Management Information Base (MIB) (83 pages) * OBSOLETED BY RFC4631 RFC4394: A Transport Network View of the Link Management Protocol (LMP) (17 pages) RFC4397: A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within The Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture (18 pages) RFC4426: Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification (20 pages) RFC4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) (20 pages) RFC4428: Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) (42 pages) RFC4558: Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement (7 pages) RFC4606: Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control (24 pages) * Obsoletes RFC3946 RFC4631: Link Management Protocol (LMP) Management Information Base (MIB) (81 pages) * Obsoletes RFC4327 RFC4652: Evaluation of Existing Routing Protocols against Automatic Switched Optical Network (ASON) Routing Requirements (0 pages) RFC4736: Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switch Path (LSP) (14 pages) RFC4726: A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering (21 pages) RFC4783: GMPLS - Communication of Alarm Information (20 pages) * Updates RFC3473 RFC4801: Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management (9 pages) RFC4802: Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base (59 pages) RFC4803: Generalized Multiprotocol Label Switching (GMPLS)Label Switching Router (LSR) Management Information Base (42 pages) RFC4874: Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) (26 pages) * Updates RFC3473 * Updates RFC3209 RFC4872: RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery (36 pages) * Updates RFC3471 * Updated by RFC4873 RFC4873: GMPLS Segment Recovery (25 pages) * Updates RFC4872 * Updates RFC3473 RFC4920: Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE (35 pages) RFC4972: Routing extensions for discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) mesh membership (16 pages) RFC4974: Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in support of Calls (30 pages) * Updates RFC3473 RFC4990: Use of Addresses in Generalized Multi-Protocol Label Switching (GMPLS) Networks (22 pages) RFC5063: Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart (24 pages) * Updates RFC2961 * Updates RFC3473 RFC5073: IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities (13 pages) RFC5151: Inter domain Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering - RSVP-TE extensions (22 pages) * Updates RFC3209 * Updates RFC3473 RFC5146: Interworking Requirements to Support operation of MPLS-TE over GMPLS Networks (13 pages) RFC5145: Framework for MPLS-TE to GMPLS migration (19 pages) RFC5152: A Per-domain path computation method for establishing Inter-domain Traffic Engineering (TE) Label Switched Paths (LSPs) (23 pages) RFC5150: Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE) (19 pages) RFC5212: Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) (28 pages) RFC5298: Analysis of Inter-domain Label Switched Path (LSP) Recovery (26 pages) RFC5339: Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN) (25 pages) RFC5316: ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering (19 pages) RFC5392: OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering (17 pages) RFC5420: Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) (22 pages) * Obsoletes RFC4420 * Updates RFC3209 * Updates RFC3473 RFC5467: GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) (15 pages) RFC5495: Description of the Resource Reservation Protocol - Traffic-Engineered (RSVP-TE) Graceful Restart Procedures (19 pages) RFC5493: Requirements for the Conversion Between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network (11 pages) RFC5553: Resource Reservation Protocol (RSVP) Extensions for Path Key Support (14 pages) Cga & Send maIntenance (csi) ---------------------------- Charter Last Modified: 2009-04-13 Current Status: Active Chairs: Marcelo Bagnulo Gabriel Montenegro Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion: cga-ext@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/cga-ext Archive: http://www.ietf.org/mail-archive/web/cga-ext/current/maillist.html Description of Working Group: The Secure Neighbor Discovery (SEND) protocol defined by RFC 3971 provides security mechanisms protecting different functions of the Neighbor Discovery (ND) protocol defined by RFC 2461. This includes address resolution (discovering link layer address of another node attached to the link), router discovery (discovering routers attached to the link), and neighbor unreachability detection (detecting that a node attached to the link is no longer reachable). SEND protection of address resolution and neighbor unreachability detection functions relies on IPv6 address proof-of-ownership and message integrity protection provided respectively via Cryptographically Generated Addresses (CGAs) and RSA Digital Signatures. CGAs are defined in RFC 3972, and are extended with a CGA extension format defined in RFC 4581, and a support for multiple hash functions defined in RFC 4982. While CGAs were originally defined for the SEND protocol, they have proved to be a useful security tool in other environments too, and its usage has been proposed to secure other protocols such as the Shim6 multihoming protocol and the Mobile IPv6 protocol. While there is very little deployment of SEND to date, there are a number of implementations, recommendations in the NIST and DOD profiles call for use of SEND, and operating system vendors are considering adding SEND to their next releases. As a result, it is desirable to review the current state of the SEND and CGA specifications, maintain and complement them where necessary. Up to date cryptographic algorithms are needed, and the protocols need to be able to deal with certain common situations currently not supported. Specifically, the WG will look at the following issues: - Develop an informational document analyzing the implications of recent attacks on hash functions used by SeND protocol. Current SeND specification uses the SHA-1 hash algorithm and does not provides support for hash algorithm agility, hence the critical need for understanding the impact of the attacks on the SeND protocol. In addition, if as a result of the aforementioned analysis it is deemed necessary, standard-track extensions to the SeND protocol to support multiple hash algorithms will be defined. - Specify a standards-track CGA and SeND extensions to support multiple public key algorithms. As currently defined CGA and SeND can only use RSA keys, and they lack support for other public key algorithms (e.g. Elliptic Curve Cryptography -- ECC). - Develop X.509 certificate management tools for SeND. SeND utilizes X.509v3 certificates for performing router authorization. It uses the X.509 extension for IP addresses to verify whether the router is authorized to advertise the mentioned IP addresses. Since the IP addresses extension does not explicitly mention what functions the node can perform for the IP addresses it becomes impossible to know the reason for which the certificate was allowed. In order to facilitate issuance of certificates for specific functions, we need to encode the functions permitted for the certificate into the certificate itself. The WG will develop a certificate profile, including a definition of X.509 Extended Key Usage for SeND . In addition, the WG will recommend best practices for (1) enrollment, (2) revocation checking, and (3) publishing of certificates. This WG will ensure that the profile and recommended practices will cover usage by hosts in addition to routers. The working group will coordinate this activity with the PKIX and SIDR WGs. Prior to IESG submission of the certificate profile, the working group will seek input from and coordinate with other groups enabling cryptographic identification of device-related properties (e.g., IEEE 802.1ar, IEEE 802.16, WiMAX Forum, IETF CAPWAP WG). - Develop a standard track document defining a mechanism to perform SeND certificate provisioning for routers. SeND protocol as defined in RFC3971 specifies how IPv6 nodes can trust the prefixes advertised by a router. The solution is based on the use of the IP Address Delegation extension (RFC3779) in X.509 v3 certificates (RFC3280). This work will provide the tools require to provision with the certificates to the routers in an automatic manner. The working will coordinate this activity with the PKIX WG. - Produce a problem statement document for Neighbor Discovery Proxies and then specify standards-track SEND Extensions to support Neighbor Discovery Proxies: SEND protocol as currently defined in RFC 3971 lacks of support for ND Proxies defined in RFC 3775 and RFC 4389. Extensions to the SEND protocol will be defined in order to provide equivalent SEND security capabilities to ND Proxies. - Develop an informational document analysing different approaches to allow SeND and CGAs to be used in conjunction with DHCP, and making recommendations on which are the best suited. Recharter based on the result of the analysis. - Update base specifications (RFC 3971 and 3972). Goals and Milestones: Jun 2008 - WG last-call on analysis of hash related threats in SeND Jul 2008 - Submit draft on analysis of hash related threats in SeND to IESG Aug 2008 - WG last-call on Proxy-SeND problem statement Sep 2008 - Submit draft on Proxy-SeND problem statement to IESG Dec 2008 - WG last-call on multiple hash function support in SeND, if required Dec 2008 - WG last-call on multiple public key algorithm support for CGA Dec 2008 - WG last-call on multiple public key algorithm support for SeND Dec 2008 - WG last-call on certificate profile definition for SeND Jan 2009 - WG last-call on Proxy SeND Jan 2009 - Submit draft on multiple hash function support in SeND to IESG, if required Jan 2009 - Submit draft on multiple public key algorithm support for CGA to IESG Jan 2009 - Submit draft on multiple public key algorithm support for SeND to IESG Jan 2009 - Submit draft on certificate profile definition for SeND to IESG Feb 2009 - Submit draft on Proxy SeND to IESG Jun 2009 - WG last-call on certificate provision mechanism for SeND routers Jun 2009 - WG last-call on certificate management best practices for SeND routers Jul 2009 - WG last-call on CGA-DHCP interaction Jul 2009 - Submit draft on certificate provision mechanism for SeND routers to IESG Jul 2009 - Submit draft on certificate management best practices for SeND routers to IESG Aug 2009 - Submit draft on CGA-DHCP interaction to IESG Nov 2009 - WG last-call on updated SeND specification Dec 2009 - Submit draft on updated SeND specification to IESG Dec 2009 - Submit draft on updated CGA specification to IESG Internet-Drafts: - SeND Hash Threat Analysis [draft-ietf-csi-hash-threat-04] (13 pages) - Securing Neighbor Discovery Proxy Problem Statement [draft-ietf-csi-sndp-prob-03] (22 pages) - Secure Proxy ND Support for SEND [draft-ietf-csi-proxy-send-01] (22 pages) - Certificate profile and certificate management for SEND [draft-ietf-csi-send-cert-01] (14 pages) - DHCPv6 and CGA Interaction: Problem Statement [draft-ietf-csi-dhcpv6-cga-ps-00] (8 pages) No Requests for Comments Datagram Congestion Control Protocol (dccp) ------------------------------------------- Charter Last Modified: 2009-06-26 Current Status: Active Chairs: Thomas Phelan Pasi Sarolahti Transport Area Directors: Magnus Westerlund Lars Eggert Transport Area Advisor: Lars Eggert Mailing Lists: General Discussion: dccp@ietf.org To Subscribe: dccp-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/dccp/index.html Description of Working Group: The Datagram Congestion Control Protocol working group is maintaining the Datagram Congestion Control Protocol (DCCP). DCCP is a minimal, general-purpose transport protocol that provides two main functions: (1) the establishment, maintenance and tear-down of an unreliable packet flow and (2) congestion control of that packet flow. The DCCP WG is chartered to work in four areas: * maintenance of the core DCCP protocol * maintenance of the TFRC congestion control protocol * promoting the use of DCCP by upper layers * modular extensions to DCCP In the first area, the WG focuses on maintenance issues (i.e., bug fixes) to the current DCCP specifications. It also provides the venue for moving the DCCP specifications along the Standards Track. To maintain stable specifications, work in this area is tightly controlled and requires strong justification. The second area of work, maintains the TCP Friendly Rate Control (TFRC) congestion control protocol. This includes identification of issues, bug fixes, and progression of the specification along the Standards Track. In the third area, the WG will promote and support the adoption and use of DCCP by upper-layer applications and protocols. This includes specifications for using existing and emerging protocols and applications with DCCP (such as RTP over DCCP and DTLS over DCCP) as well as supporting documents that enhance DCCP deployment and management. In the fourth area, the WG identifies and develops modular extensions to the DCCP specifications that increase the usefulness of DCCP. The goal of this work is to make DCCP attractive to upper-layer protocols and applications. The WG will consider both requirements brought to it from external groups that develop or use upper-layer protocols and applications and may also itself identify a limited number of prospective applications and upper-layer protocols to investigate. This work will provide refinements to the existing congestion control schemes currently provided by DCCP and may also include, for example, mobility support for DCCP. (The acceptance of new work items on mobility requires the approval of the IESG.) This work includes the provision of new congestion control profiles, which are variants of existing ones, that better serve certain applications, for example, interactive applications. The WG may consider to recharter in the future to support the IRTF Internet Congestion Control Research Group (ICCRG) in the development of new congestion control algorithms through the definition of concrete specifications for these algorithms. New work items in the latter two areas must satisfy four conditions: (1) WG consensus on the suitability and projected quality of the proposed work item. (2) A core group of WG participants with sufficient energy and expertise to advance the work item according to the proposed schedule. (3) Commitment from the WG as a whole to provide sufficient and timely review of the proposed work item. (4) Agreement by the AD, who, depending on the scope of the proposed work item, may decide that an IESG review is needed first. The DCCP WG pursues its work in close collaboration with several other IETF WGs and IRTF RGs, including TSVWG, AVT, MMUSIC, BEHAVE, ICCRG and TMRG. Goals and Milestones: Done - Publish summary of required protocol functions/requirements Done - Decision to build on proposed DCCP protocol, alternate protocol, or quit and go home Done - Detailed review of spec and CCIDs Done - Public design review at IETF meeting Done - Working group last call for spec and CCIDs Done - Submit DCCP spec for IESG/IETF review to be Proposed Standard Done - Submit DCCP CCIDs for IESG/IETF review to be Proposed Standard Done - Complete WGLC draft-ietf-dccp-problem-xx as Informational Done - Complete WGLC draft-ietf-dccp-tfrc-voip as Experimental Done - Complete WGLC 'RTP over DCCP' as PS Done - Complete WGLC 'DTLS over DCCP' as PS Done - Complete WGLC for draft-ietf-dccp-rfc3448bis as PS Done - Complete WGLC for draft-ietf-dccp-serv-codes as PS Done - Complete WGLC draft-ietf-dccp-ccid4 as Experimental Sep 2008 - Complete WGLC draft-ietf-dccp-tfrc-faster-restart as Experimental Done - Complete WGLC for draft-ietf-dccp-simul-open as PS Done - Complete WGLC draft-ietf-dccp-quickstart as Experimental Internet-Drafts: - Datagram Congestion Control Protocol (DCCP) [draft-ietf-dccp-spec-14] (130 pages) - Profile for DCCP Congestion Control ID 2:TCP-like Congestion Control [draft-ietf-dccp-ccid2-11] (22 pages) - Problem Statement for DCCP [draft-ietf-dccp-problem-04] (23 pages) - Profile for DCCP Congestion Control ID 3:TFRC Congestion Control [draft-ietf-dccp-ccid3-12] (40 pages) - Datagram Congestion Control Protocol (DCCP) User Guide [draft-ietf-dccp-user-guide-03] (26 pages) - DCCP CCID 3-Thin [draft-ietf-dccp-ccid3-thin-01] (11 pages) - TCP Friendly Rate Control (TFRC): the Small-Packet (SP) Variant [draft-ietf-dccp-tfrc-voip-08] (49 pages) - Faster Restart for TCP Friendly Rate Control (TFRC) [draft-ietf-dccp-tfrc-faster-restart-06] (24 pages) - Strategies for Streaming Media Applications Using TCP-Friendly Rate Control [draft-ietf-dccp-tfrc-media-02] (17 pages) - RTP and the Datagram Congestion Control Protocol (DCCP) [draft-ietf-dccp-rtp-07] (17 pages) - TCP Friendly Rate Control (TFRC): Protocol Specification [draft-ietf-dccp-rfc3448bis-07] (65 pages) - The DCCP Service Code [draft-ietf-dccp-serv-codes-12] (26 pages) - Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP) [draft-ietf-dccp-dtls-07] (11 pages) - Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP) [draft-ietf-dccp-ccid4-06] (22 pages) - DCCP Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal [draft-ietf-dccp-simul-open-09] (34 pages) - Quick-Start for Datagram Congestion Control Protocol (DCCP) [draft-ietf-dccp-quickstart-06] (23 pages) Requests for Comments: RFC4336: Problem Statement for the Datagram Congestion Control Protocol (DCCP) (23 pages) RFC4340: Datagram Congestion Control Protocol (DCCP) (130 pages) * Updated by RFC5595 * Updated by RFC5596 RFC4341: Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control (22 pages) RFC4342: Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC) (40 pages) RFC4828: TCP Friendly Rate Control (TFRC): the Small-Packet (SP) Variant (49 pages) RFC5238: Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP) (11 pages) RFC5348: TCP Friendly Rate Control (TFRC): Protocol Specification (58 pages) RFC5622: Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP) (19 pages) RFC5634: Quick-Start for Datagram Congestion Control Protocol (DCCP) (22 pages) RFC5595: The Datagram Congestion Control Protocol (DCCP) Service Codes (19 pages) * Updates RFC4340 RFC5596: Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal (25 pages) * Updates RFC4340 Dynamic Host Configuration (dhc) -------------------------------- Charter Last Modified: 2009-04-16 Current Status: Active Chairs: Ted Lemon John Jason Brzozowski Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion: dhcwg@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/dhcwg Archive: http://www.ietf.org/mail-archive/web/dhcwg/current/maillist.html Description of Working Group: The dhc working group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCPv4 is currently a "Draft Standard" and is documented in RFC 2131 and RFC 2132. DHCPv6 is currently a "Proposed Standard" and is documented in RFC 3315. Subsequent RFCs document additional options and other enhancements to the specifications. The DHC WG is responsible for reviewing DHCP options or other extensions (for both IPv4 and IPv6). The DHC WG is expected to review all proposed extensions to DHCP to ensure that they are consistent with the DHCP specification and other option formats, that they do not duplicate existing mechanisms, etc. Generally speaking, the DHC WG will not be responsible for evaluating the semantic content of proposed options. Similarly, the ownership of specifications typically belongs the relevant working group that needs more functionality from DHCP, not the DHC WG. The DHC WG coordinates reviews of the proposed options together with those working groups. It is required that those working groups have consensus to take on the work and that the work is within their charter. Exceptionally, with AD agreement, this same process can also be used for Individual Submissions originating outside WGs. However, the DHC WG can in some cases develop its own options that relate to either maintenance of existing specifications or improvements in the operation of the DHCP infrastructure itself. The DHC WG has the following main objectives: * Develop extensions to the DHCP infrastructure as required to meet new applications and deployments of DHCP. The topics currently in development are: - Subnet allocation mechanisms - Virtual subnet identification option - Option for passing DNS domain information in DHCPv6 - DHCP relay agent assignment notification in DHCPv6 - Option for DHCPv6 server reply sequence numbers - Rebinding capability for DHCPv6 Reconfigure messages - Behavior of layer 2 relay agents The adoption of new items requires explicit agreement from the AD or rechartering. * Write analyses of the DHCPv4 and DHCPv6 specifications, including RFC 2131, RFC 2132, RFC 3315 and other RFCs defining additional options, which identifies ambiguities, contradictory specifications and other obstacles to development of interoperable implementations. Recommend a process for resolving identified problems and incorporating the resolutions into the DHCP specification. Secondly, advance DHCPv4 (RFC 2131 and RFC 2132) and DHCPv6 (RFC 3315) in IETF Standards Track. Thirdly, specify guidelines for creating new DHCP options, and report on the status of DHCPv4 option reclassification. * Assess the requirements for a dual-stack host to use DHCP to obtain configuration settings for both IPv4 and IPv6. Hosts that include implementations of both IPv4 and IPv6 ("dual-stack hosts") may use DHCP to obtain configuration settings (including assigned addresses) for both IPv4 and IPv6. The DHCPv4 and DHCPv6 specifications (RFC 2131, RFC 2132, RFC 3315 and subsequent RFCs) do not explicitly explain how a dual-stack host uses DHCP to obtain configuration settings for both IP stacks. The DHC WG will evaluate solutions for configuration of dual-stack hosts through DHCP and select a solution that will be developed and published by the WG. * Hold a discussion whether on-link prefix information and default router information is needed in DHCP in addition to router advertisements. Actual solutions are out of scope for the WG, however. Goals and Milestones: Done - WG Last Call on DHCP Options for Internet Storage Name Service (draft-ietf-dhc-isnsoption-03.txt) Done - WG Last Call on Load Balancing for DHCPv6 (draft-ietf-dhc-dhcpv6-loadb-02.txt) Done - WG Last Call on Time Configuration Options for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt) Done - WG Last Call on IPv6 Prefix Options for DHCPv6 (draft-troan-dhcpv6-opt-prefix-delegation-02.txt) Done - WG Last Call on DNS Configuration options for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-dnsconfig-01.txt) Done - WG Last Call on NIS Configuration Options for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt) Done - Resubmit draft-ietf-dhc-dhcpv6-28.txt to IESG Done - Identify DHCPv4 authentication design team Done - Identify DHCPv4 specification review design team Done - Identify DHCPv4 relay agent message authentication design team Done - Submit DHCP Options for Internet Storage Name Service to IESG (draft-ietf-dhc-isnsoption) Done - Submit DNS Configuration options for DHCPv6 to IESG (draft-ietf-dhc-dhcpv6-opt-dnsconfig) Done - Submit NIS Configuratio Options for DHCPv6 to IESG (draft-ietf-dhc-dhcpv6-opt-nisconfig) Done - Submit IPv6 Prefix Options for DHCPv6 to IESG (draft-troan-dhcpv6-opt-prefix-delegation) Done - Submit 'Detection of Network Attachment (DNA) in IPv4' to IESG (draft-ietf-dhc-dna-ipv4) Done - Resolve IPR issues around 'Rapid Commit Option for DHCPv4' Done - Publish report on dual-stack issues in DHCP (draft-ietf-dhc-dual-stack) Done - Publish report on requirements for renumbering using stateless DHCPv6 (draft-ietf-dhc-stateless-dhcpv6-renumbering) Done - Submit 'Lifetime Option for DHCPv6' to IESG (draft-ietf-dhc-lifetime) Done - Submit 'Rapid Commit Option for DHCPv4' to IESG (draft-ietf-dhc-rapid-commit-opt) Done - Submit DDNS/DHCP documents to IESG Done - Submit 'Node-Specific Client Identifiers for DHCPv4' to IESG (draft-ietf-dhc-3315id-for-v4) Done - WG last call for 'Subnet Allocation Option' Done - WG last call on 'Virtual Subnet Selection Option' Oct 2007 - Submit 'Subnet Allocation Option' (draft-ietf-dhc-subnet-alloc-04) to IESG for Proposed Standard Nov 2007 - WG last call on 'Guidelines for Creating New DHCP Options' (draft-ietf-dhc-option-guidelines) Nov 2007 - Submit 'Virtual Subnet Selection Option', (draft-ietf-dhc-vpn-option) and (draft-ietf-dhc-agent-vpn-id) to IESG for Proposed Standard Dec 2007 - WG last call for 'Domain Suffix Option for DHCPv6' (draft-ietf-dhc-dhcpv6-opt-dnsdomain) Jan 2008 - Submit 'Domain Suffix Option for DHCPv6' (draft-ietf-dhc-dhcpv6-opt-dnsdomain) to IESG for Proposed Standard Jan 2008 - Submit 'Guidelines for Creating New DHCP Options' (draft-ietf-dhc-option-guidelines) to IESG for Best Current Practice Jan 2008 - Develop plan for advancing DHCPv4 and DHCPv6 plan to include completion of DHCPv4 specification review report, 'Implementation Issues with RFC 2131' (draft-ietf-dhc-implementation) for Informational Feb 2008 - WG last call for 'Status of Reclassifying DHCPv4 Options' (draft-ietf-dhc-status-3942) Feb 2008 - WG last call for 'Dual-stack clients and merging of data from DHCPv4 and DHCPv6' (draft-ietf-dhc-dual-stack-merge); waiting for more experience with IPv6 deployment Feb 2008 - WG last call for 'Rebind Capability in DHCPv6 Reconfigure Messages' (draft-ietf-dhc-dhcpv6-reconfigure-rebind) Mar 2008 - Submit 'Status of Reclassifying DHCPv4 Options' (draft-ietf-dhc-status-3942) to IESG for Informational Apr 2008 - 2nd WG last call for 'DHCP Relay Agent Assignment Notification Option (draft-ietf-dhc-dhcpv6-agentopt-delegate) and 'DHCPv6 Server Reply Sequence Number Option' (draft-ietf-dhc-dhcpv6-srsn-option) May 2008 - Submit 'Rebind Capability in DHCPv6 Reconfigure Messages' (draft-ietf-dhc-dhcpv6-reconfigure-rebind) to IESG for Proposed Standard Jun 2008 - WG last call on 'Layer 2 Relay Agent Behaviour' (draft-ietf-dhc-layer2-relay-agent) Jul 2008 - Submit 'Layer 2 Relay Agent Behaviour' to IESG (draft-ietf-dhc-layer2-relay-agent) for Informational Jul 2008 - Submit 'DHCP Relay Agent Assignment Notification Option' (draft-ietf-dhc-dhcpv6-agentopt-delegate) and 'DHCPv6 Server Reply Sequence Number Option' (draft-ietf-dhc-dhcpv6-srsn-option) to IESG for Proposed Standard Jul 2008 - Recharter, if needed Internet-Drafts: - Dynamic Configuration of Internet Hosts [draft-ietf-dhc-problem-stmt-00] (0 pages) - Clarifications and Extensions for the Bootstrap Protocol [draft-ietf-dhc-bootp-02] (27 pages) - Dynamic Host Configuration Protocol [draft-ietf-dhc-protocol-07] (38 pages) - DHCP Options and BOOTP Vendor Extensions [draft-ietf-dhc-options-04] (27 pages) - Interoperation Between DHCP and BOOTP [draft-ietf-dhc-between-bootp-03] (4 pages) - Dynamic Host Configuration Protocol [draft-ietf-dhc-dhcp-09] (45 pages) - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-ietf-dhc-dhcpv6-28] (89 pages) - DHCP Options and BOOTP Vendor Extensions [draft-ietf-dhc-options-1533update-06] (38 pages) - Options for DHCPv6 [draft-ietf-dhc-v6opts-00] (15 pages) - Procedure for Defining New DHCP Options [draft-ietf-dhc-new-options-06] (6 pages) - Interaction between DHCP and DNS [draft-ietf-dhc-dhcp-dns-12] (19 pages) - Authentication for DHCP Messages [draft-ietf-dhc-authentication-16] (17 pages) - An Extension to the DHCP Option Codes [draft-ietf-dhc-options-opt127-03] (3 pages) - An option for FQDNs in DHCP options [draft-ietf-dhc-fqdn-opt-03] (4 pages) - Extensions for the Dynamic Host Configuration Protocol for IPv6 [draft-ietf-dhc-dhcpv6exts-12] (39 pages) - Graceful renumbering of networks with DHCP [draft-ietf-dhc-renumbering-00] (8 pages) - DHCP Options for Service Location Protocol [draft-ietf-dhc-slp-08] (5 pages) - The User Class Option for DHCP [draft-ietf-dhc-userclass-11] (5 pages) - DHCP Options for Novell Directory Services [draft-provan-dhcp-options-dir-serv-02] (3 pages) - DHCP Option for IEEE 1003.1 POSIX Timezone Specifications [draft-ietf-dhc-timezone-03] (3 pages) - An Inter-server Protocol for DHCP [draft-ietf-dhc-interserver-02] (89 pages) - DHCP Relay Agent Information Option [draft-ietf-dhc-agent-options-12] (15 pages) - Multicast Address Allocation Configuration Options [draft-ietf-dhc-multopt-03] (5 pages) - Multicast address allocation extensions to the Dynamic Host Configuration Protocol [draft-ietf-dhc-mdhcp-03] (14 pages) - Subnet Configuration Option Set for DHCP [draft-ietf-dhc-dyn-subnet-conf-02] (14 pages) - The Server Identification Option for DHCP [draft-ietf-dhc-sio-00] (6 pages) - The Server Selection Option for DHCP [draft-ietf-dhc-sso-03] (14 pages) - Security Architecture for DHCP [draft-ietf-dhc-security-arch-01] (14 pages) - An Inter-server Protocol for DHCP [draft-ietf-dhc-interserver-alt-00] (53 pages) - The Named Pool Request Option for DHCP [draft-ietf-dhc-namedpool-00] (4 pages) - Netware/IP Domain Name and Information [draft-ietf-dhc-netware-options-01] (6 pages) - Securing DHCP [draft-ietf-dhc-securing-dhc-00] (5 pages) - The Domain Search Option for DHCP [draft-ietf-dhc-domsrch-02] (4 pages) - Subnet Selection Option for DHCP [draft-ietf-dhc-subsel-00] (5 pages) - DHCP Failover Protocol [draft-ietf-dhc-failover-12] (133 pages) - DHCP Continuation Option Code [draft-ietf-dhc-options-cont-01] (3 pages) - The Autonomous System Option for DHCP [draft-ietf-dhc-asnum-00] (5 pages) - The Server Range Option for DHCP [draft-ietf-dhc-range-00] (2 pages) - DHCP Safe Failover Protocol [draft-ietf-dhc-safe-failover-proto-00] (29 pages) - Security Requirements for the DHCP protocol [draft-ietf-dhc-security-requirements-00] (12 pages) - Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Server MIB [draft-ietf-dhc-server-mib-10] (37 pages) - DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients [draft-ietf-dhc-autoconfig-05] (9 pages) - DHCP Option for User Authentication Protocol [draft-ietf-dhc-options-uap-03] (3 pages) - Automatically Choosing an IP Address in an Ad-Hoc IPv4 Network [draft-ietf-dhc-ipv4-autoconfig-05] (8 pages) - DHCP Use of the User Class Option for Address Assignment [draft-ietf-dhc-useraddr-00] (5 pages) - The Subnet Selection Option for DHCP [draft-ietf-dhc-subnet-option-08] (6 pages) - DHCP Options for Call Control Servers [draft-ietf-dhc-callcontrolserv-00] (4 pages) - The Name Service Search Option for DHCP [draft-ietf-dhc-nsso-06] (4 pages) - New Option Review Guidelines and Additional Option Namespace [draft-ietf-dhc-option-review-and-namespace-02] (14 pages) - DHCP Schema for LDAP [draft-ietf-dhc-schema-02] (23 pages) - Interpreting Client Options for the Dynamic Host Configuration Protocol [draft-ietf-dhc-client-options-00] (24 pages) - DHC load balancing algorithm [draft-ietf-dhc-loadb-03] (9 pages) - The Migration Agent List Option for DHCP [draft-ietf-dhc-migagntlist-00] (4 pages) - DHCP Next Server Option [draft-ietf-dhc-nextserver-02] (0 pages) - The Classless Static Route Option for DHCP [draft-ietf-dhc-csr-08] (0 pages) - DHCP reconfigure extension [draft-ietf-dhc-pv4-reconfigure-06] (6 pages) - Authentication, Authorization, and Accounting Requirements for Roaming Nodes using DHCP [draft-ietf-dhc-aaa-requirements-00] (8 pages) - Requirements for Extending DHCP into New Environments [draft-ietf-dhc-enhance-requirements-00] (15 pages) - DHCP Option for CableLabs Client Configuration [draft-ietf-dhc-packetcable-06] (12 pages) - Procedure for Defining New DHCP Options and Message Types [draft-ietf-dhc-new-opt-msg-03] (7 pages) - The DHCP Client FQDN Option [draft-ietf-dhc-fqdn-option-14] (17 pages) - Resolution of FQDN Conflicts among DHCP Clients [draft-ietf-dhc-ddns-resolution-13] (14 pages) - New Option Review Guidelines for DHCP [draft-ietf-dhc-new-opt-review-00] (8 pages) - The DOCSIS Device Class DHCP Relay Agent Information Sub-option [draft-ietf-dhc-agentoptions-device-class-04] (5 pages) - DHCP Lease Query [draft-ietf-dhc-leasequery-10] (27 pages) - Triggering AAA from DHCP Relay Agents [draft-ietf-dhc-aaa-ra-00] (7 pages) - Encoding Long Options in DHCPv4 [draft-ietf-dhc-concat-05] (0 pages) - Extensions to DHCP for Roaming Users [draft-ietf-dhc-dhcproam-00] (15 pages) - LDAP Schema for DHCP [draft-ietf-dhc-ldap-schema-00] (18 pages) - Link Selection sub-option for the Relay Agent Information Option for DHCPv4 [draft-ietf-dhc-agent-subnet-selection-04] (8 pages) - Virtual Subnet Selection Sub-Option for the Relay Agent Information Option for DHCPv4 [draft-ietf-dhc-agent-vpn-id-06] (11 pages) - Virtual Subnet Selection Options for DHCPv4 and DHCPv6 [draft-ietf-dhc-vpn-option-11] (20 pages) - Wireless Key Management using DHCP [draft-ietf-dhc-key-management-00] (0 pages) - DSTM Options for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-dstm-01] (7 pages) - DNS Configuration Options for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-dnsconfig-05] (8 pages) - RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option [draft-ietf-dhc-agentopt-radius-09] (9 pages) - Load Balancing for DHCPv6 [draft-ietf-dhc-dhcpv6-loadb-02] (6 pages) - DSTM Ports Option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-dstm-ports-01] (4 pages) - NIS Configuration Options for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-nisconfig-06] (6 pages) - Time Configuration Options for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-timeconfig-03] (8 pages) - Considerations for the use of the Host Name option [draft-ietf-dhc-host-option-considerations-02] (8 pages) - The IPv4 DHCP Options for the Internet Storage Name Service [draft-ietf-dhc-isnsoption-14] (14 pages) - Unused DHCP Option Codes [draft-ietf-dhc-unused-optioncodes-08] (11 pages) - Extending DHCP Options Codes [draft-ietf-dhc-extended-optioncodes-00] (9 pages) - Client Preferred Prefix option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-cliprefprefix-01] (6 pages) - The Authentication Suboption for the DHCP Relay Agent Option [draft-ietf-dhc-auth-suboption-06] (15 pages) - KDC Server Address Sub-option [draft-ietf-dhc-suboptions-kdc-serveraddress-05] (5 pages) - IPv6 Prefix Options for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-prefix-delegation-06] (20 pages) - DHCP Option for Mobile IP Mobility Agents [draft-ietf-dhc-mipadvert-opt-02] (15 pages) - DHCP Subscriber ID Suboption for the DHCP Relay Agent Option [draft-ietf-dhc-subscriber-id-08] (10 pages) - PacketCable Security Ticket Control Sub-option for the the DHCP CableLabs Client Configuration Option [draft-ietf-dhc-pktc-kerb-tckt-03] (7 pages) - DHCP Server Identifier Override Suboption [draft-ietf-dhc-server-override-06] (12 pages) - Results from Interoperability Tests of DHCPv6 Implementations [draft-ietf-dhc-dhcpv6-interop-01] (12 pages) - Subnet Allocation Option [draft-ietf-dhc-subnet-alloc-10] (32 pages) - Implementation Issues with RFC 2131, "Dynamic Host Configuration Protocol (DHCPv4)" [draft-ietf-dhc-implementation-02] (41 pages) - Stateless DHCP Service for IPv6 [draft-ietf-dhc-dhcpv6-stateless-05] (10 pages) - The Authentication Suboption for the DHCP Relay Agent Option [draft-ietf-dhc-relay-agent-auth-01] (16 pages) - Node-Specific Client Identifiers for DHCPv4 [draft-ietf-dhc-3315id-for-v4-06] (11 pages) - Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis [draft-ietf-dhc-v4-threat-analysis-03] (20 pages) - DHCP RSA/DSA Authentication using DNS KEY records [draft-ietf-dhc-auth-sigzero-00] (0 pages) - Detecting Network Attachment in IPv4 (DNAv4) [draft-ietf-dhc-dna-ipv4-19] (16 pages) - Authentication of DHCP Relay Agent Options Using IPsec [draft-ietf-dhc-relay-agent-ipsec-02] (10 pages) - DHCP Options for the Intel Preboot eXecution Environment (PXE) [draft-ietf-dhc-pxe-options-04] (8 pages) - Vendor-Identifying Vendor Options for DHCPv4 [draft-ietf-dhc-vendor-04] (10 pages) - Rapid Commit Option for DHCPv4 [draft-ietf-dhc-rapid-commit-opt-06] (12 pages) - The Name Service Search Option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-nss-00] (6 pages) - Timezone Specifier Option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-tz-00] (6 pages) - Simple Network Time Protocol Configuration Option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-sntp-02] (5 pages) - Reclassifying DHCPv4 Options [draft-ietf-dhc-reclassify-options-02] (8 pages) - Client Identifier option in server replies [draft-ietf-dhc-client-id-00] (4 pages) - DHCP Option for Proxy Server Configuration [draft-ietf-dhc-proxyserver-opt-05] (8 pages) - Configured Tunnel End Point Option for DHCPv6 [draft-ietf-dhc-dhcpv6-ctep-opt-02] (6 pages) - DHCPv6 Support for Remote Boot [draft-ietf-dhc-dhcpv6-opt-rboot-00] (6 pages) - The Extended Remote Boot Option for DHCPv4 [draft-ietf-dhc-opt-extrboot-00] (7 pages) - DHCP: IPv4 and IPv6 Dual-Stack Issues [draft-ietf-dhc-dual-stack-05] (14 pages) - Information Refresh Time Option for DHCPv6 [draft-ietf-dhc-lifetime-04] (8 pages) - Renumbering Requirements for Stateless DHCPv6 [draft-ietf-dhc-stateless-dhcpv6-renumbering-03] (8 pages) - Vendor-Specific Information Suboption for the DHCP Relay Agent Option [draft-ietf-dhc-vendor-suboption-01] (9 pages) - The DHCPv6 Client FQDN Option [draft-ietf-dhc-dhcpv6-fqdn-06] (15 pages) - Clarifications on DHCPv6 Authentication [draft-ietf-dhc-dhcpv6-clarify-auth-01] (14 pages) - DHCPv4 Options for Broadcast and Multicast Control Servers [draft-ietf-dhc-bcmcv4-option-00] (12 pages) - DHCPv6 Options for Broadcast and Multicast Control Servers [draft-ietf-dhc-bcmcv6-option-00] (14 pages) - Service-Oriented Address Assignment using DHCPv6 [draft-ietf-dhc-soa-option-00] (9 pages) - DHCPv6 Relay agent RADIUS Attribute Option [draft-ietf-dhc-v6-relay-radius-02] (12 pages) - DHCP Options for Broadcast and Multicast Control Servers [draft-ietf-dhc-bcmc-options-06] (15 pages) - DHCPv6 Relay Agent Subscriber-ID Option [draft-ietf-dhc-dhcpv6-subid-02] (8 pages) - DHCPv6 Relay Agent Remote ID Option [draft-ietf-dhc-dhcpv6-remoteid-02] (8 pages) - Dual-stack clients and merging of data from DHCPv4 and DHCPv6 [draft-ietf-dhc-dual-stack-merge-01] (8 pages) - DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents [draft-ietf-dhc-paa-option-06] (9 pages) - Domain Suffix Option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-dnsdomain-04] (7 pages) - DHCPv6 Relay Agent Assignment Notification (RAAN) Option [draft-ietf-dhc-dhcpv6-agentopt-delegate-04] (8 pages) - Time Protocol Servers and Time Offset Options for IPv6 DHCP [draft-ietf-dhc-dhcpv6-rfc868-servers-00] (6 pages) - A Timezone Option for DHCP [draft-ietf-dhc-timezone-option-06] (11 pages) - DHCPv4 Relay Agent Flags Suboption [draft-ietf-dhc-relay-agent-flags-04] (8 pages) - Dynamic Host Configuration Protocol Options Used by PXELINUX [draft-ietf-dhc-pxelinux-04] (14 pages) - Rebind Capability in DHCPv6 Reconfigure Messages [draft-ietf-dhc-dhcpv6-reconfigure-rebind-07] (6 pages) - DHCPv6 Leasequery [draft-ietf-dhc-dhcvp6-leasequery-01] (21 pages) - DHCPv6 Leasequery [draft-ietf-dhc-dhcpv6-leasequery-02] (23 pages) - DHCPv6 Relay Agent Echo Request Option [draft-ietf-dhc-dhcpv6-ero-02] (7 pages) - DHCPv6 Server Reply Sequence Number Option [draft-ietf-dhc-dhcpv6-srsn-option-03] (7 pages) - Guidelines for Creating New DHCP Options [draft-ietf-dhc-option-guidelines-06] (17 pages) - Container Option for Server Configuration [draft-ietf-dhc-container-opt-05] (10 pages) - DHCPv6 Bulk Leasequery [draft-ietf-dhc-dhcpv6-bulk-leasequery-07] (18 pages) - Layer 2 Relay Agent Information [draft-ietf-dhc-l2ra-05] (18 pages) - Extensions to Layer 2 Relay Agent [draft-ietf-dhc-l2ra-extensions-02] (22 pages) - The DHCPv4 Relay Agent Identifier Suboption [draft-ietf-dhc-relay-id-suboption-07] (7 pages) - DHCPv6 option for network boot [draft-ietf-dhc-dhcpv6-opt-netboot-06] (11 pages) - Dynamic Host Configuration Protocol DHCPINFORM Message Clarifications [draft-ietf-dhc-dhcpinform-clarify-04] (11 pages) - DHCPv4 Leasequery by relay agent remote ID [draft-ietf-dhc-leasequery-by-remote-id-03] (25 pages) - DHCPv6 Vendor-specific Message [draft-ietf-dhc-dhcpv6-vendor-message-01] (6 pages) - DHCPv4 Vendor-specific Message [draft-ietf-dhc-dhcpv4-vendor-message-01] (7 pages) - Bulk DHCPv4 Lease Query [draft-ietf-dhc-dhcpv4-bulk-leasequery-01] (38 pages) - Forcerenew Nonce Authentication [draft-ietf-dhc-forcerenew-nonce-00] (11 pages) - Lightweight DHCPv6 Relay Agent [draft-ietf-dhc-dhcpv6-ldra-01] (15 pages) Requests for Comments: RFC2131: Dynamic Host Configuration Protocol (34 pages) * Obsoletes RFC1541 * Obsoletes RFC1533 * Updated by RFC3396 * Updated by RFC4361 * Updated by RFC5494 RFC2132: DHCP Options and BOOTP Vendor Extensions (34 pages) * Obsoletes RFC1533 * Updated by RFC3442 * Updated by RFC3942 * Updated by RFC4361 * Updated by RFC4833 * Updated by RFC5494 RFC1542: Clarifications and Extensions for the Bootstrap Protocol (23 pages) * Obsoletes RFC1532 RFC1541: Dynamic Host Configuration Protocol (39 pages) * Obsoletes RFC1531 * OBSOLETED BY RFC2131 RFC1532: Clarifications and Extensions for the Bootstrap Protocol (22 pages) * Obsoletes RFC951 * OBSOLETED BY RFC1542 RFC1534: Interoperation Between DHCP and BOOTP (4 pages) RFC1533: DHCP Options and BOOTP Vendor Extensions (30 pages) * Obsoletes RFC1497 * OBSOLETED BY RFC2132 * OBSOLETED BY RFC2131 RFC1531: Dynamic Host Configuration Protocol (39 pages) * OBSOLETED BY RFC1541 RFC2241: DHCP Options for Novell Directory Services (5 pages) RFC2242: Netware/IP Domain Name and Information (6 pages) RFC2485: DHCP Option for The Open Group's User Authentication Protocol (4 pages) RFC2489: Procedure for Defining New DHCP Options (5 pages) * OBSOLETED BY RFC2939 RFC2610: DHCP Options for Service Location Protocol (6 pages) RFC2939: Procedure for Defining New DHCP Options and Message Types (7 pages) * Obsoletes RFC2489 RFC2937: The Name Service Search Option for DHCP (5 pages) RFC3004: The User Class Option for DHCP (6 pages) RFC3011: The Subnet Selection Option for DHCP (6 pages) RFC3046: DHCP Relay Agent Information Option (14 pages) RFC2563: DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients (9 pages) RFC3074: DHC load balancing algorithm (10 pages) RFC3118: Authentication for DHCP Messages (17 pages) RFC3203: DHCP reconfigure extension (6 pages) RFC3256: The DOCSIS Device Class DHCP Relay Agent Information Sub-option (5 pages) RFC3396: Encoding Long Options in DHCPv4 (9 pages) * Updates RFC2131 RFC3442: The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4 (9 pages) * Updates RFC2132 RFC3495: Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration (13 pages) RFC3527: Link Selection sub-option for the Relay Agent Information Option for DHCPv4 (9 pages) RFC3315: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (101 pages) * Updated by RFC4361 * Updated by RFC5494 RFC3594: PacketCable Security Ticket Control Sub-option for the the DHCP CableLabs Client Configuration (CCC)Option (7 pages) RFC3646: DNS Configuration Options for DHCPv6 (8 pages) RFC3633: IPv6 Prefix Options for DHCPv6 (20 pages) RFC3634: KDC Server Address Sub-option (5 pages) RFC3679: Unused DHCP Option Codes (8 pages) RFC3736: Stateless DHCP Service for IPv6 (10 pages) RFC3898: NIS Configuration Options for DHCPv6 (6 pages) RFC3925: Vendor-Identifying Vendor Options for DHCPv4 (10 pages) RFC3942: Reclassifying DHCPv4 Options (8 pages) * Updates RFC2132 RFC4014: RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option (9 pages) RFC3993: DHCP Subscriber ID Suboption for the DHCP Relay Agent Option (10 pages) RFC4030: The Authentication Suboption for the DHCP Relay Agent Option (15 pages) RFC4039: Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4) (12 pages) RFC4075: Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6 (5 pages) RFC4076: Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (8 pages) RFC4174: The IPv4 Dynamic Host Configuration Protocol (DHCP) Options for the Internet Storage Name Service (14 pages) RFC4242: Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (8 pages) RFC4280: Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers (15 pages) RFC4243: Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option (9 pages) RFC4361: Node-Specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4) (11 pages) * Updates RFC2131 * Updates RFC2132 * Updates RFC3315 * Updated by RFC5494 RFC4388: Dynamic Host Configuration Protocol (DHCP) Leasequery (27 pages) RFC4436: Detecting Network Attachment in IPv4 (DNAv4) (16 pages) RFC4477: Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues (14 pages) RFC4580: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option (8 pages) RFC4649: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option (8 pages) RFC4704: The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option (15 pages) RFC4703: Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients (14 pages) RFC4702: The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option (17 pages) RFC4578: Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE) (8 pages) RFC4833: A Timezone Option for DHCP (11 pages) * Updates RFC2132 RFC5010: The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption (8 pages) RFC5007: DHCPv6 Leasequery (23 pages) RFC4994: DHCPv6 Relay Agent Echo Request Option (7 pages) RFC5071: Dynamic Host Configuration Protocol Options Used by PXELINUX (14 pages) RFC5107: DHCP Server Identifier Override Suboption (12 pages) RFC5192: DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents (8 pages) RFC5460: DHCPv6 Bulk Leasequery (18 pages) Diameter Maintenance and Extensions (dime) ------------------------------------------ Charter Last Modified: 2009-07-07 Current Status: Active Chairs: Hannes Tschofenig Victor Fajardo Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion: dime@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dime Archive: http://www.ietf.org/mail-archive/web/dime/current/maillist.html Description of Working Group: The Diameter Maintenance and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use for authentication, authorization, accounting and provisioning in network access as well as for other applications environments (e.g., IP telephony, mobility). The IETF has completed work on the Diameter Base protocol and is working on revising the base protocol specification. There is on-going work on defining RADIUS extensions and the DIME WG will ensure that work done in RADEXT is also available for Diameter. The DIME working group plains to address the following items: - Maintaining and/or progressing, along the standards track, the Diameter Base protocol and Diameter Applications. This includes extensions to Diameter Base protocol that can be considered as enhanced features or bug fixes, such NAI routing or capability update extensions. - Diameter application design guideline. This document will provide guidelines for design of Diameter extensions. It will detail when to consider reusing an existing application and when to develop a new application. - Diameter QoS extensions. This work focuses on extensions to Diameter to support QoS information to be authorized and provisioned in AAA deployments. - Protocol extensions for the management of Diameter entities. This work focuses on the standardization of Management Information Bases (MIBs) to configure Diameter entities (such as the Diameter Base protocol or Diameter Credit Control nodes). The usage of other management protocols for configuring Diameter entities may be future work within the group. - Diameter extensions for mobility protocols, such as Mobile IPv6 and Proxy Mobile IPv6. Diameter extensions to support handover keying developed in the HOKEY WG are part of this effort. - New Diameter applications, such as the Diameter NAT control application. This group will also conduct work on new Diameter applications with a Diameter application for configuring NATs as the first item. Additionally, AAA systems require interoperability in order to work. The working group, along with the AD, will need to evaluate any potential extensions and require verification that the proposed extension is needed. Coordination with other IETF working groups and other SDOs will used to ensure this. Goals and Milestones: Done - Submit the following two Diameter Mobility documents to the IESG for consideration as a Proposed Standards:* 'Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction' * 'Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction' Done - Submit 'Diameter API' to the IESG for consideration as an Informational RFC Done - Submit 'Quality of Service Parameters for Usage with Diameter' to the IESG for consideration as a Proposed Standard. Done - Submit 'Diameter QoS Application' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Support for EAP Re-authentication Protocol' as DIME working group item Done - Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' as DIME working group item Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working group item Done - Submit 'Quality of Service Attributes for Diameter' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' to the IESG for consideration as a Proposed Standard Jun 2009 - Submit new DIME charter to the IESG Jun 2009 - Submit 'Updated IANA Considerations for Diameter Command Code Allocations' as DIME working group item Jul 2009 - Submit 'Updated IANA Considerations for Diameter Command Code Allocations' to the IESG for consideration as a Proposed Standard Jul 2009 - Submit 'Diameter NAT Control Application' as DIME working group item Jul 2009 - Submit 'Diameter Capabilities Update' as DIME working group item Aug 2009 - Submit 'Diameter Application Design Guidelines' to the IESG for consideration as a BCP document Nov 2009 - Submit Revision of 'Diameter Base Protocol' to the IESG for consideration as a Proposed Standard Done - Submit ' Diameter Credit Control Application MIB' to the IESG for consideration as an Informational RFC Done - Submit 'Diameter Base Protocol MIB' to the IESG for consideration as an Informational RFC Done - Submit 'Diameter Capabilities Update' to the IESG for consideration as a Proposed Standard Jan 2010 - Submit 'Diameter Support for EAP Re-authentication Protocol' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter NAT Control Application' to the IESG for consideration as a Proposed Standard Internet-Drafts: - The Diameter API [draft-ietf-dime-diameter-api-08] (46 pages) - Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction [draft-ietf-dime-mip6-split-17] (42 pages) - Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction [draft-ietf-dime-mip6-integrated-13] (18 pages) - Diameter Base Protocol [draft-ietf-dime-rfc3588bis-19] (159 pages) - Diameter Quality of Service Application [draft-ietf-dime-diameter-qos-13] (57 pages) - Quality of Service Parameters for Usage with Diameter [draft-ietf-dime-qos-parameters-12] (11 pages) - Diameter Applications Design Guidelines [draft-ietf-dime-app-design-guide-09] (16 pages) - Quality of Service Attributes for Diameter [draft-ietf-dime-qos-attributes-14] (42 pages) - Diameter Support for EAP Re-authentication Protocol (ERP) [draft-ietf-dime-erp-02] (18 pages) - Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server [draft-ietf-dime-pmip6-04] (21 pages) - Diameter User-Name and Realm Based Request Routing Clarifications [draft-ietf-dime-nai-routing-04] (12 pages) - Diameter Credit Control Application MIB [draft-ietf-dime-diameter-cc-appl-mib-01] (20 pages) - Diameter Base Protocol MIB [draft-ietf-dime-diameter-base-protocol-mib-02] (51 pages) - Updated IANA Considerations for Diameter Command Code Allocations [draft-ietf-dime-diameter-cmd-iana-01] (10 pages) - Realm-Based Redirection In Diameter [draft-ietf-dime-realm-based-redirect-02] (6 pages) - The Diameter Capabilities Update Application [draft-ietf-dime-capablities-update-00] (7 pages) - Diameter NAT Control Application [draft-ietf-dime-nat-control-01] (40 pages) Requests for Comments: RFC5447: Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction (17 pages) RFC5624: Quality of Service Parameters for Usage with Diameter (11 pages) Dispatch (dispatch) ------------------- Charter Last Modified: 2009-04-20 Current Status: Active Chairs: Mary Barnes Gonzalo Camarillo Real-time Applications and Infrastructure Area Directors: Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Cullen Jennings Secretary: Oscar Novo Mailing Lists: General Discussion: dispatch@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dispatch Archive: http://www.ietf.org/mail-archive/web/dispatch/ Description of Working Group: The Dispatch working group is chartered to consider proposals for new work in the RAI area and identify, or help create, an appropriate venue for the work. Options for handling new work include: - Directing the work to an existing WG. - Developing a proposal for a BOF. - Developing a charter and establishing consensus for a new WG or Exploratory Group. This option will primarily be used with fairly mature and well-defined efforts. - Rejecting and deferring work. A major objective of the DISPATCH WG is to provide timely, clear dispositions of new efforts. Where there is consensus to take on new work, the WG will strive to quickly find a home for it. Reconsideration of proposals which have failed to gather consensus will be prioritized behind proposals for new work which have not yet been considered. In general, requests for reconsideration should only be made once a proposal has been significantly revised. Guiding principles will include: 1. Providing a clear problem statement for proposed new work. 2. Prioritizing new efforts so that RAI does not take on more work than it can effectively complete. 3. Looking for commonalities among ongoing development efforts. Such commonalities may indicate the need to develop more general, reusable components. 4. Protecting the architectural integrity of RAI protocols and ensuring that work has general applicability. If the group decides that a particular topic needs to be addressed by a new or existing WG, the normal IETF chartering process will be followed, including, for instance, IETF-wide review of the proposed changes. Proposal for large work efforts SHOULD lead to a BOF where the topic can be discussed in front of the entire IETF community. Prior experience in RAI, particularly in SIPPING, indicates that the activities described here are significantly hindered when trying to complete the identified protocol work items in the same venue. The DISPATCH working group will not direct protocol work to itself. Goals and Milestones: Aug 2009 - Proposed charter for SIP Overload WG Aug 2009 - Proposed disposition for SIP Common Log Format Sep 2009 - Proposed charter for SIP Configuration WG Sep 2009 - Proposed disposition for SAML for SIP Internet-Drafts: No Requests for Comments Domain Keys Identified Mail (dkim) ---------------------------------- Charter Last Modified: 2008-08-21 Current Status: Active Chairs: Stephen Farrell Barry Leiba Security Area Directors: Tim Polk Pasi Eronen Security Area Advisor: Pasi Eronen Mailing Lists: General Discussion: ietf-dkim@mipassoc.org To Subscribe: http://mipassoc.org/mailman/listinfo/ietf-dkim Archive: http://mipassoc.org/pipermail/ietf-dkim/ Description of Working Group: The Internet mail protocols and infrastructure allow mail sent from one domain to purport to be from another. While there are sometimes legitimate reasons for doing this, it has become a source of general confusion, as well as a mechanism for fraud and for distribution of spam (when done illegitimately, it's called "spoofing"). The DKIM working group will produce standards-track specifications that allow a domain to take responsibility, using digital signatures, for having taken part in the transmission of an email message and to publish "policy" information about how it applies those signatures. Taken together, these will assist receiving domains in detecting (or ruling out) certain forms of spoofing as it pertains to the signing domain. The DKIM working group will produce a summary of the threats that are addressed by the proposed standards-track specifications, while acknowledging their limitations and scope. The DKIM working group will also produce security requirements to guide their efforts, and will analyze the impact on senders and receivers who are not using DKIM, particularly any cases in which mail may be inappropriately labeled as suspicious or spoofed. While the techniques specified by the DKIM working group will not prevent fraud or spam, they will provide a tool for defense against them by assisting receiving domains in detecting some spoofing of known domains. The standards-track specifications will not mandate any particular action by the receiving domain when a signature fails to validate. That said, with the understanding that guidance is necessary for implementers, the DKIM documents should discuss a reasonable set of possible actions and strategies, and analyze their likely effects on attacks and on normal email delivery. The DKIM working group will not attempt to establish requirements for trust relationships between domains nor to specify reputation or accreditation systems. The DKIM working group will consider mailing-list behaviour that is currently deemed acceptable, will make every effort to allow such mailing lists to continue to operate in a DKIM environment, and will provide a plan for smooth transition of mailing lists that fail to operate. The specifications will also advise mailing lists on how to take advantage of DKIM if they should choose to do so. The signatures will use public-key cryptography and will be based on domain name identifiers. Public keys needed to validate the signatures will be stored in the responsible identity's DNS hierarchy. The specifications will be based on the following Internet Drafts: * draft-fenton-dkim-threats * draft-allman-dkim-base * draft-allman-dkim-ssp These documents represent experimentation and consensus from a number of designers and early implementors. Experimentation has resulted in Internet deployment of these specifications. Although not encouraged, non-backwards-compatible changes to these specifications will be acceptable if the DKIM working group determines that the changes are required to meet the group's technical objectives. The resulting protocols must meet typical criteria for success. In addition to security, these include usability, scalability, ease of deployment, and cryptographic algorithm independence. To prevent this task from becoming unwieldy, several related topics are considered out of scope for the DKIM working group. These topics include: * Reputation and accreditation systems. While we expect these to add value to what is defined by the DKIM working group, their development will be separate, and is out of scope for the DKIM working group. * Message content encryption. * Additional key management protocols or infrastructure. * Signatures that are intended to make long-term assertions beyond the expected transit time of a message from originator to recipient, which is normally only a matter of a few days at most. * Signatures that attempt to make strong assertions about the identity of the message author, and details of user-level signing of messages (as distinguished from domain-level keys that are restricted to specific users). * Duplication of prior work in signed email, including S/MIME and OpenPGP. Once the primary goals are met, the DKIM working group may also study whether to adopt a work item for specifying a common mechanism to communicate the results of message verification to the message recipient. The generation of a standards-track specification on this topic will require an update to the DKIM working group charter. The deliverables for the DKIM working group are these: * An informational RFC presenting a detailed threat analysis of, and security requirements for, DKIM. IESG approval of this document is a prerequisite for the submission of the standards-track specifications. * A standards-track specification for DKIM signature and verification. * A standards-track specification for DKIM policy handling. * A standards-track specification for DKIM DNS Resource Record(s). * An informational RFC providing an overview of DKIM and how it can fit into overall messaging systems, how it relates to other IETF message signature technologies, implementation and migration considerations, and outlining potential DKIM applications and future extensions. Goals and Milestones: Done - WG last call on DKIM threats and security requirements Done - WG last call on DKIM signature specification Done - WG last call on SSP requirements Done - WG adoption of SSP protocol draft Nov 2007 - WG last call on SSP protocol Nov 2007 - WG last call on overview document Internet-Drafts: - Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) [draft-ietf-dkim-threats-04] (31 pages) - DomainKeys Identified Mail (DKIM) Signatures [draft-ietf-dkim-base-11] (81 pages) - DomainKeys Identified Mail (DKIM) Service Overview [draft-ietf-dkim-overview-13] (25 pages) - Requirements for a DKIM Signing Practices Protocol [draft-ietf-dkim-ssp-requirements-06] (24 pages) - DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) [draft-ietf-dkim-ssp-11] (26 pages) - DomainKeys Identified Mail (DKIM) Development, Deployment and Operations [draft-ietf-dkim-deployment-09] (49 pages) - RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update [draft-ietf-dkim-rfc4871-errata-08] (13 pages) Requests for Comments: RFC4686: Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) (31 pages) RFC4871: DomainKeys Identified Mail (DKIM) Signatures (81 pages) * Obsoletes RFC4870 * Updated by RFC5672 RFC5016: Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol (24 pages) RFC5585: DomainKeys Identified Mail (DKIM) Service Overview (23 pages) RFC5617: DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) (21 pages) RFC5672: RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update (14 pages) * Updates RFC4871 DNS Extensions (dnsext) ----------------------- Charter Last Modified: 2009-09-16 Current Status: Active Chairs: Olafur Gudmundsson Andrew Sullivan Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion: namedroppers@ops.ietf.org To Subscribe: namedroppers-request@ops.ietf.org Archive: http://ops.ietf.org/lists/namedroppers/ Description of Working Group: The DNS has a large installed base and repertoire of protocol specifications. The DNSEXT WG group will actively advance DNS protocol-related RFCs on the standards track while thoroughly reviewing further proposed extensions. The scope of the DNSEXT WG is confined to the DNS protocol, particularly changes that affect DNS protocols "on the wire" or the internal processing of DNS data. DNS operations are out of scope for the WG. The WG will limit itself to review of proposals for new extensions and clarification to the DNS protocol, including DNSSEC. Adoption of new work targeted for standards track will require changes to this charter. The working group can nevertheless undertake work in following subjects without a charter change: DNSSEC and TSIG/TKEY algorithm maintenance Hardening DNS protocol and providing guidance to implementors Advancing existing Proposed Standard RFCs to Draft/Full Standard Obsoleting RFCs. Maintaining a Wiki containing a guide to DNS protocol RFC's. Improving DNS zone synchronization mechanisms Examining transport protocols, possibly adding new ones. Before formal adoption of any such items at least 5 working group participants must publicly state that the item is within charter and is worthwhile item for further study. The DNSEXT WG will conduct the specified RFC5395 review of RR templates as they are posted, and EDNS0 Option templates if EDNS0-bis updates registration requirements. The WG will review DNS protocol related work which may originate elsewhere in the IETF, including AD-sponsored submissions or drafts in other working group. The WG does not intend to hold face to face meetings, though may do so if deemed necessary for resolution of a specific issue at hand. Goals and Milestones: Done - Forward NSEC rdata to IESG for Proposed Standard Done - Forward RFC2535-bis to IESG for proposed standard Done - Forward Case Insensitive to IESG for Proposed Standard Done - Forward LLMNR to IESG for Proposed Standard Done - Update boilerplate text on OPT-IN Done - Forward Wildcard clarification to IESG for proposed standard Done - Finalize Zone Enumeration Requirements Done - RFC2538 (CERT RR) to Draft Standard Done - Forgery Resilience advanced to IESG Aug 2009 - TSIG/MD5 Obsoleting to IESG. Sep 2009 - EDNS0 Ping Option advanced to IESG Oct 2009 - Resolver side Forgery Resilience advanced to IESG Oct 2009 - DNSSEC Errata document to IESG Nov 2009 - GOST DNSKEY and DS support advanced to IESG Dec 2009 - EDNS0-bis update advanced to IESG Jan 2010 - AXFR Clarify to IESG Feb 2010 - DNS existing transport protocol recommendations/clarifications to IESG Internet-Drafts: - Secret Key Transaction Authentication for DNS (TSIG) [draft-ietf-dnsind-tsig-13] (14 pages) - Extensions to DNS (EDNS1) [draft-ietf-dnsext-edns1-03] (4 pages) - A DNS RR for specifying the location of services (DNS SRV) [draft-ietf-dnsind-rfc2052bis-06] (10 pages) - A DNS RR Type for Lists of IP Address Prefixes (APL RR) [draft-ietf-dnsind-apl-rr-03] (6 pages) - Simple Secure Domain Name System (DNS) Dynamic Update [draft-ietf-dnsind-simple-secure-update-02] (8 pages) - Secret Key Establishment for DNS (TKEY RR) [draft-ietf-dnsind-tkey-03] (18 pages) - Domain Name System (DNS) IANA Considerations [draft-ietf-dnsind-iana-dns-04] (13 pages) - DNS Request and Transaction Signatures ( SIG(0)s ) [draft-ietf-dnsind-sig-zero-01] (10 pages) - DNS SIGALGOPT [draft-ietf-dnsind-sigalgopt-00] (3 pages) - A DNS RR for encoding DHCP information [draft-ietf-dnsind-dhcp-rr-00] (4 pages) - DNS Security Extension Clarification on Zone Status [draft-ietf-dnsind-zone-status-00] (9 pages) - Domain Name System Security (DNSSEC) Signing Authority [draft-ietf-dnsext-signing-auth-03] (7 pages) - Secure Domain Name System (DNS) Dynamic Update [draft-ietf-dnsext-simple-secure-update-03] (9 pages) - DNS Security Extension Clarification on Zone Status [draft-ietf-dnsext-zone-status-05] (9 pages) - Secret Key Establishment for DNS (TKEY RR) [draft-ietf-dnsext-tkey-05] (17 pages) - Domain Name System (DNS) IANA Considerations [draft-ietf-dnsext-iana-dns-02] (12 pages) - A Proposed Enhancement to the EDNS0 Version Mechanism [draft-ietf-dnsext-edns0dot5-02] (6 pages) - DNS Request and Transaction Signatures ( SIG(0)s ) [draft-ietf-dnsext-sig-zero-03] (9 pages) - A DNS RR Type for Lists of Address Prefixes (APL RR) [draft-ietf-dnsext-apl-rr-02] (7 pages) - Secret Key Transaction Authentication for DNS (TSIG) [draft-ietf-dnsext-tsig-01] (15 pages) - DNS Zone Transfer Protocol (AXFR) [draft-ietf-dnsext-axfr-clarify-12] (15 pages) - Incremental Zone Transfer in DNS [draft-ietf-dnsext-ixfr-01] (10 pages) - DNSSEC and IPv6 A6 aware server/resolver message size requirements [draft-ietf-dnsext-message-size-04] (6 pages) - GSS Algorithm for TSIG (GSS-TSIG) [draft-ietf-dnsext-gss-tsig-07] (22 pages) - A DNS RR for Encoding DHCP Information (DHCID RR) [draft-ietf-dnsext-dhcid-rr-14] (12 pages) - DNS Security Document Roadmap [draft-ietf-dnsext-dnssec-roadmap-07] (16 pages) - RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) [draft-ietf-dnsext-rsa-03] (8 pages) - Authenticating denial of existence in DNS with minimum disclosure (or; An alternative to DNSSEC NXT records) [draft-ietf-dnsext-not-existing-rr-01] (17 pages) - Indicating Resolver Support of DNSSEC [draft-ietf-dnsext-dnssec-okbit-03] (5 pages) - Applicability Statement for DNS MIB Extensions [draft-ietf-dnsext-dnsmib-historical-00] (4 pages) - Handling of Unknown DNS Resource Record Types [draft-ietf-dnsext-unknown-rrs-06] (8 pages) - Link-local Multicast Name Resolution (LLMNR) [draft-ietf-dnsext-mdns-48] (29 pages) - Redefinition of DNS AD bit [draft-ietf-dnsext-ad-is-secure-07] (7 pages) - A DNS RR for specifying the location of services (DNS SRV) [draft-ietf-dnsext-rfc2782bis-01] (12 pages) - ZONE option in DNS messages [draft-ietf-dnsext-edns-zone-option-00] (4 pages) - Bind VIEW option in DNS messages [draft-ietf-dnsext-edns-bind-view-option-00] (4 pages) - Handling of unknown EDNS0 attributes [draft-ietf-dnsext-ends-unknown-00] (6 pages) - Obsoleting IQUERY [draft-ietf-dnsext-obsolete-iquery-04] (4 pages) - Parent's SIG over child's KEY [draft-ietf-dnsext-parent-sig-00] (7 pages) - Parent stores the child's zone KEYs [draft-ietf-dnsext-parent-stores-zone-keys-01] (10 pages) - Comparison of AAAA and A6 (do we really need A6?) [draft-ietf-dnsext-aaaa-a6-01] (13 pages) - Delegation Signer Resource Record [draft-ietf-dnsext-delegation-signer-16] (16 pages) - DNSSEC Opt-In [draft-ietf-dnsext-dnssec-opt-in-10] (16 pages) - DSA Keying and Signature Information in the DNS [draft-ietf-dnsext-rfc2536bis-dsa-08] (11 pages) - Storage of Diffie-Hellman Keying Information in the DNS [draft-ietf-dnsext-rfc2539bis-dhk-08] (12 pages) - Tradeoffs in DNS support for IPv6 [draft-ietf-dnsext-ipv6-dns-tradeoffs-02] (10 pages) - DNS Security Introduction and Requirements [draft-ietf-dnsext-dnssec-intro-14] (26 pages) - Elliptic Curve Keys and Signatures in the Domain Name System (DNS) [draft-ietf-dnsext-ecc-key-10] (16 pages) - Representing IPv6 addresses in DNS [draft-ietf-dnsext-ipv6-addresses-02] (6 pages) - TKEY Secret Key Renewal Mode [draft-ietf-dnsext-tkey-renewal-mode-05] (23 pages) - Limiting the Scope of the KEY Resource Record out [draft-ietf-dnsext-restrict-key-for-dnssec-04] (15 pages) - Threat Analysis Of The Domain Name System [draft-ietf-dnsext-dns-threats-08] (16 pages) - DNSSEC NSEC RDATA Format [draft-ietf-dnsext-nsec-rdata-07] (9 pages) - Resource Records for the DNS Security Extensions [draft-ietf-dnsext-dnssec-records-12] (33 pages) - The DISCOVER opcode [draft-dnsext-opcode-discover-02] (0 pages) - KEY RR Secure Entry Point Flag [draft-ietf-dnsext-keyrr-key-signing-flag-13] (10 pages) - DNS Extensions to support IP version 6 [draft-ietf-dnsext-rfc1886bis-04] (7 pages) - Protocol Modifications for the DNS Security Extensions [draft-ietf-dnsext-dnssec-protocol-10] (58 pages) - Domain Name System (DNS) Case Insensitivity Clarification [draft-ietf-dnsext-insensitive-07] (13 pages) - Domain Name Auto-Registration for Plugged-in IPv6 Nodes [draft-ietf-dnsext-ipv6-name-auto-reg-01] (21 pages) - Legacy Resolver Compatibility for Delegation Signer [draft-ietf-dnsext-dnssec-2535typecode-change-07] (5 pages) - The Role of Wildcards in the Domain Name System [draft-ietf-dnsext-wcard-clarify-12] (30 pages) - Minimally Covering NSEC Records and DNSSEC On-line Signing [draft-ietf-dnsext-dnssec-online-signing-03] (11 pages) - DNS Name Server Identifier Option (NSID) [draft-ietf-dnsext-nsid-03] (16 pages) - Evaluating DNSSEC Transition Mechanisms [draft-ietf-dnsext-dnssec-trans-06] (16 pages) - HMAC SHA TSIG Algorithm Identifiers [draft-ietf-dnsext-tsig-sha-07] (9 pages) - RFC 3597 Interoperability Report [draft-ietf-dnsext-interop3597-02] (6 pages) - Automated Updates of DNSSEC Trust Anchors [draft-ietf-dnsext-trustupdate-timers-07] (13 pages) - Requirements related to DNSSEC Signed Proof of Non-Existence [draft-ietf-dnsext-signed-nonexistence-requirements-03] (14 pages) - An In-Band Rollover Mechanism and an Out-Of-Band Priming Method for DNSSEC Trust Anchors [draft-ietf-dnsext-trustupdate-threshold-01] (24 pages) - Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC [draft-ietf-dnsext-dnssec-rsasha256-15] (10 pages) - DNSSEC Hashed Authenticated Denial of Existence [draft-ietf-dnsext-nsec3-14] (52 pages) - Storing Certificates in the Domain Name System (DNS) [draft-ietf-dnsext-rfc2538bis-10] (17 pages) - DNSSEC Experiments [draft-ietf-dnsext-dnssec-experiments-05] (15 pages) - Clarifications and Implementation Notes for DNSSECbis [draft-ietf-dnsext-dnssec-bis-updates-09] (12 pages) - Domain Name System (DNS) IANA Considerations [draft-ietf-dnsext-2929bis-08] (21 pages) - Derivation of DNS Name Predecessor and Successor [draft-ietf-dnsext-dns-name-p-s-02] (26 pages) - Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) [draft-ietf-dnsext-ds-sha256-06] (9 pages) - Requirements related to DNSSEC Trust Anchor Rollover [draft-ietf-dnsext-rollover-requirements-05] (11 pages) - Update to DNAME Redirection in the DNS [draft-ietf-dnsext-rfc2672bis-dname-17] (17 pages) - Measures for making DNS more resilient against forged answers [draft-ietf-dnsext-forgery-resilience-11] (26 pages) - The Modern DNS Implementation Guide [draft-ietf-dnsext-dns-protocol-profile-01] (26 pages) - Extension Mechanisms for DNS (EDNS0) [draft-ietf-dnsext-rfc2671bis-edns0-02] (11 pages) - Deprecation of HMAC-MD5 in DNS TSIG and TKEY Resource Records [draft-ietf-dnsext-tsig-md5-deprecated-03] (6 pages) - DNS Proxy Implementation Guidelines [draft-ietf-dnsext-dnsproxy-07] (14 pages) - DNS Security (DNSSEC) DNSKEY IANA Registry Algorithm Status Addition [draft-ietf-dnsext-dnssec-registry-fixes-00] (6 pages) - Cryptographic Algorithm Identifier Allocation for DNSSEC [draft-ietf-dnsext-dnssec-alg-allocation-00] (5 pages) - Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records for DNSSEC [draft-ietf-dnsext-dnssec-gost-01] (8 pages) - Handling of Unknown DNS Resource Record (RR) Types [draft-ietf-dnsext-rfc3597-bis-00] (7 pages) - DNS Transport over TCP [draft-ietf-dnsext-dns-tcp-requirements-01] (8 pages) Requests for Comments: RFC2782: A DNS RR for specifying the location of services (DNS SRV) (2 pages) * Obsoletes RFC2052 RFC2845: Secret Key Transaction Authentication for DNS (TSIG) (15 pages) * Updates RFC1035 * Updated by RFC3645 RFC2929: Domain Name System (DNS) IANA Considerations (12 pages) * OBSOLETED BY RFC5395 RFC2930: Secret Key Establishment for DNS (TKEY RR) (16 pages) RFC2931: DNS Request and Transaction Signatures ( SIG(0)s ) (10 pages) * Updates RFC2535 RFC3007: Secure Domain Name System (DNS) Dynamic Update (9 pages) * Updates RFC2137 * Obsoletes RFC2535 * Obsoletes RFC2136 * Updated by RFC4033 * Updated by RFC4034 * Updated by RFC4035 RFC3008: Domain Name System Security (DNSSEC) Signing Authority (7 pages) * Updates RFC2535 * Updated by RFC3658 * OBSOLETED BY RFC4033 * OBSOLETED BY RFC4034 * OBSOLETED BY RFC4035 RFC3090: DNS Security Extension Clarification on Zone Status (11 pages) * Updated by RFC3658 * OBSOLETED BY RFC4033 * OBSOLETED BY RFC4034 * OBSOLETED BY RFC4035 RFC3110: RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) (7 pages) RFC3123: A DNS RR Type for Lists of Address Prefixes (APL RR) (8 pages) RFC3225: Indicating Resolver Support of DNSSEC (6 pages) * Updated by RFC4033 * Updated by RFC4034 * Updated by RFC4035 RFC3226: DNSSEC and IPv6 A6 aware server/resolver message size requirements (6 pages) * Updates RFC2874 * Updates RFC2535 * Updated by RFC4033 * Updated by RFC4034 * Updated by RFC4035 RFC3363: Representing IPv6 addresses in DNS (6 pages) * Updates RFC2673 * Updates RFC2874 RFC3364: Tradeoffs in DNS support for IPv6 (11 pages) * Updates RFC2874 RFC3197: Applicability Statement for DNS MIB Extensions (5 pages) RFC3425: Obsoleting IQUERY (5 pages) * Updates RFC1035 RFC3445: Limiting the Scope of the KEY Resource Record out (10 pages) * Updates RFC2535 * OBSOLETED BY RFC4033 * OBSOLETED BY RFC4034 * OBSOLETED BY RFC4035 RFC3597: Handling of Unknown DNS Resource Record (RR) Types (8 pages) * Updated by RFC4033 * Updated by RFC4034 * Updated by RFC4035 * Updated by RFC5395 RFC3596: DNS Extensions to support IP version 6 (7 pages) RFC3645: GSS Algorithm for TSIG (GSS-TSIG) (22 pages) * Updates RFC2845 RFC3655: Redefinition of DNS AD bit (7 pages) * Obsoletes RFC2535 * OBSOLETED BY RFC4033 * OBSOLETED BY RFC4034 * OBSOLETED BY RFC4035 RFC3658: Delegation Signer Resource Record (19 pages) * Updates RFC3090 * Updates RFC3008 * Updates RFC2535 * Updates RFC1035 * Updated by RFC3755 * OBSOLETED BY RFC4033 * OBSOLETED BY RFC4034 * OBSOLETED BY RFC4035 RFC3755: Legacy Resolver Compatibility for Delegation Signer (5 pages) * Updates RFC3658 * Updates RFC2535 * Updated by RFC3757 * OBSOLETED BY RFC4033 * OBSOLETED BY RFC4034 * Updated by RFC3845 * OBSOLETED BY RFC4035 RFC3757: KEY RR Secure Entry Point Flag (10 pages) * Updates RFC3755 * Updates RFC2535 * OBSOLETED BY RFC4033 * OBSOLETED BY RFC4034 * OBSOLETED BY RFC4035 RFC3845: DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format (9 pages) * Updates RFC3755 * Updates RFC2535 * OBSOLETED BY RFC4035 * OBSOLETED BY RFC4034 * OBSOLETED BY RFC4033 RFC3833: Threat Analysis Of The Domain Name System (16 pages) RFC4033: DNS Security Introduction and Requirements (26 pages) * Updates RFC1034 * Updates RFC1035 * Updates RFC2136 * Updates RFC2181 * Updates RFC2308 * Updates RFC3225 * Updates RFC3007 * Updates RFC3597 * Updates RFC3226 * Obsoletes RFC2535 * Obsoletes RFC3008 * Obsoletes RFC3090 * Obsoletes RFC3445 * Obsoletes RFC3655 * Obsoletes RFC3658 * Obsoletes RFC3755 * Obsoletes RFC3757 * Obsoletes RFC3845 RFC4034: Resource Records for the DNS Security Extensions (33 pages) * Obsoletes RFC3845 * Obsoletes RFC2535 * Obsoletes RFC3008 * Obsoletes RFC3090 * Obsoletes RFC3445 * Obsoletes RFC3655 * Obsoletes RFC3658 * Obsoletes RFC3755 * Obsoletes RFC3757 * Updates RFC1034 * Updates RFC1035 * Updates RFC2136 * Updates RFC2181 * Updates RFC2308 * Updates RFC3225 * Updates RFC3007 * Updates RFC3597 * Updates RFC3226 * Updated by RFC4470 RFC4035: Protocol Modifications for the DNS Security Extensions (58 pages) * Obsoletes RFC3845 * Updates RFC1034 * Updates RFC1035 * Updates RFC2136 * Updates RFC2181 * Updates RFC2308 * Updates RFC3225 * Updates RFC3007 * Updates RFC3597 * Updates RFC3226 * Obsoletes RFC2535 * Obsoletes RFC3008 * Obsoletes RFC3090 * Obsoletes RFC3445 * Obsoletes RFC3655 * Obsoletes RFC3658 * Obsoletes RFC3755 * Obsoletes RFC3757 * Updated by RFC4470 RFC4343: Domain Name System (DNS) Case Insensitivity Clarification (13 pages) * Updates RFC1034 * Updates RFC1035 * Updates RFC2181 RFC4398: Storing Certificates in the Domain Name System (DNS) (17 pages) * Obsoletes RFC2538 RFC4470: Minimally Covering NSEC Records and DNSSEC On-line Signing (11 pages) * Updates RFC4035 * Updates RFC4034 RFC4509: Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) (9 pages) RFC4592: The Role of Wildcards in the Domain Name System (30 pages) * Updates RFC1034 * Updates RFC2672 RFC4471: Derivation of DNS Name Predecessor and Successor (26 pages) RFC4635: HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers (9 pages) RFC4701: A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR) (12 pages) * Updated by RFC5494 RFC4795: Link-local Multicast Name Resolution (LLMNR) (29 pages) RFC4955: DNS Security (DNSSEC) Experiments (15 pages) RFC4956: DNS Security (DNSSEC) Opt-In (16 pages) RFC5001: DNS Name Server Identifier Option (NSID) (16 pages) RFC4986: Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover (11 pages) RFC5011: Automated Updates of DNS Security (DNSSEC) Trust Anchors (13 pages) RFC5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence (52 pages) RFC5395: Domain Name System (DNS) IANA Considerations (17 pages) * Obsoletes RFC2929 * Updates RFC1183 * Updates RFC3597 RFC5452: Measures for Making DNS More Resilient against Forged Answers (18 pages) * Updates RFC2181 RFC5625: DNS Proxy Implementation Guidelines (12 pages) RFC5702: Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC (10 pages) Domain Name System Operations (dnsop) ------------------------------------- Charter Last Modified: 2008-12-16 Current Status: Active Chairs: Rob Austein Peter Koch Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Ronald Bonica Mailing Lists: General Discussion: dnsop@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/dnsop Archive: http://www.ietf.org/mail-archive/web/dnsop Description of Working Group: The DNS Operations Working Group will develop guidelines for the operation of DNS software servers and the administration of DNS zone files. These guidelines will provide technical information relating to the implementation of the DNS protocol by the operators and administrators of DNS zones. The group will perform the following activities: 1. Define the processes by which Domain Name System (DNS) software may be efficiently and correctly administered, configured, and operated on Internet networks. This will include root zone name servers, gTLD name servers, name servers for other DNS zones, iterative DNS resolvers, and recursive DNS resolvers. As part of this effort, the group will produce documents explaining to the general Internet community what processes and mechanisms should be employed for the effective management and operation of DNS software. 2. Publish documents concerning DNSSEC operational procedures. 3. Publish documents concerning the IPv6 DNS operational procedures and DNS-related IPv6 transition and coexistence issues. 4. Publish documents concerning the operations of the root and TLD services, and DNS resolvers. Goals and Milestones: Done - Submit I-D: revised Root Server Requirements. Done - Submit I-D: revised version of Key Handling. Done - Submit I-D: first version of Servers Sharing IP#. Done - Submit I-D: first version of Performance and Measuring. Done - Submit I-D: revised version of Key Handling. Done - Submit I-D: revised version of Servers Sharing IP#. Done - Submit Root Server Requirements to the IESG for consideration as Informational (BCP?). Done - Submit I-D: 2nd revised version of Servers Sharing IP#. Done - Distributing Authoritative Name Servers via Shared Unicast Addresses to the IESG for Informational Done - Submit Observed DNS Resolution Misbehavior to the IESG for Informational Done - Submit document describing the outstanding problems and issues with DNS discovery for IPv6 to the IESG for Informational. Done - Submit Operational Guidelines for 'local' zones in the DNS to IESG. Category to be determined. Done - Submit Operational Considerations and Issues with IPv6 DNS to the IESG for Informational Done - Submit Common Misbehavior against DNS Queries for IPv6 Addresses to the IESG for Informational Done - Submit DNSSEC Operational Procedures to IESG for BCP Done - Submit Identifying an Authoritative Name Server to IESG for Informational Done - Submit I-D: revised version of Considerations for the use of DNS Reverse Mapping Done - Submit I-D: revised version of Considerations for the use of DNS Reverse Mapping Sep 2007 - Submit I-D: revised version of Considerations for the use of DNS Reverse Mapping Sep 2007 - Submit I'm Being Attacked by PRISONER.IANA.ORG! to IESG for FYI Sep 2007 - Submit Locally-served DNS Zones to IESG for BCP Oct 2007 - Submit DNS Response Size Issues to IESG for Informational Dec 2007 - Submit Considerations for the use of DNS Reverse Mapping to IESG for BCP Dec 2007 - Submit AS112 Nameserver Operations to IESG for Informational Feb 2008 - Submit Initializing a DNS Resolver with Priming Queries to IESG for BCP Internet-Drafts: - Domain Name System (DNS) Security Key Rollover [draft-ietf-dnsind-rollover-00] (11 pages) - Root Name Server Operational Requirements [draft-ietf-dnsop-root-opreq-05] (9 pages) - Handling of DNS Zone Signing Keys [draft-ietf-dnsop-keyhand-04] (9 pages) - Distributing Root Name Servers via Shared Unicast Addresses [draft-ietf-dnsop-shared-root-server-01] (4 pages) - Distributing Authorittative Name Servers via Shared Unicast Addresses [draft-ietf-dnsop-hardie-shared-root-server-07] (0 pages) - DNSSEC Implementation in the CAIRN Testbed [draft-ietf-dnsop-dnsseccairn-00] (22 pages) - Domain Name System (DNS) Security Key Rollover [draft-ietf-dnsop-rollover-01] (11 pages) - Root Name Servers with Inter Domain Anycast Addresses [draft-ietf-dnsop-ohta-shared-root-server-03] (5 pages) - Testing Root Name Servers with Inter Domain Anycast Addresses [draft-ietf-dnsop-ohta-shared-root-server-test-00] (3 pages) - Encouraging the use of DNS IN-ADDR Mapping [draft-ietf-dnsop-inaddr-required-07] (7 pages) - Parent's SIG over child's KEY [draft-ietf-dnsop-parent-sig-00] (0 pages) - DNS IPv6 transport operational guidelines [draft-ietf-dnsop-ipv6-transport-guidelines-03] (6 pages) - Rollover of statically configured resolver keys [draft-ietf-dnsop-resolver-rollover-00] (9 pages) - IP Addresses that should never appear in the public DNS [draft-ietf-dnsop-dontpublish-unreachable-03] (0 pages) - Observed DNS Resolution Misbehavior [draft-ietf-dnsop-bad-dns-res-07] (23 pages) - IPv4-to-IPv6 migration and DNS name space fragmentation [draft-ietf-dnsop-v6-name-space-fragmentation-01] (0 pages) - Requirements for a Mechanism Identifying a Name Server Instance [draft-ietf-dnsop-serverid-09] (13 pages) - Operational Considerations and Issues with IPv6 DNS [draft-ietf-dnsop-ipv6-dns-issues-13] (30 pages) - An Interim Scheme for Signing the Public DNS Root [draft-ietf-dnsop-interim-signed-root-01] (0 pages) - DNS Referral Response Size Issues [draft-ietf-dnsop-respsize-11] (13 pages) - IPv6 Host Configuration of DNS Server Information Approaches [draft-ietf-dnsop-ipv6-dns-configuration-07] (33 pages) - DNSSEC Operational Practices [draft-ietf-dnsop-dnssec-operational-practices-09] (36 pages) - Common Misbehavior against DNS Queries for IPv6 Addresses [draft-ietf-dnsop-misbehavior-against-aaaa-03] (8 pages) - Requirements for Automated Key Rollover in DNSsec [draft-ietf-dnsop-key-rollover-requirements-02] (8 pages) - Preventing Use of Recursive Nameservers in Reflector Attacks [draft-ietf-dnsop-reflectors-are-evil-07] (8 pages) - Locally-served DNS Zones [draft-ietf-dnsop-default-local-zones-09] (13 pages) - DNSSEC Trust Anchor Configuration and Maintenance [draft-ietf-dnsop-dnssec-trust-anchor-04] (14 pages) - Considerations for the use of DNS Reverse Mapping [draft-ietf-dnsop-reverse-mapping-considerations-06] (15 pages) - I'm Being Attacked by PRISONER.IANA.ORG! [draft-ietf-dnsop-as112-under-attack-help-help-03] (17 pages) - AS112 Nameserver Operations [draft-ietf-dnsop-as112-ops-03] (23 pages) - Initializing a DNS Resolver with Priming Queries [draft-ietf-dnsop-resolver-priming-02] (8 pages) - Requirements for Management of Name Servers for the DNS [draft-ietf-dnsop-name-server-management-reqs-03] (18 pages) - DNSSEC Operational Practices, Version 2 [draft-ietf-dnsop-rfc4641bis-02] (38 pages) Requests for Comments: RFC2870: Root Name Server Operational Requirements (10 pages) * Obsoletes RFC2010 RFC3258: Distributing Authorittative Name Servers via Shared Unicast Addresses (11 pages) RFC3901: DNS IPv6 transport operational guidelines (6 pages) RFC4074: Common Misbehavior against DNS Queries for IPv6 Addresses (8 pages) RFC4339: IPv6 Host Configuration of DNS Server Information Approaches (33 pages) RFC4472: Operational Considerations and Issues with IPv6 DNS (30 pages) RFC4641: DNSSEC Operational Practices (36 pages) * Obsoletes RFC2541 RFC4697: Observed DNS Resolution Misbehavior (23 pages) RFC4892: Requirements for a Mechanism Identifying a Name Server Instance (13 pages) RFC5358: Preventing Use of Recursive Nameservers in Reflector Attacks (8 pages) Data for Reachability of Inter/tra-NetworK SIP (drinks) ------------------------------------------------------- Charter Last Modified: 2009-03-30 Current Status: Active Chairs: Richard Shockey Alexander Mayrhofer Debbie Guyton Real-time Applications and Infrastructure Area Directors: Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Cullen Jennings Mailing Lists: General Discussion: drinks@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/drinks Archive: http://www.ietf.org/mail-archive/web/drinks/current/maillist.html Description of Working Group: The IETF has been working on various aspects of SIP-enabled Multimedia administrative domains among SIP Service Providers (SSP's). SSP's are entities that provide session services utilizing SIP signaling to their customers. In addition, the IETF has done significant work on data exchanges among various network elements. The DRINKS working group is chartered with a scope that is orthogonal to SPEERMINT and ENUM. The protocol work of DRINKS will be designed to build from the work of SPEERMINT and ENUM to identify and define the data structures and data exchange protocol(s) among SIP based Multimedia administrative domains. The ENUM working group is specifically chartered to develop protocols that involve the translation of E.164 numbers to URIs. While the SPEERMINT working group has been chartered to develop requirements and best current practices among real-time application SSPs and to describe how such services may best interconnect across administrative boundaries. These administrative domains may be of any practical size and could be any type of SSP, such as recognized telephony carriers, enterprises, end-user groups, or Federations. Data exchanges among these administrative domains may be bi-lateral or multi-lateral in nature, and could include bulk updates and/or more granular real-time updates. Administrative domains may exchange data through the use of an external registry to aggregate data from multiple administrative domains or multiple data providers into a single view. The DRINKS WG will provide details of how Session Establishment Data (SED) is collected, what comprises SED, how SED should be used to properly identify an optimal path to a destination SIP user agent (UA),either internally or externally to the SSP. In addition DRINKS will insure that the SED and the SIP session data is securely exchanged between the peering functions. Typical SED data might include: + Routes - Destination SIP/SIPS/TEL URI Egress and Ingress Routes - Relevant route names, identifiers, and services - Attributes affecting route selection - PSTN database information + Targets - Individual, ranges, or groups of user-agent identifiers - Target aggregation entities (e.g. service areas) and target-to-aggregate associations + Treatment Profiles - Priority - Location Potential SED Data types not in scope will be session rating or other billing or pricing information between SSP's The working group will draw upon expert advice and on-going consultation from the ENUM and SPEERMINT working groups, and also the XML Directorate. The working group will consider the reuse of elements of RFC 4114. The final work product(s) from this working group will utilize and be based on XML documents and XML document exchanges. Goals and Milestones: Sep 2008 - Requirements for Session Establishment Data (SED) data exchanges. Nov 2008 - Exchanging of Session Establishment Data (SED) from data providers to registries or between bi/multi-lateral partners. Feb 2009 - Exchange of Session Establishment Data (SED) from registries to Location Routing Function databases. Internet-Drafts: - Consolidated Provisioning Problem Statement [draft-ietf-drinks-cons-rqts-00] (12 pages) - DRINKS Use cases and Protocol Requirements [draft-ietf-drinks-usecases-requirements-00] (22 pages) No Requests for Comments Email Address Internationalization (eai) ---------------------------------------- Charter Last Modified: 2009-04-03 Current Status: Active Chairs: Harald Alvestrand XiaoDong Lee Applications Area Directors: Lisa Dusseault Alexey Melnikov Applications Area Advisor: Alexey Melnikov Mailing Lists: General Discussion: ima@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ima Archive: http://www.ietf.org/mail-archive/web/ima Description of Working Group: Since early in the effort to internationalize domain names, which resulted in the standards associated with IDNA, it has been understood that internationalization of email address local parts is required. At the same time, email address internationalization poses a series of special problems. Constraints on the interpretation of local-parts by any system other than the final delivery one make address encoding nearly impossible. The need to use addresses in both the email envelope and in header fields, and to do so in ways that are at least compatible, suggests that this is not a simple and isolated problem. This working group will address one basic approach to email internationalization. That approach is based on the use of an SMTP extension to enable both the use of UTF-8 in envelope address local- parts and optionally in domain-parts and the use of UTF-8 in mail headers -- both in address contexts and wherever encoded-words are permitted today. Its initial target will be a set of experimental RFCs that specify the details of this approach and provide the basis for generating and testing interoperable implementations. Its work will include examining whether "downgrading" -- transforming an internationalized message to one that is compatible with unextended SMTP clients and servers and unextended MUAs -- is feasible and appropriate and, if it is, specifying a way to do so. If it is not, the WG will evaluate whether the effort is worth taking forward. Other approaches may be considered by the formation of other working groups. Key parts of this effort include extended analyses and, if necessary, proof of concept in three areas in addition to smooth operation when all systems and components along a message path have been upgraded to support the new facilities. They are o Examination of scenarios for the appearance of these facilities to users, including ways in which alternate addresses may be specified if those are needed for downgrading. o Examination of different locations at which downgrading might be required and accomplished, differentiating between requirements and capabilities at the point of origin (at or before the submission server), those that exist while the message is in transit, and those that apply after SMTP "final delivery" or in the logical vicinity or an IMAP or POP server. o Examination of the "mailing list question", i.e., how a mixture of traditional and internationalized addresses on a mailing list will impact message flows, error reports, and delivery notifications in all plausible combinations of servers and addresses, including internationalizated and traditional reverse paths. Once the Experimental RFCs are completed and implemented, the experience gathered will be evaluated. If the approach is found to have been successful (using criteria the WG will establish as an early work item), the WG will be rechartered to update the documents for processing onto the standards track. 1.6. Deliverables The following deliverables are foreseen in this charter. The WG chairs may structure the deliverables into specific documents or document sets as needed. Adding or removing documents outside of these deliverables will require a charter update. o Overview and architecture (Info) o Interworking scenarios, including the "mailing list question" (Info) o SMTP extensions specification (Exp) o Header format specification (Exp) o Downgrading specification in SMTP (Exp) o Downgrading specification in POP servers (Exp) o Downgrading specification in IMAP servers (Exp) o Results and evaluation of experiment (Info) Going forward, it is possible that the SMTP downgrading specification will go for Informational due to the difficulty of fully specifying all necessary behavior. Additional possible documents suggested: Advice for MUA implementors (Info) Goals and Milestones: Done - Overview/architecture draft first Done - Interworking scenarios first draft Done - SMTP Extensions first draft Done - Header format first draft Done - Downgrading in SMTP first draft Done - Downgrading in IMAP first draft Done - Downgrading in POP first draft Jun 2006 - Overview/architecture draft to IESG Jun 2006 - Interworking scenarios to IESG Sep 2006 - SMTP Extensions to IESG Sep 2006 - Header format to IESG Sep 2006 - Downgrading in SMTP to IESG Sep 2006 - Downgrading in POP to IESG Sep 2006 - Downgrading in IMAP to IESG Dec 2006 - Results and evaluation first draft Mar 2007 - Results and evaluation to IESG Mar 2007 - Group recharter for standards track Internet-Drafts: - POP3 Support for UTF-8 [draft-ietf-eai-pop-09] (17 pages) - SMTP extension for internationalized email address [draft-ietf-eai-smtpext-14] (24 pages) - Downgrading mechanism for Email Address Internationalization [draft-ietf-eai-downgrade-13] (28 pages) - IMAP Support for UTF-8 [draft-ietf-eai-imap-utf8-08] (14 pages) - UTF-8 Mail: Scenarios [draft-ietf-eai-scenarios-03] (9 pages) - Overview and Framework for Internationalized Email [draft-ietf-eai-framework-06] (23 pages) - Internationalized Email Headers [draft-ietf-eai-utf8headers-13] (17 pages) - Mailing Lists and Internationalized Email Addresses [draft-ietf-eai-mailinglist-05] (11 pages) - Internationalized Delivery Status and Disposition Notifications [draft-ietf-eai-dsn-07] (19 pages) - An update to the mailto URI scheme for Email Address Internationalization [draft-ietf-eai-mailto-02] (6 pages) - Displaying Downgraded Messages for Email Address Internationalization [draft-ietf-eai-downgraded-display-02] (14 pages) - Internationalized Delivery Status and Disposition Notifications [draft-ietf-eai-dsnbis-01] (17 pages) - Guidelines for Internationalized Email Clients [draft-ietf-eai-email-clients-00] (16 pages) Requests for Comments: RFC4952: Overview and Framework for Internationalized Email (23 pages) * Updated by RFC5336 RFC5335: Internationalized Email Headers (14 pages) * Updates RFC2045 * Updates RFC2822 RFC5336: SMTP Extension for Internationalized Email Addresses (22 pages) * Updates RFC2821 * Updates RFC2822 * Updates RFC4952 RFC5337: Internationalized Delivery Status and Disposition Notifications (18 pages) * Updates RFC3461 * Updates RFC3464 * Updates RFC3798 RFC5504: Downgrading Mechanism for Email Address Internationalization (24 pages) Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- Charter Last Modified: 2009-09-30 Current Status: Active Chairs: Hannes Tschofenig Marc Linsner Real-time Applications and Infrastructure Area Directors: Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Cullen Jennings Secretary: Roger Marshall Mailing Lists: General Discussion: ecrit@ietf.org To Subscribe: https://www.ietf.org/mailman//listinfo/ecrit Archive: http://www.ietf.org/mail-archive/web/ecrit/current/maillist.html Description of Working Group: In a number of areas, the public switched telephone network (PSTN) has been configured to recognize an explicitly specified number (commonly one that is short and easily memorized) as a call for emergency services. These numbers (e.g. 911, 112) relate to an emergency service context and depend on a broad, regional configuration of service contact methods and a geographically-constrained context of service delivery. These calls are intended to be delivered to special call centers equipped to manage emergency response. Successful delivery of an emergency service call within those systems requires both an association of the physical location of the originator with an appropriate emergency service center and call routing to deliver the call to the center. Calls placed using Internet technologies do not use the same systems to achieve those goals, and the common use of overlay networks and tunnels (either as VPNs or for mobility) makes meeting them more challenging. There are, however, Internet technologies available to describe location and to manage call routing. This working group will describe when these may be appropriate and how they may be used. Explicitly outside the scope of this group is the question of pre-emption or prioritization of emergency services traffic. This group is considering emergency services calls which might be made by any user of the Internet, as opposed to government or military services that may impose very different authentication and routing requirements. The group will show how the availability of location data and call routing information at different steps in session setup would enable communication between a user and a relevant emergency response center. Though the term "call routing" is used in this document, it should be understood that some of the mechanisms which will be described might be used to enable other types of media streams. Video and text messaging, for example, might be used to request emergency services. While this group anticipates a close working relationship with groups such as NENA and ETSI EMTEL, any solution presented must be useful regardless of jurisdiction, and it must be possible to use without a single, central authority. Further, it must be possible for multiple delegations within a jurisdiction to be handled independently, as call routing for specific emergency types may be independent. This working group cares about privacy and security concerns, and will address them within its documents. Goals and Milestones: Done - Informational RFC containing terminology definitions and the requirements Done - An Informational document describing the threats and security considerations Done - A Standards Track RFC describing how to identify a session set-up request is to an emergency response center Done - A Standards Track RFC describing how to route an emergency call based on location information Done - An Informational document describing the Mapping Protocol Architecture Done - Submit 'Location Hiding: Problem Statement and Requirements' to the IESG for consideration as an Informational RFC. Done - Submit 'Framework for Emergency Calling using Internet Multimedia' to the IESG for consideration as an Informational RFC. Done - Submit 'Best Current Practice for Communications Services in support of Emergency Calling' to the IESG for consideration as a BCP document Oct 2009 - Submit 'Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements' to the IESG for consideration as an Experimental RFC Done - Submit "LoST Extension for returning Boundary Information for Services" to the IESG for consideration as an Experimental RFC Done - Submit "Using Imprecise Location for Emergency Call Routing" to the IESG for consideration as an Informational RFC Internet-Drafts: - Requirements for Emergency Context Resolution with Internet Technologies [draft-ietf-ecrit-requirements-14] (32 pages) - Framework for Emergency Calling using Internet Multimedia [draft-ietf-ecrit-framework-10] (37 pages) - A Uniform Resource Name (URN) for Emergency and Other Well-Known Services [draft-ietf-ecrit-service-urn-08] (15 pages) - Security Threats and Requirements for Emergency Call Marking and Mapping [draft-ietf-ecrit-security-threats-06] (18 pages) - LoST: A Location-to-Service Translation Protocol [draft-ietf-ecrit-lost-11] (79 pages) - Location-to-URL Mapping Architecture and Framework [draft-ietf-ecrit-mapping-arch-05] (18 pages) - Best Current Practice for Communications Services in support of Emergency Calling [draft-ietf-ecrit-phonebcp-13] (45 pages) - Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP) [draft-ietf-ecrit-dhc-lost-discovery-04] (8 pages) - Location Hiding: Problem Statement and Requirements [draft-ietf-ecrit-location-hiding-req-02] (11 pages) - Specifying Holes in LoST Service Boundaries [draft-ietf-ecrit-specifying-holes-01] (18 pages) - Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements [draft-ietf-ecrit-lost-sync-08] (27 pages) - IANA Registering a SIP Resource Priority Header Namespace for Local Emergency Communications [draft-ietf-ecrit-local-emergency-rph-namespace-04] (9 pages) - Location-to-Service Translation Protocol (LoST) Extension: ServiceListBoundary [draft-ietf-ecrit-lost-servicelistboundary-00] (9 pages) - Using Imprecise Location for Emergency Context Resolution [draft-ietf-ecrit-rough-loc-00] (14 pages) Requests for Comments: RFC5012: Requirements for Emergency Context Resolution with Internet Technologies (32 pages) RFC5031: A Uniform Resource Name (URN) for Emergency and Other Well-Known Services (15 pages) RFC5069: Security Threats and Requirements for Emergency Call Marking and Mapping (18 pages) RFC5222: LoST: A Location-to-Service Translation Protocol (69 pages) RFC5223: Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP) (8 pages) RFC5582: Location-to-URL Mapping Architecture and Framework (18 pages) EAP Method Update (emu) ----------------------- Charter Last Modified: 2009-02-11 Current Status: Active Chairs: Alan DeKok Joseph Salowey Alan DeKok Security Area Directors: Tim Polk Pasi Eronen Security Area Advisor: Pasi Eronen Mailing Lists: General Discussion: emu@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/emu Archive: http://www.ietf.org/mail-archive/web/emu/current/maillist.html Description of Working Group: The Extensible Authentication Protocol (EAP) [RFC 3748] is a network access authentication framework used in the PPP, 802.11, 802.16, VPN, PANA, and in some functions in 3G networks. EAP itself is a simple protocol and actual authentication happens in EAP methods. Over 40 different EAP methods exist. Most of these methods are proprietary methods, but some are documented in informational RFCs. In the past the lack of documented, open specifications has been a deployment and interoperability problem. There are currently only two EAP methods in the standards track that implement features such as key derivation that are required for many modern applications. Authentication types and credentials continue to evolve as do requirements for EAP methods. This group is chartered to work on the following types of mechanisms to meet requirements relevant to EAP methods in RFC 3748, RFC 4017, RFC 4962 and EAP Keying: - A mechanism based on strong shared secrets. This mechanism should strive to be simple and compact for implementation in resource constrained environments. - A document that defines EAP channel bindings and provides guidance for establishing EAP channel bindings within EAP methods. - Enable TLS-based EAP methods to support channel bindings. This item will not generate a new method; rather, it will focus on adding support for EAP channel bindings to the tunneled method (described below), and if possible, other TLS-based EAP methods. Potential mechanisms for adding channel binding support will be investigated, including tunneling of channel binding parameters, or a TLS extension, or other standard TLS mechanism - A mechanism to support extensible communication within a TLS protected tunnel. This mechanism will support meeting the requirements of an enhanced TLS mechanism, a password based authentication mechanism, and additional inner authentication mechanisms. It will also support channel bindings (as described above) in order to meet RFC 4962 requirements. - A mechanism that makes use of existing password databases such as AAA databases. This item will be based on the above tunnel method. Goals and Milestones: Done - Form design team to work on strong shared secret mechanism Done - Submit 2716bis I-D Jun 2006 - Submit first draft of enhanced EAP-TLS I-D Done - Form password based mechanism design team Done - Submit first draft of shared secret mechanism I-D Aug 2006 - Submit 2716bis draft to IESG for Proposed Standard Nov 2006 - Submit 2716bis draft to IESG for draft standard Dec 2006 - Submit first draft password based method I-D Jan 2007 - Submit Strong Shared Secret Mechanism to IESG Jan 2007 - Submit enhanced EAP-TLS to IESG Aug 2007 - Submit password Based Mechanism to IESG Jun 2008 - Submit Tunnel and Password Method requirements first Draft Sep 2008 - Submit EAP Channel Bindings First Draft Sep 2008 - Submit Tunnel Method first draft Oct 2008 - Submit TLS based method channel binding first draft Oct 2008 - Submit Password Method first draft Jan 2009 - Send EAP Channel Bindings to IESG Mar 2009 - Send Tunnel Method to IESG Apr 2009 - Send TLS based method channel binding to IESG Apr 2009 - Send Password based method to IESG Internet-Drafts: - The EAP TLS Authentication Protocol [draft-simon-emu-rfc2716bis-14] (33 pages) - EAP Generalized Pre-Shared Key (EAP-GPSK) Method [draft-ietf-emu-eap-gpsk-18] (39 pages) - Requirements for a Tunnel Based EAP Method [draft-ietf-emu-eaptunnel-req-04] (24 pages) - Channel Binding Support for EAP Methods [draft-ietf-emu-chbind-04] (23 pages) Requests for Comments: RFC5216: The EAP TLS Authentication Protocol (33 pages) * Obsoletes RFC2716 RFC5433: Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method (38 pages) Telephone Number Mapping (enum) ------------------------------- Charter Last Modified: 2009-03-30 Current Status: Active Chairs: Patrik Faltstrom Richard Shockey Real-time Applications and Infrastructure Area Directors: Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Cullen Jennings Secretary: Alexander Mayrhofer Mailing Lists: General Discussion: enum@ietf.org To Subscribe: enum-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/enum/index.html Description of Working Group: The ENUM working group has defined a DNS-based architecture and protocol [RFC 3761] by which an E.164 number, as defined in ITU Recommendation E.164, can be expressed as a Fully Qualified Domain Name in a specific Internet Infrastructure domain defined for this purpose (e164.arpa). Background: E.164 numbers are globally unique, language independent identifiers for resources on Public Telecommunication Networks that can support many different services and protocols. There is an emerging desire for network operators to utilize aspects of RFC 3761 to discover points of interconnection necessary to terminate communications sessions identified by a E164 number,in addition to identifying end point protocols and services. Working Group Revised Goals and Scope: 1. The working group will update RFC 3761 and advance to Draft Standard. 2. The working group will examine and document the use of RFC 3761 to facilitate network interconnection for services using E.164 addressing. The working group will coordinate its activities with other IETF working groups, existing or to be chartered, that are investigating elements of peering and or interconnection for VoIP or other services that typically use E.164 addressing. 3. The working group will continue examine and document various aspects of ENUM administrative and /or operational procedures irrespective of whether e164.arpa domain is used. 4. The working group will also examine the use of RFC 3761 technology for storing and delivering other information about services addressed by E.164 numbers, for example PSTN call routing and signaling data. 5. The Working Group will continue to maintain appropriate contact and liaison with other standards bodies and groups, specifically ITU-T SG2, to provide technical or educational information and address, as needed, issues related to the use of the E.164 numbering plan for services on IP networks. In addition the Working Group will continue to encourage the exchange of technical information within the emerging global ENUM community as well as documentation on practical experiences with implementations, alternate technology uses and the administration and provisioning of RFC 3761. 6. As described in RFC 3761, the IETF documents and registers the Enumservices. While extant, it is the ENUM working group that performs the technical review and development of the Enumservices for the Internet community. The working group determines whether to advance them and how to progress them technically. Coordination with other WGs will be taken into account on these. Other than Enumservices, all proposed deliverables of the working group will be discussed with and approved by the Area Directors, who may require wider review due to the broad impact of the subject. Goals and Milestones: Done - Initial draft of Service ENUM Requirements Done - Initial draft of ENUM Protocol Done - Revised draft of ENUM Protocol Done - Submit ENUM Protocol document to IESG for publication as Proposed Done - Revise and update RFC 2916 appropriate to DDDS (revision of 2915) Done - ENUM service registrations for SIP and H.323 Done - Enumservice Registration for Local Number Portability and Related Data as a Proposed Standard Done - Requirements for Carrier Interconnection using ENUM as an Informational Done - Carrier Interconnection using ENUM as a Proposed Standard Jul 2006 - ENUM Privacy and Security Considerations as an Informational Done - Advancement of RFC 3761 to Draft Standard Internet-Drafts: - ENUM Requirements [draft-ietf-enum-rqmts-01] (0 pages) - E.164 number and DNS [draft-ietf-enum-e164-dns-04] (13 pages) - The Number Portability Supplement to ITU-T Recommendation E.164 [draft-ietf-enum-e164s2-np-00] (28 pages) - ENUM Service Reference Model [draft-ietf-enum-operation-02] (15 pages) - IANA Registration for Enumservice Voice [draft-ietf-enum-voice-02] (14 pages) - Number Portability in the GSTN: An Overview [draft-ietf-enum-e164-gstn-np-06] (27 pages) - The E.164 to URI DDDS Application (ENUM) [draft-ietf-enum-rfc2916bis-08] (22 pages) - E.164 Number Mapping for the Extensible Provisioning Protocol [draft-ietf-enum-epp-e164-09] (17 pages) - ENUM Usage Scenarios [draft-ietf-enum-usage-scenarios-00] (17 pages) - enumservice registration for SIP Addresses-of-Record [draft-ietf-enum-sip-02] (9 pages) - Privacy and Security Considerations in ENUM [draft-ietf-enum-privacy-security-01] (17 pages) - ENUM Service Registration for H.323 URL [draft-ietf-enum-h323-02] (4 pages) - ENUM Implementation Issues and Experiences [draft-ietf-enum-experiences-12] (31 pages) - IANA Registration for Enumservices email, fax, mms, ems and sms [draft-ietf-enum-msg-06] (21 pages) - IANA Registration for ENUMservices web and ft [draft-ietf-enum-webft-02] (13 pages) - Enumservice Registration for Presence Services [draft-ietf-enum-pres-02] (8 pages) - IANA Registration for Enumservice VOID [draft-ietf-enum-void-02] (19 pages) - An ENUM Registry Type for the Internet Registry Information Service [draft-ietf-enum-iris-ereg-03] (57 pages) - Infrastructure ENUM Requirements [draft-ietf-enum-infrastructure-enum-reqs-05] (8 pages) - Carrier/Infrastrucure ENUM Requirements [draft-lind-infrastructure-enum-reqs-01] (7 pages) - IANA Registration for an Enumservice Containing PSTN Signaling Information [draft-ietf-enum-pstn-06] (12 pages) - ENUM Validation Information Mapping for the Extensible Provisioning Protocol [draft-ietf-enum-validation-epp-07] (26 pages) - ENUM Validation Architecture [draft-ietf-enum-validation-arch-05] (18 pages) - ENUM Validation Token Format Definition [draft-ietf-enum-validation-token-05] (17 pages) - IANA Registration for vCard Enumservice [draft-ietf-enum-vcard-07] (9 pages) - IANA Registration for IAX Enumservice [draft-ietf-enum-iax-05] (8 pages) - IANA Registration of Enumservices: Guide, Template and IANA Considerations [draft-ietf-enum-enumservices-guide-18] (46 pages) - A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services [draft-ietf-enum-im-service-04] (6 pages) - A Telephone Number Mapping (ENUM) Service Registration for Internet Calendaring Services [draft-ietf-enum-calendar-service-05] (7 pages) - The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM [draft-ietf-enum-infrastructure-08] (6 pages) - IANA Registration for an Enumservice Calling Name Delivery (CNAM) Information and IANA Registration for URI type 'pstndata' [draft-ietf-enum-cnam-08] (18 pages) - The ENUM Branch Location Record [draft-ietf-enum-branch-location-record-03] (10 pages) - Combined User and Infrastructure ENUM in the e164.arpa tree [draft-ietf-enum-combined-10] (11 pages) - The Uniform Resource Identifier (URI) DNS Resource Record [draft-ietf-enum-uri-01] (11 pages) - ENUM Requirement for EDNS0 Support [draft-ietf-enum-edns0-00] (16 pages) - The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) [draft-ietf-enum-3761bis-04] (22 pages) - IANA Registration for Enumservice 'XMPP' [draft-ietf-enum-xmpp-03] (8 pages) - IANA Registration for Enumservice UNUSED [draft-ietf-enum-unused-04] (16 pages) - Operational Requirements for ENUM-Based Softswitch Use [draft-ietf-enum-softswitch-req-05] (19 pages) - IANA Registration of Experimental and Trial Enumservices (X-Enumservices) [draft-ietf-enum-x-service-regs-01] (15 pages) - IANA Registration of Enumservices for Voice and Video Messaging [draft-ietf-enum-vmsg-03] (21 pages) - IANA Registrations of Enumservice "sms:smpp" and URI Scheme "smpp" [draft-ietf-enum-enumservice-sms-smpp-01] (12 pages) - IANA Registration for an Enumservice Trunkgroup [draft-ietf-enum-trunkgroup-00] (10 pages) - Update of legacy IANA Registrations of Enumservices [draft-ietf-enum-enumservices-transition-04] (68 pages) Requests for Comments: RFC2916: E.164 number and DNS (10 pages) * OBSOLETED BY RFC3761 RFC3482: Number Portability in the Global Switched Telephone Network (GSTN): An Overview (30 pages) RFC3764: enumservice registration for SIP Addresses-of-Record (9 pages) RFC3762: ENUM Service Registration for H.323 URL (4 pages) RFC3761: The E.164 to URI DDDS Application (ENUM) (22 pages) * Obsoletes RFC2916 RFC3953: Enumservice Registration for Presence Services (8 pages) RFC4002: IANA Registration for ENUMservices web and ft (13 pages) RFC4114: E.164 Number Mapping for the Extensible Provisioning Protocol (EPP) (17 pages) RFC4355: IANA Registration for Enumservices email, fax, mms, ems and sms (21 pages) RFC4415: IANA Registration for Enumservice Voice (14 pages) RFC4414: An ENUM Registry Type for the Internet Registry Information Service (IRIS) (57 pages) RFC4769: IANA Registration for an Enumservice Containing Public Switched Telephone Network (PSTN) Signaling Information (12 pages) RFC4725: ENUM Validation Architecture (18 pages) RFC4979: IANA Registration for Enumservice 'XMPP' (8 pages) RFC4969: IANA Registration for vCard Enumservice (9 pages) RFC5028: A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services (6 pages) RFC5105: ENUM Validation Token Format Definition (17 pages) RFC5076: ENUM Validation Information Mapping for the Extensible Provisioning Protocol (26 pages) RFC5067: Infrastructure ENUM Requirements (8 pages) RFC5278: IANA Registration of Enumservices for Voice and Video Messaging (22 pages) RFC5346: Operational Requirements for ENUM-Based Softswitch Use (19 pages) RFC5483: ENUM Implementation Issues and Experiences (30 pages) RFC5526: The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM (5 pages) RFC5527: Combined User and Infrastructure ENUM in the e164.arpa tree (11 pages) RFC5333: IANA Registration of Enumservices for Internet Calendaring (8 pages) FEC Framework (fecframe) ------------------------ Charter Last Modified: 2008-12-16 Current Status: Active Chairs: Greg Shepherd Marshall Eubanks Transport Area Directors: Magnus Westerlund Lars Eggert Transport Area Advisor: Magnus Westerlund Mailing Lists: General Discussion: fecframe@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/fecframe Archive: http://www.ietf.org/mail-archive/web/fecframe Description of Working Group: The object of this group is to develop specifications for using forward error correction (FEC) codes with applications in the Internet to provide protection against packet loss. The group will develop a protocol framework for application of FEC codes to arbitrary packet flows over unreliable transport protocols over both IP multicast and unicast. The application of the FEC codec on an aggregate of multiple packet flows may be investigated and considered to be included in the solution. The FECFrame working group will use the building block approach (RFC 3269), especially the FEC Building Block (RFC 3452), developed by the RMT working group. The FEC Building Block was developed to ensure that the RMT framework developed can support multiple FEC codes and maintain independence between FEC codes and protocols based on the framework. The FECFrame WG may develop new FEC schemes if necessary to provide substantial performance gains for the intended applications. However the acceptance of any FEC scheme will require multiple, prior, detailed reviews of the FEC code by independent experts from both the IETF and the broader community, since it is likely that the IETF working group will not include a large enough number of suitable experts in its working set. If these reviews are positive, then Working Group acceptance of an FEC scheme work item still needs the approval of the responsible Area Director. A primary objective of this framework is to support FEC for real-time media applications using RTP over UDP, such as on demand streaming and audio/video broadcast. Other potential usages of the framework may be brought to the working group for consideration during the development of the requirements, to enable future support of those usages. The group will coordinate closely with the AVT and MMUSIC working groups to ensure that the streaming use-case is fully specified both in terms of interactions with RTP/RTCP and application layer signalling. The group will also coordinate with the DCCP working group, at least to consider that transport protocol's role in streaming media. The interactions of the framework with existing and used security mechanisms must also be considered. The group will work with the RMT working group to ensure that the FEC Building Block defined in RMT supports both the RMT use-cases (object delivery over multicast) and the more general FEC protection of flow(s) over unreliable unicast and multicast transport. Specification of hybrid schemes involving both retransmission and forward error correction is out of scope of the group. Goals and Milestones: Done - Working Group consensus on requirements and their prioritization for the FEC protocol framework Done - Completed selection of solution to develop and mature Done - FEC framework requirements WG soft-freeze Done - FEC Streaming Framework WG soft-freeze Mar 2008 - FEC Grouping informational draft submitted to MMUSIC Nov 2008 - FEC Streaming Framework submitted as Proposed Standard Nov 2008 - FEC framework requirements submitted as Proposed Standard Nov 2008 - Usage of FEC framework with RTP submitted as Proposed Standard Nov 2008 - FEC SDP Elements submitted as Proposed Standard Nov 2008 - Discuss re-chartering Internet-Drafts: - FECFRAME requirements [draft-ietf-fecframe-req-02] (14 pages) - SDP Elements for FEC Framework [draft-ietf-fecframe-sdp-elements-04] (21 pages) - Forward Error Correction (FEC) Framework [draft-ietf-fecframe-framework-05] (39 pages) - SDP Elements for FEC Framework [draft-begen-fecframe-sdp-elements-01] (14 pages) - Methods to convey FEC Framework Configuration Information [draft-ietf-fecframe-config-signaling-01] (17 pages) - RTP Payload Format for 1-D Interleaved Parity FEC [draft-ietf-fecframe-interleaved-fec-scheme-05] (31 pages) - DVB-IPTV Application-Layer Hybrid FEC Protection [draft-ietf-fecframe-dvb-al-fec-03] (11 pages) - Raptor FEC Schemes for FECFRAME [draft-ietf-fecframe-raptor-01] (18 pages) - Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in FEC Framework [draft-ietf-fecframe-pseudo-cdp-02] (12 pages) - RTP Payload Format for Non-Interleaved and Interleaved Parity FEC [draft-ietf-fecframe-1d2d-parity-scheme-01] (39 pages) - RTP Payload Format for Raptor FEC [draft-ietf-fecframe-rtp-raptor-02] (20 pages) No Requests for Comments Forwarding and Control Element Separation (forces) -------------------------------------------------- Charter Last Modified: 2008-11-17 Current Status: Active Chairs: Patrick Droz Jamal Hadi Salim Routing Area Directors: Ross Callon Adrian Farrel Routing Area Advisor: Ross Callon Mailing Lists: General Discussion: forces@peach.ease.lsoft.com To Subscribe: listserv@peach.ease.lsoft.com Archive: http://www.ietf.org/mail-archive/web/forces/ Description of Working Group: The emergence of off-the-shelf network processor devices that implement the fast path or forwarding plane in network devices such as routers, along with the appearance of a new generation of third party signaling, routing, and other router control plane software, has created the need for standard mechanisms to allow these components to be combined into functional wholes. ForCES aims to define a framework and associated mechanisms for standardizing the exchange of information between the logically separate functionality of the control plane, including entities such as routing protocols, admission control, and signaling, and the forwarding plane, where per-packet activities such as packet forwarding, queuing, and header editing occur. By defining a set of standard mechanisms for control and forwarding separation, ForCES will enable rapid innovation in both the control and forwarding planes. A standard separation mechanism allows the control and forwarding planes to innovate in parallel while maintaining interoperability. The products of this working group will be: o A set of requirements for mechanisms to logically separate the control and data forwarding planes of an IP network element (NE) o An applicability statement for the ForCES model and protocol o Informational RFCs as necessary documenting current approaches to the functional model and controlled objects therein o An architectural framework defining the entities comprising a ForCES network element and identifying the interactions between them. o A description of the functional model of a Forwarding Element o A formal definition of the controlled objects in the functional model of a forwarding element. This includes IP forwarding, IntServ and DiffServ QoS. An existing specification language shall be used for this task. o Specification of IP-based protocol for transport of the controlled objects. When the control and forwarding devices are separated beyond a single hop, ForCES will make use of an existing RFC2914 compliant L4 protocol with adequate reliability, security and congestion control (e.g. TCP, SCTP) for transport purposes. The main focus area of the working group will be control and forwarding separation for IP forwarding devices where the control and forwarding elements are in close (same room/small number of hops) or very close (same box/one hop) proximity. Other scenarios will be considered but at not the main focus of the work. The functional model of the forwarding element will include QoS (DiffServ and IntServ) capabilities of modern networking devices such as routers. In order to minimize the effort to integrate forwarding elements and control elements, a mechanism for auto discovery and capability information exchange will form an integral part of the standardized interface. ForCES will coordinate with other standards bodies and working groups as appropriate. Examples of such bodies include IETF/GSMP, IETF/Megaco, the Network Processing Forum (NPF), the Multiservice Switching Forum (MSF), IEEE P1520, and SoftSwitch. ForCES will review relevant protocol efforts such as GSMP and Megaco and will extend or reuse them if appropriate. If protocol reuse is accepted as satisfactory for fulfilling the ForCES requirements then ForCES may recharter to adopt specific deliverables around the selected protocol. Goals and Milestones: Done - Submit requirements document to IESG Done - Submit framework document to IESG Done - Submit forwarding element functional model document to IESG Mar 2005 - Submit formal definition of controlled objects in functional model Done - Submit protocol selection/definition document to IESG Mar 2009 - Submit applicability statement to IESG Internet-Drafts: - Netlink as an IP Services Protocol [draft-ietf-forces-netlink-04] (32 pages) - Requirements for Separation of IP Control and Forwarding [draft-ietf-forces-requirements-11] (16 pages) - ForCES Forwarding Element Model [draft-ietf-forces-model-16] (132 pages) - ForCES Applicability Statement [draft-crouch-forces-applicability-01] (10 pages) - ForCES Applicability Statement [draft-ietf-forces-applicability-07] (13 pages) - Forwarding and Control Element Separation (ForCES) Framework [draft-ietf-forces-framework-14] (40 pages) - ForCES Protocol Evaluation Draft [draft-ietf-forces-evaluation-00] (31 pages) - ForCES Protocol Specification [draft-ietf-forces-protocol-22] (127 pages) - TCP/IP based TML (Transport Mapping Layer) for ForCES protocol [draft-ietf-forces-tcptml-04] (27 pages) - ForCES Intra-NE Topology Discovery [draft-ietf-forces-discovery-02] (17 pages) - ForCES MIB [draft-ietf-forces-mib-10] (20 pages) - ForCES Transport Mapping Layer (TML) Service Primitives [draft-ietf-forces-tmlsp-01] (25 pages) - SCTP based TML (Transport Mapping Layer) for ForCES protocol [draft-ietf-forces-sctptml-06] (29 pages) - ForCES Interoperability Draft [draft-ietf-forces-interoperability-04] (34 pages) - ForCES LFB Library [draft-ietf-forces-lfb-lib-00] (118 pages) - Implementation Report for ForCES [draft-ietf-forces-implementation-report-00] (38 pages) - ForCES Implementation Experience Draft [draft-ietf-forces-implementation-experience-00] (19 pages) Requests for Comments: RFC3549: Linux Netlink as an IP Services Protocol (33 pages) RFC3654: Requirements for Separation of IP Control and Forwarding (16 pages) RFC3746: Forwarding and Control Element Separation (ForCES) Framework (40 pages) Geographic Location/Privacy (geopriv) ------------------------------------- Charter Last Modified: 2009-10-15 Current Status: Active Chairs: Richard Barnes Alissa Cooper Real-time Applications and Infrastructure Area Directors: Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Cullen Jennings Tech Advisor: Lisa Dusseault Mailing Lists: General Discussion: geopriv@ietf.org To Subscribe: geopriv-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/geopriv/index.html Description of Working Group: The IETF has recognized that many applications are emerging that require geographic and civic location information about resources and entities, and that the representation and transmission of that information has significant privacy and security implications. We have created a suite of protocols that allow such applications to represent and transmit such location objects and to allow users to express policies on how these representations are exposed and used. The IETF has also begun working on creating applications that use these capabilities, for emergency services, general real-time communication, and other usages. The GEOPRIV working group is chartered to continue to develop and refine representations of location in Internet protocols, and to analyze the authorization, integrity, and privacy requirements that must be met when these representations of location are created, stored, and used. The group will create and refine mechanisms for the transmission of these representations that address the requirements that have been identified. The working group will work with other IETF working groups and other standards development organizations that are building applications that use location information to ensure that the requirements are well understood and met, and that no additional security or privacy issues related to location are left unaddressed as these location information is incorporated into other protocols. It remains a goal of the GEOPRIV working group to deliver specifications of broad applicability that will become mandatory to implement for IETF protocols that are location aware. This working group will not develop location-determining technology. However, the IETF acknowledges that information used in the location- determination process will in some cases need to be carried over the Internet. Where necessary, this working group will develop protocols or protocol extensions to encode location-determination data structures defined elsewhere. This working group will not develop technologies to directly address any particular regulatory requirements (e.g. 9-1-1). The group will continue to coordinate with any other IETF entities that are working on those problems to ensure the technologies created here meet the needs of those entities, and that the authorization, integrity, and privacy requirements on the mechanisms provided by these technologies continue to be met. Goals and Milestones: Done - Discuss initial geopriv scenarios and application requirements i-d's Done - Discuss initial geographic location privacy and security requirements i-d. Done - Initial i-d on geographic information protocol design, including privacy and security techniques. Done - Review charter and initial i-ds with AD, and have IESG consider rechartering if necessary. Done - Submit geopriv scenarios and application requirements to IESG for publicaiton as Informational RFCs Done - Submit security/privacy requirements I-D to IESG for publication as Informational RFC. Done - Submit PIDF-LO basic geopriv object draft as a PS Done - Initial Common Rules base object draft Done - Initial Common Ruels GEOPRIV object draft Done - Submit DHCP Civil draft as a PS Done - Resubmit Conveying Location Objects in RADIUS and Diameter to the IESG for publication as PS Done - Submit Additional Civic PIDF-LO types (updating 4119) to the IESG for publication as PS Done - Submit Layer 7 Location Conveyance Protocol Problem Statement and Requirements to the IESG for publication as Informational Done - Submit Requirements for Location by Reference Protocols to the IESG for publication as Informational Done - Submit PIDF-LO Usage Clarifications and Recommendations (updating 4119) to the IESG for publication as PS Done - Submit minimal HTTP based protocol satisfying baseline requirements specified in the Layer 7 Location Conveyance Protocol Problem Statement and Requirements to the IESG for publication as PS Done - Submit a LIS Discovery Mechanism to the IESG for publication as a PS Done - Submit Recommendations for Retransmission in SIP Location Conveyance to the IESG for publication as Informational Done - Submit recommendations for representing civic addresses in PIDF-LO to the IESG for publication as BCP Jun 2009 - Resubmit Geolocation Policy to the IESG for publication as PS Sep 2009 - Submit an draft for DHCP geodetic location to the IESG for publication as PS to obsolete 3825 Sep 2009 - Submit an Architecture for Location and Location Privacy to the IESG for publication as Informational Dec 2009 - Submit a Document Format for Filtering and Reporting PIDF-LO Location Notifications to the IESG for publication as PS Dec 2009 - Submit a URI scheme for directly expressing geodetic location to the IESG for publication as PS Dec 2009 - Submit a DHCP Option for a Location Uniform Resource Identifier (URI) to the IESG for publication as PS Done - Submit recommendations for LIS discovery through residential gateways as Informational Internet-Drafts: - Carrying Location Objects in RADIUS and Diameter [draft-ietf-geopriv-radius-lo-25] (61 pages) - Geopriv requirements [draft-ietf-geopriv-reqs-05] (27 pages) - Threat Analysis of the GEOPRIV Protocol [draft-danley-geopriv-threat-analysis-00] (18 pages) - DHC Location Object within GEOPRIV [draft-ietf-geopriv-dhcp-lo-option-00] (12 pages) - Threat Analysis of the geopriv Protocol [draft-ietf-geopriv-threat-analysis-02] (18 pages) - Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information [draft-ietf-geopriv-dhcp-lci-option-04] (14 pages) - Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information [draft-ietf-geopriv-dhcp-civil-10] (23 pages) - Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information [draft-ietf-geopriv-policy-21] (38 pages) - A Presence-based GEOPRIV Location Object Format [draft-ietf-geopriv-pidf-lo-04] (24 pages) - A Presence Architecture for the Distribution of GEOPRIV Location Objects [draft-ietf-geopriv-pres-03] (9 pages) - Common Policy: A Document Format for Expressing Privacy Preferences [draft-ietf-geopriv-common-policy-12] (43 pages) - Location Types Registry [draft-ietf-geopriv-location-types-registry-07] (18 pages) - GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations and Recommendations [draft-ietf-geopriv-pdif-lo-profile-15] (35 pages) - Revised Civic Location Format for PIDF-LO [draft-ietf-geopriv-revised-civic-lo-08] (19 pages) - Filtering Location Notifications in the Session Initiation Protocol (SIP) [draft-ietf-geopriv-loc-filters-07] (22 pages) - HTTP Enabled Location Delivery (HELD) [draft-ietf-geopriv-http-location-delivery-16] (47 pages) - Binary to Decimal Conversion for Location Configuration Information [draft-ietf-geopriv-binary-lci-01] (8 pages) - GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements [draft-ietf-geopriv-l7-lcp-ps-10] (26 pages) - Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI) [draft-ietf-geopriv-dhcp-lbyr-uri-option-06] (13 pages) - Requirements for a Location-by-Reference Mechanism [draft-ietf-geopriv-lbyr-requirements-08] (24 pages) - Discovering the Local Location Information Server (LIS) [draft-ietf-geopriv-lis-discovery-11] (16 pages) - Implications of 'retransmission-allowed' for SIP Location Conveyance [draft-ietf-geopriv-sip-lo-retransmission-03] (13 pages) - Considerations for Civic Addresses in PIDF-LO - Guidelines and IANA Registry Definition [draft-ietf-geopriv-civic-address-recommendations-03] (35 pages) - Use of Device Identity in HTTP-Enabled Location Delivery (HELD) [draft-ietf-geopriv-held-identity-extensions-01] (26 pages) - A Uniform Resource Identifier for Geographic Locations ('geo' URI) [draft-ietf-geopriv-geo-uri-03] (21 pages) - Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information [draft-ietf-geopriv-rfc3825bis-02] (20 pages) - An Architecture for Location and Location Privacy in Internet Applications [draft-ietf-geopriv-arch-01] (39 pages) Requests for Comments: RFC3693: Geopriv requirements (27 pages) RFC3694: Threat Analysis of the geopriv Protocol (18 pages) RFC3825: Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information (14 pages) RFC4079: A Presence Architecture for the Distribution of GEOPRIV Location Objects (9 pages) RFC4119: A Presence-based GEOPRIV Location Object Format (24 pages) * Updated by RFC5139 * Updated by RFC5491 RFC4589: Location Types Registry (18 pages) RFC4676: Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information (23 pages) * OBSOLETED BY RFC4776 RFC4745: Common Policy: A Document Format for Expressing Privacy Preferences (43 pages) RFC4776: Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information (19 pages) * Obsoletes RFC4676 RFC5139: Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO) (19 pages) * Updates RFC4119 RFC5491: GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations (28 pages) * Updates RFC4119 RFC5580: Carrying Location Objects in RADIUS and Diameter (53 pages) RFC5606: Implications of 'retransmission-allowed' for SIP Location Conveyance (11 pages) Global Routing Operations (grow) -------------------------------- Charter Last Modified: 2008-12-16 Current Status: Active Chairs: Christopher Morrow Peter Schoenmaker Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Ronald Bonica Tech Advisors: Bill Fenner Vijay Gill Mailing Lists: General Discussion: grow@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/grow Archive: http://www.ietf.org/mail-archive/web/grow Description of Working Group: The Border Gateway Protocol (BGP) is fundamental to the operation of the Internet. In recent years, occurrences of BGP related operational issues have increased, and while overall understanding of the default-free routing system has improved, there is still a long and growing list of concerns. Among these are routing table growth rates, interaction of interior and exterior routing protocols, dynamic properties of the routing system, and the effects of routing policy on both the size and dynamic nature of the routing table. In addition, new and innovative uses of BGP, such as the use of BGP as a signaling protocol for some types of Virtual Private Networks, have created new and unexpected operational issues. The purpose of the GROW is to consider the operational problems associated with the IPv4 and IPv6 global routing systems, including but not limited to routing table growth, the effects of the interactions between interior and exterior routing protocols, and the effect of address allocation policies and practices on the global routing system. Finally, where appropriate, the GROW documents the operational aspects of measurement, policy, security, and VPN infrastructures. GROW will also advise various working groups, including the IDR and RPSEC working groups, with respect to whether it is addressing the relevant operational needs, and where appropriate, suggest course corrections. Finally, operational requirements developed in GROW can also be used by any new working group charged with standardizing a next generation inter-domain routing protocol. GOALS: ----- (i). Evaluate and develop various methodologies of controlling policy information in order to reduce the effect of prefix sub-aggregates beyond the necessary diameter, so as to reduce the Network Layer Reachability Information (or NLRI; see e.g.,draft-ietf-idr-bgp4-23.txt) load on network infrastructure. (ii). Document and suggest operational solutions to problematic aspects of the currently deployed routing system. Examples include instability caused by oscillation of MULTI_EXIT_DISC (or MED; see RFC 3345) values. (iii). Analyze aspects of supporting new applications, including extending existing routing protocols and creating new ones. This includes risk, interference and application fit. (iv). Determine the effect of IGP extensions on the stability of the Internet routing system. (v). Document the operational aspects of securing the Internet routing system, and provide recommendations to other WGs. Some Relevant References: ------------------------- http://www.routeviews.org http://bgp.potaroo.net http://www.cidr-report.org http://www.pch.net/routing/BGP_table_size.ital http://moat.nlanr.net/AS http://www.apnic.net/stats/bgp http://www.merit.edu/ipma http://www.caida.org/projects/routing/atoms Goals and Milestones: Done - Publish Risk, Interference and Fit (RIFT) document as WG I-D Done - Publish Embedding Globally ...Considered Harmful as WG I-D Done - Publish MED Considerations Draft as WG I-D Done - Publish Collection Communities as WG I-D Done - Submit Collection Communities to IESG for BCP Done - Submit Embedding Globally ...Considered Harmful to IESG for Info Done - Submit MED Considerations to IESG for Info Internet-Drafts: - BGP Communities for Data Collection [draft-ietf-grow-collection-communities-09] (13 pages) - Controlling the redistribution of BGP routes [draft-ietf-grow-bgp-redistribution-00] (16 pages) - Bounding Longest Match Considered [draft-grow-bounded-longest-match-00] (8 pages) - BGP MULTI_EXIT_DISC (MED) Considerations [draft-ietf-grow-bgp-med-considerations-06] (17 pages) - Embedding Globally Routable Internet Addresses Considered Harmful [draft-ietf-grow-embed-addr-06] (11 pages) - Operational Concerns and Considerations for Routing Protocol Design -- Risk, Interference, and Fit (RIFT) [draft-ietf-grow-rift-01] (39 pages) - BGP Wedgies [draft-ietf-grow-bgp-wedgies-04] (10 pages) - Operation of Anycast Services [draft-ietf-grow-anycast-05] (31 pages) - Classless Inter-Domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan [draft-ietf-grow-rfc1519bis-05] (29 pages) - MRT routing information export format [draft-ietf-grow-mrt-10] (28 pages) - BGP Monitoring Protocol [draft-ietf-grow-bmp-02] (12 pages) - Routing System Stability [draft-ietf-grow-rss-01] (13 pages) - MPLS Tunnels for Virtual Aggregation [draft-ietf-grow-va-mpls-00] (5 pages) - FIB Suppression with Virtual Aggregation [draft-ietf-grow-va-01] (27 pages) - Requirements for the graceful shutdown of BGP sessions [draft-ietf-grow-bgp-graceful-shutdown-requirements-01] (14 pages) - Graceful BGP session shutdown [draft-ietf-grow-bgp-gshut-01] (19 pages) - Performance of Virtual Aggregation [draft-ietf-grow-va-perf-00] (16 pages) - GRE and IP-in-IP Tunnels for Virtual Aggregation [draft-ietf-grow-va-gre-00] (7 pages) - Proposal to use an inner MPLS label to identify the remote ASBR VA [draft-ietf-grow-va-mpls-innerlabel-00] (6 pages) - Proposal for Auto-Configuration in Virtual Aggregation [draft-ietf-grow-va-auto-00] (11 pages) Requests for Comments: RFC4085: Embedding Globally Routable Internet Addresses Considered Harmful (11 pages) RFC4264: BGP Wedgies (10 pages) RFC4384: BGP Communities for Data Collection (13 pages) RFC4451: BGP MULTI_EXIT_DISC (MED) Considerations (17 pages) RFC4632: Classless Inter-Domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan (29 pages) RFC4786: Operation of Anycast Services (31 pages) Host Identity Protocol (hip) ---------------------------- Charter Last Modified: 2009-04-13 Current Status: Active Chairs: David Ward Gonzalo Camarillo Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion: hipsec@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/hipsec Archive: http://www.ietf.org/mail-archive/web/hipsec/current/maillist.html Description of Working Group: The Host Identity Protocol (HIP) provides a method of separating the end-point identifier and locator roles of IP addresses. It introduces a new Host Identity (HI) name space, based on public keys. The public keys are typically, but not necessarily, self generated. The specifications for the architecture and protocol details for these mechanisms consist of: HIP Architecture (RFC 4423) Host Identity Protocol (RFC 5201) There are several publicly known interoperating implementations, some of which are open source. Currently, the HIP base protocol works well with any pair of co-operating end-hosts. However, to be more useful and more widely deployable, HIP needs some support from the existing infrastructure, including the DNS, and a new piece of infrastructure, called the HIP rendezvous server. +-------------------------------------------------------+ | The purpose of this Working Group is to define the | | minimal infrastructure elements that are needed for | | HIP experimentation on a wide scale. | +-------------------------------------------------------+ At this point, the missing elements for running such wide-scale experiments are a NAT traversal solution, a description on the interactions between legacy (i.e., HIP unaware) applications and HIP, and a native API for HIP. Additionally, the working group will specify, also in Experimental RFCs, how to build HIP-based overlays. HIP-based overlays have received a lot of attention in different fora and are seen as a key area for HIP experimentation where the benefits HIP brings may be most relevant. Note that even though the specifications are chartered for Experimental, it is understood that their quality and security properties should match the standards track requirements. The main purpose for producing Experimental documents instead of standards track ones are the unknown effects that the mechanisms may have on applications and on the Internet at large. In parallel to this working group, there is an IRTF Research Group with a broader scope that includes efforts both on developing the more forward looking aspects of the HIP architecture and on exploring the effects that HIP may have on the applications and the Internet. The following are charter items for the working group: o Specify how legacy (i.e., HIP unaware) applications can be made to work with HIP. o Specify a solution for HIP to traverse legacy (i.e., HIP unaware) NATs. This solution will be based on existing NAT traversal mechanisms such as ICE (Interactive Connectivity Establishment). o Specify a native HIP socket API. o Specify a framework to build HIP-based overlays. This framework will describe how HIP can perform some of the tasks needed to build an overlay and how technologies developed somewhere else (e.g., a peer protocol developed in the P2PSIP WG) can complement HIP by performing the tasks HIP was not designed to perform. o Specify how to generate ORCHIDs from other node identifiers including both cryptographic ones (leading to cryptographic delegation) and non-cryptographic ones (e.g., identifiers defined by a peer protocol). o Specify how to carry certificates in the base exchange. This was removed from the base HIP spec so that the mechanism is specified in a stand-alone spec. o Specify how to carry upper-layer data over specified HIP packets. These include some of the existing HIP packets and possibly new HIP packets (e.g., a HIP packet that occurs outside a HIP base exchange). Goals and Milestones: Done - First version of the HIP basic mobility and multi-homing mechanism specification. Done - First version of the HIP DNS resource record(s) specification. Done - First version of the HIP basic rendezvous mechanism specification. Done - WGLC on the HIP architecture specification Done - Submit the HIP architecture specification to the IESG Done - WG LC on the base protocol specification Done - WG LC on the ESP usage specification Done - WGLC the HIP registration extensions specification Done - WGLC the HIP DNS resource record(s) specification Done - WG LC on the basic HIP rendezvous mechanism specification. Done - Submit the ESP usage specification to the IESG for Experimental Done - Submit the base protocol specification to the IESG for Experimental Done - WG LC on the HIP basic mobility and multi-homing specification. Done - Submit the HIP registration extensions specification for Experimental Done - Submit the HIP DNS resource record(s) specification to the IESG for Experimental. Done - Submit the HIP basic mobility and multihoming specification to the IESG for Experimental. Done - Submit the basic HIP rendezvous mechanism specification to the IESG for Experimental. Done - WGLC Legacy Application Interworking specification Done - Submit the Legacy Application Interworking specification to the IESG Dec 2008 - WGLC Legacy NAT traversal specification Feb 2009 - WGLC Native API specification Feb 2009 - Submit the Legacy NAT traversal specification to the IESG Apr 2009 - Submit Native API specification to the IESG Apr 2009 - WGLC Framework for HIP overlays specification Apr 2009 - WGLC ORCHID generation specification Apr 2009 - WGLC Certs in HIP base exchange specification Apr 2009 - WGLC Upper-layer data transport in HIP Jul 2009 - Recharter or close the WG Jul 2009 - Submit Framework for HIP overlays specification to the IESG Jul 2009 - Submit ORCHID generation specification to the IESG Jul 2009 - Submit Certs in HIP base exchange specification to the IESG Jul 2009 - Submit Upper-layer data transport in HIP to the IESG Internet-Drafts: - Host Identity Protocol [draft-ietf-hip-base-11] (108 pages) - Host Identity Protocol Architecture [draft-ietf-hip-arch-04] (24 pages) - End-Host Mobility and Multihoming with the Host Identity Protocol [draft-ietf-hip-mm-06] (48 pages) - Host Identity Protocol (HIP) Domain Name System (DNS) Extensions [draft-ietf-hip-dns-10] (21 pages) - Host Identity Protocol (HIP) Rendezvous Extension [draft-ietf-hip-rvs-06] (15 pages) - Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) [draft-ietf-hip-esp-07] (37 pages) - Host Identity Protocol (HIP) Registration Extension [draft-ietf-hip-registration-03] (14 pages) - Using the Host Identity Protocol with Legacy Applications [draft-ietf-hip-applications-05] (22 pages) - Basic HIP Extensions for Traversal of Network Address Translators [draft-ietf-hip-nat-traversal-09] (33 pages) - Basic Socket Interface Extensions for Host Identity Protocol (HIP) [draft-ietf-hip-native-api-09] (18 pages) - HIP Certificates [draft-ietf-hip-cert-02] (10 pages) - HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment [draft-ietf-hip-bone-03] (18 pages) - HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper-layer Protocol Signaling (HICCUPS) [draft-ietf-hip-hiccups-00] (19 pages) - Host Identity Protocol (HIP) Multi-hop Routing Extension [draft-ietf-hip-via-00] (7 pages) Requests for Comments: RFC4423: Host Identity Protocol (HIP) Architecture (24 pages) RFC5201: Host Identity Protocol (108 pages) RFC5205: Host Identity Protocol (HIP) Domain Name System (DNS) Extensions (21 pages) RFC5203: Host Identity Protocol (HIP) Registration Extension (14 pages) RFC5202: Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) (37 pages) RFC5204: Host Identity Protocol (HIP) Rendezvous Extension (15 pages) RFC5206: End-Host Mobility and Multihoming with the Host Identity Protocol (48 pages) RFC5338: Using the Host Identity Protocol with Legacy Applications (14 pages) Handover Keying (hokey) ----------------------- Charter Last Modified: 2009-07-20 Current Status: Active Chairs: Glen Zorn Tina Tsou (Ting ZOU) Security Area Directors: Tim Polk Pasi Eronen Security Area Advisor: Tim Polk Mailing Lists: General Discussion: hokey@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/hokey Archive: http://www.ietf.org/mail-archive/web/hokey/current/maillist.html Description of Working Group: Most deployments of EAP in wireless networks employ an authenticator in pass-through mode, usually located at the edge, coupled with a backend AAA/EAP server. Many EAP methods generate an MSK and an EMSK. The MSK is used by several EAP lower layers. The EMSK remains at the peer and server, but it is not presently used in any specifications. Different EAP lower layers make use of the MSK differently; the most common usage is to derive Transient Session Keys (TSKs) to provide access link security in networks (e.g., IEEE 802.11i, IEEE 802.16e), although some lower layers (e.g., IKEv2) use the MSK for other purposes. Extensions to current EAP key framework will be needed to facilitate inter-authenticator handover and roaming. Some problems that need to be addressed with extensions to EAP keying include: 1) Inter-authenticator handovers require re-execution of EAP authentication even though the same EAP authentication server is used. Handover scenarios vary considerably in their fundamental assumptions. In scenarios where hosts remain connected during the handover period, EAP authentication need not be in the critical path for handover. However, there are scenarios where necessary connectivity is not available to support "make before break" communications. In these scenarios, significant handover latency can result. To avoid this latency, SDOs have employed methods such as context transfer and anchoring that are inefficient or insecure or both. 2) EAP peers with unexpired keying material from a full EAP exchange must take part in a full EAP exchange with the same AAA server to extend a session. While some EAP methods provide fast re- authentication mechanisms, a consistent, EAP-method-independent, low- latency re-authentication mechanism is needed. 3) EAP generates keys (MSK and EMSK). When the EAP WG updated the protocol and specified the keying framework, many details regarding the use of the EMSK were not specified. The EMSK can be used as the root of a cryptographic key hierarchy, and then the keys in the hierarchy are used in various ways to provide the needed security services. In order to ensure that different keys derived from the EMSK are cryptographically separate and that the key derivations are coordinated in an acceptable manner, it is important to clearly specify the top of the topology for the key hierarchy and some guidelines for child key derivations. 4) When wireless networks employ AAA infrastructures, the cross-domain roaming is handled by inter-domain authentication via the "home" AAA/EAP server. Any authentication must pass through the home server, which increases latency. Latency can be reduced by establishing a trust relationship between the EAP peer and the visited domain's AAA/EAP server. This trust relationship would be brokered by the home EAP/AAA server. Efficient re-authentication for the EAP peer can be supported locally within the visited domain. Some of the inconsistency in current handoff and roaming solutions can be attributed to different trade-offs between computational cost, mobility performance, and security. Specifications are not consistent in the way that the key derivation function (KDF) and KDF parameters are used. Clear direction by the IETF on the topology and construction of a key hierarchy could reduce some of the inconsistencies. However, the HOKEY WG will not attempt to standardize TSK derivation from the MSK, as this would interference with work of other SDOs. The solutions specified by the HOKEY WG fall into several categories, based on timing and mechanism. The authentication and key management may occur before handoff, when latency is much less critical. Alternatively, authentication and key management can occur as part of the handoff, where latency is critical. Solutions should reduce or eliminate the number of referrals to AAA servers, and solutions should avoid re-executing lengthy EAP method exc hanges.This may be accomplished by providing new mechanisms for cryptographic keying material in combination with a protocol for the timely delivery of appropriate keys to the appropriate entities. Solutions are expected to include "handover keying," "low-latency re-authentication," and "pre-authentication." All solution categories are useful, each supporting different scenarios. The HOKEY WG may provide multiple solutions, each addressing a different scenario. Solutions specified by the HOKEY WG must: 1) Be responsive to handover and re-authentication latency performance objectives within a mobile wireless access network. 2) Fulfill the requirements in draft-housley-aaa-key-mgmt and draft-ietf-eap-keying. 3) Be independent of the access-technology. Any key hierarchy topology or protocol defined must be independent of EAP lower layers. The protocols may require additional support from the EAP lower layers that use it. 4) Accommodate inter-technology heterogeneous handover and roaming. 5) No changes to EAP methods. Any extensions defined to EAP must not cause changes to existing EAP methods. In specifying an access-technology-independent solution, media independent guidelines for SDOs may also be needed to explain how the keying material and signaling can be employed in a specific access technology. HOKEY WG Deliverables ===================== All the specifications will be EAP-method-independent manner and access-technology-agnostic. EAP re-authentication and EAP pre- authentication authenticator are expected to use the same layer and the same protocol as the original EAP authentication used for the authenticator. They will provide enough semantics and guidance so that all SDOs can employ them and preserve cryptographic separation. 1) A Problem Statement that defines the problem of re-authentication and key management. The discussion will include security and performance goals for the solutions. Too often, mobility optimization discussions do not clearly identify the scenarios that are being addressed; this lack of clarity often makes it difficult to agree on whether the proposed optimizations offer real value. To avoid this situation, the Problem Statement must clearly describe the scenarios that are being addressed, and the assumptions about the handover environment associated with that scenario. 2) A specification of an EMSK-based key hierarchy topology. The specification will include a requirements, one or more KDF, and parameters. This is follow-on work EAP (RFC 3748) and EAP keying framework that was developed in the EAP WG. 3) A specification for the derivation of root keys, such as the handover root key (HRK), as well as any other media-independent keys (e.g., authenticator level keys) that need to be derived from such a root key, to support re-authentication and handover key management. The HOKEY WG can base these keys on either the MSK or the EMSK produced by EAP (pick one). If the consensus is to use the EMSK, then the HRK forms one branch in the EMSK-based key hierarchy. This specification will describe the properties of each key that is specified, and the topics must include caching, naming, scope, binding, storage, and key lifetime. 4) A protocol specification for media-independent, low-latency re-authentication. The protocol specification must support handovers between EAP authenticators. This protocol specification is expected to employ a re-authentication branch in the key hierarchy. 5) A protocol specification for secure and timely distribution of cryptographic keys to support roaming and handover. Use of AAA protocols is preferred, and if used, should leverage existing work if possible (such as RADEXT WG work on RFC 3576bis and RADIUS cryptographic algorithm agility). However, if AAA protocols cannot meet the objectives, other protocols for reactive or proactive distribution or retrieval of keys by the proper entities is permitted. 6) A specification for inter-EAP-authenticator roaming and re- authentication in visited domains that is brokered using inter-domain trust relationships to support efficient inter-domain roaming. 7) A specification for EAP pre-authentication to support low-latency inter-authenticator handoffs. Goals and Milestones: Done - First draft with a problem statement on EAP re-authentication and key management Done - First draft on EMSK-based Keying Hierarchy Done - First draft on EAP Re-authentication and Handover Keying Hierarchy Done - First draft on EAP Re-authentication Protocol Done - First draft on Protocol and Keying Hierarchy for Visited Domain Handovers and Re-authentication Done - Submit EMSK-based Keying Hierarchy draft to IESG Done - First draft on Handover Key Distribution Protocol Done - Submit the problem statement draft to IESG Done - Submit EAP Re-authentication and Handover Keying Hierarchy draft to IESG Done - Submit EAP Re-authentication Protocol draft to IESG Done - Submit Protocol and Keying Hierarchy for Visited Domain Handovers and Re-authentication draft to IESG Done - First draft on EAP Pre-authentication Specification for inter-technology and inter-domain handoffs Mar 2009 - Submit EAP Pre-authentication Specification to IESG Mar 2009 - Re-charter or shut down WG Internet-Drafts: - Handover Key Management and Re-authentication Problem Statement [draft-ietf-hokey-reauth-ps-10] (15 pages) - Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK) [draft-ietf-hokey-emsk-hierarchy-08] (20 pages) - EAP Extensions for EAP Re-authentication Protocol (ERP) [draft-ietf-hokey-erx-15] (43 pages) - Distribution of EAP based keys for handover and re-authentication [draft-ietf-hokey-key-mgm-10] (13 pages) - Extensible Authentication Protocol (EAP) Early Authentication Problem Statement [draft-ietf-hokey-preauth-ps-09] (21 pages) Requests for Comments: RFC5169: Handover Key Management and Re-authentication Problem Statement (15 pages) RFC5295: Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK) (21 pages) RFC5296: EAP Extensions for EAP Re-authentication Protocol (ERP) (43 pages) Hypertext Transfer Protocol Bis (httpbis) ----------------------------------------- Charter Last Modified: 2008-08-21 Current Status: Active Chair: Mark Nottingham Applications Area Directors: Lisa Dusseault Alexey Melnikov Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion: ietf-http-wg@w3.org To Subscribe: http://lists.w3.org/Archives/Public/ietf-http-wg/ Archive: Description of Working Group: HTTP is one of the most successful and widely-used protocols on the Internet today. However, its specification has several editorial issues. Additionally, after years of implementation and extension, several ambiguities have become evident, impairing interoperability and the ability to easily implement and use HTTP. The working group will refine RFC2616 to: * Incorporate errata and updates (e.g., references, IANA registries, ABNF) * Fix editorial problems which have led to misunderstandings of the specification * Clarify conformance requirements * Remove known ambiguities where they affect interoperability * Clarify existing methods of extensibility * Remove or deprecate those features that are not widely implemented and also unduly affect interoperability * Where necessary, add implementation advice * Document the security properties of HTTP and its associated echanisms (e.g., Basic and Digest authentication, cookies, TLS) for common applications In doing so, it should consider: * Implementer experience * Demonstrated use of HTTP * Impact on existing implementations and deployments The Working Group must not introduce a new version of HTTP and should not add new functionality to HTTP. The WG is not tasked with producing new methods, headers, or extension mechanisms, but may introduce new protocol elements if necessary as part of revising existing functionality which has proven to be problematic The Working Group's specification deliverables are: * A document that is suitable to supersede RFC 2616 * A document cataloguing the security properties of HTTP Goals and Milestones: Done - First HTTP Revision Internet Draft Feb 2008 - First HTTP Security Properties Internet Draft Jun 2008 - Request Last Call for HTTP Revision Jul 2008 - Request Last Call for HTTP Security Properties Oct 2008 - Submit HTTP Revision to IESG for consideration as a Draft Standard Oct 2008 - Submit HTTP Security Properties to IESG for consideration as Informational Internet-Drafts: - HTTP/1.1, part 1: URIs, Connections, and Message Parsing [draft-ietf-httpbis-p1-messaging-08] (86 pages) - HTTP/1.1, part 2: Message Semantics [draft-ietf-httpbis-p2-semantics-08] (58 pages) - HTTP/1.1, part 3: Message Payload and Content Negotiation [draft-ietf-httpbis-p3-payload-08] (47 pages) - HTTP/1.1, part 4: Conditional Requests [draft-ietf-httpbis-p4-conditional-08] (26 pages) - HTTP/1.1, part 5: Range Requests and Partial Responses [draft-ietf-httpbis-p5-range-08] (26 pages) - HTTP/1.1, part 6: Caching [draft-ietf-httpbis-p6-cache-08] (40 pages) - HTTP/1.1, part 7: Authentication [draft-ietf-httpbis-p7-auth-08] (16 pages) - Security Requirements for HTTP [draft-ietf-httpbis-security-properties-04] (11 pages) - Initial Hypertext Transfer Protocol (HTTP) Method Registrations [draft-ietf-httpbis-method-registrations-02] (5 pages) No Requests for Comments Internationalized Domain Names in Applications, Revised (idnabis) ----------------------------------------------------------------- Charter Last Modified: 2009-09-01 Current Status: Active Chair: Vinton Cerf Applications Area Directors: Lisa Dusseault Alexey Melnikov Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion: idna-update@alvestrand.no To Subscribe: http://www.alvestrand.no/mailman/listinfo/idna-update Archive: http://www.alvestrand.no/pipermail/idna-update/ Description of Working Group: The original Internationalized Domain Name (IDN) WG specified rules for the use of characters other than Latin A(a)-Z(z), digits 0-9 and the hyphen (-) in domain names in RFC3490, RFC3491 and RFC3492 in 2002 (published in 2003 and often referenced collectively as "IDNA2003"). These documents depend on RFC 3454 and were tied to Unicode version 3.2. An update to the current version (5.x) is required to accommodate additional scripts. In addition, experience has shown that significant improvements could be made in the protocol as presently specified. This WG is chartered to decouple IDNA from specific versions of Unicode using algorithms that define validity based on Unicode properties. It is recognized that some explicit exceptions may be necessary in any case, but attempts will be made to minimize these exceptions. Additional goals: - Separate requirements for valid IDNs at registration time (insertion of names into DNS zone files), vs. at resolution time (looking up those names) - Review, and if necessary revise, the algorithms and rules for handling right to left character sequences in an IDN context to allow labels based on additional scripts and languages and to make presentation as predictable as reasonably possible. - Permit use of some scripts that were inadvertently excluded by the original protocols. - Ensure practical stability of validity algorithms for IDNs. The constraints of the original IDN WG still apply to IDNABIS, namely to avoid disturbing the current use and operation of the domain name system, and for the DNS to continue to allow any system to resolve any domain name in a consistent way. The client-based approach of the original IDN work will be maintained -- substantially new protocols or mechanisms are not in scope. In particular, IDNs continue to use the "xn--" prefix and the same ASCII-compatible encoding, and the bidirectional algorithm follows the same basic design. The specifications are initially organized as four documents: overview and rationale, protocol, table algorithm, and improvements to the bidirectional algorithm. These documents are to be used as the basis for the discussion of the general direction of the work. This working group will be providing extended public review of the output of a design team that has been working on improvement of the IDNA specifications. This review-based approach is being used in part because of the way the work was undertaken by the team; in particular, the design team has been working with IETF visibility and has solicited and received significant amounts of technical review already from IETF participants and from others including experts in the Unicode specifications and the use of scripts in languages. If the public review provided by this Working Group confirms the basic method outlined in the input documents, it is expected that the working group will be able to respond with any needed changes and close in a short period of time. If technical issues arise that indicate a fundamentally different approach must be taken from the one outlined above, it is anticipated that this working group would close, and a new one with an appropriate charter would be considered. This work is intended to specify an improved means to produce and use stable and unambiguous IDN identifiers. There are a variety of generally unsolvable problems, notably the problem of characters that are confusingly similar in appearance (often known as the "phishing" problem) that are not specifically part of the scope of the WG although some of the preliminary results of the design team suggest that the improvements contemplated in the specifications might mitigate some of the ways in which the current IDNA specifications can be abused for phishing purposes. While it is referenced from the original IDNA2003 package, the original Stringprep specification, RFC 3454, is not formally part of the IDNA package and will not be altered by this work. The work will update or obsolete RFC 3490. It is not expected to continue to use Nameprep (RFC 3491). Nameprep is used by other specifications; determining how (or whether) to update those specifications and, consequently, the long-term status of Nameprep, are not part of this effort. The method for ASCII-compatible ("ACE") encoding of IDNs, "Punycode" (RFC 3492) will not be revised by this WG. Subject to the more general constraints described above, the WG is permitted to consider changes that are not strictly backwards- compatible. For any such change that is recommended, it is expected to document the reasons for the change, the characters affected, and possible transition strategies. The assumptions outlined above are considered critical to the WG constituted by this charter. The WG will stop work and recommend that a new charter be generated if it concludes that any of the following are necessary to meet its goals: (i) A change to the "punycode" algorithm or to the ACE approach to encoding names in the DNS. (ii) A change to the ACE prefix from "xn--" (iii) A change to the basic approach taken in the design team documents (Namely: independence from Unicode version and reduction of dependency on character mapping ) Goals and Milestones: Apr 2008 - WG formation May 2008 - Decision on form and structure of the WG document set Sep 2008 - WG Last Call on WG document set Nov 2008 - IETF Last Call on WG document set Internet-Drafts: - The Unicode code points and IDNA [draft-ietf-idnabis-tables-07] (64 pages) - Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale [draft-ietf-idnabis-rationale-14] (49 pages) - Internationalized Domain Names in Applications (IDNA): Protocol [draft-ietf-idnabis-protocol-17] (24 pages) - Right-to-left scripts for IDNA [draft-ietf-idnabis-bidi-06] (20 pages) - Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework [draft-ietf-idnabis-defs-12] (26 pages) - Mapping Characters in IDNA [draft-ietf-idnabis-mappings-05] (5 pages) No Requests for Comments Inter-Domain Routing (idr) -------------------------- Charter Last Modified: 2009-06-01 Current Status: Active Chairs: Susan Hares John Scudder Routing Area Directors: Ross Callon Adrian Farrel Routing Area Advisor: Ross Callon Tech Advisors: Randall Atkinson Sharon Chisholm Mailing Lists: General Discussion: idr@ietf.org To Subscribe: idr-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/idr/index.html Description of Working Group: The Inter-Domain Routing Working Group is chartered to standardize and promote the Border Gateway Protocol Version 4 (BGP-4) [RFC 1771] capable of supporting policy based routing for TCP/IP internets. The objective is to promote the use of BGP-4 to support IP version 4 and IP version 6. The working group will continue to work on improving the scalability of BGP. The current tasks of the WG are limited to: - Revise and clarify the base BGP4 document (RFC 1771). Note that RFC 1771 no longer documents existing practice and one goal of the update is document existing practice. Determine whether the document can be advanced as full Standard or needs to recycle at Proposed or Draft Standard. - Submit updated base BGP4 MIB to accompany the revised base BGP4 document. Once these tasks are finished (means WG consensus, WG Last Call, AD Review, IETF Last Call, and IESG approval for publication), work will progress on the following: - Review and Evaluate Existing RFCs on AS Confederations and Route Reflection. If changes are needed, create and advance revisions. - Review and evaluate Multiprotocol BGP (RFC 2858) for advancement as Draft Standard. - Progress BGP Extended Communities along standards track. - Extend BGP to support a 4-byte AS number, develop plan for transitioning to usage of 4-byte AS numbers. Advance support for a 4-byte AS numbers along standards track. - Produce BGP MIB v2 that includes support for AS Confederations, Route Reflection, Communities, Multi-Protocol BGP, BGP Extended Communities, support for 4-byte AS numbers. - Progress along the IETF standards track 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. Currently defined in draft-ietf-idr-route-filter-03.txt. - Progress along standards track an Outbound Router Filter (ORF) type for BGP, that can be used to perform aspath based route filtering. The ORF-type will support aspath based route filtering as well as regular expression based matching for address groups. Currently defined in draft-ietf-idr-aspath-orf-00.txt. - Progress a BGP Graceful Restart mechanism along standards track. - Progress Subcodes for BGP Cease Notification Message along standards track. - Progress AS-wide Unique BGP Identifier for BGP-4 along standards track. - Progress Dynamic Capability for BGP-4 along standards track. - Progress Flow Specification rules along standards track. Tasks for this working group are limited to those listed above; new items to be added to the charter must be approved by the IESG. Goals and Milestones: Done - Submit to BGP Capability Advertisement to the IESG Done - Submit BGP Security Vulnerabilities Analysis to IESG as an Informational Done - Submit BGP4 MIB to IESG as a Proposed Standard Done - Submit BGP4 document to IESG as a Draft Standard Done - Submit BGP Graceful Restart to IESG as a Proposed Standard Done - Submit Extended Communities draft to IESG as a Proposed Standard Done - Submit revised text on Multi-Protocol BGP (rfc2858bis) to IESG as a Draft Standard Done - Submit Subcodes for BGP Cease Notification Message to IESG as a Proposed Standard Done - Submit 4-byte AS ID to IESG as a Proposed Standard Done - Submit Outbound Route Filter, Prefix and ASpath ORF draft to IESG as a Proposed Standard Mar 2008 - Submit AS-wide Unique BGP Identifier for BGP-4 to IESG as a Proposed Standard Mar 2008 - Prefix and ASpath ORF draft to IESG as a Proposed Standard Mar 2008 - Prefix and ASpath ORF draft to IESG as a Proposed Standard Mar 2008 - Submit Dynamic Capability for BGP-4 to IESG as a Proposed Standard Internet-Drafts: - Application of the Border Gateway Protocol in the Internet [draft-ietf-iwg-bgpapplication-01] (13 pages) - A Border Gateway Protocol (BGP) [draft-ietf-iwg-bgp-01] (0 pages) - Definitions of Managed Objects for the Border Gateway Protocol (Version 3) [draft-ietf-iwg-bgp-mib-03] (13 pages) - A Border Gateway Protocol 3 (BGP-3) [draft-ietf-bgp-bgp3-01] (35 pages) - Border Gateway Protocol NEXT-HOP-SNPA Attribute [draft-ietf-bgp-nexthop-01] (3 pages) - Experience with the BGP Protocol [draft-ietf-bgp-experience-01] (9 pages) - BGP Protocol Analysis [draft-ietf-bgp-analysis-01] (0 pages) - Default Route Advertisement In The Border Gateway Protocol [draft-ietf-bgp-defaultroute-02] (2 pages) - IP Multicast Communications Using BGP [draft-ietf-bgp-multicast-02] (10 pages) - Application of the Border Gateway Protocol in the Internet [draft-ietf-bgp-usage-02] (7 pages) - BGP OSPF Interaction [draft-ietf-bgp-ospfinteract-07] (15 pages) - A Border Gateway Protocol 4 (BGP-4) [draft-ietf-bgp-bgp4-10] (58 pages) - Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4) [draft-ietf-bgp-mibv4-06] (21 pages) - BGP4/IDRP for IP---OSPF Interaction [draft-ietf-idr-bgp4ospf-interact-08] (19 pages) - Application of the Border Gateway Protocol in the Internet [draft-ietf-bgp-application-04] (19 pages) - IDRP for SIP [draft-ietf-ipidrp-sip-01] (9 pages) - Application of the Border Gateway Protocol and IDRP for IP in the Internet [draft-ietf-bgp-idrp-usage-00] (21 pages) - BGP-4 protocol document roadmap and implementation experience [draft-ietf-bgp-bgp4-implement-02] (5 pages) - Guidelines for creation, selection, and registration of an Autonomous System (AS) [draft-ietf-idr-autosys-guide-04] (12 pages) - IDRP for IP v4 and v6 [draft-ietf-idr-idrp-v4v6-02] (20 pages) - Experience with the BGP-4 protocol [draft-ietf-idr-bgp4-experience-01] (9 pages) - BGP-4 Protocol Analysis [draft-ietf-idr-bgp4-analysis-01] (10 pages) - A Border Gateway Protocol 4 (BGP-4) [draft-ietf-idr-bgp4-27] (100 pages) - Extensions for Selective Updates in Inter Domain Routing [draft-ietf-idr-rifs-00] (9 pages) - A BGP/IDRP Route Server alternative to a full mesh routing [draft-haskin-bgp-idrp-mesh-routing-01] (17 pages) - BGP AS Path Metrics [draft-ietf-idr-bgp-metrics-00] (8 pages) - BGP communities attribute [draft-ietf-idr-communities-01] (5 pages) - Destination Preference Attribute for BGP [draft-ietf-idr-bgp-dpa-05] (4 pages) - Current Practice of Implementing Symmetric Routing and Load Sharing in the Multi-Provider Internet [draft-ietf-idr-symm-multi-prov-02] (13 pages) - Application of the BGP Destination Preference Attribute in Implementing Symmetric Routing [draft-ietf-idr-dpa-application-02] (8 pages) - Operational Experience with the BGP-4 protocol [draft-ietf-idr-bgp4-op-experience-02] (9 pages) - BGP-4 Requirement Satisfaction Report [draft-ietf-idr-bgp4-stdreport1-02] (3 pages) - Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4) [draft-ietf-idr-bgp4-mib-16] (37 pages) - An Application of the BGP Community Attribute in Multi-home Routing [draft-ietf-idr-community-usage-01] (10 pages) - BGP Route Reflection An alternative to full mesh IBGP [draft-ietf-idr-route-reflect-03] (8 pages) - An Application of the BGP Community Attribute in Multi-home Routing [draft-ietf-idr-community-00] (10 pages) - Configuring IDRP Confederations [draft-ietf-idr-rdc-config-01] (5 pages) - Autonomous System Confederations for BGP [draft-ietf-idr-bgp-confed-01] (7 pages) - Inter-Domain Routing Protocol, Version 2 [draft-ietf-idr-idrp2-00] (110 pages) - A Framework for Inter-Domain Route Aggregation [draft-ietf-idr-aggregation-framework-05] (12 pages) - Using a Dedicated AS for Sites Homed to a Single Provider [draft-ietf-idr-as-dedicated-01] (6 pages) - Route Aggregation Tutorial [draft-ietf-idr-aggregation-tutorial-01] (8 pages) - Multiprotocol Extensions for BGP-4 [draft-ietf-idr-bgp4-multiprotocol-02] (9 pages) - Capabilities Advertisement with BGP-4 [draft-ietf-idr-bgp4-cap-neg-06] (5 pages) - BGP Route Flap Damping [draft-ietf-idr-route-damp-04] (36 pages) - Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing [draft-ietf-idr-bgp4-ipv6-02] (5 pages) - Protection of BGP Sessions via the TCP MD5 Signature Option [draft-ietf-idr-bgp-tcp-md5-01] (5 pages) - Protection of BGP Sessions via the TCP MD5 Signature Option [draft-ietf-idr-bgp-tcp-md5bad-01] (5 pages) - Multiprotocol Extensions for BGP-4 [draft-ietf-idr-bgp4-multiprotocol-v2-05] (11 pages) - BGP Route Reflection An alternative to full mesh IBGP [draft-ietf-idr-route-reflect-v2-04] (10 pages) - BGP Support for Four-octet AS Number Space [draft-ietf-idr-as4bytes-14] (10 pages) - Route Refresh Capability for BGP-4 [draft-ietf-idr-bgp-route-refresh-02] (4 pages) - Outbound Route Filtering Capability for BGP-4 [draft-ietf-idr-route-filter-18] (12 pages) - Autonomous System Confederations for BGP [draft-ietf-idr-bgp-confed-rfc1965bis-02] (10 pages) - Graceful Restart Mechanism for BGP [draft-ietf-idr-restart-14] (11 pages) - BGP Persistent Route Oscillation Condition [draft-ietf-idr-route-oscillation-01] (20 pages) - BGP Extended Communities Attribute [draft-ietf-idr-bgp-ext-communities-10] (12 pages) - Aspath Based Outbound Route Filter for BGP-4 [draft-ietf-idr-aspath-orf-09] (4 pages) - Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4), Second Version [draft-ietf-idr-bgp4-mibv2-10] (45 pages) - Dynamic Capability for BGP-4 [draft-ietf-idr-dynamic-cap-09] (8 pages) - Subcodes for BGP Cease Notification Message [draft-ietf-idr-cease-subcode-08] (6 pages) - Protection of BGP Sessions via the TCP MD5 Signature Option [draft-ietf-idr-rfc2385bis-01] (6 pages) - Multiprotocol Extensions for BGP-4 [draft-ietf-idr-rfc2858bis-11] (0 pages) - Capabilities Advertisement with BGP-4 [draft-ietf-idr-rfc2842bis-02] (5 pages) - AS-wide Unique BGP Identifier for BGP-4 [draft-ietf-idr-bgp-identifier-10] (5 pages) - Security Requirements for Keys used with the TCP MD5 Signature Option [draft-ietf-idr-md5-keys-00] (7 pages) - Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE) [draft-ooms-v6ops-bgp-tunnel-08] (14 pages) - BGP Graceful Restart - Implementation Survey [draft-ietf-idr-bgp-gr-survey-01] (10 pages) - BGP-4 Protocol Analysis [draft-ietf-idr-bgp-analysis-08] (20 pages) - The AS_HOPCOUNT Path Attribute [draft-ietf-idr-as-hopcount-00] (16 pages) - Issues in Revising BGP-4 [draft-ietf-idr-bgp-issues-01] (180 pages) - BGP Security Vulnerabilities Analysis [draft-ietf-idr-bgp-vuln-02] (24 pages) - Experience with the BGP-4 Protocol [draft-ietf-idr-bgp4-experience-protocol-06] (23 pages) - Autonomous System Confederations for BGP [draft-ietf-idr-rfc3065bis-07] (17 pages) - BGP-4 MIB Implementation Survey [draft-ietf-idr-bgp-mibagent-survey-03] (37 pages) - BGP 4 Implementation Report [draft-ietf-idr-bgp-implementation-03] (86 pages) - BGP Route Reflection - An Alternative to Full Mesh IBGP [draft-ietf-idr-rfc2796bis-03] (12 pages) - Multisession BGP [draft-ietf-idr-bgp-multisession-04] (16 pages) - Avoid BGP Best Path Transitions from One External to Another [draft-ietf-idr-avoid-transition-06] (7 pages) - Reclassification of RFC 1863 to Historic [draft-ietf-idr-rfc1863-historic-01] (4 pages) - Address-Prefix-Based Outbound Route Filter for BGP-4 [draft-ietf-idr-bgp-prefix-orf-06] (6 pages) - The AS_PATHLIMIT Path Attribute [draft-ietf-idr-as-pathlimit-03] (16 pages) - Advertising an IPv4 NLRI with an IPv6 Next Hop [draft-ietf-idr-v4nlri-v6nh-01] (10 pages) - Dissemination of flow specification rules [draft-ietf-idr-flow-spec-10] (24 pages) - BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute [draft-ietf-idr-encaps-safi-00] (13 pages) - The Accumulated IGP Metric Attribute for BGP [draft-ietf-idr-aigp-01] (13 pages) - Capabilities Advertisement with BGP-4 [draft-ietf-idr-rfc3392bis-06] (7 pages) - Textual Representation of AS Numbers [draft-ietf-idr-as-representation-02] (4 pages) - AS Number Reservation for Documentation Use [draft-ietf-idr-as-documentation-reservation-01] (5 pages) - Revisions to the BGP 'Minimum Route Advertisement Interval' [draft-ietf-idr-mrai-dep-01] (4 pages) - Advertisement of Multiple Paths in BGP [draft-ietf-idr-add-paths-02] (8 pages) - Generic Subtype for BGP Four-octet AS specific extended community [draft-ietf-idr-as4octet-extcomm-generic-subtype-01] (6 pages) - Definitions of Textual Conventions for the Management of the Fourth Version of Border Gateway Protocol (BGP-4) [draft-ietf-idr-bgp4-mibv2-tc-mib-01] (6 pages) - BGP Support for Four-octet AS Number Space [draft-ietf-idr-rfc4893bis-01] (11 pages) - Error Handling for Optional Transitive BGP Attributes [draft-ietf-idr-optional-transitive-01] (8 pages) - BGP Link Bandwidth Extended Community [draft-ietf-idr-link-bandwidth-01] (5 pages) - Advertisement of the best external route in BGP [draft-ietf-idr-best-external-00] (11 pages) - BGP Bestpath Selection Criteria [draft-ietf-idr-bgp-bestpath-selection-criteria-01] (9 pages) - BGP Advisory Message [draft-ietf-idr-advisory-00] (7 pages) Requests for Comments: RFC1930: Guidelines for creation, selection, and registration of an Autonomous System (AS) (10 pages) RFC1267: A Border Gateway Protocol 3 (BGP-3) (35 pages) * Obsoletes RFC1105 * Obsoletes RFC1163 RFC1268: Application of the Border Gateway Protocol in the Internet (13 pages) * Obsoletes RFC1164 * OBSOLETED BY RFC1655 RFC1771: A Border Gateway Protocol 4 (BGP-4) (57 pages) * Obsoletes RFC1654 * OBSOLETED BY RFC4271 RFC1863: A BGP/IDRP Route Server alternative to a full mesh routing (16 pages) * OBSOLETED BY RFC4223 RFC1965: Autonomous System Confederations for BGP (7 pages) * OBSOLETED BY RFC3065 RFC1966: BGP Route Reflection An alternative to full mesh IBGP (7 pages) * Updated by RFC2796 * OBSOLETED BY RFC4456 RFC1105: Border Gateway Protocol BGP (17 pages) * OBSOLETED BY RFC1267 * OBSOLETED BY RFC1163 RFC1656: BGP-4 Protocol Document Roadmap and Implementation Experience (4 pages) * OBSOLETED BY RFC1773 RFC1266: Experience with the BGP Protocol (9 pages) RFC1265: BGP Protocol Analysis (8 pages) RFC1998: An Application of the BGP Community Attribute in Multi-home Routing (9 pages) RFC1773: Experience with the BGP-4 protocol (9 pages) * Obsoletes RFC1656 RFC1774: BGP-4 Protocol Analysis (10 pages) RFC1745: BGP4/IDRP for IP---OSPF Interaction (19 pages) RFC1997: BGP Communities Attribute (5 pages) RFC1364: BGP OSPF Interaction (14 pages) * OBSOLETED BY RFC1403 RFC1403: BGP OSPF Interaction (17 pages) * Obsoletes RFC1364 RFC1397: Default Route Advertisement In BGP2 And BGP3 Versions Of The Border Gateway Protocol (2 pages) RFC1164: Application of the Border Gateway Protocol in the Internet (23 pages) * OBSOLETED BY RFC1268 RFC1163: A Border Gateway Protocol (BGP) (29 pages) * Obsoletes RFC1105 * OBSOLETED BY RFC1267 RFC1269: Definitions of Managed Objects for the Border Gateway Protocol (Version 3) (13 pages) * OBSOLETED BY RFC4273 RFC1657: Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2 (21 pages) * OBSOLETED BY RFC4273 RFC1654: A Border Gateway Protocol 4 (BGP-4) (56 pages) * OBSOLETED BY RFC1771 RFC1655: Application of the Border Gateway Protocol in the Internet (19 pages) * Obsoletes RFC1268 * OBSOLETED BY RFC1772 RFC2270: Using a Dedicated AS for Sites Homed to a Single Provider (6 pages) RFC2283: Multiprotocol Extensions for BGP-4 (9 pages) * OBSOLETED BY RFC2858 RFC2385: Protection of BGP Sessions via the TCP MD5 Signature Option (6 pages) RFC2439: BGP Route Flap Damping (37 pages) RFC2519: A Framework for Inter-Domain Route Aggregation (13 pages) RFC2545: Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing (5 pages) RFC2796: BGP Route Reflection An alternative to full mesh IBGP (11 pages) * Updates RFC1966 * OBSOLETED BY RFC4456 RFC2842: Capabilities Advertisement with BGP-4 (5 pages) * OBSOLETED BY RFC3392 RFC2858: Multiprotocol Extensions for BGP-4 (11 pages) * Obsoletes RFC2283 * OBSOLETED BY RFC4760 RFC2918: Route Refresh Capability for BGP-4 (4 pages) RFC3065: Autonomous System Confederations for BGP (11 pages) * Obsoletes RFC1965 * OBSOLETED BY RFC5065 RFC3345: Border Gateway Protocol (BGP) Persistent Route Oscillation Condition (19 pages) RFC3392: Capabilities Advertisement with BGP-4 (6 pages) * Obsoletes RFC2842 * OBSOLETED BY RFC5492 RFC3562: Security Requirements for Keys used with the TCP MD5 Signature Option (7 pages) RFC4223: Reclassification of RFC 1863 to Historic (4 pages) * Obsoletes RFC1863 RFC4272: BGP Security Vulnerabilities Analysis (24 pages) RFC4273: Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4) (37 pages) * Obsoletes RFC1269 * Obsoletes RFC1657 RFC4274: BGP-4 Protocol Analysis (20 pages) RFC4275: BGP-4 MIB Implementation Survey (37 pages) RFC4276: BGP 4 Implementation Report (86 pages) RFC4277: Experience with the BGP-4 Protocol (23 pages) RFC4271: A Border Gateway Protocol 4 (BGP-4) (100 pages) * Obsoletes RFC1771 RFC4360: BGP Extended Communities Attribute (12 pages) RFC4456: BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) (12 pages) * Obsoletes RFC2796 * Obsoletes RFC1966 RFC4486: Subcodes for BGP Cease Notification Message (6 pages) RFC4760: Multiprotocol Extensions for BGP-4 (0 pages) * Obsoletes RFC2858 RFC4724: Graceful Restart Mechanism for BGP (11 pages) RFC4798: Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE) (14 pages) RFC4893: BGP Support for Four-octet AS Number Space (10 pages) RFC5065: Autonomous System Confederations for BGP (17 pages) * Obsoletes RFC3065 RFC5004: Avoid BGP Best Path Transitions from One External to Another (7 pages) RFC5291: Outbound Route Filtering Capability for BGP-4 (12 pages) RFC5292: Address-Prefix-Based Outbound Route Filter for BGP-4 (6 pages) RFC5396: Textual Representation of Autonomous System (AS) Numbers (3 pages) RFC5398: Autonomous System (AS) Number Reservation for Documentation Use (4 pages) RFC5492: Capabilities Advertisement with BGP-4 (7 pages) * Obsoletes RFC3392 RFC5575: Dissemination of Flow Specification Rules (22 pages) IP over DVB (ipdvb) ------------------- Charter Last Modified: 2009-05-26 Current Status: Active Chair: Gorry Fairhurst Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Secretary: Martin Stiemerling Mailing Lists: General Discussion: ipdvb@erg.abdn.ac.uk To Subscribe: majordomo@erg.abdn.ac.uk Archive: http://www.erg.abdn.ac.uk/ipdvb/archive/ Description of Working Group: The WG will develop new protocols and architectures to enable better deployment of IP over MPEG-2 transport and provide easier interworking with IP networks. Specific properties of this subnetwork technology include link-layer support for unicast and multicast, large numbers of down-stream receivers, and efficiency of transmission. These properties resemble those in some other wireless networks. The specific focus of the group is on the use of MPEG-2 transport (examples include the Digital Video Broadcast (DVB) standards: DVB-RCS; DVB-S and DVB-T and related ATSC Specifications) in next generation networks and is not concerned with the development, replacement, or retention of existing protocols on the existing generation of networks. The WG will endeavour to reuse existing open standard technologies, giving guidance on usage in IP networks, whenever they are able to fulfill requirements. For instance, we acknowledge the existing Multiprotocol Encapsulation (MPE) [ATSC A/90;ETSI EN 301192] and that this will continue to be deployed in the future to develop new markets. Any alternative encapsulation would need to co-exist with MPE. Appropriate standards will be defined to support transmission of IPv4 and IPv6 datagrams between IP networks connected using MPEG-2 transport subnetworks. This includes options for encapsulation, dynamic unicast address resolution for IPv4/IPv6, and the mechanisms needed to map routed IP multicast traffic to the MPEG-2 transport subnetwork. The standards will be appropriate to both MPE and any alternative encapsulation method developed. The developed protocols may also be applicable to other multicast enabled subnetwork technologies supporting large numbers of directly connected systems. The current list of work items is: Specify the requirements and architecture for supporting IPv4/IPv6 via MPEG-2 transmission networks. Such requirements should consider the range of platforms currently (or anticipated to be) in use. This draft will be an Informational RFC. Define a standards-track RFC defining an efficient encapsulation method. The design will consider the need for MAC addresses, the potential need for synchronisation between streams, support for a wide range of IPv4/IPv6 and multicast traffic. Provide an Informational RFC describing a framework for unicast and multicast address resolution over MPEG-2 transmission networks. The document will describe options for the address resolution process, relating these to appropriate usage scenarios and suggesting appropriate protocol mechanisms for both the existing Multi-Protocol Encapsulation (MPE) and the efficient encapsulation (2). Consideration will be paid to existing standards, and the cases for IPv6 and IPv4 will be described. Define standards-track RFC(s) to specify procedures for dynamic address resolution for IPv4/IPv6. This will describe the protocol and syntax of the information exchanged to bind unicast and multicast flows to the MPEG-2 TS Logical Channels. This will include specific optimisations appropriate for networks reaching large numbers of down-stream systems. Goals and Milestones: Done - Draft of a WG Architecture ID describing usage of MPEG-2 transport for IP transmission. Done - Draft of a WG ID on the new Encapsulation. Done - Submit Architecture to IESG Done - Draft of a WG ID on the AR Framework, specifying mechanisms to perform address resolution. Done - Submit Encapsulation to IESG Done - Draft of a WG ID defining Security Requirements for the ULE protocol Done - Submit AR Framework to IESG Apr 2006 - Draft of a WG ID defining an IP Address Resolution (AR) protocol Jan 2007 - Submit AR Protocol to IESG Done - Submit Extension Header Formats to IESG for publication as PS Done - Submit ULE Security Requirements to IESG Dec 2007 - Progress the Encapsulation RFC along the IETF standards track Internet-Drafts: - Unidirectional Lightweight Encapsulation (ULE) for transmission of IP datagrams over an MPEG-2 Transport Stream [draft-ietf-ipdvb-ule-07] (49 pages) - A Framework for transmission of IP datagrams over MPEG-2 Networks [draft-ietf-ipdvb-arch-05] (39 pages) - Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks [draft-ietf-ipdvb-ar-07] (0 pages) - Security requirements for the Unidirectional Lightweight Encapsulation (ULE) protocol [draft-ietf-ipdvb-sec-req-10] (30 pages) - Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE) [draft-ietf-ipdvb-ule-ext-08] (19 pages) Requests for Comments: RFC4259: A Framework for transmission of IP datagrams over MPEG-2 Networks (39 pages) RFC4326: Unidirectional Lightweight Encapsulation (ULE) for transmission of IP datagrams over an MPEG-2 Transport Stream (49 pages) RFC4947: Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks (0 pages) RFC5163: Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE) (19 pages) RFC5458: Security Requirements for the Unidirectional Lightweight Encapsulation (ULE) Protocol (26 pages) IP Flow Information Export (ipfix) ---------------------------------- Charter Last Modified: 2009-09-29 Current Status: Active Chairs: Nevil Brownlee Juergen Quittek Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion: ipfix@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/ipfix Archive: http://www.ietf.org/mail-archive/web/ipfix Description of Working Group: The IPFIX working group has specified the Information Model (to describe IP flows) and the IPFIX protocol (to transfer IP flow data from IPFIX exporters to collectors). Several implementers have already built applications using the IPFIX protocol. As a result of a series of IPFIX interoperability testing events the WG has produced guidelines for IPFIX implementation and testing as well as recommendations for handling special cases such as bidirectional flow reporting and reducing redundancy in flow records. Practical experiences with IPFIX implementations exposed new requirements for the IPFIX protocol that so far have not been addressed by the WG. The major current goal of the WG is developing solutions that meet the new requirements without modifying the core IPFIX protocol specifications. 1. The IPFIX WG has developed a MIB module for monitoring IPFIX implementations. Means for configuring these devices have not been standardized yet. The WG will develop an XML-based configuration data model that can be used for configuring IPFIX devices and for storing, modifying and managing IPFIX configurations parameter sets. This work will be performed in close collaboration with the NETCONF WG. 2. First applications of IPFIX at large operator networks showed the need for mediation of flow information, for example, for aggregating huge amounts of flow data and for anomymization of flow information. The IPFIX WG will investigate this issue and produce a problem statement and a framework for IPFIX flow mediation. 3. The PSAMP WG has developed a protocol for reporting observed packets. The PSAMP protocol is an extension of the IPFIX protocol. The IPFIX WG will develop a MIB module for monitoring PSAMP implementations. The new MIB module will be an extension of the IPFIX MIB module. 4. Anonymization of flow information has been identified as a requirement for flow information export already in RFC 3917. However, technologies for flow anonymization are still a research issue and have so far not been considered to be mature enough for standardization. As one step in this direction, the IPFIX WG will develop guidelines for the implementation of anonymized data export and storage over IPFIX and define an information model for configuring and reporting anonymization applied at IPFIX devices. 5. The IPFIX and PSAMP WGs have defined standards for selecting observed IP packets and collecting information in flow records. In order to reduce the amount of data to be processed, packet selection methods have been defined. Another method for reducing flow data is flow selection. The IPFIX WG will define methods for flow selection and provide an information model for configuring and reporting flow selection applied at IPFIX devices. 6. Being designed for the export of flow records the IPFIX protocol provides very limited means for structuring information elements within IPFIX records. With the increasing number of IPFIX applications there is a need for exporting more complex information. The IPFIX WG will develop an extension of the IPFIX protocol that supports hierarchically structured data and lists (sequences) of Information Elements in data records. Goals and Milestones: Done - Submit Revised Internet-Draft on IP Flow Export Requirements Done - Submit Internet-Draft on IP Flow Export Architecture Done - Submit Internet-Draft on IP Flow Export Data Model Done - Submit Internet-Draft on IPFIX Protocol Evaluation Report Done - Submit Internet-Draft on IP Flow Export Applicability Statement Done - Select IPFIX protocol, revise Architecture and Data Model drafts Done - Submit IPFX-REQUIREMENTS to IESG for publication as Informational RFC Done - Submit IPFIX Protocol Evaluation Report to IESG for publication as Informational RFC Done - Submit IPFX-ARCHITECTURE to IESG for publication as Proposed Standard RFC Done - Submit IPFX-INFO_MODEL to IESG for publication as Informational RFC Done - Submit IPFX-APPLICABILITY to IESG for publication as Informational RFC Done - Submit IPFX-PROTOCOL to IESG for publication as Proposed Standard RFC Done - Publish Internet Draft on IPFIX Implementation Guidelines Done - Publish Internet Draft on IPFIX Testing Done - Publish Internet Draft on Reducing Redundancy in IPFIX data transfer Done - Publish Internet Draft on IPFIX MIB Done - Publish Internet Draft on Handling IPFIX Bidirectional Flows Done - Submit IPFIX Implementation Guidelines draft to IESG for publication as Informational RFC Done - Submit IPFIX Testing draft to IESG for publication as Informational RFC Done - Submit IPFIX Reducing Redundancy draft to IESG for publication as Informational RFC Done - Submit IPFIX Biflows draft to IESG for publication as Standards Track RFC Done - Publish Internet draft on IPFIX Type Information Export Done - Publish Internet draft on IPFIX Configuration Data Model Done - Publish Internet draft on IPFIX File Format Done - Publish Internet draft on Single SCTP Stream Reporting Done - Publish Internet draft on IPFIX Mediation Problem Statement Done - Submit File Format draft to IESG for publication as Standards track RFC Done - Submit IPFIX MIB draft to IESG for publication as Standards track RFC Done - Submit Type Export draft to IESG for publication as Standards track RFC Done - Submit Single SCTP Stream draft to IESG for publication as Informational RFC Oct 2009 - Submit Mediation Problem Statement I-D to IESG for publication as Informational RFC Done - Submit initial draft on anonymization support Done - Submit initial draft on flow selection Done - Submit initial draft on structuring information elements Jan 2010 - Submit final version of PSAMP MIB module Jan 2010 - Submit Configuration Data Model draft to IESG for publication as Standards track RFC Jan 2010 - Submit Mediation Framework I-D to IESG for publication as Informational RFC Done - Submit anonymization support I-D to IESG for publication as Experimental RFC Done - Submit flow selection I-D to IESG for publication as Standards Track RFC Done - Submit structuring information elements I-D to IESG for publication as Standards Track RFC Internet-Drafts: - Requirements for IP Flow Information Export [draft-ietf-ipfix-reqs-17] (32 pages) - Architecture for IP Flow Information Export [draft-ietf-ipfix-architecture-13] (32 pages) - IPFIX Data Model Data Model for IP Flow Information Export [draft-ietf-ipfix-data-00] (25 pages) - Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX) [draft-leinen-ipfix-eval-contrib-04] (28 pages) - Information Model for IP Flow Information Export [draft-ietf-ipfix-info-16] (170 pages) - Architecture Model for IP Flow Information Export [draft-ietf-ipfix-arch-02] (28 pages) - Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information [draft-ietf-ipfix-protocol-27] (65 pages) - IPFIX Applicability [draft-ietf-ipfix-as-13] (32 pages) - IPFIX Implementation Guidelines [draft-ietf-ipfix-implementation-guidelines-09] (36 pages) - Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports [draft-ietf-ipfix-reducing-redundancy-05] (32 pages) - Bidirectional Flow Export using IPFIX [draft-ietf-ipfix-biflow-06] (23 pages) - Guidelines for IP Flow Information eXport (IPFIX) Testing [draft-ietf-ipfix-testing-06] (38 pages) - Definitions of Managed Objects for IP Flow Information Export [draft-ietf-ipfix-mib-08] (67 pages) - Specification of the IPFIX File Format [draft-ietf-ipfix-file-06] (66 pages) - Exporting Type Information for IPFIX Information Elements [draft-ietf-ipfix-exporting-type-06] (20 pages) - IPFIX Mediation: Problem Statement [draft-ietf-ipfix-mediators-problem-statement-06] (31 pages) - IPFIX Mediation: Framework [draft-ietf-ipfix-mediators-framework-04] (33 pages) - IPFIX Export per SCTP Stream [draft-ietf-ipfix-export-per-sctp-stream-04] (22 pages) - Configuration Data Model for IPFIX and PSAMP [draft-ietf-ipfix-configuration-model-04] (94 pages) - IP Flow Anonymisation Support [draft-ietf-ipfix-anon-00] (31 pages) - Export of Structured Data in IPFIX [draft-ietf-ipfix-structured-data-00] (57 pages) - Flow Selection Techniques [draft-ietf-ipfix-flow-selection-tech-00] (25 pages) Requests for Comments: RFC3917: Requirements for IP Flow Information Export (32 pages) RFC3955: Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX) (28 pages) RFC5103: Bidirectional Flow Export using IP Flow Information Export (IPFIX) (23 pages) RFC5102: Information Model for IP Flow Information Export (170 pages) RFC5101: Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information (65 pages) RFC5153: IPFIX Implementation Guidelines (36 pages) RFC5470: Architecture for IP Flow Information Export (32 pages) RFC5471: Guidelines for IP Flow Information Export (IPFIX) Testing (32 pages) RFC5472: IP Flow Information Export (IPFIX) Applicability (31 pages) RFC5473: Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports (27 pages) RFC5610: Exporting Type Information for IPFIX Information Elements (20 pages) RFC5655: Specification of the IP Flow Information Export (IPFIX) File Format (66 pages) IP Performance Metrics (ippm) ----------------------------- Charter Last Modified: 2009-04-22 Current Status: Active Chairs: Henk Uijterwaal Matthew Zekauskas Transport Area Directors: Magnus Westerlund Lars Eggert Transport Area Advisor: Lars Eggert Mailing Lists: General Discussion: ippm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ippm Archive: http://www.ietf.org/mail-archive/web/ippm/current/maillist.html Description of Working Group: The IPPM WG has developed a set of standard metrics that can be applied to the quality, performance, and reliability of Internet data delivery services. These metrics are designed such that they can be performed by network operators, end users, or independent testing groups. It is important that the metrics not represent a value judgment (i.e. define "good" and "bad"), but rather provide unbiased quantitative measures of performance. Functions peripheral to Internet data delivery services, such as NOC/NIC services, are beyond the scope of this working group. The IPPM WG has produced documents that define specific metrics and procedures for accurately measuring and documenting these metrics. This is the current list of fundamental metrics and the existing set of derived metrics. - connectivity - one-way delay and loss - round-trip delay. - delay variation - loss patterns - packet reordering - bulk transport capacity - link bandwidth capacity - packet duplication The working group will advance these metrics along the standards track within the IETF. The WG will document the process of moving documents along the standards track, based on draft-bradner-metricstest. As this process is likely to be needed by other groups as well (in particular BMWG, PMOL), the group will collaborate with other groups in order to ensure that there is consensus amongst all groups expected to use the process. Additionally, the WG will produce Proposed Standard AS documents, comparable to applicability statements in RFC 2026, that will focus on procedures for measuring the individual metrics and how these metrics characterize features that are important to different service classes, such as bulk transport, periodic streams, packet bursts or multimedia streams. Each AS document will discuss the performance characteristics that are pertinent to a specified service class; clearly identify the set of metrics that aid in the description of those characteristics; specify the methodologies required to collect said metrics; and lastly, present the requirements for the common, unambiguous reporting of testing results. The AS documents can also discuss the use of the metrics to verify performance expectations, such as SLA's, report results to specific user groups or investigate network problems. The focus is, again, to define how this should be done, not to define a value judgment. The WG may define additional statistics for its metrics if needed. Specific topics of these AS documents must be approved by the Area Directors as charter additions. The WG will work on documents describing how to compose and decompose the results of its metrics over time or space. The WG has produced protocols to enable communication among test equipment that implements the one- and two-way metrics (OWAMP and TWAMP respectively). OWAMP and TWAMP will be advanced along the standards track. Further development of these protocols will also be done inside the WG. The metrics developed by the WG were developed inside an active measurement context, that is, the devices used to measure the metrics produce their own traffic. However, most metrics can be used inside a passive context as well. No work is planned is this area though, this may be changed with AD approval. The intent of the WG is to cooperate with other appropriate standards bodies and forums (such as ATIS IIF, ITU-T SG 12, 13 and 15, MEF) to promote consistent approaches and metrics. Within the IETF process, IPPM metrics definitions will be subject to as rigorous a scrutiny for usefulness, clarity, and accuracy as other protocol standards. The IPPM WG will interact with other areas of IETF activity whose scope intersect with the requirement of these specific metrics. The WG will, on request, provide input to other IETF WG on the use of these metrics. Goals and Milestones: Done - Submit drafts of standard metrics for connectivity and treno-bulk-throughput. Done - Submit a framework document describing terms and notions used in the IPPM effort, and the creation of metrics by the working group to IESG for publication as an Informational RFC. Done - Submit documents on delay and loss to IESG for publication as Informational RFCs. Done - Submit a document on connectivity to IESG for publication as an Informational RFC. Done - Submit a document on bulk-throughput to IESG for publication as an Informational RFC. Done - Submit draft on loss pattern sample metrics to the IESG for publication as an Informational RFC. Done - Submit draft on metrics for periodic streams to the IESG for publication as a Proposed Standard RFC. Done - Submit draft on IP delay variation to the IESG for publication as a Proposed Standard RFC. Done - First draft for AS on one-way delay and loss. Done - Submit draft on One-Way Active Measurement Protocol Requirements to the IESG for consideration as an Informational RFC. Done - Create initial draft on a MIB for reporting IPPM metrics. Done - Create initial draft on a packet reordering metric. Done - Create draft on a One-Way Active Measurement Protocol that satisfies the requirements document. Done - Submit draft on the One-Way Active Measurement Protocol to the IESG for consideration as a PS. Done - Submit draft on implementation reports for RFCs 2678-2681 to the IESG Done - Submit initial draft on framework for Composition and Aggregation Metrics Done - Submit draft on the One-Way Active Measurement Protocol to the IESG for consideration as a PS Done - Submit initial applicability statement for the IPPM and ITU Jitter Measurements to the WG Done - Submit draft on a packet reordering metric to the IESG for Proposed Standard Done - Submit link bandwidth capacity definitions draft to the IESG, for consideration as an Informational RFC Done - Submit draft on storing results of traceroute measurements to the IESG Done - Submit draft on Two-way active measurements protocol (TWAMP) to the IESG for consideration as proposed standard Done - Develop new charter text Done - Delay Variation Applicability Statement (Informational) to IESG Review Done - Assemble editorial team to work on the process draft (WG version of draft-bradner-metricstest) Mar 2009 - -00 version of SLA validation draft Apr 2009 - Submit draft on spatial composition of metrics to the IESG Apr 2009 - Submit draft on Temporal Aggregation of Metrics to the IESG Apr 2009 - Submit draft on spatial decomposition and multicast metrics to the IESG Apr 2009 - Submit Jun 2009 - Initial version of process draft Nov 2009 - Submit other TWAMP extensions draft to IESG. Dec 2009 - Final version of process draft Mar 2010 - Implementation report based on process draft Jun 2010 - Revise charter Internet-Drafts: - TReno Bulk Transfer Capacity [draft-ietf-ippm-treno-btc-03] (5 pages) - Framework for IP Performance Metrics [draft-ietf-ippm-framework-03] (38 pages) - A One-way Delay Metric for IPPM [draft-ietf-ippm-delay-08] (20 pages) - A One-way Packet Loss Metric for IPPM [draft-ietf-ippm-loss-08] (16 pages) - IPPM Metrics for Measuring Connectivity [draft-ietf-ippm-connectivity-05] (10 pages) - IP Packet Delay Variation Metric for IPPM [draft-ietf-ippm-ipdv-10] (21 pages) - A Framework for Defining Empirical Bulk Transfer Capacity Metrics [draft-ietf-ippm-btc-framework-06] (9 pages) - A Round-trip Delay Metric for IPPM [draft-ietf-ippm-rt-delay-02] (20 pages) - One-way Loss Pattern Sample Metrics [draft-ietf-ippm-loss-pattern-07] (14 pages) - Network performance measurement for periodic streams [draft-ietf-ippm-npmps-08] (20 pages) - A One-way Active Measurement Protocol (OWAMP) [draft-ietf-ippm-owdp-17] (56 pages) - A Bulk Transfer Capacity Methodology for Cooperating Hosts [draft-ietf-ippm-btc-cap-00] (5 pages) - A One-way Active Measurement Protocol Requirements [draft-ietf-ippm-owdp-reqs-07] (10 pages) - IP Performance Metrics (IPPM) metrics registry [draft-ietf-ippm-metrics-registry-09] (16 pages) - IP Performance Metrics (IPPM) reporting Information Base (MIB) [draft-ietf-ippm-reporting-mib-06] (80 pages) - Packet Reordering Metric for IPPM [draft-ietf-ippm-reordering-14] (42 pages) - One-Way Metric Applicability Statement [draft-ietf-ippm-owmetric-as-01] (8 pages) - Overview of Implementation reports relating to IETF work on IP Performance Measurements (IPPM, RFC 2678 - 2681) [draft-ietf-ippm-implement-02] (24 pages) - Defining Network Capacity [draft-ietf-ippm-bw-capacity-06] (20 pages) - A Two-Way Active Measurement Protocol (TWAMP) [draft-ietf-ippm-twamp-10] (26 pages) - IP Performance Metrics (IPPM) for spatial and multicast [draft-ietf-ippm-multimetrics-13] (52 pages) - Spatial Composition of Metrics [draft-ietf-ippm-spatial-composition-10] (27 pages) - Framework for Metric Composition [draft-ietf-ippm-framework-compagg-08] (17 pages) - Reporting IP Performance Metrics to Users [draft-ietf-ippm-reporting-04] (45 pages) - Information Model and XML Data Model for Traceroute Measurements [draft-ietf-ippm-storetraceroutes-13] (72 pages) - A One-Way Packet Duplication Metric [draft-ietf-ippm-duplicate-09] (14 pages) - Packet Delay Variation Applicability Statement [draft-ietf-ippm-delay-var-as-03] (39 pages) - More Features for the Two-Way Active Measurement Protocol - TWAMP [draft-ietf-ippm-more-twamp-03] (10 pages) - TWAMP Reflect Octets and Symmetrical Size Features [draft-ietf-ippm-twamp-reflect-octets-03] (19 pages) - Individual Session Control Feature for TWAMP [draft-ietf-ippm-twamp-session-cntrl-02] (18 pages) - Reporting Metrics: Different Points of View [draft-ietf-ippm-reporting-metrics-00] (17 pages) Requests for Comments: RFC2330: Framework for IP Performance Metrics (40 pages) RFC2678: IPPM Metrics for Measuring Connectivity (10 pages) RFC2679: A One-way Delay Metric for IPPM (20 pages) RFC2680: A One-way Packet Loss Metric for IPPM (15 pages) RFC2681: A Round-trip Delay Metric for IPPM (20 pages) RFC3148: A Framework for Defining Empirical Bulk Transfer Capacity Metrics (15 pages) RFC3357: One-way Loss Pattern Sample Metrics (15 pages) RFC3393: IP Packet Delay Variation Metric for IPPM (21 pages) RFC3432: Network performance measurement for periodic streams (23 pages) RFC3763: A One-way Active Measurement Protocol Requirements (10 pages) RFC4148: IP Performance Metrics (IPPM) metrics registry (16 pages) RFC4656: A One-way Active Measurement Protocol (OWAMP) (56 pages) RFC4737: Packet Reordering Metrics (42 pages) RFC5136: Defining Network Capacity (20 pages) RFC5357: A Two-Way Active Measurement Protocol (TWAMP) (26 pages) * Updated by RFC5618 RFC5388: Information Model and XML Data Model for Traceroute Measurements (75 pages) RFC5481: Packet Delay Variation Applicability Statement (39 pages) RFC5560: A One-Way Packet Duplication Metric (14 pages) RFC5618: Mixed Security Mode for the Two-Way Active Measurement Protocol - TWAMP (8 pages) * Updates RFC5357 RFC5644: IP Performance Metrics (IPPM): Spatial and Multicast (57 pages) IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ Charter Last Modified: 2008-08-21 Current Status: Active Chairs: Paul Hoffman Yaron Sheffer Security Area Directors: Tim Polk Pasi Eronen Security Area Advisor: Pasi Eronen Mailing Lists: General Discussion: ipsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: http://www.ietf.org/mail-archive/web/ipsec/ Description of Working Group: The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs), IKEv2 (RFC 4306, RFC 4718, and associated RFCs), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group will continue the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions and improvements to IPsec, mostly to IKEv2. The working group will also be a focus point for other IETF Working Groups who use IPsec in their own protocols. The initial set of work items is: - A revision to IKEv2 (RFC 4306) that incorporates the clarifications from RFC 4718, and otherwise improves the quality of the specification, taking into account implementation and interoperability experience. In some cases, the revision may include small technical corrections; however, impact on existing implementations must be considered. Major changes and adding new features is beyond the scope of this work item. The starting point for this work is draft-hoffman-ikev2bis. - An IPsec document roadmap that describes the various RFC documents covering IPsec, including both the core RFC 240x and RFC 430x versions of IPsec, and extensions specified in other documents. Sections 2 and 3 of RFC 2411 can provide useful material, but the expected scope is slightly different from RFC 2411. This document will be informational. - A standards-track extension to IKEv2 that provides full IPv6 support for IPsec remote access clients that use configuration payloads. This work will be based on draft-eronen-ipsec-ikev2-ipv6-config. The WG shall solicit help and reviews from the 6MAN WG to ensure that all aspects of IPv6 are properly considered. - A standards-track extension that allows an IPsec remote access client to "resume" a session with a gateway; that is, to skip certain parts of IKE negotiation when connecting again to the same gateway (or possibly a cluster of closely cooperating gateways). The idea is similar to TLS session resumption without server-side state, specified in RFC 5077. The main goals for this extension are to avoid public-key computations (to reduce VPN gateway load when a large number of clients reconnect to the gateway within a short period of time, such as following a network outage), and remove the need for user interaction for authentication (which may be required by some authentication mechanisms). The extension shall not have negative impact on IKEv2 security features. Failover from one gateway to another, mechanisms for detecting when a session should be resumed, and specifying communication mechanisms between gateways are beyond the scope of this work item. Specifying the detailed contents of the "session ticket" is also beyond the scope of this document; if there is sufficient interest, this could be specified later in a separate document. To the degree its content falls within the scope of this work item, text and ideas from draft-sheffer-ipsec-failover will be used as a starting point. - A standards-track extension to IPsec that allows an IPsec remote access gateway to redirect VPN clients to another gateway. This extension should be aligned with the session resumption extension, (the previous work item), and if so decided by the WG, could be specified in the same document. The starting point will be draft-devarapalli-ipsec-ikev2-redirect. - A standards-track mechanism that allows an intermediary device, such as a firewall or intrusion detection system, to easily and reliably determine whether an ESP packet is encrypted with the NULL cipher; and if it is, determine the location of the actual payload data inside the packet. The starting points for this work item are draft-grewal-ipsec-traffic-visibility and draft-hoffman- esp-null-protocol. The initial scope of the WG is restricted to the work items listed above. The WG shall not consider adding new work items until one or more of its documents progress to IESG evaluation. At that time, the WG can propose rechartering. Chartering this WG is not intended to have effect on documents that beyond the initial scope. In particular, work on IPsec extensions that are not included in this charter can happen as usual in other WGs (and there are currently several other WGs working on IPsec extensions; for example, BTNS and ROHC), or as individual submissions. This charter will expire in July 2010 (24 months from approval). If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Goals and Milestones: Dec 2008 - WG last call on IPv6 configuration payloads Dec 2008 - WG last call on IPsec roadmap Jan 2009 - WG last call on session resumption Feb 2009 - WG last call on redirect Mar 2009 - WG last call on IKEv2bis Apr 2009 - WG last call on ESP NULL traffic visibility Internet-Drafts: - Internet Key Exchange Protocol: IKEv2 [draft-ietf-ipsecme-ikev2bis-05] (149 pages) - Redirect Mechanism for IKEv2 [draft-ietf-ipsecme-ikev2-redirect-14] (15 pages) - Wrapped ESP for Traffic Visibility [draft-ietf-ipsecme-traffic-visibility-09] (15 pages) - IKEv2 Session Resumption [draft-ietf-ipsecme-ikev2-resumption-09] (29 pages) - IPv6 Configuration in IKEv2 [draft-ietf-ipsecme-ikev2-ipv6-config-03] (36 pages) - IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap [draft-ietf-ipsecme-roadmap-04] (65 pages) - Heuristics for Detecting ESP-NULL packets [draft-ietf-ipsecme-esp-null-heuristics-01] (33 pages) - Using Advanced Encryption Standard (AES) Counter Mode with IKEv2 [draft-ietf-ipsecme-aes-ctr-ikev2-02] (18 pages) Requests for Comments: RFC5685: Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2) (15 pages) IS-IS for IP Internets (isis) ----------------------------- Charter Last Modified: 2009-10-16 Current Status: Active Chairs: Chris Hopps David Ward Routing Area Directors: Ross Callon Adrian Farrel Routing Area Advisor: Ross Callon Mailing Lists: General Discussion: isis-wg@ietf.org To Subscribe: isis-wg-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/isis-wg/index.html Description of Working Group: IS-IS is an IGP specified and standarized by ISO and incorporating extensions to support IP. It has been deployed successfully in the Internet for several years years. The IS-IS Working Group is chartered to document current protocol implementation practices and improvements, as well as to propose further extensions to be used within the scope of IS-IS and IP routing. Short term, the WG is expected to deliver a set of documents describing common implementation practices and extensions necessary to scale the protocol. These specifications will encourage multiple, inter-operable vendor implementations. This working group will interact with other standards bodies that have responsibility for standardizing IS-IS. The status of the WG documents maintained by the WG chairs can be found at http://skat.usc.edu/~tli/Schedule.htm. Goals and Milestones: Done - Submit I-D on IS-IS Traffic Engineering Extensions Done - Submit I-D on IS-IS HMAC-MD5 Authentication Done - Submit I-D on Maintaining more than 255 adjacencies in IS-IS Done - Submit I-D on Optional Checksums on IIHs, CSNPs, and PSNPs in IS-IS Done - Submit I-D on IS-IS MIB Done - Submit IS-IS Traffic Engineering Extensions to IESG for publication as an Informational RFC Done - Submit IS-IS HMAC-MD5 Authentication to IESG for publication as an Informational RFC Done - Submit Maintaining more than 255 adjacencies in IS-IS to IESG for publication as an Informational RFC Done - Submit Optional Checksums on IIHs, CSNPs, and PSNPs in IS-IS to IESG for publication as an Informational RFC Done - Submit IPv6 to IESG for publication as an Informational RFC Done - Submit M-ISIS to IESG for publication as an Informational RFC Done - Submit 256+ Fragments to IESG for publication as an Informational RFC Done - Submit Administrative Tags to IESG for publication as an Informational RFC Done - Submit Interoperable IP Networks to IESG for publication as an Informational RFC Done - Submit Interoperable Networks to IESG for publication as an Informational RFC Done - Submit P2P over LAN to IESG for publication as an Informational RFC Done - Submit Gracefull Restart to IESG for publication as an Informational RFC Jun 2005 - Submit Experimental TLVs to IESG for publication as an Informational RFC Done - Submit Definition of an IS-IS Link Attribute sub-TLV to IESG for publication as Informational RFC Done - Submit A Policy Control Mechanism in IS-IS Using Administrative Tags to IESG for publication as Informational RFC Done - Submit IS-IS MIB to IESG for consideration as a Proposed Standard Done - Submit Multi Topology (MT) Routing in ISIS to IESG for publication as Informational RFC Done - Submit IS-IS extensions for advertising router information to IESG for publication as Informational RFC Done - Submit Routing IPv6 with IS-IS to IESG for publication as Proposed Standard Nov 2005 - Review WG's priorities and future potential Internet-Drafts: - Integrated IS-IS Management Information Base [draft-ietf-isis-mib-04] (97 pages) - Use of OSI IS-IS for Routing in TCP/IP and Multi-Protocol Environments [draft-ietf-isis-tcpip-01] (98 pages) - Further Integration of IS-IS; Appletalk, IPX, and Other Protocols [draft-ietf-isis-atipx-00] (24 pages) - Routing over Nonbroadcast Multiaccess Links [draft-ietf-isis-nbma-00] (39 pages) - Multiple Levels of Hierarchy with IS-IS [draft-ietf-isis-multilevel-routing-00] (10 pages) - Integrated ISIS Protocol Analysis [draft-ietf-isis-prot-anal-01] (20 pages) - Experience with the Integrated ISIS Protocol [draft-ietf-isis-opexp-01] (25 pages) - Three-Way Handshake for IS-IS Point-to-Point Adjacencies [draft-ietf-isis-3way-06] (9 pages) - Management Information Base for IS-IS [draft-ietf-isis-wg-mib-27] (104 pages) - Optional Checksums in ISIS [draft-ietf-isis-wg-snp-checksum-03] (5 pages) - Maintaining more than 255 adjacencies in IS-IS [draft-ietf-isis-wg-255adj-02] (6 pages) - Dynamic Hostname Exchange Mechanism for IS-IS [draft-ietf-isis-dyname-04] (4 pages) - IS-IS Cryptographic Authentication [draft-ietf-isis-hmac-05] (6 pages) - IS-IS Optimized Multipath (ISIS-OMP) [draft-ietf-isis-omp-01] (8 pages) - IS-IS over IPv4 [draft-ietf-isis-wg-over-ip-02] (8 pages) - IS-IS extensions for Traffic Engineering [draft-ietf-isis-traffic-06] (13 pages) - L1/L2 Optimal IS-IS Routing [draft-ietf-isis-l1l2-00] (7 pages) - Domain-wide Prefix Distribution with Two-Level IS-IS [draft-ietf-isis-domain-wide-04] (10 pages) - Extended Ethernet Frame Size Support [draft-kaplan-isis-ext-eth-02] (0 pages) - Routing IPv6 with IS-IS [draft-ietf-isis-ipv6-08] (6 pages) - IS-IS Mesh Groups [draft-ietf-isis-wg-mesh-group-02] (9 pages) - IS-IS Extensions in Support of Generalized MPLS [draft-ietf-isis-gmpls-extensions-20] (12 pages) - Extensions to ISIS for support of Diff-Serv-aware MPLS Traffic Engineering [draft-ietf-isis-diff-te-00] (7 pages) - IS-IS Transient Blackhole Avoidance [draft-ietf-isis-transient-02] (6 pages) - M-ISIS: Multi Topology (MT) Routing in IS-IS [draft-ietf-isis-wg-multi-topology-13] (13 pages) - Extended Ethernet Frame Size Support [draft-ietf-isis-ext-eth-01] (0 pages) - Reserved TLV Codepoints in ISIS [draft-ietf-isis-wg-tlv-codepoints-01] (0 pages) - Restart signaling for IS-IS [draft-ietf-isis-restart-06] (21 pages) - Point-to-point operation over LAN in link-state routing protocols [draft-ietf-isis-igp-p2p-over-lan-07] (10 pages) - Extending the Number of IS-IS LSP Fragments Beyond the 256 Limit [draft-ietf-isis-ext-lsp-frags-03] (13 pages) - Recommendations for Interoperable IP Networks using IS-IS [draft-ietf-isis-interoperable-01] (20 pages) - TLV for Experimental Use [draft-ietf-isis-experimental-tlv-05] (0 pages) - IS-IS Automatic Encapsulation [draft-ietf-isis-auto-encap-03] (24 pages) - A Policy Control Mechanism in IS-IS Using Administrative Tags [draft-ietf-isis-admin-tags-05] (9 pages) - TLV for Proprietary Use [draft-ietf-isis-proprietary-tlv-00] (5 pages) - Recommendations for Interoperable IP Networks using IS-IS [draft-ietf-isis-ip-interoperable-03] (12 pages) - Recommendations for Interoperable Networks using IS-IS [draft-ietf-isis-iso-interoperable-03] (15 pages) - Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication [draft-ietf-isis-rfc3567bis-04] (11 pages) - IPv6 Traffic Engineering in IS-IS [draft-ietf-isis-ipv6-te-07] (10 pages) - Definition of an IS-IS Link Attribute sub-TLV [draft-ietf-isis-link-attr-04] (6 pages) - IS-IS Extensions for Advertising Router Information [draft-ietf-isis-caps-08] (8 pages) - IS-IS extensions for Traffic Engineering [draft-ietf-isis-te-bis-01] (21 pages) - Advertising Generic Information in IS-IS [draft-ietf-isis-genapp-01] (12 pages) - Simplified Extension of LSP Space for IS-IS [draft-ietf-isis-wg-extlsp-06] (15 pages) - IS-IS Generic Cryptographic Authentication [draft-ietf-isis-hmac-sha-08] (12 pages) - Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) [draft-ietf-isis-rfc4205bis-01] (12 pages) - IS-IS Transient Blackhole Avoidance [draft-ietf-isis-rfc3277bis-00] (9 pages) - Dynamic Hostname Exchange Mechanism for IS-IS [draft-ietf-isis-rfc2763bis-01] (9 pages) - Restart Signaling for Intermediate System to Intermediate System (IS-IS) [draft-ietf-isis-rfc3847bis-01] (22 pages) - Domain-wide Prefix Distribution with Two-Level IS-IS [draft-ietf-isis-rfc2966bis-04] (16 pages) - IS-IS Multi-Instance [draft-ietf-isis-mi-02] (9 pages) - IS-IS BFD Enabled TLV [draft-ietf-isis-bfd-tlv-01] (9 pages) - Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies [draft-ietf-isis-rfc3373bis-02] (14 pages) - Extensions to IS-IS for Layer-2 Systems [draft-ietf-isis-layer2-01] (38 pages) Requests for Comments: RFC1195: Use of OSI IS-IS for Routing in TCP/IP and Dual Environments (68 pages) * Updated by RFC5302 * Updated by RFC5304 RFC2763: Dynamic Hostname Exchange Mechanism for IS-IS (5 pages) * OBSOLETED BY RFC5301 RFC2966: Domain-wide Prefix Distribution with Two-Level IS-IS (14 pages) * OBSOLETED BY RFC5302 RFC2973: IS-IS Mesh Groups (8 pages) RFC3277: IS-IS Transient Blackhole Avoidance (6 pages) RFC3358: Optional Checksums in ISIS (4 pages) RFC3359: Reserved TLV Codepoints in ISIS (5 pages) RFC3373: Three-Way Handshake for IS-IS Point-to-Point Adjacencies (9 pages) * OBSOLETED BY RFC5303 RFC3567: Intermediate System to Intermediate System (IS-IS)Cryptographic Authentication (6 pages) * OBSOLETED BY RFC5304 RFC3719: Recommendations for Interoperable Networks using IS-IS (15 pages) RFC3786: Extending the Number of IS-IS LSP Fragments Beyond the 256 Limit (13 pages) * OBSOLETED BY RFC5311 RFC3787: Recommendations for Interoperable IP Networks using IS-IS (12 pages) RFC3784: IS-IS extensions for Traffic Engineering (13 pages) * Updated by RFC4205 * OBSOLETED BY RFC5305 RFC3847: Restart signaling for IS-IS (21 pages) * OBSOLETED BY RFC5306 RFC4205: Intermediate System to Intermediate System (IS-IS) Extensions in Support of Multi-Protocol Label Switching (GMPLS) (12 pages) * Updates RFC3784 * OBSOLETED BY RFC5307 RFC4444: Management Information Base for Intermediate System to Intermediate System (IS-IS) (104 pages) RFC4971: Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information (8 pages) RFC5029: Definition of an IS-IS Link Attribute sub-TLV (6 pages) RFC5120: M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs) (13 pages) RFC5130: A Policy Control Mechanism in IS-IS Using Administrative Tags (9 pages) RFC5301: Dynamic Hostname Exchange Mechanism for IS-IS (9 pages) * Obsoletes RFC2763 RFC5302: Domain-wide Prefix Distribution with Two-Level IS-IS (16 pages) * Obsoletes RFC2966 * Updates RFC1195 RFC5303: Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies (14 pages) * Obsoletes RFC3373 RFC5304: Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication (11 pages) * Obsoletes RFC3567 * Updates RFC1195 RFC5305: IS-IS extensions for Traffic Engineering (21 pages) * Obsoletes RFC3784 * Updated by RFC5307 RFC5306: Restart Signaling for Intermediate System to Intermediate System (IS-IS) (22 pages) * Obsoletes RFC3847 RFC5307: Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) (12 pages) * Obsoletes RFC4205 * Updates RFC5305 RFC5308: Routing IPv6 with IS-IS (6 pages) RFC5309: Point-to-point operation over LAN in link-state routing protocols (10 pages) RFC5311: Simplified Extension of Link State PDU (LSP) Space for IS-IS (15 pages) * Obsoletes RFC3786 RFC5310: IS-IS Generic Cryptographic Authentication (12 pages) Integrated Security Model for SNMP (isms) ----------------------------------------- Charter Last Modified: 2009-08-04 Current Status: Active Chairs: Russ Mundy Juergen Schoenwaelder Security Area Directors: Tim Polk Pasi Eronen Security Area Advisor: Pasi Eronen Mailing Lists: General Discussion: isms@ietf.org To Subscribe: isms-request@ietf.org Archive: http://www.ietf.org/mail-archive/working-groups/isms/current/maillist.html Description of Working Group: The Simple Network Management Protocol version 3 (SNMPv3) provides message security services through the security subsystem. Previously the ISMS Working Group defined a Transport Subsystem definition, a new Transport Security Model, and a Secure Shell Transport Model and a method for authenticating SNMPv3 users via the Remote Authentication Dial-In User Service (RADIUS). The initial body of work to be tackled by the working group involved only these pieces. Additional work on other transport models and other security extensions were to wait until the initial transport architecture and defining documents were completed. It is now possible to authenticate SNMPv3 messages via a RADIUS when those messages are sent over the newly defined SSH transport. However, it still remains impossible to centrally authorize a given SNMP transaction as on-device pre-existing authorization configuration is still required. In order to leverage a centralized RADIUS service to its full extent, the access control decision in the Access Control Subsystem needs to be based on authorization information received from RADIUS as well. The result will be an extension to obtain authorization information for an authenticated principal from RADIUS. The authorization information will be limited to mapping the authenticated principal to existing named access control policies, defining session timeouts, and similar session parameters. This mechanism will not provision the detailed access control rules. Additionally, new work will be undertaken to define TLS and DTLS-based transports that can offer support for environments that prefer certificate authentication. Certificate based authentication is desirable for many environments with a centralized authentication service. DTLS also provides datagram-based transmissions which may be desired for environments where TCP performance suffers because of network anomalies (e.g. high packet loss rates). A combination of TLS and DTLS-based transports offers solutions that addresses both the need for certificate-based authentication and for datagram-based delivery. Operators will be able to chose the transport solution that best meets their needs. The current goal of the ISMS working group is two-fold: to develop a method for allowing for access control decisions to be based on information provide by an AAA provisioning service and to develop TLS-based and DTLS-based Transport Models. The new work must not modify any other aspects of SNMPv3 protocol as defined in STD 62 (e.g., it must not create new PDU types). The working group will cover the following work items: - Specify a mechanism to support centralization of SNMPv3 Access Control decisions by means of a RADIUS-provisioned policy name bound to a username, which the VACM extension will use to dynamically populate the securityToGroupname table. Additionally, specify a time limit for access decisions, and such a time limit should be used to garbage collect expired dynamic securityToGroup mappings. - Specify TLS and DTLS transport models for SNMP. Goals and Milestones: Done - Cut-off date for internet-drafts to be submitted to the working group for consideration as a proposed solution Done - Decision about which architecture the WG will focus its efforts on Done - Initial version of a general transport mapping security models (TMSMs) document that specifies how TMSMs fit into the SNMPv3 architecture and that defines the requirements for transport mapping security models Done - Initial version of a document specifying the SSH security model for SNMP Jul 2009 - Publish initial documentation for the centralized access control Jul 2009 - Publish initial documentation on the (D)TLS transports for SNMP Jan 2010 - Submit documentation for the centralized access control to IESG Jan 2010 - Submit documentation on the (D)TLS transports for SNMP to IESG Internet-Drafts: - Comparison of Proposals for Integrated Security Models for SNMP (Simple Network Management Protocol) [draft-ietf-isms-proposal-comparison-00] (21 pages) - Secure Shell Transport Model for SNMP [draft-ietf-isms-secshell-19] (39 pages) - Transport Subsystem for the Simple Network Management Protocol (SNMP) [draft-ietf-isms-tmsm-19] (36 pages) - Transport Security Model for SNMP [draft-ietf-isms-transport-security-model-15] (29 pages) - Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models [draft-ietf-isms-radius-usage-08] (16 pages) - Transport Layer Security Transport Model for SNMP [draft-ietf-isms-dtls-tm-01] (67 pages) Requests for Comments: RFC5592: Secure Shell Transport Model for the Simple Network Management Protocol (SNMP) (39 pages) RFC5591: Transport Security Model for the Simple Network Management Protocol (SNMP) (29 pages) RFC5590: Transport Subsystem for the Simple Network Management Protocol (SNMP) (36 pages) * Updates RFC3411 * Updates RFC3412 * Updates RFC3414 * Updates RFC3417 RFC5608: Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models (14 pages) Provisioning of Symmetric Keys (keyprov) ---------------------------------------- Charter Last Modified: 2008-12-16 Current Status: Active Chairs: Phillip Hallam-Baker Hannes Tschofenig Security Area Directors: Tim Polk Pasi Eronen Security Area Advisor: Pasi Eronen Mailing Lists: General Discussion: keyprov@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/keyprov Archive: http://www.ietf.org/mail-archive/web/keyprov Description of Working Group: Current developments in deployment of Shared Symmetric Key (SSK) tokens have highlighted the need for a standard protocol for provisioning symmetric keys. The need for provisioning protocols in PKI architectures has been recognized for some time. Although the existence and architecture of these protocols provides a feasibility proof for the KEYPROV work assumptions built into these protocols mean that it is not possible to apply them to symmetric key architectures without substantial modification. In particular the ability to provision symmetric keys and associated attributes dynamically to already issued devices such as cell phones and USB drives is highly desirable. The working group will develop the necessary protocols and data formats required to support provisioning and management of symmetric key authentication tokens, both proprietary and standards based. Input Documents --------------- The following Internet drafts have been proposed by their authors as input documents: * Dynamic Symmetric Key Provisioning Protocol (M. Pei, S. Machani) * Portable Symmetric Key Container (A. Vassilev, J. Martinsson, M. Pei, P. Hoyer, S. Machani) * Extensions to CT-KIP to support one- and two-pass key initialization (M. Nystroem, S. Machani) Scope and Deliverables ---------------------- The scope of the working group shall be to define protocols and data formats necessary for provisioning of symmetric cryptographic keys and associated attributes. The group shall consider use cases related to use of Shared Symmetric Key Tokens. Other use cases may be considered for the purpose of avoiding unnecessary restrictions in the design and ensure the potential for future extensibility. The working group will produce the following deliverables: * Portable Symmetric Key Container * Dynamic Symmetric Key Provisioning Protocol Goals and Milestones: Jun 2007 - WG Last Call Portable Symmetric Key Container Jun 2007 - WG Last Call Dynamic Symmetric Key Provisioning Protocol Aug 2007 - IETF Last Call Portable Symmetric Key Container Aug 2007 - IETF Last Call Dynamic Symmetric Key Provisioning Protocol Jan 2008 - Complete implementation and interoperability tests Jan 2008 - WG documents to DRAFT Standard Status Internet-Drafts: - Dynamic Symmetric Key Provisioning Protocol (DSKPP) [draft-ietf-keyprov-dskpp-08] (94 pages) - Portable Symmetric Key Container [draft-ietf-keyprov-portable-symmetric-key-container-07] (95 pages) - Symmetric Key Package Content Type [draft-ietf-keyprov-symmetrickeyformat-06] (25 pages) - Portable Symmetric Key Container (PSKC) [draft-ietf-keyprov-pskc-04] (62 pages) No Requests for Comments Kitten (GSS-API Next Generation) (kitten) ----------------------------------------- Charter Last Modified: 2009-05-14 Current Status: Active Chairs: Tom Yu Shawn Emery Security Area Directors: Tim Polk Pasi Eronen Security Area Advisor: Tim Polk Mailing Lists: General Discussion: kitten@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/kitten Archive: http://www.ietf.org/mail-archive/web/kitten/current/maillist.html Description of Working Group: The Generic Security Services API [RFC 2743, RFC 2744] provides an API for applications to set up security contexts and to use these contexts for per-message protection services. The Common Authentication Technology Next Generation Working Group (Kitten) will work on standardizing extensions and improvements to the core GSSAPI specification and language bindings that the IETF believes are necessary based on experience using GSSAPI over the last 10 years. Extensions may be published as separate drafts or included in a GSSAPI version 3. While version 2 of the GSSAPI may be clarified, no backward incompatible changes will be made to this version of the API. This working group is chartered to revise the GSSAPI v2 RFCs for the purpose of clarifying areas of ambiguity: o Use of channel bindings o Thread safety restrictions o C language utilization clarifications and recommendations (e.g., type utilization, name spaces) o Guidelines for GSS-API mechanism designers o Guidelines for GSS-API application protocol designers This working group is chartered to specify a non-backward compatible GSSAPI v3 including support for the following extensions: o Clarify the portable use of channel bindings and better specify channel bindings in a language-independent manner. o Specify thread safety extensions to allow multi-threaded applications to use GSSAPI o Definitions of channel bindings for TLS, IPSec, SSH and other cryptographic channels based on work started in the NFSV4 working group. o Define a GSSAPI extension to allow applications to store credentials. Discussions to be started based upon: o draft-williams-gss-store-deleg-creds-xx.txt o Extensions to solve problems posed by the Global Grid Forum's GSSAPI extensions document. o Extensions to deal with mechanism-specific extensibility in a multi-mechanism environment. o Extend the GSS-API to support authorization by portable GSS applications while also supporting mechanisms that do not have a single canonical name for each authentication identity. o Specify a Domain-based GSS service principal name consisting of: service name, host name, and domain name for use by application services hosted across multiple servers. o Extensions to support stackable GSSAPI mechanisms. o Define a Psuedo-Random Function for GSSAPI This working group is chartered to perform the following GSSAPI mechanism specification work: o Specify a GSSAPI v2/v3 Channel Conjunction Mechanism o Revise RFC 2748 (SPNEGO) to correct problems that make the specification unimplementable and to document the problems found in widely-deployed attempts to implement this spec. o Update the GSSAPI Java Language Bindings to match actual implementation This working group is chartered to perform the following new GSSAPI Language Binding specification work: o Specify a language binding for C# DELIVERABLES Either: o Clarifications to GSSAPIv2 (May 2005 to IESG)Informational [editor: TBD] Or: o Generic Security Service Application Program Interface Version 2, Update 2 [editor: TBD] o Generic Security Service API Version 2, Update 1 : C-bindings [editor: TBD] End: o The Channel Conjunction Mechanism (CCM) for the GSSAPI [editors: Mike Eisler/Nicolas Williams] (based on draft-ietf-nfsv4-ccm, which has been discussed previously in the NFSv4 WG) o On the Use of Channel Bindings to Secure Channels [editor: Nicolas Williams] (based on draft-ietf-nfsv4-channel-bindings, which has been discussed previously in the NFSv4 WG) o GSSAPIv3 [editor: to be determined] o Stackable Generic Security Service Pseudo-mechanisms [editor: Nicolas Williams] draft-williams-gssapi-stackable-pseudo-mechs o GSS-APIv2 Extension for Storing Delegated Credentials [editor: Nicolas Williams] draft-williams-gssapi-store-deleg-creds o GSSAPI Mechanisms without a Unique Canonical Name [editor: Sam Hartman] draft-hartman-gss-naming o SPNEGO (RFC 2478) Revisions [editor: Wyllys Ingersoll / Larry Zhu] draft-zhu-spnego-2478bis o Guide to the GSS-APIv3 [editor: Nicolas Williams] draft-williams-gssapi-v3-guide-to o Namespace Considerations and Registries for GSS-API Extensions [editor: Nicolas Williams] draft-williams-gssapi-extensions-iana o GSS-API Domain-Based Service Names and Name Type [editor: Nicolas Williams] draft-williams-gssapi-domain-based-names o GSS-API Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism [editor: Nicolas Williams] draft-williams-krb5-gssapi-domain-based-names o A PRF API extension for the GSS-API [editor: Nicolas Williams] draft-williams-gssapi-prf o A PRF for the Kerberos V GSS-API Mechanism [editor: Nicolas Williams] draft-williams-krb5-gssapi-prf o Generic Security Service API Version 2 : Java & C# Bindings [editors: Larry Zhu / Corby Morris] draft-morris-java-gssapi-update-for-csharp Goals and Milestones: Done - First Meeting Sep 2007 - Submit updated draft-ietf-kitten-gssapi-domain-based-names and draft-ietf-kitten-krb5-gssapi-domain-based-names to the IESG Oct 2007 - WGLC on draft-ietf-kitten-gssapi-channel-bindings Oct 2007 - Submit draft-ietf-kitten-extended-mech-inquiry to the IESG as Proposed Standard Nov 2007 - WGLC on GSS-API Naming Extensions (draft-ietf-kitten-gssapi-naming-exts) Nov 2007 - Submit draft-ietf-kitten-stackable-pseudo-mechs to the IESG as Proposed Standard Nov 2007 - Submit draft-ietf-kitten-gssapi-channel-bindings to the IESG as Proposed Standard Dec 2007 - WGLC on draft-ietf-kitten-gssapi-store-cred Dec 2007 - Submit GSS-API Naming Extensions (draft-ietf-kitten-gssapi-naming-exts) to the IESG as Proposed Standard Jan 2008 - WGLC on Generic Security Service API Version 3 : Java-bindings (draft-ietf-kitten-rfc2853bis) Jan 2008 - Submit draft-ietf-kitten-gssapi-store-cred to the IESG as Proposed Standard as Proposed Standard Feb 2008 - Submit Generic Security Service API Version 3 : Java-bindings (draft-ietf-kitten-rfc2853bis) to the IESG as Proposed Standard Internet-Drafts: - Desired Enhancements to GSSAPI Version 3 Naming [draft-ietf-kitten-gss-naming-06] (17 pages) - GSS-API Naming Extensions [draft-ietf-kitten-gssapi-naming-exts-05] (16 pages) - The Simple and Protected GSS-API Negotiation Mechanism [draft-ietf-kitten-2478bis-06] (30 pages) - Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type [draft-ietf-kitten-gssapi-domain-based-names-07] (9 pages) - A PRF API extension for the GSS-API [draft-ietf-kitten-gssapi-prf-08] (9 pages) - Generic Security Service Application Program Interface (GSS-API) Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism [draft-ietf-kitten-krb5-gssapi-domain-based-names-06] (6 pages) - A PRF for the Kerberos V GSS-API Mechanism [draft-ietf-kitten-krb5-gssapi-prf-05] (6 pages) - GSS-API V2: Java & C# Bindings [draft-ietf-kitten-gssapi-rfc2853-update-for-csharp-00] (10 pages) - Generic Security Service API Version 2 : Java Bindings Update [draft-ietf-kitten-rfc2853bis-06] (95 pages) - Guide to the GSS-APIv3 [draft-ietf-kitten-gssapi-v3-guide-to-01] (22 pages) - Extended Generic Security Service Mechanism Inquiry APIs [draft-ietf-kitten-extended-mech-inquiry-07] (13 pages) - Stackable Generic Security Service Pseudo-Mechanisms [draft-ietf-kitten-stackable-pseudo-mechs-02] (17 pages) - Clarifications and Extensions to the GSS-API for the Use of Channel Bindings [draft-ietf-kitten-gssapi-channel-bindings-08] (11 pages) - GSS-API Extension for Storing Delegated Credentials [draft-ietf-kitten-gssapi-store-cred-05] (12 pages) - Namespace Considerations and Registries for GSS-API Extensions [draft-ietf-kitten-gssapi-extensions-iana-06] (10 pages) - GSS_API V2: C# Bindings [draft-ietf-kitten-gssapi-csharp-bindings-00] (95 pages) Requests for Comments: RFC4178: The Simple and Protected Generic Security ServiceApplication Program Interface (GSS-API) Negotiation Mechanism (30 pages) * Obsoletes RFC2478 RFC4401: A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API) (9 pages) RFC4402: A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism (6 pages) RFC4768: Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming (17 pages) RFC5179: Generic Security Service Application Program Interface (GSS-API) Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism (5 pages) RFC5178: Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type (9 pages) RFC5554: Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings (4 pages) * Updates RFC2473 RFC5588: Generic Security Service Application Program Interface (GSS-API) Extension for Storing Delegated Credentials (7 pages) RFC5587: Extended Generic Security Service Mechanism Inquiry APIs (13 pages) RFC5653: Generic Security Service API Version 2: Java Bindings Update (99 pages) * Obsoletes RFC2853 Kerberos (krb-wg) ----------------- Charter Last Modified: 2009-01-12 Current Status: Active Chairs: Jeffrey Hutzelman Larry Zhu Security Area Directors: Tim Polk Pasi Eronen Security Area Advisor: Tim Polk Mailing Lists: General Discussion: ietf-krb-wg@lists.anl.gov To Subscribe: https://lists.anl.gov/mailman/listinfo/ietf-krb-wg Archive: https://lists.anl.gov/pipermail/ietf-krb-wg/ Description of Working Group: Kerberos over the years has been ported to virtually every operating system. There are at least two open source versions, with numerous commercial versions based on these and other proprietary implementations. Kerberos evolution has continued in recent years, with the development of a new crypto framework, publication of a new version of the Kerberos specification, support for initial authentication using public keys, and numerous extensions developed in and out of the IETF. However, wider deployment and advances in technology bring with them both new challenges and new opportunities, particularly with regard to making initial authentication of users to the Kerberos system both convenient and secure. In addition, several key features remain undefined. The Kerberos Working Group will continue to improve the core Kerberos specification, develop extensions to address new needs and technologies related to improving the process of client authentication, and produce specifications for missing functionality. Specifically, the Working Group will: * Complete existing work: - ECC for PKINIT (draft-zhu-pkinit-ecc-03.txt) - Set/Change Password (draft-ietf-krb-wg-kerberos-set-passwd-05.txt) - Naming Constraints (draft-ietf-krb-wg-naming-02.txt) - Anonymity (draft-ietf-krb-wg-anon-03.txt) - Hash agility for GSS-KRB5 (draft-ietf-krb-wg-gss-cb-hash-agility-00.txt) - Hash agility for PKINIT (draft-ietf-krb-wg-pkinit-alg-agility-01.txt) - Referrals (draft-ietf-krb-wg-kerberos-referrals-08.txt) * Prepare and advance a specification for an updated, backward- compatible version of the Kerberos version 5 protocol which supports non-ASCII principal and realm names, salt strings, and passwords; insures that those portions of the protocol which are not encrypted are nonetheless authenticated whenever possible; and enables future protocol revisions and extensions. * Develop extensions which reduce or eliminate exposure of Kerberos clients' long-term keys to attack and enable the use of alternate mechanisms for initial authentication. This task will comprise the following items: - A model and framework for preauthentication mechanisms - A mechanism for providing a protected channel for carrying preauthentication data and/or a reply key between a Kerberos client and KDC, within the KDC_REQ/KDC_REP exchange. - Support for One-Time Passwords - Support for hardware authentication tokens - Support for using TLS to secure communications with Kerberos KDCs. * Examine issues related to the current cross-realm model, produce a list of problems to be solved, and evaluate approaches to solving them. * Develop extensions to Kerberos and a GSS-API mechanism (IAKERB) to enable Kerberos clients to communicate with a KDC by using a GSS-API acceptor as a proxy. * Produce a data model for information needed by the KDC, and an LDAP schema for management of that data. Goals and Milestones: Done - First meeting Done - Submit the Kerberos Extensions document to the IESG for consideration as a Proposed standard. Done - Complete first draft of Pre-auth Framework Done - Complete first draft of Extensions Done - Submit K5-GSS-V2 document to IESG for consideration as a Proposed Standard Done - Last Call on OCSP for PKINIT Done - Consensus on direction for Change/Set password Done - PKINIT to IESG Done - Enctype Negotiation to IESG Done - Last Call on PKINIT ECC Done - TCP Extensibility to IESG Done - ECC for PKINIT to IESG Done - Naming Constraints to IESG Done - Anonymity to IESG Sep 2007 - WGLC on preauth framework Done - WGLC on OTP Done - WGLC on data model Done - WGLC on cross-realm issues Jan 2008 - WGLC on Referrals Dec 2008 - Set/Change Password to IESG Dec 2008 - Hash agility for GSS-KRB5 to IESG Dec 2008 - Hash agility for PKINIT to IESG Done - WGLC on IAKERB Done - Anonymity back to IESG Jan 2009 - WGLC on STARTTLS Done - Data Model to IESG Done - OTP to IESG Internet-Drafts: - Public Key Cryptography for Initial Authentication in Kerberos [draft-ietf-cat-kerberos-pk-init-35] (42 pages) - Public Key Cryptography for Cross-Realm Authentication in Kerberos [draft-ietf-cat-kerberos-pk-cross-08] (5 pages) - Public Key Utilizing Tickets for Application Servers (PKTAPP) [draft-ietf-cat-kerberos-pk-tapp-04] (5 pages) - The Kerberos Network Authentication Service (V5) [draft-ietf-cat-kerberos-revisions-10] (103 pages) - Initial and Pass Through Authentication Using Kerberos V5 and GSS-API (IAKERB) [draft-ietf-cat-iakerb-09] (13 pages) - The Kerberos Version 5 GSSAPI Mechanism, Version 2 [draft-ietf-cat-krb5gss-mech2-03] (23 pages) - Distributing Kerberos KDC and Realm Information with DNS [draft-ietf-krb-wg-krb-dns-locate-03] (7 pages) - Kerberos Set/Change Password: Version 2 [draft-ietf-cat-kerberos-set-passwd-06] (13 pages) - Kerberos KDC LDAP Schema [draft-skibbie-krb-kdc-ldap-schema-02] (0 pages) - AES Encryption for Kerberos 5 [draft-raeburn-krb-rijndael-krb-08] (15 pages) - Kerberos Principal Name Canonicalization and KDC-Generated Cross-Realm Referrals [draft-ietf-krb-wg-kerberos-referrals-11] (19 pages) - Passwordless Initial Authentication to Kerberos by Hardware Preauthentication [draft-ietf-krb-wg-hw-auth-04] (7 pages) - Informational: Kerberos GeneralString to be Interpreted as ASCII Only [draft-ietf-krb-wg-info-ascii-gen-string-00] (0 pages) - Encryption and Checksum Specifications for Kerberos 5 [draft-ietf-krb-wg-crypto-08] (51 pages) - The Kerberos Network Authentication Service (V5) [draft-ietf-krb-wg-kerberos-clarifications-08] (135 pages) - Preparation of Internationalized Strings Profile for Kerberos UTF-8 Strings [draft-ietf-krb-wg-utf8-profile-01] (0 pages) - Keys Extension for the Kerberos KDC LDAP Schema [draft-skibbie-krb-kdckeys-ldap-schema-00] (0 pages) - Integrating Single-use Authentication Mechanisms with Kerberos [draft-ietf-krb-wg-kerberos-sam-03] (16 pages) - OCSP Support for PKINIT [draft-ietf-krb-wg-ocsp-for-pkinit-07] (7 pages) - Kerberos Set/Change Key/Password Protocol Version 2 [draft-ietf-krb-wg-kerberos-set-passwd-08] (41 pages) - Kerberos Cryptosystem Negotiation Extension [draft-zhu-kerb-enctype-nego-05] (7 pages) - General Kerberos Cryptosystem Support for the Kerberos 5 GSSAPI Mechanism [draft-ietf-krb-wg-gss-crypto-00] (10 pages) - The Kerberos Version 5 GSS-API Mechanism: Version 2 [draft-ietf-krb-wg-gssapi-cfx-08] (17 pages) - A Generalized Framework for Kerberos Pre-Authentication [draft-ietf-krb-wg-preauth-framework-15] (51 pages) - Unkeyed SHA-1 Checksum Specification for Kerberos 5 [draft-ietf-krb-wg-sha1-00] (4 pages) - Using Kerberos V5 over the Transport Layer Security (TLS) protocol [draft-josefsson-kerberos5-starttls-07] (14 pages) - The Kerberos Network Authentication Service (Version 5) [draft-ietf-krb-wg-rfc1510ter-04] (114 pages) - ECC Support for PKINIT [draft-zhu-pkinit-ecc-05] (11 pages) - Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges Over TCP [draft-josefsson-krb-tcp-expansion-02] (7 pages) - Additional Kerberos Naming Constraints [draft-ietf-krb-wg-naming-07] (8 pages) - PK-INIT algorithm agility [draft-ietf-krb-wg-pkinit-alg-agility-04] (24 pages) - Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges Over TCP [draft-ietf-krb-wg-tcp-expansion-03] (7 pages) - Anonymity Support for Kerberos [draft-ietf-krb-wg-anon-10] (16 pages) - Kerberos Version 5 GSS-API Channel Binding Hash Agility [draft-ietf-krb-wg-gss-cb-hash-agility-05] (12 pages) - Kerberos ticket extensions [draft-ietf-krb-wg-ticket-extensions-01] (17 pages) - OTP Pre-authentication [draft-ietf-krb-wg-otp-preauth-11] (38 pages) - Problem statement on the cross-realm operation of Kerberos [draft-ietf-krb-wg-cross-problem-statement-05] (13 pages) - Initial and Pass Through Authentication Using Kerberos V5 and the GSS- API (IAKERB) [draft-ietf-krb-wg-iakerb-02] (10 pages) - An information model for Kerberos version 5 [draft-ietf-krb-wg-kdc-model-06] (18 pages) Requests for Comments: RFC3962: AES Encryption for Kerberos 5 (15 pages) RFC3961: Encryption and Checksum Specifications for Kerberos 5 (51 pages) RFC4120: The Kerberos Network Authentication Service (V5) (135 pages) * Obsoletes RFC1510 * Updated by RFC4537 * Updated by RFC5021 RFC4121: The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2 (17 pages) * Updates RFC1964 RFC4537: Kerberos Cryptosystem Negotiation Extension (7 pages) * Updates RFC4120 RFC4557: Online Certificate Status Protocol (OCSP) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) (7 pages) RFC4556: Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) (42 pages) RFC5021: Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges Over TCP (7 pages) * Updates RFC4120 RFC5349: Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) (10 pages) Layer Two Tunneling Protocol Extensions (l2tpext) ------------------------------------------------- Charter Last Modified: 2009-06-25 Current Status: Active Chairs: Ignacio Goyret Carlos Pignataro Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion: l2tpext@ietf.org To Subscribe: l2tpext-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/l2tpext/index.html Description of Working Group: This group is responsible for extensions to the Layer 2 Tunneling Protocol. Examples of L2TP "extensions" include any changes to the L2TP encapsulation, control messages, or new AVPs sent in IETF standard control messages. I. L2TP Background: L2TP (RFC2661) provides a means for tunneling PPP over IP. Because PPP can effectivly carry any traffic (e.g., IP (RFC 1332), IPX (RFC 1552), etc.) it can effectively be used to tunnel arbitrary protocols over IP. L2TP provides: - An extensible control protocol for dynamic setup, maintenance, and teardown of multiple layer 2 tunnels between two logical endpoints. - An encapsulation method for tunneling PPP frames between each endpoint. This includes multiplexing of multiple, discrete, PPP streams between each endpoint. L2TP looks (in most ways) like just another point-to-point link to PPP and may thereby take advantage of the work done for any protocol defined for use over a traditional PPP WAN link. It should be noted, however, that the ability to dynamically establish a PPP connection between any two IP connected endpoints brings new applications and challenges of scale to existing PPP implementations and protocol definitions that must be considered. As high-speed broadband access to the home replaces traditional dialup infrastructure, L2TP has been utilized as one standard method for aggregation and delivery of PPP connections over packet networks. Thus, rather than a relatively small scale or low speed circuit-switched connection such as an analog modem or ISDN connection at the L2TP Access Concentrator (LAC), we see PPP being received over ATM PVCs which are generally higher speed and "always-on" vs. temporally connected. Further, there are non-IETF standard PPP tunneling protocols that have been developed and deployed, including PPPoE (RFC 2516) and the 3GPP2 Wireless GPRS Tunneling Protocol Standard (http://www.3gpp.org) that interface with L2TP at various points in the network. While it is unfortunate that there is more than one standard method for tunneling PPP defined, each of these have their own installed bases and specific application-driven nuances. Proper integration with these various tunneling methods as they "hand-off" to the L2TP portion of the network must be ensured. II. L2TP Interaction with PWE3 for Pseudo-Wire Transport: In addition to tunneling PPP, L2TPEXT will develop protocol extensions necessary for the tunneling of specific "pseudo-wires" as defined in the PWE3 WG. Specific milestone identification for this activity is currently subject to ongoing work and results from PWE3. III. WG Activities The Working Group is currently focussed on the following activities: - RFC2661 bundles data transport, protocol signaling, and PPP emulation methods into a single document. This working group will separate RFC2661 into stand-alone documents for greater modularity. This will consist of a base L2TP document defining common tunneling constructs and encapsulation, and a PPP document defining the use of these constructs for tunneling of PPP sessions as defined in RFC2661. Documents for tunneling of pseudo-wires defined in PWE3 will be forthcoming as well. As RFC2661 is rewritten to separate the tunnel setup and maintenance sections for support of new applications and increased modularity, some modifications to the base protocol may be necessary. This includes addition of a Pseudo Wire AVP to identify the pseudo wire being carried (with PPP identified as 0). In all cases, these will follow the extensible models offered in the L2TP base protocol design, with as much attention to backwards compatibility as possible given the new requirements. In addition to its broader scope, L2TPEXT has ongoing work to complete from its inception as a tunneling protocol for PPP only. While RFC2661 will ultimately be made obsolete by a new L2TP base specification and companion PPP over L2TP specification, documents based on RFC2661 which do not require this new degree of modularity will still be published in the near term. These include: - Identification of specific parameters and modes of IPsec in order to aid interoperability when IPsec is used to secure L2TP traffic. - An L2TP MIB for network management. - An L2TP Differentiated Services Extension to negotiate DSCP parameters to be set for packets associated with a given L2TP tunnel, sessions within a tunnel, or L2TP control traffic which may need differentiated QoS settings. - Extensions to L2TP for additional or more robust control information for informational or operational purposes as deemed necessary based on operational experience. These include better transfer of L2TP PPP LCP Information between tunnel endpoints when such state needs to be shared, PPP Disconnect codes within L2TP control messages for better debugging, and L2TP session information for enhanced logging, billing, and error reporting. - Standard methods for operation over such packet networks such as Frame Relay and AAL5. - L2TP defines a base encapsulation for operation in typical environments for tunneling PPP at the time RFC2661 was being developed. In cases where bandwidth cost is at a premium, the size of the L2TP header becomes more significant. L2TP will define a compressed version of the L2TP header for these environments that takes advantage of the L2TP control plane to establish operational parameters allowing removal of information from individual packets. Goals and Milestones: Done - Submit L2TP over Frame Relay to IESG for consideration as a Proposed Standard Done - Submit L2TP Security to IESG for consideration as a Proposed Standard Done - Submit L2TP PPP Disconnect Information to IESG for consideration as a Proposed Standard Done - Submit L2TP ATM extensions to IESG for consideration as a Proposed Standard Done - Submit L2TP MIB to IESG for consideration as a Proposed Standard Done - Submit L2TP Link Information to IESG for consideration as a Proposed Standard Done - Submit L2TP Session Info to IESG for consideration as a Proposed Standard Done - Submit L2TP Differentiated Services to IESG for consideration as a Proposed Standard Done - Submit L2TP over AAL5 to IESG for consideration as a Proposed Standard Done - Submit initial Internet-Draft of L2TP Base Specification Done - Submit initial Internet-Draft of PPP over L2TP Done - Submit final Internet-Draft of L2TPv3 Base Specification to IESG Done - Submit Internet-Draft of HDLC over L2TPv3 to IESG Done - Submit Internet-Draft of Frame Relay over L2TPv3 to IESG Done - Submit L2VPN Extensions for L2TP to IESG Done - Submit Internet-Draft of Ethernet over L2TPv3 to IESG Done - WG Last Call on L2TP Failover Done - WG Last Call on L2TP Tunnel Switching Mar 2008 - WG Last Call on L2TP Proxy Authenticate Extensions for EAP Mar 2008 - Submit Internet-Draft of PPP over L2TPv3 to IESG Mar 2008 - WG Last Call on L2TP Tunnel Switching Jun 2008 - WG Last Call on L2TP RADIUS and Infomsg Extensions Done - WG Last Call on TDM over L2TPv3 Jun 2008 - WG Last Call on IP over L2TPv3 Internet-Drafts: - Layer Two Tunneling Protocol 'L2TP' Management Information Base [draft-ietf-pppext-l2tp-mib-05] (68 pages) - Securing L2TP using IPSEC [draft-ietf-pppext-l2tp-security-05] (14 pages) - Layer Two Tunneling Protocol ''L2TP'' IP Differential Services Extension [draft-ietf-pppext-l2tp-ds-03] (5 pages) - Layer Two Tunneling Protocol ''L2TP'' Multi-Protocol Label Switching Extension [draft-ietf-pppext-l2tp-mpls-02] (5 pages) - Layer Two Tunneling Protocol (L2TP) over Frame Relay [draft-ietf-pppext-l2tp-fr-02] (7 pages) - L2TP Over AAL5 and FUNI [draft-ietf-pppext-l2tp-atm-02] (11 pages) - Layer Two Tunnelling Protocol : ATM access network extensions. [draft-ietf-pppext-l2tp-atmext-01] (14 pages) - L2TP Alternate Data Channel ('ADC') [draft-ietf-l2tpext-adc-00] (4 pages) - L2TP Session Information (``SESINFO'') [draft-ietf-l2tpext-sesinfo-04] (4 pages) - Layer Two Tunnelling Protocol : ATM access network extensions [draft-ietf-l2tpext-atmext-04] (19 pages) - L2TP Over AAL5 [draft-ietf-l2tpext-l2tp-atm-03] (12 pages) - Layer-Two Tunneling Protocol (L2TP) Extensions for PPP Link Control P[rotocol (LCP) Negotiation [draft-ietf-l2tpext-link-07] (10 pages) - L2TP Header Compression ('L2TPHC') [draft-ietf-l2tpext-l2tphc-06] (7 pages) - Securing L2TP using IPSEC [draft-ietf-l2tpext-security-08] (27 pages) - L2TP IP Differentiated Services Extension [draft-ietf-l2tpext-ds-05] (10 pages) - Layer Two Tunneling Protocol 'L2TP' Multi-Protocol Label Switching Extension [draft-ietf-l2tpext-mpls-00] (5 pages) - Layer Two Tunneling Protocol 'L2TP' Management Information Base [draft-ietf-l2tpext-l2tp-mib-04] (86 pages) - L2TP Disconnect Cause Information [draft-ietf-l2tpext-ppp-discinfo-04] (9 pages) - Layer Two Tunneling Protocol (L2TP) over Frame Relay [draft-ietf-l2tpext-fr-01] (7 pages) - Layer Two Tunneling Protocol 'L2TP' [draft-ietf-l2tpext-l2tpbis-01] (77 pages) - L2TP Service Type [draft-ietf-l2tpext-svctype-01] (7 pages) - Ethernet Service Type for Layer Two Tunneling Protocol [draft-ietf-l2tpext-eth-00] (6 pages) - Extensions to support efficient carrying of multicast traffic in Layer-2 Tunneling Protocol (L2TP) [draft-ietf-l2tpext-mcast-06] (25 pages) - L2TP Active Discovery Relay for PPPoE [draft-dasilva-l2tp-relaysvc-09] (16 pages) - Layer Two Tunneling Protocol (Version 3) [draft-ietf-l2tpext-l2tp-base-16] (93 pages) - PPP Tunneling Using Layer Two Tunneling Protocol Version 3 (L2TPv3) [draft-ietf-l2tpext-l2tp-ppp-08] (44 pages) - PPP over L2TP Tunnel Switching [draft-ietf-l2tpext-tunnel-switching-08] (16 pages) - Frame-Relay over L2TPv3 [draft-ietf-l2tpext-pwe3-fr-08] (14 pages) - L2TP IANA Considerations Update [draft-ietf-l2tpext-rfc2661-iana-01] (5 pages) - Fail Over extensions for L2TP "failover" [draft-ietf-l2tpext-failover-13] (22 pages) - Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP) [draft-ietf-l2tpext-v92-moh-05] (13 pages) - HDLC Frames over L2TPv3 [draft-ietf-l2tpext-pwe3-hdlc-08] (12 pages) - Layer Two Tunneling Protocol : ATM Access Network Extensions [draft-ietf-l2tpext-atmext-rfc3301-bis-00] (18 pages) - Layer Two Tunneling Protocol (Version 3) "L2TPv3" Management Information Base [draft-ietf-l2tpext-l2tpmib-base-02] (55 pages) - Transport of Ethernet Frames over L2TPv3 [draft-ietf-l2tpext-pwe3-ethernet-10] (15 pages) - L2VPN Extensions for L2TP [draft-ietf-l2tpext-l2vpn-08] (15 pages) - ATM over L2TPv3 [draft-ietf-l2tpext-pwe3-atm-05] (21 pages) - Layer Two Tunneling Protocol version 3 - Setup of Time-Division Multiplexing (TDM) Pseudowires [draft-ietf-l2tpext-tdm-08] (10 pages) - Signaling and Encapsulation for the Transport of IP over L2TPv3 [draft-ietf-l2tpext-pwe3-ip-05] (20 pages) - L2TP Proxy Authenticate Extensions for EAP [draft-ietf-l2tpext-proxy-authen-ext-eap-02] (11 pages) - RADIUS & L2TP Extended NAS-Port AVPs [draft-ietf-l2tpext-radius-ext-nas-port-02] (14 pages) - L2TPv3 Extended Circuit Status Values [draft-ietf-l2tpext-circuit-status-extensions-06] (12 pages) - Layer Two Tunneling Protocol - Setup of TDM Pseudowires [draft-ieft-l2tpext-tdm-04] (8 pages) Requests for Comments: RFC3070: Layer Two Tunneling Protocol (L2TP) over Frame Relay (7 pages) RFC3145: L2TP Disconnect Cause Information (10 pages) RFC3193: Securing L2TP using IPSEC (28 pages) RFC3301: Layer Two Tunnelling Protocol : ATM access network extensions (19 pages) RFC3355: L2TP Over AAL5 (13 pages) RFC3371: Layer Two Tunneling Protocol 'L2TP' Management Information Base (70 pages) RFC3308: L2TP IP Differentiated Services Extension (10 pages) RFC3438: L2TP IANA Considerations Update (5 pages) RFC3437: Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation (10 pages) RFC3573: Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP) (13 pages) RFC3817: L2TP Active Discovery Relay for PPPoE (16 pages) RFC3931: Layer Two Tunneling Protocol (Version 3) (93 pages) * Updated by RFC5641 RFC4045: Extensions to support efficient carrying of multicast traffic in Layer-2 Tunneling Protocol (L2TP) (25 pages) RFC4349: High-Level Data Link Control (HDLC) Frames over Layer 2 Tunneling Protocol, Version 3 (L2TPv3) (12 pages) * Updated by RFC5641 RFC4454: Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3) (21 pages) * Updated by RFC5641 RFC4591: Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3) (14 pages) * Updated by RFC5641 RFC4667: Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP) (15 pages) RFC4719: Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3) (15 pages) * Updated by RFC5641 RFC4951: Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) (22 pages) RFC5611: Layer Two Tunneling Protocol version 3 - Setup of Time-Division Multiplexing (TDM) Pseudowires (10 pages) RFC5641: Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values (12 pages) * Updates RFC3931 * Updates RFC4349 * Updates RFC4454 * Updates RFC4591 * Updates RFC4719 Layer 2 Virtual Private Networks (l2vpn) ---------------------------------------- Charter Last Modified: 2009-10-19 Current Status: Active Chairs: Shane Amante Giles Heron Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Tech Advisor: Alex Zinin Mailing Lists: General Discussion: l2vpn@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/l2vpn Archive: http://www.ietf.org/mail-archive/web/l2vpn/current/maillist.html Description of Working Group: The L2VPN working group is responsible for defining and specifying a limited number of solutions for supporting provider-provisioned Layer-2 Virtual Private Networks (L2VPNs). Layer-2 VPN's comprise the following: 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that emulates an Ethernet (V)LAN across an IP or an MPLS-enabled IP Packet Switched Network (PSN). 2. Virtual Private Wire Service (VPWS) -- A Layer 2 service that provides point-to-point connectivity for a variety of link layers, including Frame Relay, ATM, Ethernet, PPP, etc., across an IP or MPLS-enabled IP PSN. 3. Virtual Private Multicast Service (VPMS) -- A Layer 2 service that Provides point-to-multipoint connectivity for a variety of link layers, including Frame Relay, ATM, Ethernet, PPP, etc., across an IP or MPLS-enabled IP PSN. 4. IP-only L2VPN -- A point-to-point or point-to-multipoint "IP-only" service over an IP or MPLS-enabled PSN. This service is similar to VPWS because it supports a variety of link-layer protocols on the Attachment Circuits, including Frame Relay, ATM, Ethernet, PPP, etc. IP-only L2VPN's are different from both VPLS and VPWS because unicast Layer-2 frames containing IP data packets, either IPv4 or IPv6, are de- encapsulated leaving only the IP data packet to be transmitted over the PSN. An IP-only L2VPN service also differs from L3VPN service, since no routing protocol operates between the PE and CE; furthermore, connectivity from CE to CE is provided via an emulated Layer-2 service over the PSN, which results in the CE's appearing to be directly attached to each other at Layer-2. The WG will address two specific types of IP-only L2VPN: a) Those with Attachment Circuits (ACs) that use the same Layer 2 framing at all attachment points in the same L2VPN; and, b) Those with ACs that use different Layer 2 framing at various attachment points in the same L2VPN. For (b), inter-working between link-layers is strictly out of scope beyond that which is minimally necessary to ensure that IP packets are transported from an AC of one type, across the IP or MPLS-enabled IP PSN, and to an AC of another type in as transparent a manner as possible to the CEs on both sides of the service. VPLS, VPWS and VPMS operate over Pseudowires (PWs) as defined by the PWE3 WG. As with a single PW, an L2VPN emulates a "native" service over a PSN that is reasonably faithful to, but may not be entirely indistinguishable from, the native service itself. Further, following in the "edge-to-edge" nature of the PWs that it uses, the L2VPN WG will not define any new mechanisms which exert control over the underlying PSN. When necessary it may, however, recommend or require the use of existing PSN QoS and path control mechanisms between PW endpoints which make up the L2VPN. L2VPN's will make use of existing IETF specified mechanisms unless there are technical reasons why the existing mechanisms are insufficient or unnecessary. The L2VPN WG is responsible for specification of the discovery and membership of PE's participating in a VPLS, VPWS or IP-only L2VPN as well as the membership of CE devices to a specific instance of a L2VPN. The L2VPN WG will provide extensions of existing protocols that will be discussed in protocol-specific WG's. In particular, the L2VPN WG may define extensions to pseudowire management mechanisms (including OAM), specifically Pseudowire Virtual Circuit Connectivity Verification (VCCV), for VPLS. Those VCCV extensions will be reviewed by PWE3 to ensure they are inline with the overall design/architecture of VCCV and MPLS. The L2VPN WG will not define new encapsulations, control (set-up, configuration, maintenance or tear-down), or resiliency mechanisms specifically related to pseudowires, because those must be defined by the PWE3 WG. Furthermore, the L2VPN WG will not define protocol inter- working between a VPLS or VPWS and native service-layer control, OAM or or resiliency mechanisms, as those will be defined by the PWE3 WG. On the other hand, the L2VPN WG may define how to operate native service- layer control, IEEE 802.1 OAM or resiliency mechanisms on top of a VPLS or VPWS service. The L2VPN WG scope includes the following: 1. Discovery of PE's participating in a Layer-2 VPN and the associated topology required for connectivity of the VPLS or VPWS service. 2. Signaling of information related to the discovery and membership of PE's within a L2VPN. These procedures must use PWE3 control and management procedures, or define requirements for extensions of PWE3 protocols to suit the needs of an L2VPN. Once those requirements are reviewed by the L2VPN WG, they should be provided to the PWE3 WG to derive solutions. 3. MIB's for Layer-2 VPN solutions. 4. Specification of requirements and framework that will define Operations Administration and Management (OAM) procedures for VPLS and VPWS VPN's, related to the operation of VPLS and VPWS VPN's over IP/MPLS PSN's. In addition, the L2VPN WG will define OAM solutions for VPLS and VPWS VPN's. 5. Mechanisms to permit optimization of multicast data traffic within a VPLS or VPWS VPN over an IP/MPLS PSN. 6. Improved service convergence for multi-homed CE's to VPLS PE's. Specifically, upon failure of a primary path from a CE to VPLS PE, initiate a rapid switch-over to an alternate path. If required, interactions with native service-layer resiliency mechanisms will be provided via solutions from other IETF WG's such as PWE3. 7. Enhancements to increase the scalability of the Control Plane and Data Plane (e.g.: number of PW's and MAC Forwarding Database, respectively) of VPLS PE nodes. 8. Define requirements and solutions for Auto-Discovery and Signaling of Inter-AS VPLS and VPWS L2VPN's, in addition to Inter-AS solutions for multicast-optimized VPLS and VPMS Layer-2 VPN's. The L2VPN WG currently works on the following tasks: - Define MIB's appropriate for each type of Layer-2 VPN. - Specification of Operations Administration and Management (OAM) mechanisms for VPLS, VPWS and IP-only VPN's. - Specification of procedures to permit optimization of L2VPN multicast data traffic within the PSN. - Define enhancements to increase scalability of VPLS PE nodes, to provide aggregation of learned customer MAC addresses at VPLS PE's. - Identify requirements for multi-homing of CE's to VPLS PE's. elements. Based on these requirements, define solutions for achieving fast convergence after a switchover to an alternate path, for example through optimized MAC flushing within a VPLS domain. - Identify requirements for Inter-AS VPLS and VPWS services. Define Inter-AS enhancements to VPLS and VPWS based on these requirements. - Include extensions to L2VPN protocols and RFC's necessary to create an MPLS Transport Profile (MPLS-TP). The work on the MPLS TP needs to be coordinated between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) that are chartered to do MPLS TP work. Where necessary, the WG will coordinate its activities with IEEE 802.1 and ITU. Goals and Milestones: Done - Submit an I-D describing MIB for VPLS Done - Submit an I-D describing MIB for VPWS Done - Submit an I-D on OAM requirements for VPLS Done - Submit an I-D on OAM requirements for VPWS Done - Submit L2 requirements to IESG for publication as Informational RFC Done - Submit L2 framework to IESG for publication as Informational RFC Done - Identify VPLS and VPWS solutions for the WG Done - Submit VPLS solution documents to IESG Done - Submit VPWS solution documents to IESG Done - Submit Auto-Discovery and Signaling for Intra-AS and Inter-AS VPLS and VPWS Layer-2 VPN's Nov 2008 - Submit IP-only L2VPN solution documents to IESG Mar 2009 - Submit OAM solutions for VPWS to IESG Mar 2009 - Submit OAM solutions for VPLS to IESG Mar 2009 - Submit signaling solution for multicast-optimized VPLS to IESG Mar 2009 - Submit I-D on Virtual Private Multicast Service (VPMS) requirements to IESG Mar 2009 - Submit PIM snooping solution for VPLS to IESG Mar 2009 - Submit OAM solutions for IP-only L2VPN to IESG Jul 2009 - Submit MIB for VPLS to IESG Jul 2009 - Submit MIB for VPWS to IESG Jul 2009 - Submit MIB for IP-only L2VPN to IESG Nov 2009 - Submit scalability solutions for VPLS Data-Plane to IESG Nov 2009 - Submit scalability solutions for VPLS Control-Plane to IESG Nov 2009 - Submit Auto-Discovery solution for VPMS to IESG Jul 2010 - Submit VPLS service convergence improvement solutions to IESG Jul 2010 - Submit VPLS multi-homing solutions to IESG Internet-Drafts: - Requirements for Virtual Private LAN Services (VPLS) [draft-ietf-l2vpn-vpls-requirements-00] (16 pages) - Framework for Layer 2 Virtual Private Networks (L2VPNs) [draft-ietf-l2vpn-l2-framework-06] (45 pages) - Service Requirements for Layer 2 Provider Provisioned Virtual Private Networks [draft-ietf-l2vpn-requirements-08] (26 pages) - Virtual Private LAN Service (VPLS) Using BGP for Auto-discovery and Signaling [draft-ietf-l2vpn-vpls-bgp-09] (37 pages) - Virtual Private LAN Services Using LDP [draft-ietf-l2vpn-vpls-ldp-10] (27 pages) - Provisioning, Autodiscovery, and Signaling in L2VPNs [draft-ietf-l2vpn-signaling-08] (39 pages) - IP-Only LAN Service (IPLS) [draft-ietf-l2vpn-ipls-08] (23 pages) - Radius/L2TP Based VPLS [draft-ietf-l2vpn-l2tp-radius-vpls-00] (9 pages) - Using RADIUS for PE-Based VPN Discovery [draft-ietf-l2vpn-radius-pe-discovery-02] (18 pages) - L2VPN OAM Requirements and Framework [draft-ietf-l2vpn-oam-req-frmk-10] (36 pages) - ARP Mediation for IP Interworking of Layer 2 VPN [draft-ietf-l2vpn-arp-mediation-12] (30 pages) - VPLS Applicability [draft-ietf-l2vpn-vpls-ldp-applic-00] (20 pages) - OAM Procedures for VPWS Interworking [draft-ietf-l2vpn-vpws-iw-oam-01] (24 pages) - Requirements for Multicast Support in Virtual Private LAN Services [draft-ietf-l2vpn-vpls-mcast-reqts-08] (31 pages) - Multicast in VPLS [draft-ietf-l2vpn-vpls-mcast-05] (44 pages) - VPLS Interoperability with CE Bridges [draft-ietf-l2vpn-vpls-bridge-interop-04] (19 pages) - PIM Snooping over VPLS [draft-ietf-l2vpn-vpls-pim-snooping-01] (37 pages) - Virtual Private Lan Services (VPLS) Management Information Base [draft-ietf-l2vpn-vpls-mib-02] (41 pages) - Framework and Requirements for Virtual Private Multicast Service (VPMS) [draft-ietf-l2vpn-vpms-frmwk-requirements-02] (26 pages) - Extensions to VPLS PE model for Provider Backbone Bridging [draft-ietf-l2vpn-pbb-vpls-pe-model-00] (14 pages) - LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS [draft-ietf-l2vpn-vpls-ldp-mac-opt-00] (16 pages) - VPLS Interoperability with Provider Backbone Bridges [draft-ietf-l2vpn-vpls-pbb-interop-00] (23 pages) Requests for Comments: RFC4665: Service Requirements for Layer 2 Provider Provisioned Virtual Private Networks (26 pages) RFC4664: Framework for Layer 2 Virtual Private Networks (L2VPNs) (45 pages) RFC4762: Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling (27 pages) RFC4761: Virtual Private LAN Service (VPLS) Using BGP for Auto-discovery and Signaling (37 pages) * Updated by RFC5462 RFC5501: Requirements for Multicast Support in Virtual Private LAN Services (31 pages) Layer 3 Virtual Private Networks (l3vpn) ---------------------------------------- Charter Last Modified: 2009-10-07 Current Status: Active Chairs: Danny McPherson Marshall Eubanks Ben Niven-Jenkins Routing Area Directors: Ross Callon Adrian Farrel Routing Area Advisor: Ross Callon Secretary: Daniel King Mailing Lists: General Discussion: l3vpn@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/l3vpn Archive: http://www.ietf.org/mail-archive/web/l3vpn/current/maillist.html Description of Working Group: This working group is responsible for defining and specifying a limited number of solutions for supporting provider-provisioned Layer-3 (routed) Virtual Private Networks (L3VPNs). The WG is responsible for standardization of the following solutions: 1. BGP/MPLS IP VPNs (based on RFC 2547) 2. IP VPNs using Virtual Routers 3. CE-based VPNs using IPsec The following VPN deployment scenarios will be considered by the WG: 1. Internet-wide: VPN sites attached to arbitrary points in the Internet 2. Single service provider (SP)/single AS: VPN sites attached to the network of a single provider within the scope of a single AS 3. Single SP/multiple AS'es: VPN sites attached to the network of a single provider consisting of multiple AS'es 4. Cooperating SPs: VPN sites attached to networks of different providers that cooperate with each other to provide VPN service The WG will address deployment of the following features in a VPN environment: 1. IP Multicast 2. IPv6 As part of this effort the WG will work on the following tasks (additional work items will require rechartering): 1. Requirements and framework for Layer 3 VPNs 2. Solution documents for each approach listed above (including applicability statements) 3. MIB definitions for each approach 4. Security mechanisms for each approach As a general rule, the WG will not create new protocols, but will provide functional requirements for extensions of the existing protocols that will be discussed in the protocol-specific WGs. L3VPN WG will review proposed protocol extensions for L3VPNs before they are recommended to appropriate protocol-specific WGs. As stated above, the WG will define an IPv6 over BGP / MPLS VPN solution. This will include a forwarding plane component and a control plane component. In the forwarding plane, IPv6 datagrams will be encapsulated within an MPLS header. If any aspect of IPv6 forwarding over MPLS is as yet undefined, the L3VPN WG will defer to the MPLS and appropriate IPv6 WGs. On the control plane, BGP extensions may also need to be defined. In this respect, the L3VPN WG will defer to the IDR and appropriate IPv6 WGs. QoS support is excluded from the charter at this time. It may be considered for inclusion in an updated charter at a later time. Future work items may also include OAM support. Goals and Milestones: Done - Submit L3 VPN Requirements Document to IESG for publication as Info Done - Submit Generic Requirements Document to IESG for publication as Info Done - Submit L3 VPN Framework Document to IESG for publication as Info Done - Submit VPN Security Analysis to IESG for publication as Info (draft-fang-ppvpn-security-framework-00) Done - Submit BGP/MPLS VPNs specification and AS to IESG for publication as PS (draft-ietf-ppvpn-rfc2547bis-03, draft-ietf-ppvpn-as2547-01) Done - Submit CE-based specification and AS to IESG for publication as PS (draft-ietf-ppvpn-ce-based-03, draft-declercq-ppvpn-ce-based-sol-00, draft-declercq-ppvpn-ce-based-as-01) Done - Submit Virtual Router specification and AS to IESG for publication as PS (draft-ietf-ppvpn-vpn-vr-03, draft-ietf-ppvpn-as-vr-01) Done - Submit BGP as an Auto-Discovery Mechanism for publication as PS (draft-ietf-ppvpn-bgpvpn-auto-05.txt) Done - Submit specification of using GRE for PE-PE encapsulation in BGP/MPLS VPNs to IESG for publication as PS (draft-ietf-ppvpn-gre-ip-2547-02) Done - Submit VPN MIB Textual Conventions to IESG for publication as PS (draft-ietf-ppvpn-tc-mib-02) Done - Submit MPLS/BGP VPN MIB to IESG for publication as PS (draft-ietf-ppvpn-mpls-vpn-mib-05) Done - Submit VR MIB to IESG for publication as PS (draft-ietf-ppvpn-vr-mib-04) Done - Submit specification of using IPSEC for PE-PE encapsulation in BGP/MPLS VPNs to IESG for publication as PS (draft-ietf-ppvpn-ipsec-2547-03) Done - Submit specification of OSPF as the PE/CE Protocol in BGP/MPLS VPNs for publication (draft-ietf-l3vpn-ospf-2547-xx.txt) Done - Submit specification of IPv6 over BGP/MPLS VPNs for publication Feb 2008 - Submit specification of IPv4 multicast over BGP/MPLS VPNs for publication Internet-Drafts: - Service requirements for Layer 3 Virtual Private Networks [draft-ietf-l3vpn-requirements-03] (44 pages) - A Framework for Layer 3 Provider Provisioned Virtual Private Networks [draft-ietf-l3vpn-framework-01] (80 pages) - An Architecture for Provider Provisioned CE-based Virtual Private Networks using IPsec [draft-ietf-l3vpn-ce-based-04] (26 pages) - BGP-MPLS IP VPN extension for IPv6 VPN [draft-ietf-l3vpn-bgp-ipv6-08] (18 pages) - MPLS/BGP Layer 3 Virtual Private Network Management Information Base [draft-ietf-l3vpn-mpls-vpn-mib-08] (42 pages) - BGP/MPLS IP VPNs [draft-ietf-l3vpn-rfc2547bis-04] (49 pages) - Architecture for the Use of PE-PE IPsec Tunnels in BGP/MPLS IP VPNs [draft-ietf-l3vpn-ipsec-2547-05] (18 pages) - OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP VPNs [draft-ietf-l3vpn-ospf-2547-07] (26 pages) - Use of PE-PE GRE or IP in BGP/MPLS IP Virtual Private Networks [draft-ietf-l3vpn-gre-ip-2547-06] (14 pages) - Using BGP as an Auto-Discovery Mechanism for VR-based Layer-3 VPNs [draft-ietf-l3vpn-bgpvpn-auto-10] (12 pages) - Network based IP VPN Architecture Using Virtual Routers [draft-ietf-l3vpn-vpn-vr-04] (24 pages) - Virtual Router Management Information Base Using SMIv2 [draft-ietf-l3vpn-vr-mib-05] (24 pages) - Definition of Textual Conventions for Virtual Private Network (VPN) Management [draft-ietf-l3vpn-tc-mib-07] (6 pages) - Applicability Statement for BGP/MPLS IP VPNs [draft-ietf-l3vpn-as2547-08] (32 pages) - Guidelines of Applicability Statements for PPVPNs [draft-ietf-l3vpn-applicability-guidelines-00] (10 pages) - Applicability Statement for Virtual Router-based Layer 3 PPVPN Approaches [draft-ietf-l3vpn-as-vr-03] (28 pages) - CE-to-CE Member Verification for Layer 3 VPNs [draft-ietf-l3vpn-auth-00] (0 pages) - Generic Requirements for Provider Provisioned Virtual Private Networks [draft-ietf-l3vpn-generic-reqts-04] (26 pages) - Security Framework for Provider Provisioned Virtual Private Networks [draft-ietf-l3vpn-security-framework-04] (43 pages) - Framework for L3VPN Operations and Management [draft-ietf-l3vpn-mgt-fwk-09] (26 pages) - CE-to-CE Member Verification for Layer 3 VPNs [draft-ietf-l3vpn-l3vpn-auth-01] (16 pages) - Applicability Statement for Provider Provisioned CE-based Virtual Private Networks using IPsec [draft-declercq-l3vpn-ce-based-as-01] (30 pages) - Provider Provissioned VPN terminology [draft-ietf-l3vpn-ppvpn-terminology-05] (26 pages) - Constrained VPN Route Distribution [draft-ietf-l3vpn-rt-constrain-03] (19 pages) - Requirements for Multicast in L3 Provider-Provisioned VPNs [draft-ietf-l3vpn-ppvpn-mcast-reqts-11] (45 pages) - Layer-3 VPN Import/Export Verification [draft-ietf-l3vpn-vpn-verification-00] (11 pages) - Multicast in MPLS/BGP IP VPNs [draft-ietf-l3vpn-2547bis-mcast-08] (96 pages) - BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs [draft-ietf-l3vpn-2547bis-mcast-bgp-08] (61 pages) - OSPFv3 as a PE-CE routing protocol [draft-ietf-l3vpn-ospfv3-pece-03] (21 pages) - Requirements for supporting Customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN [draft-ietf-l3vpn-e2e-rsvp-te-reqts-04] (24 pages) - Four-octet AS Specific BGP Extended Community [draft-ietf-l3vpn-as4octet-ext-community-04] (5 pages) - IPv6 Address Specific BGP Extended Communities Attribute [draft-ietf-l3vpn-v6-ext-communities-02] (5 pages) - BGP ACCEPT_OWN Standards Action Community Attribute [draft-ietf-l3vpn-acceptown-community-01] (9 pages) - Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution [draft-ietf-l3vpn-mvpn-considerations-05] (39 pages) Requests for Comments: RFC3809: Generic Requirements for Provider Provisioned Virtual Private Networks (26 pages) RFC4026: Provider Provisioned Virtual Private Network (VPN) Terminology (26 pages) RFC4031: Service requirements for Layer 3 Provider Provisioned Virtual Private Networks (44 pages) RFC4110: A Framework for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs) (80 pages) RFC4111: Security Framework for Provider Provisioned Virtual Private Networks (PPVPNs) (43 pages) RFC4176: Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management (26 pages) RFC4265: Definition of Textual Conventions for Virtual Private Network (VPN) Management (6 pages) RFC4364: BGP/MPLS IP Virtual Private Networks (VPNs) (49 pages) * Obsoletes RFC2547 * Updated by RFC4577 * Updated by RFC4684 * Updated by RFC5462 RFC4365: Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs) (32 pages) RFC4382: MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base (42 pages) RFC4577: OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) (26 pages) * Updates RFC4364 RFC4659: BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN (18 pages) RFC4684: Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protcol (IP) Virtual Private Networks (VPNs) (19 pages) * Updates RFC4364 RFC4797: Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks (14 pages) RFC4834: Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private (PPVPNs) (45 pages) RFC5668: 4-Octet AS Specific BGP Extended Community (5 pages) Low Extra Delay Background Transport (ledbat) --------------------------------------------- Charter Last Modified: 2009-08-10 Current Status: Active Chairs: Stanislav Shalunov Murari Sridhavan Transport Area Directors: Magnus Westerlund Lars Eggert Transport Area Advisor: Lars Eggert Mailing Lists: General Discussion: ledbat@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ledbat Archive: http://www.ietf.org/mail-archive/web/ledbat Description of Working Group: The LEDBAT WG is chartered to standardize a congestion control mechanism that should saturate the bottleneck, maintain low delay, and yield to standard TCP. Applications that transmit large amounts of data for a long time with congestion-limited TCP, but without AQM, fill the buffer at the head of the bottleneck link. With FIFO queue, this increases the delay experienced by other applications. With buffer of one RTT, the delay doubles. In some cases, the extra delay may be much larger. This is a particularly acute and common case is when P2P applications upload over thin home uplinks: delays in these cases can sometimes be of the order of seconds. The IETF's standard end-to-end transport protocols have not been designed to minimize the extra delay introduced by them into the network. TCP, as a side effect of filling the buffer until it experiences drop-tail loss, effectively maximizes the delay. While this works well for applications that are not delay-sensitive, it harms interactive applications that share the same bottleneck. VoIP and games are particularly affected, but even web browsing may become problematic. LEDBAT is a transport-area WG that will focus on broadly applicable techniques that allow large amounts of data to be consistently transmitted without substantially affecting the delays experienced by other users and applications. The WG will work on the following: (1) An experimental congestion control algorithm for less-than-best-effort "background" transmissions, i.e., an algorithm that attempts to scavenge otherwise idle bandwidth for its transmissions in a way that minimizes interference with regular best-effort traffic. Desired features of such an algorithm are: * saturate the bottleneck * eliminate long standing queues and thus keep delay low when no other traffic is present * quickly yield to traffic sharing the same bottleneck queue that uses standard TCP congestion control * add little to the queueing delays induced by TCP traffic * operate well in networks with FIFO queueing with drop-tail discipline * be deployable for popular applications that currently comprise noticeable fractions of Internet traffic * where available, use explicit congestion notification (ECN), active queue management (AQM), and/or end-to-end differentiated services (DiffServ). Application of this algorithm to existing transport protocols (TCP, SCTP, DCCP) is expected to occur in the working groups that maintain those protocols. Once experience is gained with this congestion control algorithm on the Internet, the WG will consider if it is appropriate to ask the IESG to advance the document as a Proposed Standard. (2) A document that clarifies the current practices of application design and reasons behind them and discusses the tradeoffs surrounding the use of many concurrent TCP connections to one destination and/or to different destinations. Applications routinely open multiple TCP connections. For example, P2P applications maintain connections to a number of different peers while web browsers perform concurrent downloads from the same web server. Application designers pursue different goals when doing so: P2P apps need to maintain a well-connected mesh in the swarm while web browsers mainly use multiple connections to parallelize requests that involve application latency on the web server side. The IETF transport area community is concerned about this practice, because standard Internet congestion control results in different transport connections sharing bottleneck capacity. When an application uses several non-rate-limited transport connections to transfer through a bottleneck, it may obtain a larger fraction of the bottleneck than if it had used fewer connections. Although capacity is the most commonly considered bottleneck resource, middlebox state table entries are also an important resource for an end system communication. Other resource types may exist, and the guidelines are expected to comprehensively discuss them. Applications use a variety of techniques to mitigate these concerns. These techniques have not always been reviewed by the IETF and their interaction with TCP dynamics is poorly understood. The WG will document the known techniques, discussing the consequences and, where appropriate, provide guidance to application designers. Goals and Milestones: Oct 2009 - Submit 'Multiple Transport Connections in Applications Design' to the IESG for consideration as an Informational RFC Oct 2009 - Submit 'Low Extra Delay Background Transport (LEDBAT)' to the IESG for consideration as an Experimental RFC Feb 2010 - Submit 'A Survey of Lower-than-Best Effort Transport Protocols' to the IESG for consideration as an Informational RFC Internet-Drafts: - Low Extra Delay Background Transport (LEDBAT) [draft-ietf-ledbat-congestion-00] (12 pages) No Requests for Comments Enhancements to Internet email to Support Diverse Service Environments (lemonade) --------------------------------------------------------------------------------- Charter Last Modified: 2009-08-20 Current Status: Active Chairs: Glenn Parsons Eric Burger Applications Area Directors: Lisa Dusseault Alexey Melnikov Applications Area Advisor: Alexey Melnikov Secretary: Alexey Melnikov Mailing Lists: General Discussion: lemonade@ietf.org To Subscribe: lemonade-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/lemonade/index.html Description of Working Group: Lemonade is tasked to provide a set of enhancements and profiles of Internet email submission, transport, and retrieval protocols to facilitate operation on platforms with constrained resources, or communications links with high latency or limited bandwidth. A primary goal of this work is to ensure that those profiles and enhancements continue to interoperate with the existing Internet email protocols in use on the Internet, so that these environments and more traditional Internet users have access to a seamless service. Lemonade's work is at the crossroads of a body of work related to Internet messaging, in particular work done by the VPIM, FAX, and IMAPEXT IETF working groups. Given the potentially broad scope of activities this group could engage in, the group will focus specifically on the following work items: 0. An informational RFC or RFCs will be produced on LEMONADE architecture and the issues it seeks to address. 1. Enhance the existing IMAP4 message retrieval and message submission (RFC 2476) protocols to satisfy the requirements for handling streaming multimedia content. The existing standards-track CONNEG framework will be used if content negotiation capabilities are needed. The group will employ existing protocols (such as for streaming) with IMAP4 instead of duplicating such functionality within IMAP4. 2. Enhance the existing IMAP4 message retrieval and/or message submission (RFC 2476) protocols to satisfy the requirements for forwarding a message and/or its attachments without downloading the message to the client and subsequently uploading the message to a server. 3. Refine the existing IMAP4 message retrieval protocol to facilitate its use with devices that have limited capabilities such as mobile endpoints. At most one backwards compatible profile of IMAP4 will be produced by this effort. 4. Define a format for message notifications for servers reporting message status information to other servers. Specify the method for delivery of those notifications. 5. Create a specification describing the use of Internet message services in environments where message delivery may take place using either Internet protocols or through an MMS server using WAP to communicate with the receiving user agent. Any protocols defined by this working group will include appopriate security mechanisms, including authentication, privacy, and access control. Mandatory-to-implement security mechanisms will be specified as needed in order to guarantee secure protocol interoperability. The transport area will be consulted to deal with any transport-related issues that arise, especially in regards to items 1-4 above. The IAB is currently working on the specification of general guidelines and requirements for notification services. Once complete this work will be used as input to item 4 above. The working group is aware of several related activities in other groups: - 3GPP TSG T WG2 SWG3 Messaging - W3C Mulitmodal interaction Activity - Open Mobile Alliance - 3GPP2 TSG-X The goal is to coordinate efforts with at least these groups as required. While there is obvious synergy, given the end-of-life of the VPIM and FAX work groups and the similar membership, the working group does not expect to coordinate with these other groups. Goals and Milestones: Done - Submit LEMONADE goals and use-cases specification to the IESG Done - Submit server to server notification requirements to the IESG Done - Submit translation to other messaging systems to the IESG Done - Submit IMAP/SUBMIT extensions for forward without download to IESG Done - Submit IMAP4 profile for mobile devices to the IESG Done - Submit IMAP COMPRESS Extension to the IESG Done - Submit Deployment Considerations to the IESG Done - Submit IMAP WITHIN Search extension to the IESG Done - Submit SASL-IR IMAP4 extension to the IESG Done - Submit IMAP CONVERT extension to the IESG Done - Submit Quick Reconnect extension to the IESG Done - Submit Update to RFC 2192 (IMAP URL) to the IESG Done - Submit Message Events to IESG Done - Submit contextual mailboxes extension to the IESG Done - Submit Body Conversions to IESG Done - Submit IMAP Sieve Extensions to IESG Done - Submit URLFETCH BINARY Extension to the IESG Done - Submit Notification Format to the IESG Done - Submit IMAP NOTIFY Extension to the IESG Done - Submit Notification Architecture to the IESG Done - Submit IMAP4 extensions for streaming multimedia to the IESG Done - Submit Profile bis document to the IESG Internet-Drafts: - IMAP Submit Without Download [draft-ietf-lemonade-submit-01] (14 pages) - IMAP4 Channel Transport Mechanism [draft-ietf-lemonade-imap-channel-02] (9 pages) - Goals for Internet Messaging to Support Diverse Service Environments [draft-ietf-lemonade-goals-06] (51 pages) - Internet Message Access Protocol (IMAP) CATENATE Extension [draft-ietf-lemonade-catenate-06] (11 pages) - Server To Server Notification Protocol Requirements [draft-ietf-lemonade-notify-s2s-00] (10 pages) - Lemonade Server to Client Notifications [draft-ietf-lemonade-server-to-client-notifications-00] (20 pages) - Internet Message Access Protocol (IMAP) - URLAUTH Extension [draft-ietf-lemonade-urlauth-09] (5 pages) - Lemonade Profile [draft-ietf-lemonade-profile-08] (18 pages) - IMAP Conventions for Message Context [draft-ietf-lemonade-msg-context-00] (5 pages) - IMAP4 Extensions for Quick Reconnect [draft-ietf-lemonade-reconnect-07] (24 pages) - Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail [draft-ietf-lemonade-mms-mapping-07] (34 pages) - SMTP Submission Service Extension for Future Message Release [draft-ietf-lemonade-futuredelivery-04] (12 pages) - Message Submission BURL Extension [draft-ietf-lemonade-burl-05] (14 pages) - Persistent Virtual Folder extension to the IMAP Protocol [draft-ietf-lemonade-vfolder-01] (12 pages) - WITHIN Search extension to the IMAP Protocol [draft-ietf-lemonade-search-within-06] (5 pages) - The IMAP COMPRESS Extension [draft-ietf-lemonade-compress-09] (9 pages) - Lemonade Notifications Architecture [draft-ietf-lemonade-notifications-11] (17 pages) - IMAP URL Scheme [draft-ietf-lemonade-rfc2192bis-10] (32 pages) - Internet Message Access Protocol - CONVERT extension [draft-ietf-lemonade-convert-21] (30 pages) - Realization of OMA Mobile Email (MEM) Architecture using Internet Mail [draft-ietf-lemonade-oma-mem-realization-00] (33 pages) - Support for Sieve in Internet Message Access Protocol (IMAP4) [draft-ietf-lemonade-imap-sieve-06] (24 pages) - The Lemonade Profile [draft-ietf-lemonade-profile-bis-13] (38 pages) - Deployment Considerations for Lemonade-Compliant Mobile Email [draft-ietf-lemonade-deployments-10] (12 pages) - Lemonade bindings to cross firewalls and mobile network intermediaries [draft-ietf-lemonade-firewall-binding-00] (20 pages) - IMAP4 extension for named searches (filters) [draft-melnikov-imapext-filters-09] (12 pages) - Internet Message Store Events [draft-ietf-lemonade-msgevent-08] (22 pages) - Streaming Internet Messaging Attachments [draft-ietf-lemonade-streaming-14] (34 pages) - IMAP4 Extensions for Quick Mailbox Resynchronization [draft-ietf-lemonade-reconnect-client-07] (25 pages) - Lemonade Notification protocol [draft-ietf-lemonade-notification-protocol-00] (8 pages) - The IMAP NOTIFY Extension [draft-ietf-lemonade-imap-notify-08] (23 pages) - LEMONADE Architecture - Supporting Open Mobile Alliance (OMA) Mobile Email (MEM) using Internet Mail [draft-ietf-lemonade-architecture-05] (16 pages) - Extended URLFETCH for binary and converted parts [draft-cridland-urlfetch-binary-04] (10 pages) - IMAP4 Extensions for Quick Mailbox Resynchronization [draft-ietf-lemonade-5162bis-00] (25 pages) Requests for Comments: RFC4356: Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail (34 pages) RFC4416: Goals for Internet Messaging to Support Diverse Service Environments (51 pages) RFC4469: Internet Message Access Protocol (IMAP) CATENATE Extension (11 pages) * Updates RFC3501 * Updates RFC3502 * Updated by RFC5550 RFC4467: Internet Message Access Protocol (IMAP) - URLAUTH Extension (5 pages) * Updated by RFC5092 * Updated by RFC5550 RFC4468: Message Submission BURL Extension (14 pages) * Updates RFC3463 * Updated by RFC5248 RFC4550: Internet Email to Support Diverse Service Environments (Lemonade) Profile (18 pages) * OBSOLETED BY RFC5550 RFC4978: The IMAP COMPRESS Extension (9 pages) RFC5032: WITHIN Search extension to the IMAP Protocol (5 pages) * Updates RFC3501 RFC5092: IMAP URL Scheme (32 pages) * Obsoletes RFC2192 * Updates RFC4467 RFC5162: IMAP4 Extensions for Quick Mailbox Resynchronization (25 pages) RFC5259: Internet Message Access Protocol - CONVERT extension (30 pages) RFC5383: Deployment Considerations for Lemonade-Compliant Mobile Email (12 pages) RFC5465: The IMAP NOTIFY Extension (22 pages) * Updates RFC5267 RFC5466: IMAP4 Extension for Named Searches (Filters) (9 pages) RFC5442: LEMONADE Architecture - Supporting Open Mobile Alliance (OMA) Mobile Email (MEM) using Internet Mail (15 pages) RFC5423: Internet Message Store Events (17 pages) RFC5524: Extended URLFETCH for Binary and Converted Parts (10 pages) RFC5550: The Internet Email to Support Diverse Service Environments (Lemonade) Profile (41 pages) * Obsoletes RFC4550 * Updates RFC4469 * Updates RFC4467 RFC5551: Lemonade Notifications Architecture (12 pages) RFC5616: Streaming Internet Messaging Attachments (34 pages) Locator/ID Separation Protocol (lisp) ------------------------------------- Charter Last Modified: 2009-06-24 Current Status: Active Chairs: Sam Hartman Darrel Lewis Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Tech Advisor: Joel Halpern Secretary: Terry Manderson <> Mailing Lists: General Discussion: lisp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lisp Archive: http://www.ietf.org/mail-archive/web/lisp/current/maillist.html Description of Working Group: The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system and the impending exhaustion of the IPv4 address space. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the "locator/identifier separation". The basic idea behind the separation is that the Internet architecture combines two functions, routing locators, (where you are attached to the network) and identifiers (who you are) in one number space: The IP address. Proponents of the separation architecture postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system. The separation aims to decouple locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. LISP supports the separation of the IPv4 and IPv6 address space following a network-based map-and-encapsulate scheme (RFC 1955). In LISP, both identifiers and locators are IP addresses. In LISP, identifiers are composed of two parts: a "global" portion that uniquely identifies a particular site and a "local" portion that identifies an interface within a site. The "local" portion may be subdivided to identify a particular network within the site. For a given identifier, LISP maps the "global" portion of the identifier into a set of locators that can be used by de-capsulation devices to reach the identified interface; as a consequence a host would typically change identifiers when it moves from one site to another or whenever it moves from one subnet to another within an site. Typically, the same IP address will not be used as an identifier and locator in LISP. LISP requires no changes to end-systems or to most routers. LISP aims for an incrementally deployable protocol. A number of approaches are being looked at in parallel in the IRTF and IETF. At this time, these proposals are at an early stage. All proposals (including LISP) have potentially harmful side-effects to Internet traffic carried by the involved routers, have parts where deployment incentives may be lacking, and are NOT RECOMMENDED for deployment beyond experimental situations at this stage. Many of the proposals have components (such as the identifier to locator mapping system) where it is not yet known what kind of design alternative is the best one among many. However, despite these issues it would be valuable to write concrete protocol specifications and develop implementations that can be used to understand the characteristics of these designs. The LISP WG is chartered to work on the LISP base protocol (draft-farinacci-lisp-12.txt), the LISP+ALT mapping system (draft-fuller-lisp-alt-05.txt), LISP Interworking (draft-lewis-lisp-interworking-02.txt), LISP Map Server (draft-fuller-lisp-ms-00.txt), and LISP multicast (draft-farinacci-lisp-multicast-01.txt) for these purposes, with the given drafts as a starting point. The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. The Working Group will also develop security profiles for the ALT and/or other mapping systems. It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF (e.g., the Routing Research Group) that attempts to understand which type of a solution is optimal. The LISP WG is NOT chartered to develop the final or standard solution for solving the routing scalability problem. Its specifications are Experimental and labeled with accurate disclaimers about their limitations and not fully understood implications for Internet traffic. In addition, as these issues are understood, the working group will analyze and document the implications of LISP on Internet traffic, applications, routers, and security. This analysis will explain what role LISP can play in scalable routing. The analysis should also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on (draft-meyer-loc-id-implications) as well as the manageability and operability of LISP. Goals and Milestones: Mar 2010 - Submit base LISP specification to the IESG as Experimental Mar 2010 - Submit base ALT specification to the IESG as Experimental Mar 2010 - Submit the LISP Interworking specification to the IESG as Experimental Jun 2010 - Submit the LISP Map Server specification to the IESG as Experimental Jun 2010 - Submit Recommendations for Securing the LISP Mapping System to the IESG as Experimental Jul 2010 - Submit LISP for Multicast Environments to the IESG as Experimental Dec 2010 - Submit a preliminary analysis as Informational Dec 2010 - Re-charter or close. Internet-Drafts: - LISP for Multicast Environments [draft-ietf-lisp-multicast-02] (34 pages) - Locator/ID Separation Protocol (LISP) [draft-ietf-lisp-05] (73 pages) - Interworking LISP with IPv4 and IPv6 [draft-ietf-lisp-interworking-00] (15 pages) - LISP Alternative Topology (LISP+ALT) [draft-ietf-lisp-alt-01] (26 pages) - LISP Map Server [draft-ietf-lisp-ms-04] (13 pages) No Requests for Comments Long-Term Archive and Notary Services (ltans) --------------------------------------------- Charter Last Modified: 2009-09-24 Current Status: Active Chairs: Carl Wallace Tobias Gondrom Security Area Directors: Tim Polk Pasi Eronen Security Area Advisor: Tim Polk Mailing Lists: General Discussion: ltans@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/ltans Archive: http://www.ietf.org/mail-archive/web/ltans/current/maillist.html Description of Working Group: In many scenarios, users need to be able to ensure and prove the existence and validity of data, especially digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. Cryptographic means are useful, but they do not provide the whole solution. For example, digital signatures (generated with a particular key size) might become weak over time due to improved computational capabilities, new cryptanalytic attacks might "break" a digital signature algorithm, public key certificates might be revoked or expire, and so on. Complementary methods covering potential weaknesses are necessary. Long-term non-repudiation of digitally signed data is an important aspect of PKI-related standards. Standard mechanisms are needed to handle routine events, such as expiry of signer's public key certificate and expiry of trusted time stamp authority certificate. A single timestamp is not sufficient for this purpose. Additionally, the reliable preservation of content across change of formats, application of electronic notarizations, and subsequent notary services require standard solutions. The objective of the LTANS working group is to define requirements, data structures and protocols for the secure usage of the necessary archive and notary services. First, the requirements for the long-term archive will be collected. Based on that information we will develop a protocol to access archive services supplying long-term non-repudiation for signed documents and define common data structures and formats. Upon completion of the archive-related specifications, we will address 'notary services' in a similar way. The term 'notary services' is not clearly defined. The working group will determine which functions need standards, including transformation of documents from one format to another without losing the value of evidence, electronic notarization, and further verification of legal validity of signed documents. We will determine the needs via the requirements paper and act upon the results accordingly. Work done by the IETF Working Groups PKIX, S/MIME and XMLDSIG will be used as the basis to define those structures and protocols. For example, the Internet-Drafts "Archive Time-Stamps Syntax (ATS)" and "Trusted Archive Protocol (TAP)" and RFC 3029, "Data Validation and Certificate Server Protocols (DVCS)", contain applicable concepts. Goals and Milestones: Done - Initial requirements for long-term archive I-D Done - Initial data structures for long-term archive I-D Done - Revised requirements for long-term archive I-D Done - Revised data structures for long-term archive I-D Done - Initial requirements for notary services I-D Done - Initial protocol for long-term archive I-D Done - Revised requirements for notary services I-D Done - WG Last call requirements for long-term archive I-D Done - Submit requirements for long-term archive to IESG as informational Done - Submit data structures for long-term archive to IESG as proposed standard Done - WG Last call data structures for long-term archive I-D Nov 2007 - Protocol revisions for long-term archive I-D Feb 2008 - WG Last call protocol for long-term archive I-D Mar 2008 - Submit protocol for long-term archive to IESG as proposed standard May 2008 - Recharter or close the working group Internet-Drafts: - Long-term Archive Protocol (LTAP) [draft-ietf-ltans-ltap-08] (63 pages) - Long-Term Archive Service Requirements [draft-ietf-ltans-reqs-11] (19 pages) - Evidence Record Syntax (ERS) [draft-ietf-ltans-ers-16] (33 pages) - Requirements for Data Validation and Certification Services [draft-ietf-ltans-notareqs-03] (12 pages) - Using the Server-Based Certificate Validation Protocol (SCVP) to Convey Long-Term Evidence Records [draft-ietf-ltans-ers-scvp-08] (13 pages) - Infrastructure Support for Retention of PKI Artifacts [draft-ietf-ltans-pki-retention-01] (14 pages) - Validation and long term verification data for Evidence Records and signed documents [draft-ietf-ltans-validate-02] (11 pages) - LTANS Architecture [draft-ietf-ltans-ari-00] (10 pages) - Extensible Markup Language Evidence Record Syntax [draft-ietf-ltans-xmlers-04] (46 pages) - Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC) [draft-ietf-ltans-dssc-13] (48 pages) Requests for Comments: RFC4810: Long-Term Archive Service Requirements (19 pages) RFC4998: Evidence Record Syntax (ERS) (33 pages) RFC5276: Using the Server-Based Certificate Validation Protocol (SCVP) to Convey Long-Term Evidence Records (13 pages) RFC5698: Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC) (40 pages) Language Tag Registry Update (ltru) ----------------------------------- Charter Last Modified: 2009-10-19 Current Status: Active Chairs: Randy Presuhn Martin Duerst Applications Area Directors: Lisa Dusseault Alexey Melnikov Applications Area Advisor: Alexey Melnikov Mailing Lists: General Discussion: ltru@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ltru Archive: http://www.ietf.org/mail-archive/web/ltru/current/maillist.html Description of Working Group: The primary language subtags allowed by the current IANA Language Subtag Registry are limited to ISO 639-1 and ISO 639-2 in the same way as they were limited by RFC 3066. This covers approximately 500 possible language subtags. ISO 639-3, scheduled for approval towards the end of 2006, will make available around 7000 more code elements for identifying languages. The working group will prepare an update to the Language Subtag Registry procedures to allow the use of 3-letter code elements from ISO 639-3 as primary language subtags or extended language subtags as appropriate. The working group will also deliver means to update the current IANA Language Subtag Registry with the newly available subtags. The working group will examine, and if necessary clarify or adjust, procedures and guidelines with respect to extended language subtags and variant subtags. Use cases include the identification of signed languages, transliterations, and transcriptions. The working group will also consider how the draft work on ISO 639-6 may relate to the future development of language tags. The working group will clarify text where necessary. It may also make adjustments to the registration process and the form of the registry if this is deemed appropriate based on ongoing registration and operational experience. These adjustments and clarifications are not expected to delay the progress of the work. Work on the drafts is planned to start before ISO 639-3 is fully approved and published. However, the WG will not finalize the drafts before ISO 639-3 is fully approved. Goals and Milestones: Done - Submit first working group draft of registry-structure draft Done - Submit first draft of matching algorithms draft Done - Submit registry structure draft for IETF Last Call Done - Submit matching algorithms draft for IETF Last Call Done - Submit first WG draft of registry procedure update Done - Submit first WG draft of registry data update Done - Submit registry procedure update draft for IETF Last Call Done - Submit registry data update draft for IETF Last Call Internet-Drafts: - Tags for Identifying Languages [draft-ietf-ltru-registry-15] (62 pages) - Matching of Language Tags [draft-ietf-ltru-matching-16] (25 pages) - Initial Language Subtag Registry [draft-ietf-ltru-initial-07] (118 pages) - Update to the Language Subtag Registry [draft-ietf-ltru-4645bis-11] (950 pages) - Tags for Identifying Languages [draft-ietf-ltru-4646bis-24] (89 pages) Requests for Comments: RFC4645: Initial Language Subtag Registry (118 pages) RFC4646: Tags for Identifying Languages (62 pages) * OBSOLETED BY RFC5646 RFC4647: Matching of Language Tags (25 pages) RFC5646: Tags for Identifying Languages (89 pages) * Obsoletes RFC4646 RFC5645: Update to the Language Subtag Registry (950 pages) Mobile Ad-hoc Networks (manet) ------------------------------ Charter Last Modified: 2009-04-22 Current Status: Active Chairs: Joseph Macker Ian Chakeres Routing Area Directors: Ross Callon Adrian Farrel Routing Area Advisor: Ross Callon Mailing Lists: General Discussion: manet@ietf.org To Subscribe: manet-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/manet/index.html Description of Working Group: The purpose of the MANET working group is to standardize IP routing protocol functionality suitable for wireless routing application within both static and dynamic topologies with increased dynamics due to node motion or other factors