6lowpan 6man 6renum abfab adslmib alto ancp appsawg armd atoca autoconf avtcore avtext behave bfcpbis bfd bliss bmwg ccamp cdni clue codec conex core csi cuss dane dccp decade dhc dime dispatch dmm dnsext dnsop drinks eai ecrit eman emu fecframe forces ftpext2 geopriv grow hip hokey homenet httpbis hybi idr intarea ipfix ippm ipsecme iri isis jose karp kitten krb-wg l2tpext l2vpn l3vpn ledbat lisp lwig manet marf mboned mediactrl mif mile mip4 mmusic mpls mptcp multimob nea netconf netext netmod nfsv4 ntp oauth opsawg opsec ospf p2psip paws payload pce pcn pcp pim pkix pppext ppsp precis pwe3 radext repute rmt roll rtcweb rtgwg salud savi sidr sieve simple sipclf sipcore siprec soc softwire speechsc spfbis storm tcpm tictoc tls trill tsvwg urnbis v6ops vcarddav vipr websec xmpp xrblock IPv6 over Low power WPAN (6lowpan) ---------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Carsten Bormann Geoffrey Mulligan Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman 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 Low Power and Lossy Networks (6LoWPAN) [draft-ietf-6lowpan-hc-16] (25 pages) - Design and Application Spaces for 6LoWPANs [draft-ietf-6lowpan-usecases-10] (33 pages) - Design Considerations for Session Initiation Protocol (SIP) Overload Control [draft-ietf-sipping-overload-design-04] (21 pages) - Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN) [draft-ietf-6lowpan-nd-18] (59 pages) - Problem Statement and Requirements for 6LoWPAN Routing [draft-ietf-6lowpan-routing-requirements-10] (35 pages) - Transmission of IPv6 Packets over Bluetooth Low Energy [draft-ietf-6lowpan-btle-05] (13 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) * Updated by RFC6282 RFC6282: Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks (24 pages) * Updates RFC4944 IPv6 Maintenance (6man) ----------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Robert Hinden Brian Haberman Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman 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 [draft-ietf-6man-node-req-bis-12] (31 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-03] (17 pages) - IPv6 Subnet Model: the Relationship between Links and Subnet Prefixes [draft-ietf-6man-ipv6-subnet-model-13] (13 pages) - Handling of overlapping IPv6 fragments [draft-ietf-6man-overlap-fragment-04] (7 pages) - IPv6 Flow Label Specification [draft-ietf-6man-flow-3697bis-08] (17 pages) - A Recommendation for IPv6 Address Text Representation [draft-ietf-6man-text-addr-representation-08] (14 pages) - IANA Allocation Guidelines for the IPv6 Routing Header [draft-ietf-6man-iana-routing-header-01] (3 pages) - Considerations for IPv6 Address Selection Policy Changes [draft-ietf-6man-addr-select-considerations-04] (19 pages) - IPv6 Router Advertisement Options for DNS Configuration [draft-ietf-6man-dns-options-bis-09] (18 pages) - An IPv6 Routing Header for Source Routes with RPL [draft-ietf-6man-rpl-routing-header-07] (20 pages) - Interface Identifier Assignment in IPv6 SLAAC [draft-ietf-6man-neighbor-inform-00] (17 pages) - An uniform format for IPv6 extension headers [draft-ietf-6man-exthdr-06] (8 pages) - IPv6 UDP Checksum Considerations [draft-ietf-6man-udpzero-05] (34 pages) - RPL Option for Carrying RPL Information in Data-Plane Datagrams [draft-ietf-6man-rpl-option-06] (14 pages) - Update to RFC 3484 Default Address Selection for IPv6 [draft-ietf-6man-rfc3484-revise-05] (12 pages) - Using 127-bit IPv6 Prefixes on Inter-Router Links [draft-ietf-6man-prefixlen-p2p-02] (9 pages) - Using the IPv6 flow label for equal cost multipath routing and link aggregation in tunnels [draft-ietf-6man-flow-ecmp-06] (10 pages) - Rationale for update to the IPv6 flow label specification [draft-ietf-6man-flow-update-08] (13 pages) - Distributing Address Selection Policy using DHCPv6 [draft-ietf-6man-addr-select-opt-02] (10 pages) - The Line Identification Destination Option [draft-ietf-6man-lineid-02] (14 pages) - Duplicate Address Detection Proxy [draft-ietf-6man-dad-proxy-02] (13 pages) - UDP Checksums for Tunneled Packets [draft-ietf-6man-udpchecksums-01] (12 pages) - Neighbor Unreachability Detection is too impatient [draft-ietf-6man-impatient-nud-00] (7 pages) - RFC3627 to Historic status [draft-ietf-6man-3627-historic-01] (4 pages) - Processing of IPv6 "atomic" fragments [draft-ietf-6man-ipv6-atomic-fragments-00] (14 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) RFC5722: Handling of Overlapping IPv6 Fragments (6 pages) * Updates RFC2460 RFC5871: IANA Allocation Guidelines for the IPv6 Routing Header (3 pages) * Updates RFC2460 RFC5942: IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes (11 pages) * Updates RFC4861 RFC5952: A Recommendation for IPv6 Address Text Representation (14 pages) * Updates RFC4291 RFC6106: IPv6 Router Advertisement Options for DNS Configuration (19 pages) * Obsoletes RFC5006 RFC6164: Using 127-bit IPv6 Prefixes on Inter-Router Links (8 pages) RFC6436: Rationale for Update to the IPv6 Flow Label Specification (13 pages) RFC6437: IPv6 Flow Label Specification (15 pages) * Updates RFC2205 * Updates RFC2460 RFC6438: Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels (9 pages) RFC6434: IPv6 Node Requirements (30 pages) * Obsoletes RFC4294 IPv6 Site Renumbering (6renum) ------------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Tim Chown Wesley George Operations and Management Area Directors: Dan Romascanu Ronald Bonica Benoit Claise Operations and Management Area Advisor: Ronald Bonica Secretary: Sheng Jiang Mailing Lists: General Discussion: renum@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/renum Archive: http://www.ietf.org/mail-archive/web/renum/ Description of Working Group: As outlined in RFC 5887, renumbering, especially for medium to large sites and networks, is currently viewed as an expensive, painful, and error-prone process, avoided by network managers as much as possible. As that RFC describes, there are triggers that mean some cases of renumbering are unavoidable, so it should be considered a given that a site may need partial or complete renumbering at some stage. It is thus important to implement and deploy techniques that facilitate simpler IPv6 site renumbering, so that as IPv6 becomes universally deployed, renumbering can be viewed as a more routine event. This includes consideration of how the initial assignment and subsequent management of address information is performed, as this will affect future renumbering operations. If IPv6 site renumbering continues to be considered difficult, network managers will turn to PI addressing for IPv6 to attempt to minimise the need for future renumbering. However, widespread use of PI may create very serious BGP4 scaling problems. It is thus desirable to develop tools and practices that may make renumbering a simpler process to reduce demand for IPv6 PI space. Renumbering, or partial renumbering, can be complicated in an enterprise site where a short prefix is divided into subnets with longer prefixes. Aggregation, synchronisation, coordination, etc., need to be carefully managed, and the use of manually inserted address literals minimised. Other factors such as applications binding long-term to low level IP addresses may add constraints to what can be realistically achieved, but identifying and documenting such factors is a useful objective. In some scenarios, consideration may also need to be made for 'flag day' renumbering (in contrast to the procedure described in RFC4192). The task of the 6RENUM working group is to document existing renumbering practices for enterprise site networks and to identify specific renumbering problems or 'gaps' in the context of partial or site-wide renumbering. Completion of these tasks should provide a basis for future work to identify and develop point solutions or system solutions to address those problems or to stimulate such development in other working groups as appropriate. 6RENUM is chartered to perform an analysis of IPv6 site renumbering. If the analysis leads to conclusions that are also applicable to IPv4 that will be an advantage, but it is not an objective of the WG to make its outputs more widely available than IPv6. Similarly the WG is targeting enterprise networks, but the analysis may also be applicable to SOHO or other (e.g. ad-hoc) scenarios. It may be that for site renumbering to become more routine, a systematic address management approach will be required. By documenting current practices and undertaking a gap analysis, we should become better informed of the requirements of such an approach. Post-analysis rechartering may lead to further work in this area. RFC 4192, RFC 5887, and draft-jiang-ipv6-site-renum-guideline are starting points for this work. Goals/deliverables ------------------ The goals of the 6RENUM working group are: 1. To undertake scenario descriptions, including documentation of current capability inventories and existing BCPs, for enterprise networks, including managed and unmanaged elements. These texts should contribute towards a gap analysis and provide an agreed basis for subsequent WG rechartering towards development of solutions (which may be more appropriate for other WGs to undertake) and improved practices. Operator input will be of high value for this text. 2. To perform a gap analysis for renumbering practices, to identify generic issues for network design, network management, address management and renumbering operations. The methodology for the WG will be to begin building the enterprise scenario description while in parallel constructing an initial gap analysis drawing on existing work in (at least) RFC4192 and RFC5887. As the scenario text hardens, its contributions will be incorporated into the more detailed gap analysis, which can be published once the scenario text is completed. The deliverables are thus the scenario and gap analysis texts. The following topics are out of scope for the working group: 1. Renumbering avoidance; this can perhaps be considered by appropriate IRTF groups. As documented in RFC5887, renumbering cannot be completely avoided. The WG is limited to dealing with how to renumber when it is unavoidable. 2. IPv4 renumbering. While many sites are likely to run dual-stack, IPv6 is the future and, especially given concerns over extensive use of IPv6 PI, the most appropriate place to focus effort. 3. ISP renumbering; this is potentially the most complex renumbering case. However, more benefit can be achieved by focusing effort on site renumbering. The enterprise site analysis should include the ISP's role in the site's renumbering events. 4. Neither SOHO nor manet networks are targeted by the WG. However, if outputs from the WG are applicable to those scenarios, that would be an advantage. A recharter of the WG will be possible once the gap analysis and scenario description are completed and published. Such rechartering would identify more specific work items within the 6RENUM WG or appropriate protocol WGs, and may include a proposal for work on a systematic address management approach. Goals and Milestones: Oct 2011 - IPv6 enterprise site scenario draft ready for WG adoption Nov 2011 - Gap analysis document ready for WG adoption Jun 2012 - IPv6 enterprise site scenario draft ready for WGLC Jul 2012 - Gap analysis document ready for WGLC Internet-Drafts: No Requests for Comments Application Bridging for Federated Access Beyond web (abfab) ------------------------------------------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Klaas Wierenga Leif Johansson Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Stephen Farrell Mailing Lists: General Discussion: abfab@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/abfab Archive: http://www.ietf.org/mail-archive/web/abfab/ Description of Working Group: Problem Statement Federated identity facilitates the controlled sharing of information about principals, commonly across organisational boundaries. This avoids redundant registration of principals who operate in multiple domains, reducing administrative overheads and improving usability while addressing privacy-related concerns and regulatory and statutory requirements of some jurisdictions. A number of such mechanisms are in use for the Web. This working group will specify a federated identity mechanism for use by other Internet protocols not based on HTML/HTTP, such as for instance IMAP, XMPP, SSH and NFS. The design will combine existing protocols, specifically the Extensible Authentication Protocol (EAP - RFC 3748), Authentication, Authorization and Account Protocols (RADIUS - RFC 2865 and Diameter - RFC 3588), and the Security Assertion Markup Language (SAML). Specifically EAP will be used to authenticate the subject to a trusted party, AAA (RADIUS and Diameter) will be used to authenticate and convey information from that party to a relying party and SAML and SAML message formats are used to carry subject information that can be used for authorization and personalization by a relying party. Any change in the choices for these three technical roles is out of scope for this charter. Constraints ----------- Initially the working group will focus on using GSS-API (RFC2743) as a mechanism for integrating the developed solution for federated identity into application protocols but other technologies for application interface are in scope of the working group and may be adopted as deliverables subject to the normal IETF consensus and (re)charter process. In order to be usable in all current Internet protocols, GSS-API mechanism must provide the following features: mutual authentication, key confirmation, host-based service naming, per-message tokens ("security layers") and channel binding. Support for Pseudo Random Function (PRF) is desirable, and generally feasible whenever per-message tokens are supported. As a result, all of those features are required for GSS-API mechanisms produced by this WG. Note also that some of these requirements derive from SASL (RFC 4422) applications, which can use GSS- API mechanisms through GS2 (RFC5081). Other application integration strategies are very likely to mirror these constraints. In particular, host-based service naming, mutual authentication and support for channel binding are likely to be important for defense against phishing attacks. The working group will ensure that any solution developed has technical controls for privacy protection. Other than a change to its applicability statement and the development of EAP mechanisms, the working group may not change EAP, RADIUS or Diameter without establishing consensus with the appropriate community within the IETF. The working group will use the following documents as a starting point for its work: - draft-howlett-eap-gss-00, - draft-howlett-radius-saml-attr-00 - draft-hartman-gss-eap-naming-00 Concerns have been raised that additional work is required in keying AAA associations in a federated environment. The working group is chartered to explore these concerns and if needed, specify protocols that use existing AAA key management mechanisms to address these concerns. Coordination with other SDOs ---------------------------- The Working Group will work in conjunction with the IAB to establish appropriate liaison relationships with the OASIS Security Services Technical Committee (SSTC) and take care that any changes or profiling required in SAML can be properly coordinated across the different organizations. In particular coordination is required with respect to the SAML-RADIUS binding. Deliverables ------------ 1. Descriptions of applicable use cases (informational). 2. An architecture that describes how the components of the solution fit together to address the use cases and open issues that will require future changes to the architecture (informational). 3. A standards-track update to the EAP applicability statement in RFC 3748 describing the applicability of EAP to application authentication and placing appropriate requirements on this new EAP use case. 4. A standards-track solution for using EAP methods to provide authentication within the application. 5. A standards-track update to the EMSK root key applicability statement in RFC 5295. 6. A standards-track description of GSS names and name attributes required by the solution. 7. Descriptions of usability and user-interface concerns related to this work (informational). 8. A standards-track protocol for carrying SAML messages in RADIUS and Diameter. Goals and Milestones: Oct 2010 - Submit Internet draft describing applicable use cases as initial WG item. Oct 2010 - Submit Internet draft describing the architecture as initial WG item. Oct 2010 - Submit Internet draft that updates the EAP applicability statement as initial WG item. Oct 2010 - Submit Internet draft for using EAP methods to provide authentication within the application as initial WG item. Oct 2010 - Submit Internet draft that updates the EMSK root key applicability statement as initial WG item. Oct 2010 - Submit Internet draft that describes GSS names and name attributes as initial WG item. Oct 2010 - Submit Internet draft for usability and user-interface concerns as initial WG item. Oct 2010 - Submit Internet draft for SAML messages in Radius and Diameter as an initial WG item. Dec 2010 - Submit Internet draft describing applicable use cases to the IESG for consideration. Dec 2010 - Submit Internet draft describing the architecture to the IESG for consideration. May 2011 - Submit Internet draft that updates the EAP applicability statement to the IESG for consideration. May 2011 - Submit Internet draft for using EAP methods to provide authentication within the application to the IESG for consideration. Aug 2011 - Submit Internet draft that updates the EMSK root key applicability statement to the IESG for consideration. Aug 2011 - Submit Internet draft that describes GSS names and name attributes to the IESG for consideration. Aug 2011 - Submit Internet draft for usability and user-interface concerns to the IESG for consideration. Dec 2011 - Submit Internet draft for SAML messages in Radius and Diameter to the IESG for consideration. Internet-Drafts: - A GSS-API Mechanism for the Extensible Authentication Protocol [draft-ietf-abfab-gss-eap-04] (36 pages) - Name Attributes for the GSS-API EAP mechanism [draft-ietf-abfab-gss-eap-naming-01] (12 pages) - A RADIUS Attribute, Binding and Profiles for SAML [draft-ietf-abfab-aaa-saml-02] (14 pages) - Application Bridging for Federated Access Beyond web (ABFAB) Use Cases [draft-ietf-abfab-usecases-02] (11 pages) - Application Bridging for Federated Access Beyond Web (ABFAB) Architecture [draft-ietf-abfab-arch-01] (37 pages) No Requests for Comments ADSL MIB (adslmib) ------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chair: Menachem Dodge Operations and Management Area Directors: Dan Romascanu Ronald Bonica Benoit Claise Operations and Management Area Advisor: Dan Romascanu Editors: Scott Baillie Edward Beili 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 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 ifCapStack and ifInvCapStack tables as defined in RFC 5066. The Broadband forum TR-159 will be used in the definition of these MIBs. 2. The working group will develop a set of managed objects as an optional extension to RFC 5650 that shall provide an alternative approach, known as the "Vector of Profiles", for the configuration of DSL lines. The Vector of Profiles MIB will be based on the Broadband Forum TR-165 document. The ITU-T G.997.1 will also be considered in the definition of this extension. 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. 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. Done - Complete Thorough Working Group Reviews of the Vdsl2 draft and produce version 05. Done - Working Group Last Call for the Vdsl2 document. Done - Early MIB Doctor Reviews of the Vdsl2 draft. Done - Make Correction to the draft following the review. Done - Working Group Last Call for the Vdsl2 document following corrections. Done - Present the Vdsl2 document to the IESG. Feb 2010 - Submit updated ATM and Ethernet G.Bond MIB drafts. Mar 2010 - Initial Vector of Profiles draft to be accepted by the Working Group. Apr 2010 - Submit G.Bond MIB and TDIM MIB Drafts Apr 2010 - Submit Vector of Profiles Draft version 01 May 2010 - Working Group Last Call on all the G. Bond documents. Jun 2010 - Submit G.Bond documents to IESG as Proposed Standard Jun 2010 - Revise the draft and post vector of Profiles draft version 02. Jul 2010 - Working Group Last Call for the Vector of Profiles draft. Aug 2010 - Post Vector of Profiles Draft version 03. Sep 2010 - Submit the Vector Of Profile document to the IESG as Proposed Standard. Oct 2010 - Re-charter or close down. 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-08] (67 pages) - Ethernet-based xDSL multi-pair bonding (G.Bond/Ethernet) MIB [draft-ietf-adslmib-gbond-eth-mib-04] (51 pages) - xDSL multi-pair bonding using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB [draft-ietf-adslmib-gbond-tdim-mib-07] (54 pages) - ATM-Based xDSL Bonded Interfaces MIB [draft-ietf-adslmib-gbond-atm-mib-05] (33 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: 2011-12-09 Current Status: Active Chairs: Vijay Gurbani Enrico Marocco Transport Area Directors: David Harrington Martin Stiemerling Wesley Eddy Transport Area Advisor: David Harrington Tech Advisor: Peter Saint-Andre 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 specification of core request and response formats and semantics to communicate network preferences to applications. Since ALTO services may be run by entities with different levels 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. - An informational document discussing deployment related issues and documenting lessons learned from early implementation experiences. 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: Done - Working Group Last Call for problem statement Done - Submit problem statement to IESG as Informational Jan 2011 - Working Group Last Call for requirements document Jan 2011 - Working Group Last Call for request/response protocol Mar 2011 - Submit request/response protocol to IESG as Proposed Standard Mar 2011 - Submit requirements document to IESG as Informational May 2011 - Working Group Last Call of deployment considerations document Aug 2011 - Submit deployment considerations document to IESG as Informational Nov 2011 - Working Group Last Call of discovery mechanism Feb 2012 - Submit discovery mechanism to IESG as Proposed Standard Mar 2012 - 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-13] (22 pages) - ALTO Server Discovery [draft-ietf-alto-server-discovery-02] (25 pages) - ALTO Protocol [draft-ietf-alto-protocol-10] (76 pages) - ALTO Deployment Considerations [draft-ietf-alto-deployments-03] (46 pages) Requests for Comments: RFC5693: Application-Layer Traffic Optimization (ALTO) Problem Statement (15 pages) Access Node Control Protocol (ancp) ----------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Matthew Bocci Wojciech Dec Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman 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 Done - Accept WG I-D for ANCP applicability to PON Sep 2010 - Access Node Control Protocol (ANCP) Last Call Dec 2010 - ANCP MIB Last Call Dec 2010 - ANCP Multicast Extensions last call Jan 2011 - ANCP applicability to PON last call Mar 2011 - 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-14] (53 pages) - Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) [draft-ietf-ancp-security-threats-09] (18 pages) - Protocol for Access Node Control Mechanism in Broadband Networks [draft-ietf-ancp-protocol-18] (82 pages) - Access Node Control Protocol (ANCP) MIB module for Access Nodes [draft-ietf-ancp-mib-an-08] (36 pages) - Multicast Control Extensions for ANCP [draft-ietf-ancp-mc-extensions-06] (95 pages) - Applicability of Access Node Control Mechanism to PON based Broadband Networks [draft-ietf-ancp-pon-02] (35 pages) Requests for Comments: RFC5713: Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) (18 pages) RFC5851: Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks (53 pages) RFC6320: Protocol for Access Node Control Mechanism in Broadband Networks (82 pages) Applications Area Working Group (appsawg) ----------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Barry Leiba Alexey Melnikov Jiankang Yao Applications Area Directors: Pete Resnick Barry Leiba Peter Saint-Andre Applications Area Advisor: Pete Resnick Mailing Lists: General Discussion: apps-discuss@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/apps-discuss Archive: http://www.ietf.org/mail-archive/web/apps-discuss/ Description of Working Group: The Applications Area sometimes receives proposals for the development of specifications dealing with application-related topics that are not in scope for an existing working group and do not justify the formation of a new working group. The Applications Area Working Group (APPSAWG) can serve as a forum for such work in the IETF. The APPSAWG accepts work items in accordance with the consensus of the Working Group and the best judgment of the Applications Area Directors, who are responsible for updating the working group milestones as needed. The working group meets if there are active proposals that require intensive discussion. Work items that are appropriate for the APPSAWG mostly fall under the following topics: (A) Well-defined security issues that are relevant to multiple application technologies (e.g., draft-saintandre-tls-server-id-check). (B) Small-scale additions to the protocol stack for HTTP and other application technologies, mostly related to service discovery and meta-data (e.g., RFC 5785, draft-nottingham-http-link-header, and draft-hammer-hostmeta). (C) Selected other work items addressing topics that historically fall within the Applications Area, such as calendaring, date and time formats, HTTP, internationalization, language tags, MIME, URIs and XML. When considering whether to accept a proposed work item, the APPSAWG and the Applications Area Directors shall take into account the following factors, among others: * There is no existing related Working Group that is willing to recharter to take on this work, and the document doesn't justify the formation of a new working group. * Whether the WG has consensus on the suitability, importance, and projected quality of the proposed work item. * Whether there is a core team of WG participants with sufficient energy and expertise to advance the proposed work item according to the proposed schedule. * Whether there are enough WG participants who are willing to review the work produced by the document authors or editors. * Whether the Area Directors judge that wider input is needed before accepting the proposed work item (e.g., from the IESG, IAB, or another standards development organization). Goals and Milestones: Sep 2011 - Submit draft-ietf-appsawg-rfc3462bis to the IESG Internet-Drafts: - The Unicode code points and IDNA - Unicode 6.0 [draft-faltstrom-5892bis-06] (5 pages) - Email Greylisting: An Applicability Statement for SMTP [draft-ietf-appsawg-greylisting-02] (12 pages) - Terminology Used in Internationalization in the IETF [draft-ietf-appsawg-rfc3536bis-07] (46 pages) - Best Current Practices for Handling of Malformed Messages [draft-ietf-appsawg-malformed-mail-01] (9 pages) - The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages [draft-ietf-appsawg-rfc3462bis-05] (18 pages) - Deprecating Use of the "X-" Prefix in Application Protocols [draft-ietf-appsawg-xdash-02] (12 pages) - The "about" URI Scheme [draft-ietf-appsawg-about-uri-scheme-01] (7 pages) - JSON Pointer [draft-ietf-appsawg-json-pointer-00] (7 pages) - JSON Patch [draft-ietf-appsawg-json-patch-00] (12 pages) - Update to MIME regarding Charset Parameter Handling in Textual Media Types [draft-ietf-appsawg-mime-default-charset-00] (6 pages) - Forwarded HTTP Extension [draft-ietf-appsawg-http-forwarded-00] (12 pages) - Media Type Specifications and Registration Procedures [draft-ietf-appsawg-media-type-regs-01] (29 pages) Requests for Comments: RFC6365: Terminology Used in Internationalization in the IETF (47 pages) * Obsoletes RFC3536 RFC6452: The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) - Unicode 6.0 (4 pages) RFC6522: The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages (9 pages) * Obsoletes RFC3462 Address Resolution for Massive numbers of hosts in the Data center (armd) ------------------------------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Linda Dunbar Benson Schliesser Operations and Management Area Directors: Dan Romascanu Ronald Bonica Benoit Claise Operations and Management Area Advisor: Ronald Bonica Mailing Lists: General Discussion: armd@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/armd Archive: http://www.ietf.org/mail-archive/web/armd/ Description of Working Group: Changing workloads in datacenters are having an impact on the performance of current datacenter network designs. For example, the use of virtual machines (VMs) as a means for deployment and management of new services often results in a significant increase in the number of hosts attached to the network. Various requirements for the deployment of VMs in data center networks, such as support for VM mobility, has led to architectures in which broadcast domains are scaling up to span more switching devices and VM servers, and to interconnect more hosts (as represented by VMs). In these deployment architectures, heavily used protocols that are based on broadcast or multicast, such as ARP and ND, may contribute to poor network performance. The armd Working Group will investigate the impact of changing workloads and existing protocols on datacenter network performance. In its work, the armd Working Group will take into consideration work done in data center networking standardization by other SDOs, such as the IEEE 802.1 Data Center Bridging Task Group, and will communicate and exchange information with these organizations. Working Group objectives: (1) Document the current practices in data center network architectures and the scaling characteristics of ARP and ND with respect to large sized layer-2 domains in data centers. (2) Provide operational recommendations intended to minimize issues associated with these architectures and characteristics. Area affiliation of the Working Group: The armd Working Group is assigned to the Operations and Management area, and will maintain close collaboration with the Internet area. Because of its affiliation with Operations and Management, the armd Working Group will focus on documenting current practices and scaling characteristics, and will not do any protocol development or extension work. If the Working Group identifies opportunities for protocol development or extensions, it will first develop requirements for that work. Any protocol development work will be conducted in the appropriate existing Working Groups if such work groups exist. If no such working groups exist, armd may recharter to address the work and may be moved to a different area. Deliverables (Informational RFCs; list to be removed prior to posting): o Problem statement and review of current L2/L3 architectures o Report on ARP/ND statistics collection and behavior analysis in various Data Center environments o Recommendations on data center L2/L3 architectures and identification of opportunities for protocol development work Goals and Milestones: May 2011 - Problem statement Nov 2011 - ARP/ND statistics collection and behavior analysis in various Data Center environments (many subnets with various sizes; subnets with hosts with VMs and VMs migrate over time; subnets with some hosts on local VMs and others on VMs in the cloud (like Amazon's ECS); Large subnet). Nov 2011 - Survey of Existing Implementations Nov 2011 - Survey of Security Mar 2012 - Recommendations to avoid or minimize issues caused by ARP/ND Mar 2012 - Gap Analysis Internet-Drafts: - ARMD Call for Investigation [draft-ietf-armd-call-for-investigation-01] (5 pages) - Problem Statement for ARMD [draft-ietf-armd-problem-statement-00] (11 pages) No Requests for Comments Authority-to-Citizen Alert (atoca) ---------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Scott Bradner Martin Thomson Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: General Discussion: atoca@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/atoca Archive: http://www.ietf.org/mail-archive/web/atoca Description of Working Group: There are a variety of mechanisms that authorities have available to notify citizens and visitors during emergency events. Traditionally, they have done so with broadcast networks (radio and television). For commercial mobile devices, broadcasting services such as the Public Warning System (PWS), the Earthquake and Tsunami Warning System (ETWS), and the Commercial Mobile Alert System (CMAS) are standardized and are in various stages of deployment. The Internet provides another way for authority-to-citizen alerts to be sent, but it also presents new challenges. While there are some existing layer 2 mechanisms for delivering alerts, the work in this group focuses on delivering alerts to IP endpoints only. The general message pattern that this group is intended to address is the sending of alerts from a set of pre-authorized agents (e.g., governmental agencies) to a large population without undue impacts on the networks serving that population. In particular, the message pattern specified should avoid congestion and other denials of service. The goal of this group is not to specify how originators of alerts obtain authorization, but rather how an ATOCA system can verify authorization and deliver messages to the intended recipients. A critical element of the work are the mechanisms that assure that only those pre-authorized agents can send alerts via ATOCA, through an interface to authorized alert distribution networks (e.g., iPAWS/DM-Open in the U.S.). The ATOCA effort is differentiated from and is not intended to replace other alerting mechanisms (e.g., PWS, CMAS, ETWS), as the recipients of ATOCA alerts are the wide range of devices connected to the Internet and various private IP networks, which humans may have "at hand" to get such events, as well as automatons who may take action based on the alerts. This implies that the content of the alert contains some information, which is intended to be consumed by humans, and some which is intended to be consumed by automatons. Ideally, the alerts would contain, or refer to media other than text media (e.g., audio and/or video). The initial work in the group is focused on small messages, which may be mechanically rendered by the device in other forms (text to speech for example). Future work in the group may investigate rich media. In situations of a major emergency there could be scenarios where there are multiple alerts generated that may require that a priority mechanism (defined by alert originator policy) has to be used. The work on a resource priority mechanism is out of scope of the initial charter, but may be revisited at a later date. Which devices should get alerts is primarily driven by location. The first set of recipients that must be catered for are those within the area identified by the alert originator to be affected by the emergency event. In many jurisdictions, there are regulations that define whether recipients/devices within the affected area have opt-in or opt-out capability, but the protocols ATOCA will define will include both opt-in and opt-out mechanisms. The group will explore how to support both opt-in and opt-out at the level of communication protocols and/or device behavior. Another class of recipients that are in scope of the work are explicit opt-in subscriptions which ask for alerts for a specified location, not necessarily the physical location of the device itself. An example of such a subscription would be 'send me alerts for location x' (previously determined as the location of interest). This work may build on existing IETF GEOPRIV location work. There are efforts in other fora on early warning, which will be considered in this effort. For example, we expect to make use of the OASIS Common Alerting Protocol (CAP) for the encoding of alerts. OGC, ATIS, TIA, ITU-T, ETSI and 3GPP also have alert efforts underway, and consultation with these efforts will be undertaken to avoid unnecessary duplication of effort and also to avoid unintentional negative impacts on the networks. Of course, existing protocols for delivering messages (e.g., SIP, XMPP, or SMTP) will be the basis for the message delivery system of this working group. Any service discovery mechanisms defined by the group are expected to reuse existing discovery frameworks. The security implications of mechanisms that can send alerts to billions of devices are profound, but the utility of the mechanism encourages us to face the problems and solve them. In addition, the potential performance and congestion impacts to networks resulting from sending alert information to billions of devices must be considered and solved if such a service is implementable. To avoid manual configuration of servers distributing alerts a discovery mechanism will be specified. Goals and Milestones: Jan 2011 - Submit 'Terminology and Framework' to the IESG for publication as Informational Apr 2011 - Submit 'Addressing security, performance and congestion issues for alert distribution' to the IESG for publication as Informational Apr 2011 - Submit conveying point-to-point Authority to Citizen Alerts to the IESG for publication as Proposed Standard May 2011 - Submit 'Discovering alerting servers' to the IESG for publication as Proposed Standard Jun 2011 - Submit conveying point-to-multipoint Authority to Citizen Alerts to the IESG for publication as Proposed Standard Aug 2011 - Submit 'Considerations for interworking with currently deployed alert distribution systems' to the IESG for publication as Informational Internet-Drafts: - Requirements, Terminology and Framework for Exigent Communications [draft-ietf-atoca-requirements-02] (16 pages) No Requests for Comments Ad-Hoc Network Autoconfiguration (autoconf) ------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Ryuji Wakikawa Thomas Clausen Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman 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: RFC 5889 presents one possible IPv6 addressing model for ad hoc nodes. In this model the ad hoc routers need to configure their network interface(s) with addresses valid in the ad hoc network, and may configure additional prefixes for use by attached nodes. After completing the work on RFC 5889, the main purpose of the AUTOCONF WG is to standardize how existing IPv6 address configuration tools can be used for address configuration. 1. DHCPv6 operation over MANET, including: - A DHCPv6-based mechanism for configuring required interface addresses for the routers in the ad hoc network. This mechanism is expected to produce addresses with properties outlined in RFC 5889. This mechanism uses the existing DHCPv6 protocol unchanged, and assumes a central node that can allocate addresses on a first-come-first-served basis. Nodes in the ad hoc network will relay messages to the central node in order to help a new node get an address for itself. This mechanism is only suitable for deployments were a central node can be set up. It should be noted that many existing deployments employ Internet gateways that can act as such a central node as well. Future extensions such as central node election may make this mechanism suitable for also for stand-alone ad hoc networks. - A DHCPv6-based mechanism for delegating a prefix(es) to each router for use by applications running on the routers themselves, or for configuration of attached hosts/networks. This mechanism works in a similar manner to the one above, but allocates prefixes instead of addresses. Both mechanisms should be independent from operation of any specific MANET routing protocol, although may exploit information maintained by such a routing protocol, if available. The working group will adapt and/or reuse existing protocols whenever reasonable and possible. No new duplicate address detection mechanisms will be specified. 2. Analysis of Problem Space for distributed address configuration and service discovery. This analysis is necessary in order to understand what type of distributed solution(s) can be standardized. There is already quite a lot of material about possible solutions in the literature. The working group plans to establish design teams for rapidly advancing towards initial submissions for these two work items. The group shall also work with the 6LOWPAN and ROLL working group to ensure that the results from AUTOCONF working group are useful for the larger community and do not overlap with work already in progress in these other working groups. 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 Jan 2011 - First working group draft of the 'Analysis of Problem Space' Jan 2011 - First working group draft of the 'DHCPv6 operation over MANET' Sep 2011 - Submission of the 'DHCPv6 operation over MANET' to the IESG for publication as BCP Sep 2011 - Submission of the 'Analysis of Problem Space' the IESG for publication as Informational RFC Oct 2011 - First working group draft of the 'Distributed Solution' Jun 2012 - Submission of the 'Distributed Solution' to the IESG for publication as an Proposed Standard RFC Jun 2012 - Rechartering or Closing 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-04] (8 pages) Requests for Comments: RFC5889: IP Addressing Model in Ad Hoc Networks (8 pages) Audio/Video Transport Core Maintenance (avtcore) ------------------------------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Magnus Westerlund Roni Even Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Robert Sparks Secretary: Tom Taylor 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 Real-time Transport Protocol, RTP, along with its associated profiles and payload formats provides for real-time transmission of audio and video over unicast and multicast transports. RTP itself has been shepherded to Full Standard. Its associated profiles, extensions, and payload formats are currently at various levels of standards maturity. The AVTCORE working group is chartered to maintain the core RTP/RTCP specifications and the AVP, SAVP, AVPF, and SAVPF profiles. The group will provide architectural guidance for extending the protocols and guidelines for their proper use. While other working groups may be chartered to work on application-specific extensions to the protocols, extensions that are generally applicable will be developed in AVTCORE. The AVTCORE working group will coordinate closely with the Security Area while working on maintenance and enhancements to the SRTP Profile. In addition to the milestones called out below, the AVTCORE working group's initial tasks will include completing any remaining work identified in those drafts from the AVT working group already in IESG Evaluation, with the exception of the Rapid Acquisition of Multicast RTP sessions, which will complete in the AVTEXT working group. Goals and Milestones: Done - Submit Guideline for Choosing RTCP CNAME as Proposed Standard Done - Submit use of AES-192 and AES-256 in Secure RTP for Proposed Standard Done - Submit Port Mapping Between Unicast and Multicast RTP Sessions for Proposed Standard Feb 2011 - Submit Monitoring Architecture for RTP for Informational Done - Submit Guidelines for the use of Variable Bit Rate Audio with Secure RTP as Informational (or possibly BCP) Apr 2011 - Submit in band keying mechanism for SRTP draft for Proposed Standard Apr 2011 - Submit Explicit Congestion Notification (ECN) for RTP over UDP for Proposed Standard May 2011 - Submit RTCP indication for retransmission suppression as Proposed Standard Sep 2011 - Submit Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP) for Proposed Standard Dec 2011 - Submit Real-Time Transport Control Protocol (RTCP) in Overlay Multicast for Proposed Standard Mar 2012 - Submit Specification for Inter-destination Media Playout Synchronization in RTP to IESG for publication as Proposed Standard Internet-Drafts: - Application Mechanism for keeping alive the Network Address Translator (NAT) mappings associated to RTP/RTCP flows. [draft-ietf-avt-app-rtp-keepalive-11] (11 pages) - Forward-shifted RTP Redundancy Payload Support [draft-ietf-avt-forward-shifted-red-09] (13 pages) - Why RTP Does Not Mandate a Single Security Mechanism [draft-ietf-avt-srtp-not-mandatory-08] (11 pages) - AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) [draft-ietf-avt-srtp-aes-gcm-02] (19 pages) - Port Mapping Between Unicast and Multicast RTP Sessions [draft-ietf-avt-ports-for-ucast-mcast-rtp-12] (35 pages) - Explicit Congestion Notification (ECN) for RTP over UDP [draft-ietf-avt-ecn-for-rtp-04] (44 pages) - Encrypted Key Transport for Secure RTP [draft-ietf-avt-srtp-ekt-03] (53 pages) - Guidelines for the use of Variable Bit Rate Audio with Secure RTP [draft-ietf-avtcore-srtp-vbr-audio-04] (7 pages) - Explicit Congestion Notification (ECN) for RTP over UDP [draft-ietf-avtcore-ecn-for-rtp-05] (56 pages) - Port Mapping Between Unicast and Multicast RTP Sessions [draft-ietf-avtcore-ports-for-ucast-mcast-rtp-03] (37 pages) - RTCP Extension for Third-party Loss Report [draft-ietf-avtcore-feedback-supression-rtp-11] (17 pages) - Monitoring Architectures for RTP [draft-ietf-avtcore-monarch-09] (26 pages) - Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP) [draft-ietf-avtcore-srtp-encrypted-header-ext-01] (13 pages) - RTCP for inter-destination media synchronization [draft-ietf-avtcore-idms-02] (24 pages) Requests for Comments: RFC6263: Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows (12 pages) RFC6284: Port Mapping Between Unicast and Multicast RTP Sessions (30 pages) RFC6354: Forward-Shifted RTP Redundancy Payload Support (13 pages) * Updates RFC2198 * Updates RFC4102 Audio/Video Transport Extensions (avtext) ----------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Magnus Westerlund Keith Drage Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo Mailing Lists: General Discussion: avtext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/avtext Archive: http://www.ietf.org/mail-archive/web/avtext/index.html Description of Working Group: The Full-Standard Real-time Transport Protocol, RTP [RFC 3550], along with its associated profiles and payload formats provides for real- time transmission of audio and video over unicast and multicast transports. RTP is widely implemented, and deployed for a wide range of applications, ranging from telephony to television over IP. As new applications have emerged, the need for guidelines for the use of the RTP/RTCP protocols and extensions specific to those applications has been identified. The AVTEXT working group is charted to develop application-specific guidelines for the use of RTP/RTCP protocols with the AVP, SAVP, AVPF, and SAVPF profiles, and extensions to those protocols that are driven by application-specific needs. Proposals for extensions with general applicability to many different RTP/RTCP usages should be taken to the AVTCORE working group. The AVTEXT working group is constrained to use the protocol extension mechanisms defined in the core protocols (such as RTP Header extensions [RFC5285], AVPF Feedback Messages [RFC4585], and SDES Items [RFC3550]). If new ways to extend the core protocols are needed, they will be developed in the AVTCORE working group. In addition to the milestones called out below, the AVTEXT working group's initial tasks will include completing any new work identified during IESG evaluation for the Rapid Acquisition of Multicast RTP Sessions. Goals and Milestones: Jun 2011 - Submit Considerations for RAMS Scenarios for Informational Done - Submit RTP Header extension for mixer to client audio level indication as Proposed Standard Done - Submit RTP Header extension for client to mixer audio level indication as proposed standard Dec 2011 - Submit Support for multiple clock rates in an RTP session for Proposed Standard Dec 2011 - Content splicing for RTP sessions as Informational Internet-Drafts: - Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) [draft-ietf-avt-multicast-acq-rtcp-xr-01] (20 pages) - A Real-Time Transport Protocol (RTP) Header Extension for Mixer-to- Client Audio Level Indication [draft-ietf-avtext-mixer-to-client-audio-level-07] (17 pages) - A Real-Time Transport Protocol (RTP) Header Extension for Client-to- Mixer Audio Level Indication [draft-ietf-avtext-client-to-mixer-audio-level-07] (11 pages) - Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) [draft-ietf-avtext-multicast-acq-rtcp-xr-07] (21 pages) - Support for multiple clock rates in an RTP session [draft-ietf-avtext-multiple-clock-rates-02] (13 pages) - Considerations for Deploying the Rapid Acquisition of Multicast RTP Sessions (RAMS) Method [draft-ietf-avtext-rams-scenarios-02] (11 pages) - Content Splicing for RTP Sessions [draft-ietf-avtext-splicing-for-rtp-05] (17 pages) Requests for Comments: RFC6332: Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) (16 pages) RFC6464: A Real-Time Transport Protocol (RTP) Header Extension for Client-to- Mixer Audio Level Indication (9 pages) RFC6465: A Real-Time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication (15 pages) Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Dave Thaler Dan Wing Transport Area Directors: David Harrington Martin Stiemerling Wesley Eddy Transport Area Advisor: David Harrington Mailing Lists: General Discussion: behave@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/behave Archive: http://www.ietf.org/mail-archive/web/behave Description of Working Group: The working group creates documents to enable NATs to function in as deterministic a fashion as possible. 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. BEHAVE will adopt additional work items to finish four scenarios: An IPv6 network to IPv4 Internet, IPv6 Internet to an IPv4 network, An IPv6 network to an IPv4 network, and An IPv4 network to an IPv6 network. These additional work items include suggestions to application developers to improve application interactions with those translation scenarios. The following scenario remains in scope for discussion, and new milestones can be created to address this scenario: * An IPv4 application running on an IPv6-only connected host to the 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 embedded in the IPv4 host. The following scenarios remain in scope for discussion, but creating new milestones will require re-chartering: * 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. * 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. * multicast translation, including control traffic (IGMP and MLD), Single Source Multicast (SSM) and Any Source Multicast (ASM). 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. 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. 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. Done - Submit to IESG: relaying of a TCP bytestream (std) Done - Submit to IESG: relay protocol (std) Done - Submit to IESG: TURN-URI document (std) Done - Submit to IESG: IPv6 relay protocol (std) Done - Submit to IESG: framework for IPv6/IPv4 translation (info) Done - Submit to IESG: stateless IPv6/IPv4 translation (std) Done - Submit to IESG: stateful IPv6/IPv4 translation (std) Done - Submit to IESG: DNS rewriting for IPv6/IPv4 translation (std) Done - Submit to IESG: IPv6 prefix for IPv6/IPv4 translator (std) Done - Determine need and scope of multicast 6/4 translation Oct 2010 - Submit to IESG: FTP ALG for IPv6/IPv4 translation (std) Dec 2010 - Submit to IESG: large scale NAT requirements (BCP) Feb 2011 - Submit to IESG: Analysis of NAT-PT considerations with IPv6/IPv4 translation (info) Apr 2011 - Submit to IESG: avoiding NAT64 with dual-stack host for local networks (std) Apr 2011 - Submit to IESG: SCTP NAT behavior (BCP) Apr 2011 - Submit to IESG: NAT64 load balancing (std/info) Apr 2011 - Submit to IESG: host-based NAT46 translation for IPv4-only applications to access IPv6-only servers (std) Internet-Drafts: - Test vectors for STUN [draft-ietf-behave-stun-test-vectors-05] (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-17] (81 pages) - Traversal Using Relays around NAT (TURN) Extension for IPv6 [draft-ietf-behave-turn-ipv6-12] (15 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-09] (31 pages) - Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations [draft-ietf-behave-turn-tcp-08] (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-06] (26 pages) - Traversal Using Relays around NAT (TURN) Resolution Mechanism [draft-ietf-behave-turn-uri-11] (15 pages) - IP/ICMP Translation Algorithm [draft-ietf-behave-v6v4-xlate-24] (33 pages) - DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers [draft-ietf-behave-dns64-12] (32 pages) - Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers [draft-ietf-behave-v6v4-xlate-stateful-13] (45 pages) - Framework for IPv4/IPv6 Translation [draft-ietf-behave-v6v4-framework-11] (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-11] (19 pages) - An FTP ALG for IPv6-to-IPv4 translation [draft-ietf-behave-ftp64-13] (17 pages) - Dual Stack Hosts Using "Bump-in-the-Host" (BIH) [draft-ietf-behave-v4v6-bih-09] (29 pages) - Common requirements for Carrier Grade NATs (CGNs) [draft-ietf-behave-lsn-requirements-05] (18 pages) - Analysis of Stateful 64 Translation [draft-ietf-behave-64-analysis-05] (15 pages) - Analysis of solution proposals for hosts to learn NAT64 prefix [draft-ietf-behave-nat64-learn-analysis-02] (25 pages) - Discovery of a Network-Specific NAT64 Prefix using a Well-Known Name [draft-ietf-behave-nat64-discovery-heuristic-05] (14 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) RFC5766: Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) (81 pages) RFC5769: Test Vectors for Session Traversal Utilities for NAT (STUN) (11 pages) RFC5780: NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN) (31 pages) RFC5928: Traversal Using Relays around NAT (TURN) Resolution Mechanism (11 pages) RFC6052: IPv6 Addressing of IPv4/IPv6 Translators (18 pages) * Updates RFC4291 RFC6062: Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations (13 pages) RFC6144: Framework for IPv4/IPv6 Translation (31 pages) RFC6145: IP/ICMP Translation Algorithm (33 pages) * Obsoletes RFC2765 RFC6146: Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (45 pages) RFC6147: DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers (32 pages) RFC6156: Traversal Using Relays around NAT (TURN) Extension for IPv6 (14 pages) RFC6384: An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation (17 pages) Binary Floor Control Protocol Bis (bfcpbis) -------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Keith Drage Charles Eckel Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo Mailing Lists: General Discussion: bfcpbis@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/bfcpbis Archive: http://www.ietf.org/mail-archive/web/bfcpbis/ Description of Working Group: The BFCPBIS working group is chartered to specify a revision of BFCP (RFC 4582) to support using both TCP and UDP as transports. The current version of BFCP only supports TCP, which when both endpoints are behind NATs or firewalls, has a lower success rate than using the ICE techniques with a UDP based transport for BFCP. The need for video endpoints to work in these types of environments is driving a strong need to support a UDP based transport as well as TCP. This WG will create a revision of RFC 4582 which adds optional support for UDP to BFCP. The security when using UDP will be based on DTLS. The updated protocol will use an existing approach (e.g., stop and wait with a single outstanding transaction) to provide a reliable, congestion safe, and TCP friendly transport. In addition to providing a way for dealing with the reliable delivery of client-initiated transactions, the updated protocol will also be able to deliver server-initiated transactions reliably when needed. The WG will research the size of messages used and decide if fragmenting a request or response over multiple UDP packets is required. The new protocol will be backwards compatible with RFC 4582 when used in TCP mode. The BFCPBIS WG will coordinate closely with the MMUSIC WG to create a revision of RFC 4583 specifying how BFCP is signaled in SDP so that it supports UDP as well as TCP transports. This WG would ask the MMUSIC WG to add a milestone to create a revisions of RFC 4583 to address signaling the use of UDP in SDP. The WG will coordinate with International Multimedia Telecommunications Consortium (IMTC) and other industry fora. Goals and Milestones: Apr 2012 - Draft revision of RFC 4582 to IESG Internet-Drafts: - Revision of the Binary Floor Control Protocol (BFCP) for use over an unreliable transport [draft-ietf-bfcpbis-rfc4582bis-00] (33 pages) No Requests for Comments Bidirectional Forwarding Detection (bfd) ---------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: David Ward Jeffrey Haas Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Stewart Bryant 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 standardize and support the bidirectional forwarding detection protocol (BFD) and its extensions. A core goal of the working group is to standardize BFD in the context of IP routing, or protocols such as MPLS that are based on IP routing, in a way that will encourage multiple, inter-operable vendor implementations. The Working Group will also provide advice and guidance on BFD to other working groups or standards bodies as requested. 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. The working group is chartered to complete the following work items: 1. Develop the MIB module for BFD and submit it to the IESG for publication as a Proposed Standard. 2a. Provide a generic keying-based cryptographic authentication mechanism for the BFD protocol. This mechanism will support authentication through a key identifier for the BFD session's Security Association rather than specifying new authentication extensions. 2b. Provide extensions to the BFD MIB in support of the generic keying-based cryptographic authentication mechanism. 2c. Specify cryptographic authentication procedures for the BFD protocol using HMAC-SHA-256 (possibly truncated to a smaller integrity check value) using the generic keying-based cryptographic authentication mechanism. 3. Provide an extension to the BFD core protocol in support of point-to-multipoint links and networks. 4. Provide a mechanism for bootstrapping BFD on dynamically configured edge devices using DHCPv4 and DHCPv6. 5. Assist in the standardization of the BFD protocol for MPLS-TP. The preferred solution will be interoperable with the current BFD specification. 6. Assist with the standardization of the BFD protocol for Trill. Goals and Milestones: Done - Submit the base protocol specification to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for single-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for MPLS LSPs to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for multi-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Sep 2011 - Submit the BFD MIB to the IESG to be considered as a Proposed Standard Dec 2011 - Submit the generic keying based cryptographic authentication mechanism to the IESG to be considered as a Proposed Standard Dec 2011 - Submit a BFD MIB extension in support of the generic keying document to the IESG to be considered as a Proposed Standard Dec 2011 - Submit the cryptographic authentication procedures for BFD to the IESG to be considered as a Proposed Standard Mar 2012 - Submit the the document on BFD point-to-multipoint support to the IESG to be considered as a Proposed Standard Jun 2012 - Submit the bootstrapping mechanism for BFD using DHCP to the IESG to be considered as a Proposed Standard Internet-Drafts: - BFD Management Information Base [draft-ietf-bfd-mib-10] (35 pages) - BFD For MPLS LSPs [draft-ietf-bfd-mpls-08] (13 pages) - Bidirectional Forwarding Detection [draft-ietf-bfd-base-12] (51 pages) - BFD for Multihop Paths [draft-ietf-bfd-multihop-10] (7 pages) - BFD for IPv4 and IPv6 (Single Hop) [draft-ietf-bfd-v4v6-1hop-12] (8 pages) - Generic Application of BFD [draft-ietf-bfd-generic-06] (18 pages) - BFD for Multipoint Networks [draft-katz-ward-bfd-multipoint-02] (29 pages) - Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management [draft-ietf-bfd-tc-mib-00] (9 pages) - BFD Generic Cryptographic Authentication [draft-ietf-bfd-generic-crypto-auth-00] (12 pages) - BFD for Multipoint Networks [draft-ietf-bfd-multipoint-00] (29 pages) - Authenticating BFD using HMAC-SHA-2 procedures [draft-ietf-bfd-hmac-sha-00] (10 pages) Requests for Comments: RFC5880: Bidirectional Forwarding Detection (BFD) (49 pages) RFC5881: Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop) (7 pages) RFC5882: Generic Application of Bidirectional Forwarding Detection (BFD) (17 pages) RFC5883: Bidirectional Forwarding Detection (BFD) for Multihop Paths (6 pages) RFC5884: Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs) (12 pages) * Updates RFC1122 Basic Level of Interoperability for SIP Services (bliss) -------------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chair: Shida Schubert Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks 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-04] (20 pages) - Call Completion for Session Initiation Protocol (SIP) [draft-ietf-bliss-call-completion-14] (33 pages) - An Analysis of Automatic Call Handling (ACH) Implementation Issues in the Session Initiation Protocol (SIP) [draft-ietf-bliss-ach-analysis-06] (25 pages) - Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR) [draft-ietf-bliss-shared-appearances-09] (70 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: 2011-12-09 Current Status: Active Chair: Al Morton Operations and Management Area Directors: Dan Romascanu Ronald Bonica Benoit Claise 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 Benchmarking Methodology Working Group (BMWG) will continue to produce a series of recommendations concerning the key performance characteristics of internetworking technologies, or benchmarks for network devices, systems, and services. Taking a view of networking divided into planes, the scope of work includes benchmarks for the management, control, and forwarding planes. 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. The set of relevant benchmarks will be developed with input from the community of users (e.g, network operators and testing organizations) and from those affected by the benchmarks when they are published (networking and test equipment manufacturers). When possible, the benchmarks and other terminology will be developed jointly with organizations that are willing to share their expertise. Joint review requirements for a specific work area will be included in the detailed description of the task, as listed below. To better distinguish the BMWG from other measurement initiatives in the IETF, the scope of the BMWG is limited to the characterization of implementations of various internetworking technologies using controlled 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 capabilities and operation of inter-networking technology implementations. The BMWG will communicate with the operations community through organizations such as NANOG, RIPE, and APRICOT. In addition to its current work plan, the BMWG is explicitly tasked to develop benchmarks and methodologies for the following technologies: * BGP Control-plane Convergence Methodology (Terminology is complete): With relevant performance characteristics identified, BMWG will prepare a Benchmarking Methodology Document with review from the Routing Area (e.g., the IDR working group and/or the RTG-DIR). The Benchmarking Methodology will be Last-Called in all the groups that previously provided input, including another round of network operator input during the last call. * 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. * Flow Export and Collection: Develop terminology and methods to characterize network devices flow monitoring, export, and collection. The goal is a methodology to assess the maximum IP flow rate that a network device can sustain without losing any IP flow information or compromising the accuracy of information exported on the IP flows, and to asses the forwarding plane performance (if the forwarding function is present) in the presence of Flow Monitoring. * Data Center Bridging Devices: Some key concepts from BMWG's past work are not meaningful when testing switches that implement new IEEE specifications in the area of data center bridging. For example, throughput as defined in RFC 1242 cannot be measured when testing devices that implement three new IEEE specifications: priority-based flow control (802.1Qbb); priority groups (802.1Qaz); and congestion notification (802.1Qau). Since devices that implement these new congestion-management specifications should never drop frames, and since the metric of throughput distinguishes between non-zero and zero drop rates, no throughput measurement is possible using the existing methodology. The current emphasis is on the Priority Flow Control aspects of Data Center Bridging, and the work will include an investigation into whether TRILL RBridges require any specific treatment in the methodology. This work will update RFC 2544 and exchange periodic Liaisons with IEEE 802.1 DCB Task Group, especially at WG Last Call. * Content Aware Devices: New classes of network devices that operate above the IP layer of the network stack require a new methodology to perform adequate benchmarking. Existing BMWG RFCs (RFC2647 and RFC3511) provides useful measurement and performance statistics, though they may not reflect the actual performance of the device when deployed in production networks. Operating within the limitations of the charter, namely blackbox characterization in laboratory environments, the BMWG will develop a methodology that more closely relates the performance of these devices to performance in an operational setting. In order to confirm or identify key performance characteristics, BMWG will solicit input from operations groups such as NANOG, RIP and APRICOT. * LDP Dataplane Convergence: In order to identify key LDP convergence performance characteristics, BMWG will solicit input from operations groups such as NANOG, RIP and APRICOT. When relevant performance characteristics have been identified, BMWG will jointly prepare a Benchmarking Terminology Document with the Routing Area (e.g., the MPLS working group and or the RTG-DIR), which would define metrics relevant to LDP convergence. The Benchmark definition document would be Last-Called in all the working groups that produced it, and solicit operator input during the last call. The work will then continue in BMWG to define the test methodology, with input and review from the aforementioned parties. 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 Done - Terminology For Protection Benchmarking to AD Review Done - Methodology for MPLS Forwarding to AD Review Done - Networking Device Reset Benchmark (Updates RFC 2544) to IESG Review Dec 2010 - Methodology For Protection Benchmarking to IESG Review Feb 2011 - Methodology for Flow Export and Collection Benchmarking to IESG Review Jun 2011 - Methodology for Data Center Bridging Benchmarking to IESG Review Jun 2011 - Terminology for SIP Device Benchmarking to IESG Review Jun 2011 - Methodology for SIP Device Benchmarking to IESG Review Jul 2011 - Basic BGP Convergence Benchmarking Methodology to IESG Review Dec 2011 - Terminology for Content Aware Device Benchmarking to IESG Review Dec 2011 - Methodology for Content Aware Device Benchmarking to IESG Dec 2011 - Terminology for LDP Convergence Benchmarking to IESG Review Dec 2011 - Methodology for LDP Convergence Benchmarking to IESG 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-24] (43 pages) - Terminology for Benchmarking Link-State IGP Data Plane Route Convergence [draft-ietf-bmwg-igp-dataplane-conv-term-24] (27 pages) - Considerations for Benchmarking Link-State IGP Data Plane Route Convergence [draft-ietf-bmwg-igp-dataplane-conv-app-17] (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-10] (29 pages) - Methodology for benchmarking MPLS protection mechanisms [draft-ietf-bmwg-protection-meth-09] (35 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-04] (36 pages) - Methodology for Benchmarking SIP Networking Devices [draft-ietf-bmwg-sip-bench-meth-04] (19 pages) - Device Reset Characterization [draft-ietf-bmwg-reset-07] (20 pages) - IP Flow Information Accounting and Export Benchmarking Methodology [draft-ietf-bmwg-ipflow-meth-07] (32 pages) - RFC 2544 Applicability Statement: Use on Production Networks Considered Harmful [draft-ietf-bmwg-2544-as-01] (9 pages) - Benchmarking Methodology for Content-Aware Network Devices [draft-ietf-bmwg-ca-bench-meth-00] (17 pages) - IMIX Genome: Specification of variable packet sizes for additional testing [draft-ietf-bmwg-imix-genome-01] (9 pages) Requests for Comments: RFC1242: Benchmarking Terminology for Network Interconnection Devices (12 pages) * Updated by RFC6201 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 * Updated by RFC6201 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) RFC6201: Device Reset Characterization (17 pages) * Updates RFC1242 * Updates RFC2544 RFC6412: Terminology for Benchmarking Link-State IGP Data Plane Route Convergence (27 pages) RFC6413: Benchmarking Methodology for Link-State IGP Data Plane Route Convergence (43 pages) RFC6414: Benchmarking Terminology for Protection Performance (29 pages) Common Control and Measurement Plane (ccamp) -------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Lou Berger Deborah Brungard Routing Area Directors: Stewart Bryant 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 and extensions to protocols for link and path attribute measurement. This includes the Link Management Protocol (LMP). - Functional specification of extensions for GMPLS-related routing (OSPF, ISIS) and signaling (RSVP-TE) protocols required for path establishment and maintenance. 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 control of 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 data paths for data planes that are already approved by a Standards Development Organization (SDO). Note that the specification or modification of data planes is out of scope of this working group. Example data planes include Wavelength Switched Optical Networks (WSON), Optical Transport Networks (OTN), Ethernet, and the MPLS data plane. - 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 (or by other means e.g. configured) can be distributed in existing routing protocols, such as OSPF and IS-IS. CCAMP will work with the WGs that supervise these protocols. The specifics of distribution within IS-IS are being addressed in the ISIS WG. Current work activities are focused in the areas of WSON and OTN. - 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 signaling mechanisms for path protection, diverse routing and fast path restoration. Ensure that multi-layer path protection and restoration functions are achievable using the defined signaling, routing, and measurement protocols, either separately or in combination. - Identify signaling and routing requirements for supporting protocol extensions in support of data plane technologies (e.g., WSON, OTN, MPLS-TP, and Ethernet) and network architectures (e.g. ITU-T's Automatically Switched Optical Network (ASON)) not currently met by protocols defined in CCAMP; based on these, define mechanisms to address these requirements. This activity will build on documents produced by the WG, including Informational, Standards Track and Experimental documents. - 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, 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 Done - Submit Protocol solutions for MLN/MRN I-D for IESG review Done - First version of WSON routing related Working Group drafts Done - Submit Ethernet related drafts for IESG review Done - Submit hierarchy bis for IESG review Apr 2010 - First version of LMP Negotiation Working Group draft Apr 2010 - First version of G.709 enhancements framework Working Group drafts Apr 2010 - First version of Working Group draft providing Control Plane Framework for MPLS-TP Apr 2010 - First versions of impairments related solutions Working Group drafts Apr 2010 - Submit TE MIB module IESG review Apr 2010 - Submit VCAT/LCAS with GMPLS for IESG review May 2010 - Submit Lambda labels draft for IESG review May 2010 - Submit WSON framework draft for IESG review May 2010 - Submit WSON impairment framework draft for IESG review May 2010 - Submit OAM configuration framework for IESG review May 2010 - First version of OAM configuration solutions Working Group draft Aug 2010 - First version of G.709 enhancements solutions Working Group drafts Aug 2010 - First version of LMP for G.709 enhancements Working Group drafts Sep 2010 - First version of Working Group draft defining RSVP-TE extensions for MPLS-TP Dec 2010 - Submit WSON routing related for IESG review Dec 2010 - Submit impairments related solutions for IESG review Dec 2010 - Submit G.709 enhancements framework for IESG review Dec 2010 - Submit Control Plane Framework for MPLS-TP for IESG review Mar 2011 - Submit RSVP-TE extensions for MPLS-TP for IESG review Apr 2011 - Submit G.709 enhancements solutions for IESG review Apr 2011 - Submit LMP Negotiation for IESG review Apr 2011 - Submit last OAM configuration solutions for IESG review Aug 2011 - Submit LMP for G.709 enhancements for IESG review Nov 2011 - 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-11] (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-09] (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-10] (29 pages) - Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks [draft-ietf-ccamp-mpls-graceful-shutdown-14] (10 pages) - Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS) [draft-ietf-ccamp-gmpls-vcat-lcas-14] (22 pages) - Traffic Engineering Database Management Information Base in support of MPLS-TE/GMPLS [draft-ietf-ccamp-gmpls-ted-mib-10] (32 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-13] (24 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-10] (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-12] (52 pages) - Data Channel Status Confirmation Extensions for the Link Management Protocol [draft-ietf-ccamp-confirm-data-channel-status-10] (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-08] (22 pages) - Generalized Multiprotocol Label Switching (GMPLS) control of Ethernet Provider Backbone Traffic Engineering (PBB-TE) [draft-ietf-ccamp-gmpls-ethernet-pbb-te-07] (21 pages) - Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching [draft-ietf-ccamp-gmpls-ether-svcs-05] (16 pages) - Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 User-Network Interface (UNI) [draft-ietf-ccamp-gmpls-mef-uni-04] (10 pages) - Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) [draft-ietf-ccamp-wavelength-switched-framework-02] (37 pages) - Generalized Labels for Lambda-Switching Capable Label Switching Routers [draft-ietf-ccamp-gmpls-g-694-lambda-labels-12] (16 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-05] (11 pages) - Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks [draft-ietf-ccamp-rwa-info-13] (27 pages) - Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks [draft-ietf-ccamp-rwa-wson-encode-13] (37 pages) - Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) [draft-ietf-ccamp-rwa-wson-framework-13] (53 pages) - GMPLS RSVP-TE extensions for OAM Configuration [draft-ietf-ccamp-oam-configuration-fwk-07] (24 pages) - GMPLS RSVP-TE Extensions for Ethernet OAM Configuration [draft-ietf-ccamp-rsvp-te-eth-oam-ext-07] (20 pages) - A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments [draft-ietf-ccamp-wson-impairments-10] (31 pages) - Framework for GMPLS and PCE Control of G.709 Optical Transport Networks [draft-ietf-ccamp-gmpls-g709-framework-05] (28 pages) - GMPLS RSVP-TE Extensions for SONET/SDH and OTN OAM Configuration [draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-03] (21 pages) - MPLS Transport Profile (MPLS-TP) Control Plane Framework [draft-ietf-ccamp-mpls-tp-cp-framework-07] (55 pages) - GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks [draft-ietf-ccamp-wson-signal-compatibility-ospf-07] (14 pages) - Usage of The RSVP Association Object [draft-ietf-ccamp-assoc-info-03] (11 pages) - Configuration of Pro-Active Operations, Administration, and Maintenance (OAM) Functions for MPLS-based Transport Networks using RSVP-TE [draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-07] (21 pages) - General Network Element Constraint Encoding for GMPLS Controlled Networks [draft-ietf-ccamp-general-constraint-encode-06] (28 pages) - Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS/ MPLS-TE Networks [draft-ietf-ccamp-dpm-05] (33 pages) - Signaling Extensions for Wavelength Switched Optical Networks [draft-ietf-ccamp-wson-signaling-02] (23 pages) - Link Management Protocol Behavior Negotiation and Configuration Modifications [draft-ietf-ccamp-lmp-behavior-negotiation-05] (11 pages) - RSVP Resource Sharing Remote Identification Association [draft-ietf-ccamp-rsvp-resource-sharing-03] (11 pages) - LSP Attributes Related Routing Backus-Naur Form [draft-ietf-ccamp-attribute-bnf-02] (8 pages) - GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) [draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-04] (15 pages) - OSPF-TE Extensions for General Network Element Constraints [draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02] (14 pages) - RSVP-TE Extensions for Associated Bidirectional LSPs [draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-02] (12 pages) - Information model for G.709 Optical Transport Networks (OTN) [draft-ietf-ccamp-otn-g709-info-model-03] (24 pages) - Updates to ASON Routing for OSPFv2 Protocols (RFC 5787bis) [draft-ietf-ccamp-rfc5787bis-03] (29 pages) - RSVP Association Object Extensions [draft-ietf-ccamp-assoc-ext-01] (15 pages) - Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks [draft-ietf-ccamp-gmpls-ospf-g709v3-01] (31 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control [draft-ietf-ccamp-gmpls-signaling-g709v3-01] (25 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 * Updated by RFC6002 * Updated by RFC6003 * Updated by RFC6205 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 * Updated by RFC6002 * Updated by RFC6003 RFC3609: Tracing Requirements for Generic Tunnels (9 pages) RFC3945: Generalized Multi-Protocol Label Switching Architecture (58 pages) * Updated by RFC6002 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) * Updated by RFC6001 * Updated by RFC6002 RFC4203: OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (12 pages) * Updates RFC3630 * Updated by RFC6001 * Updated by RFC6002 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 * Updated by RFC6344 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 * Updated by RFC6001 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 * Updated by RFC6001 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) * OBSOLETED BY RFC6387 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) RFC5814: Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks (44 pages) RFC5787: OSPFv2 Routing Protocols Extensions for Automatically Switched Optical Network (ASON) Routing (29 pages) RFC5828: Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework (20 pages) RFC5852: RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network. (22 pages) RFC5818: Data Channel Status Confirmation Extensions for the Link Management Protocol (16 pages) RFC5817: Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks (10 pages) RFC6001: Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) (24 pages) * Updates RFC4974 * Updates RFC4874 * Updates RFC4206 * Updates RFC4203 * Updates RFC4202 * Updates RFC5307 RFC6002: Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions (10 pages) * Updates RFC4203 * Updates RFC4202 * Updates RFC3945 * Updates RFC3473 * Updates RFC3471 * Updates RFC5307 RFC6003: Ethernet Traffic Parameters (14 pages) * Updates RFC3471 * Updates RFC3473 RFC6004: Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching (15 pages) RFC6005: Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 User Network Interface (UNI) (10 pages) RFC6107: Procedures for Dynamically Signaled Hierarchical Label Switched Paths (30 pages) * Updates RFC3477 * Updates RFC4206 RFC6060: Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE) (20 pages) RFC6205: Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers (15 pages) * Updates RFC3471 RFC6163: Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSON) (51 pages) RFC6344: Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS) (21 pages) * Updates RFC4606 RFC6387: GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) (15 pages) * Obsoletes RFC5467 RFC6373: MPLS-TP Control Plane Framework (55 pages) Content Delivery Networks Interconnection (cdni) ------------------------------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Richard Woundy Francois Le Faucheur Transport Area Directors: David Harrington Martin Stiemerling Wesley Eddy Transport Area Advisor: David Harrington Mailing Lists: General Discussion: cdni@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/cdni Archive: http://www.ietf.org/mail-archive/web/cdni/ Description of Working Group: A Content Delivery Network (CDN) is an infrastructure of network elements operating at layer 4 through layer 7, arranged for the efficient distribution and delivery of digital content. Such content includes, but is not limited to, web pages and images delivered via HTTP, and streaming of continuous media delivered via HTTP, RTSP, RTMP, etc. CDNs typically provide services to multiple Content Service Providers (CSPs). CDNs provide numerous benefits: a shared platform for multi-service content delivery, reduced transmission costs for cacheable content, improved quality of experience for end users and increased robustness of delivery. For these reasons they are frequently used for large-scale content delivery. As a result of the significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure and many Network Service Providers and Enterprise Service Providers are deploying their own CDNs. Subject to the policy of the CSP, it is generally desirable that a given item of content can be delivered to an end user regardless of that end user's location or attachment network. This creates a need for interconnecting (previously) standalone CDNs so they can interoperate and collectively behave as a single delivery infrastructure. The goal of the CDNI Working Group is to allow the interconnection of separately administered CDNs in support of the end-to-end delivery of content from CSPs through multiple CDNs and ultimately to end users (via their respective User Agents). The CDNI WG aims at delivering a targeted, deployable solution in a short timeframe (18-24 months) as needed by the industry. It is expected that the CDNI interfaces will be realized using existing IETF protocols for transport and message exchange, and using existing object notation grammars/languages for the definition of CDNI objects and semantics. In the event that protocol extensions or new protocols are deemed necessary by the WG, the WG will recharter. The working group will focus on the following items: - A "problem statement" document providing a description of the problem and a common terminology. - A "use case" document describing scenarios for usage and applications of the CDNI solution and protocols. - A "framework" document providing a description of the different components of the CDNI architecture and how they interact with one another. This document will also include a "threat analysis" discussing the security concerns and threats, the trust model and privacy issues specific to CDNI. - A "requirements" document. This document lists the requirements for the CDNI architecture and the CDNI interfaces. In particular, this document will focus on identifying a reasonable set of more urgent and important requirements that will be addressed in the initial set of CDNI protocols and solutions produced by the working group. This document will list the requirements stemming from the threat analysis and to be met by each of the CDNI interfaces. - A specification of the "CDNI request-routing interface". This interface will allow an upstream CDN request routing system to obtain from the downstream CDN the information necessary to perform request redirection. - A specification of the "CDNI metadata interface". This interface will allow the CDNs to exchange content distribution metadata of inter-CDN scope. Content distribution metadata refers to the subset of content metadata that is relevant to the distribution of the content and therefore is to be processed by CDNs (for example, this may include information enabling: content acquisition, geo-blocking, enforcement of availability windows or access control). - A specification of the "CDNI logging interface". This interface will allow CDN logging systems to exchange logging information associated with actions that are relevant across CDNs (such as content distribution, content delivery and content routing actions) for purposes of accounting, analytics, monitoring, etc. - A specification of the "CDNI control interface". In particular, this interface will allow an upstream CDN to remove or invalidate content in a downstream CDN. The WG will discuss and address the security, management and operational issues specific to CDNI, inside the above documents and specifications. The working group will only define solutions for aspects of the CDN Interconnection problem space that require direct communication or interoperation between CDNs. In particular, the WG will not define: - New session, transport or network protocols. - New protocols for delivering content from a CDN to an End User/User Agent. - New protocols for ingestion of content or metadata between a CSP and a CDN. - New protocols for acquiring content across CDNs. - Protocols and algorithms for intra-CDN operations. - Support for Transparent Caching across CDNs. - New applications consuming CDNI logs. - Digital Right Management (DRM) mechanisms. The CDNI WG will work with other IETF WGs to assess, and where appropriate, leverage protocols developed by those WGs, in order to realize the CDNI requirements and CDNI interfaces. For example, the WG may assess the suitability of the ALTO protocol as a protocol to enable downstream CDNs to exchange information which may aid an upstream CDN with making CDNI request routing decisions. The CDNI WG will also coordinate with relevant groups outside the IETF such as UltraViolet. Goals and Milestones: Dec 2011 - Submit CDNI problem statement to IESG as Informational Mar 2012 - Submit CDNI use cases to IESG as Informational Jun 2012 - Submit CDNI framework to IESG as Informational Jun 2012 - Submit CDNI requirements to IESG as Informational Dec 2012 - Submit specification of the CDNI Request Routing interface to IESG as Proposed Standard Dec 2012 - Submit specification of the CDNI Logging interface to IESG as Proposed Standard Dec 2012 - Submit specification of the CDNI Control interface to IESG as proposed Standard Jun 2013 - Submit specification of the CDNI Metadata Distribution interface to IESG as Proposed Standard Jun 2013 - Recharter or dissolve Internet-Drafts: - Content Distribution Network Interconnection (CDNI) Problem Statement [draft-ietf-cdni-problem-statement-03] (35 pages) - Content Distribution Network Interconnection (CDNI) Requirements [draft-ietf-cdni-requirements-02] (21 pages) - Use Cases for Content Delivery Network Interconnection [draft-ietf-cdni-use-cases-03] (18 pages) No Requests for Comments ControLling mUltiple streams for tElepresence (clue) ---------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Mary Barnes Paul Kyzivat Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo Mailing Lists: General Discussion: clue@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/clue Archive: http://www.ietf.org/mail-archive/web/clue/ Description of Working Group: In the context of this WG, the term telepresence is used in a general manner to describe systems that provide high definition, high quality audio/video enabling a "being-there" experience. One example is an immersive telepresence system using specially designed and special purpose rooms with multiple displays permitting life size image reproduction using multiple cameras, encoders, decoders, microphones and loudspeakers. Current telepresence systems are based on open standards such as RTP, SIP, H.264, the H.323 suite. However, they cannot easily interoperate with each other without operator assistance and expensive additional equipment which translates from one vendor to another. A major factor limiting the interoperability of telepresence systems is the lack of a standardized way to describe and negotiate the use of the multiple streams of audio and video comprising the media flows. The WG will create specifications for SIP-based conferencing systems to enable communication of information about media streams so that a sending system, receiving system, or intermediate system can make reasonable decisions about transmitting, selecting, and rendering media streams. This enables systems to make choices that optimize user experience. This working group is chartered to specify the following information about media streams from one entity to another entity: * Spatial relationships of cameras, displays, microphones, and loudspeakers - relative to each other and to likely positions of participants * Viewpoint, field of view/capture for camera/microphone/display/loudspeaker - so that senders and intermediate devices can understand how best to compose streams for receivers, and the receiver will know the characteristics of its received streams * Usage of the stream, for example whether the stream is presentation, or document camera output * Aspect ratio of cameras and displays * Which sources a receiver wants to receive. For example, it might want the source for the left camera, or might want the source chosen by VAD (Voice Activity Detection) Information between sources and sinks about media stream capabilities will be exchanged. The working group will define the semantics, syntax, and transport mechanism for communicating the necessary information. It will consider whether existing protocols for signaling, messaging and transport are adequate or need to be extended. Any extensions to IETF protocols will be done in appropriate WGs, for example extensions to SDP in MMUSIC. The scope of the work includes describing relatively static relations between entities (participants and devices). It also includes handling more dynamic relationships, such as specifying the audio and video streams for defined speakers. Specifying the location of the current speakers relative to display microphones needs to be provided dynamically as speakers move. As part of the receiver telling the sender what it wants dynamically, explicit receiver notification to the sender of the desired video stream and video pause will be considered. The scope includes both systems that provide a fully immersive experience, and systems that interwork with them and therefore need to understand the same multiple stream semantics. The focus of this work is on multiple RTP audio and video streams. Other media types may be considered, however development of methodologies for them is not within the scope of this work. Interoperation with SIP and related standards for audio and video is required. However, backwards compatibility with existing non-standards compliant telepresence systems is not required. This working group is not currently chartered to work on issues of continuous conference control including: far end camera control, floor control, conference roster. The working group may identify interoperability obstacles in existing open standards. If so, the WG will develop requirements to be communicated to other IETF WGs or Standards Forums, or recharter as appropriate. Reuse of existing protocols and backwards compatibility with SIP-compliant audio/video endpoints are important factors for the working group to consider. The work will closely coordinate with the appropriate areas (e.g., OPS and SEC), and working groups including AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. Goals and Milestones: Jul 2011 - Submit informational draft to IESG on use cases Jul 2011 - Submit informational draft to IESG on framework and requirements Nov 2011 - Submit standards track specification(s) to IESG to support framework and requirements Internet-Drafts: - Use Cases for Telepresence Multi-streams [draft-ietf-clue-telepresence-use-cases-02] (16 pages) - Requirements for Telepresence Multi-Streams [draft-ietf-clue-telepresence-requirements-01] (12 pages) - Framework for Telepresence Multi-Streams [draft-ietf-clue-framework-03] (32 pages) No Requests for Comments Internet Wideband Audio Codec (codec) ------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Cullen Jennings Jonathan Rosenberg Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Robert Sparks Tech Advisor: Stephan Wenger Mailing Lists: General Discussion: codec@ietf.org To Subscribe: https://www.ietf.org/mailman//listinfo/codec Archive: http://www.ietf.org/mail-archive/web/codec/current/maillist.html Description of Working Group: Problem Statement According to reports from developers of Internet audio applications and operators of Internet audio services, there are no standardized, high-quality audio codecs that meet all of the following three conditions: 1. Are optimized for use in interactive Internet applications. 2. Are published by a recognized standards development organization (SDO) and therefore subject to clear change control. 3. Can be widely implemented and easily distributed among application developers, service operators, and end users. There exist codecs that provide high quality encoding of audio information, but that are not optimized for the actual conditions of the Internet; according to reports, this mismatch between design and deployment has hindered adoption of such codecs in interactive Internet applications. There exist codecs that can be widely implemented and easily distributed, but that are not standardized through any SDO; according to reports, this lack of standardization and clear change control has hindered adoption of such codecs in interactive Internet applications. There exist codecs that are standardized, but that cannot be widely implemented and easily distributed; according to reports, the presence of various usage restrictions (e.g., in the form of requirements to pay royalty fees, obtain a license, enter into a business agreement, or meet other special conditions imposed by a patent holder) has hindered adoptions of such codecs in interactive Internet applications. According to application developers and service operators, an audio codec that meets all three of these would: (1) enable protocol designers to more easily specify a mandatory-to-implement codec in their protocols and thus improve interoperability; (2) enable developers to more easily easily build innovative, interactive applications for the Internet; (3) enable service operators to more easily deploy affordable, high-quality audio services on the Internet; and (4) enable end users of Internet applications and services to enjoy an improved user experience. Objectives The goal of this working group is to ensure the existence of a single high-quality audio codec that is optimized for use over the Internet and that can be widely implemented and easily distributed among application developers, service operators, and end users. At present it appears that ensuring the existence of such a codec will require a development effort within the working group, however if a candidate codec is presented that achieves the goal then the working group should seriously consider stopping its development work. The core technical considerations for such a codec include, but are not necessarily limited to, the following: 1. Designing for use in interactive applications (examples include, but are not limited to, point-to-point voice calls, multi-party voice conferencing, telepresence, teleoperation, in-game voice chat, and live music performance) 2. Addressing the real transport conditions of the Internet as identified and prioritized by the working group 3. Ensuring interoperability and clean integration with the Real-time Transport Protocol (RTP), including secure transport via SRTP 4. Ensuring interoperability with Internet signaling technologies such as Session Initiation Protocol (SIP), Session Description Protocol (SDP), and Extensible Messaging and Presence Protocol (XMPP); however, the result should not depend on the details of any particular signaling technology Optimizing for very low bit rates (typically below 2.4 kbps) and for non-interactive audio is out of scope because such work might necessitate specialized optimizations. Although a codec produced by this working group or another standards organization might be used as a mandatory-to-implement technology by designers of particular Internet protocols, it is explicitly not a goal of the working group to produce or select a codec that will be mandated for use across the entire IETF or Internet community nor would their be any expectation that this would be the only mandatory-to-implement codec. Based on the working group's analysis of the design space, the working group might determine that it needs to produce more than one codec, or a codec with multiple modes; however, it is not the goal of working group to produce more than one codec, and to reduce confusion in the marketplace the working group shall endeavor to produce as few codecs as possible. In completing its work, the working group should collaborate with other IETF working groups to complete particular tasks. These might include, but would not be limited to, the following: - Within the AVT WG, define the codec's payload format for use with the Real-time Transport Protocol (RTP). - Collaborate with working groups in the Transport Area to identify important aspects of packet transmission over the Internet. - Collaborate with working groups in the Transport Area to understand the degree of rate adaptation desirable, and to reflect that understanding in the design of a codec that can adjust its transmission in a way that minimizes disruption to the audio. - Collaborate with working groups in the RAI Area to ensure that information about and negotiation of the codec can be easily represented at the signaling layer. In accordance with the liaison agreement in place, the working group will continue to coordinate with the ITU-T (Study group 16), with the intent of submitting the completed codec RFC for co-publication by the ITU-T if the ITU-T finds that appropriate. The working group will communicate a detailed description of the requirements and goals to other SDOs including the ITU-T, 3GPP, and MPEG to help determine if existing codecs meet the requirements and goals. Information about codecs being standardized will be available to other SDOs in the form of internet drafts and the working group welcomes technical feedback from other SDOs and experts from other organizations. Suggested Codec Standardization Guidelines and Requirements for achieving the foregoing objectives are provisionally outlined in draft-valin-codec-guidelines and draft-valin-codec-requirements respectively; these documents will form the starting point for working toward consensus and, if accepted as work items of the working group, will be refined by the working group in accordance with the usual IETF procedures. A codec that can be widely implemented and easily distributed among application developers, service operators, and end users is preferred. Many existing codecs that might fulfill some or most of the technical attributes listed above are encumbered in various ways. For example, patent holders might require that those wishing to implement the codec in software, deploy the codec in a service, or distribute the codec in software or hardware need to request a license, enter into a business agreement, pay licensing fees or royalties, or attempt to adhere to other special conditions or restrictions. Because such encumbrances have made it difficult to widely implement and easily distribute high-quality audio codecs across the entire Internet community, the working group prefers unencumbered technologies in a way that is consistent with BCP 78 and BCP 79. In particular, the working group shall heed the preference stated in BCP 79: "In general, IETF working groups prefer technologies with no known IPR claims or, for technologies with claims against them, an offer of royalty-free licensing." Although this preference cannot guarantee that the working group will produce an unencumbered codec, the working group shall follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to redistribute and use. Deliverables 1. A set of Codec Standardization Guidelines that define the work processes of the working group. This document shall be Informational. 2. A set of technical Requirements. This document shall be Informational. 3. Specification of a codec that meets the agreed-upon requirements, in the form of an Internet-Draft that defines the codec algorithm along with source code for a reference implementation. The text description of the codec shall indicate which components of the encoder and decoder are mandatory, recommended, and optional. It is envisioned that this document shall be a Proposed Standard document. Goals and Milestones: Done - WGLC on Codec Standardization Guidelines Done - WGLC on Requirements, liaise to other SDOs Done - Requirements to IESG (Informational) Done - Liaise requirements RFC to other SDOs Done - WGLC on codec specification, liaise to other SDOs Aug 2011 - Codec Standardization Guidelines to IESG (Informational) Aug 2011 - WGLC #2 on Codec specification Sep 2011 - Submit codec specification to IESG (Standards Track) Oct 2012 - WGLC on Testing document Dec 2012 - Testing document to IESG Internet-Drafts: - Requirements for an Internet Audio Codec [draft-ietf-codec-requirements-06] (23 pages) - Definition of the IETF Interactive Audio Codec [draft-ietf-codec-description-00] (12 pages) - Definition of the Harmony Audio Codec [draft-ietf-codec-harmony-00] (12 pages) - Definition of the Opus Audio Codec [draft-ietf-codec-opus-10] (322 pages) - Guidelines for Development of an Audio Codec Within the IETF [draft-ietf-codec-guidelines-08] (21 pages) - Summary of Opus listening test results [draft-ietf-codec-results-00] (31 pages) Requests for Comments: RFC6366: Requirements for an Internet Audio Codec (17 pages) Congestion Exposure (conex) --------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Marcelo Bagnulo Nandita Dukkipati Transport Area Directors: David Harrington Martin Stiemerling Wesley Eddy Transport Area Advisor: Wesley Eddy Mailing Lists: General Discussion: conex@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/conex Archive: http://www.ietf.org/mail-archive/web/conex/current/maillist.html Description of Working Group: The purpose of the CONEX working group is to develop a mechanism by which senders inform the network about the congestion encountered by previous packets on the same flow. Today, the network may signal congestion by ECN markings or by dropping packets, and the receiver passes this information back to the sender in transport-layer acknowledgements. The mechanism to be developed by the CONEX WG will enable the sender to also relay the congestion information back into the network in-band at the IP layer, such that the total level of congestion is visible to all IP devices along the path, from where it could, for example, be provided as input to traffic management. The primary goal of the CONEX WG is to develop experimental specifications to achieve the above in IPv6 networks. The WG will also develop an abstract, higher-level description of the congestion exposure mechanism. Primary work items are: * An Informational document containing an abstract description of the congestion exposure mechanism that is independent of specific transport protocols and congestion information encoding techniques needed for different IP protocol versions. * An Experimental specification of an IPv6 packet structure that encapsulates CONEX information, defining a packet format and an interpretation. * An Experimental specification of a modification to TCP, for the timely transport of congestion information from the destination to the sender. It is believed that the CONEX mechanism will be useful as a generative technology that can be applied as a key element of congestion management solutions in a wide variety of use cases. However, the CONEX WG will initially focus on one use case, where the end hosts and the network that contains the destination end host are CONEX-enabled but other networks need not be. CONEX information can assist the network operator's traffic management and, for example, incentivize LEDBAT-like applications. Congestion-based billing is not within the scope of the WG. Experiments on use cases are encouraged and the WG will solicit feedback from such deployments. The WG may decide to document the experience from such use cases in Informational documents, covering: * Assumptions made * Deployment considerations * Advice on how to use the CONEX mechanism as an element of a congestion management solution * Security threats and advice on mitigation approaches (detailed specifications of threat mitigation techniques are out of scope) * Descriptions of results from experiments with the use case The CONEX WG is only chartered to work on a congestion exposure mechanism for IPv6 networks. When the output of the WG has seen adoption and has proven to be useful, the WG may propose to the IESG that it should be rechartered to extend this effort. The first result of the WG is the usage scenarios document. Other documents will not be considered for publication before this first document has seen IETF consensus (but may be worked on in the WG). Goals and Milestones: Mar 2011 - Submit use case description to IESG as Informational Jul 2011 - Submit abstract specification for the congestion exposure mechanism to IESG as Informational Nov 2011 - Submit specification of IPv6 packet structure to IESG as Experimental Nov 2011 - Submit specification for modification to TCP to IESG as Experimental Internet-Drafts: - ConEx Concepts and Use Cases [draft-ietf-conex-concepts-uses-03] (17 pages) - Congestion Exposure (ConEx) Concepts and Abstract Mechanism [draft-ietf-conex-abstract-mech-03] (23 pages) - IPv6 Destination Option for Conex [draft-ietf-conex-destopt-01] (7 pages) - TCP modifications for Congestion Exposure [draft-ietf-conex-tcp-modifications-00] (12 pages) No Requests for Comments Constrained RESTful Environments (core) --------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Carsten Bormann Cullen Jennings Applications Area Directors: Pete Resnick Barry Leiba Peter Saint-Andre Applications Area Advisor: Peter Saint-Andre Mailing Lists: General Discussion: core@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/core Archive: http://www.ietf.org/mail-archive/web/core/current/maillist.html Description of Working Group: CoRE is providing a framework for resource-oriented applications intended to run on constrained IP networks. A constrained IP network has limited packet sizes, may exhibit a high degree of packet loss, and may have a substantial number of devices that may be powered off at any point in time but periodically "wake up" for brief periods of time. These networks and the nodes within them are characterized by severe limits on throughput, available power, and particularly on the complexity that can be supported with limited code size and limited RAM per node. More generally, we speak of constrained networks whenever at least some of the nodes and networks involved exhibit these characteristics. Low-Power Wireless Personal Area Networks (LoWPANs) are an example of this type of network. Constrained networks can occur as part of home and building automation, energy management, and the Internet of Things. The CoRE working group will define a framework for a limited class of applications: those that deal with the manipulation of simple resources on constrained networks. This includes applications to monitor simple sensors (e.g. temperature sensors, light switches, and power meters), to control actuators (e.g. light switches, heating controllers, and door locks), and to manage devices. The general architecture consists of nodes on the constrained network, called Devices, that are responsible for one or more Resources that may represent sensors, actuators, combinations of values or other information. Devices send messages to change and query resources on other Devices. Devices can send notifications about changed resource values to Devices that have subscribed to receive notification about changes. A Device can also publish or be queried about its resources. (Typically a single physical host on the network would have just one Device but a host might represent multiple logical Devices. The specific terminology to be used here is to be decided by the WG.) As part of the framework for building these applications, the WG will define a Constrained Application Protocol (CoAP) for the manipulation of Resources on a Device. CoAP will be designed for use between Devices on the same constrained network, between Devices and general nodes on the Internet, and between Devices on different constrained networks both joined by an internet. CoAP targets the type of operating environments defined in the ROLL and 6LOWPAN working groups which have additional constraints compared to normal IP networks, but the CoAP protocol will also operate over traditional IP networks. There also may be proxies that interconnect between other Internet protocols and the Devices using the CoAP protocol. The WG will define a mapping from CoAP to an HTTP REST API; this mapping will not depend on a specific application. It is worth noting that proxy does not have to occur at the boundary between the constrained network and the more general network, but can be deployed at various locations in the unconstrained network. CoAP will support various forms of "caching". For example, if a temperature sensor is normally asleep but wakes up every five minutes and sends the current temperature to a proxy that has subscribed, when the proxy receives a request over HTTP for that temperature resource, it can respond with the last seen value instead of trying to query the Device which is currently asleep. The initial work item of the WG is to define a protocol specification for CoAP that includes: 1) The ability to create, read, update and delete a Resource on a Device. 2) The ability to allow a Device to publish a value or event to another Device that has subscribed to be notified of changes, as well as the way for a Device to subscribe to receive publishes from another Device. 3) The ability to support a non-reliable multicast message to be sent to a group of Devices to manipulate a resource on all the Devices in the group. 4) The core CoAP functionality MUST operate well over UDP and UDP MUST be implemented on CoAP Devices. There may be OPTIONAL functions in CoAP (e.g. delivery of larger chunks of data) which if implemented are implemented over TCP. Applications which require the optional TCP features will limit themselves to a narrower subset of deployment cases. 5) A definition of how to use CoAP to advertise about or query for a Device's description. This description may include the device name and a list of its Resources, each with a URL, an interface description URI (pointing e.g. to a Web Application Description Language (WADL) document) and an optional name or identifier. The name taxonomy used for this description will be consistent with other IETF work, e.g. draft-cheshire-dnsext-dns-sd. 6) Specification for the HTTP REST based API and translation to communicate with Devices. Translation should make use of Device description information and should not need code updates to deal with new Devices. 7) Consider operational and manageability aspects of the protocol and at a minimum provide a way to tell if a Device is powered on or not. The working group will not develop a reliable multicast solution, and will not develop a general service discovery solution. There is a desire for discovery and configuration features, but the working group has not yet closed in on an specific approach. Thus, the WG may explore these topics and adopt drafts that define requirements or set problem statements, but will not adopt implementable specifications without a recharter. Security, particularly keying of new Devices, is very challenging for these applications. The WG will work to select approaches to security bootstrapping which are realistic given the constraints and requirements of the network. To ensure that any two nodes can join together, all nodes must implement at least one universal bootstrapping method. Security can be achieved using either session security or object security. For both object and session security, the WG will work with the security area to select appropriate security framework and protocol as well as selecting a minimal required to implement cipher suite. CoAP will initially look at CMS (RFC 5652), TLS/DTLS, and EAP. The WG will coordinate on requirements from many organizations including OpenSG/NIST, ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI, ASHRAE/BACnet; other SDOs and organizations. The WG will closely coordinate with other IETF WGs including ROLL, 6LoWPAN, and appropriate groups in the IETF OPS and Security areas. Goals and Milestones: Apr 2010 - Select WG document for basis of the CoAP protocol Dec 2010 - CoAP protocol specification with mapping to HTTP Rest API submitted to IESG as PS Dec 2010 - Constrained security bootstrapping specification submitted to IESG as PS Jan 2011 - Recharter to add things reduced out of initial scope Nov 2012 - Using CoAP for group communications to IESG as Informational Internet-Drafts: - Group Communication for CoAP [draft-ietf-core-groupcomm-00] (32 pages) - Constrained Application Protocol (CoAP) [draft-ietf-core-coap-08] (88 pages) - Blockwise transfers in CoAP [draft-ietf-core-block-07] (28 pages) - Observing Resources in CoAP [draft-ietf-core-observe-03] (27 pages) - CoRE Link Format [draft-ietf-core-link-format-11] (20 pages) No Requests for Comments Cga & Send maIntenance (csi) ---------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Marcelo Bagnulo Gabriel Montenegro Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman 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-13] (7 pages) - Securing Neighbor Discovery Proxy: Problem Statement [draft-ietf-csi-sndp-prob-05] (22 pages) - Secure Proxy ND Support for SEND [draft-ietf-csi-proxy-send-06] (29 pages) - Certificate profile and certificate management for SEND [draft-ietf-csi-send-cert-11] (21 pages) - DHCPv6 and CGA Interaction: Problem Statement [draft-ietf-csi-dhcpv6-cga-ps-07] (10 pages) - Subject Key Identifier (SKI) SEND Name Type fields. [draft-ietf-csi-send-name-type-registry-07] (6 pages) Requests for Comments: RFC5909: Securing Neighbor Discovery Proxy: Problem Statement (22 pages) RFC6273: The Secure Neighbor Discovery (SEND) Hash Threat Analysis (7 pages) RFC6495: Subject Key Identifier (SKI) SEcure Neighbor Discovery (SEND) Name Type Fields (5 pages) * Updates RFC3971 RFC6496: Secure Proxy ND Support for SEcure Neighbor Discovery (SEND) (24 pages) RFC6494: Certificate Profile and Certificate Management for SEcure Neighbor Discovery (SEND) (12 pages) * Updates RFC3971 Call Control UUI Service for SIP (cuss) --------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Vijay Gurbani Enrico Marocco Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo Mailing Lists: General Discussion: cuss@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/cuss Archive: http://www.ietf.org/mail-archive/web/cuss/current/maillist.html Description of Working Group: The Call control UUI Service for SIP (CUSS) working group is chartered to define a Session Initiation Protocol (SIP) mechanism for transporting call-control related user-to-user information (UUI) for applications using SIP to establish media sessions. The information transported is essentially opaque to SIP, but is tagged with the application that generated it and the encoding method. One important application of this mechanism is interworking with the ISDN User to User Information Service. This application, defined by ITU-T Q.931, is extensively deployed in the PSTN today supporting such applications as contact centers, call centers, and automatic call distributors (ACDs). A major barrier to the movement of these applications to SIP is the lack of a standard mechanism to transport this information in SIP. For interworking with ISDN, minimal information about the content of the UUI is available to the PSTN-SIP gateways. In this special case, the application tag will indicate ISDN UUI Service 1 interworking. Call control UUI is a small piece of application information conveyed between user agents during call control operations. As a result, the information must be conveyed with the INVITE transaction. A goal is to avoid a dependency on multipart MIME support. The mechanism must interwork with the existing ISDN service but should also be extensible for use by other applications and non-ISDN protocols. Even though interworking with the PSTN is an important requirement, call control UUI can be exchanged between native SIP clients that do not have any ISUP support. Therefore, existing SIP-T encapsulation-based approaches defined in RFC3372 do not meet the requirements to transport this type of information. Mechanisms based on the SIP INFO method, RFC2976, will not be considered by the working group since the UUI contents carry information that must be conveyed during session setup at the user agent - the information must be conveyed with the INVITE transaction. The information must be passed with the session setup request (INVITE), responses to that INVITE, or session termination requests. As a result, it is not possible to use INFO in these cases. The working group will define guidelines for other applications to utilize the mechanism and the information that each application must specify to utilize the mechanism. New applications of the mechanism will require a standards-track document. The mechanism developed in this working group is applicable in the following situations: 1. The information is generated and consumed by an application during session setup using SIP, but the application is not necessarily even SIP aware. 2. The behavior of SIP entities that support it is not significantly changed (as discussed in Section 4 of RFC 5727). 3. User Agent Clients (UAC) and User Agent Servers (UAS) are the generator and consumer of the UUI data. Proxies may route based on the application tag. 4. Intermediary elements or proxies can remove or insert UUI information This mechanism is not applicable in the following situations: 1. The behavior of SIP entities that support it is significantly changed (as discussed in Section 4 of RFC 5727). 2. The information is generated and consumed at the SIP layer by SIP elements. 3. SIP elements besides the UAC and UAS might be interested in consuming (beyond adding or removing) the information. 4. There are specific privacy issues involved with the information being transported (e.g., geolocation or emergency-related information). The group will produce: - A problem statement and requirements document for implementing a SIP call control UUI mechanism. - A specification of the SIP extension to best meet those requirements. - An application usage specification for the ISDN UUI Service. Goals and Milestones: Aug 2011 - Problem statement and requirements document to IESG (Informational) Oct 2011 - SIP call control UUI specification to IESG (PS) Nov 2011 - ISDN UUI Service application usage specification to IESG (PS) Internet-Drafts: - Interworking ISDN Call Control User Information with SIP [draft-ietf-cuss-sip-uui-isdn-01] (17 pages) - Problem Statement and Requirements for Transporting User to User Call Control Information in SIP [draft-ietf-cuss-sip-uui-reqs-09] (12 pages) - A Mechanism for Transporting User to User Call Control Information in SIP [draft-ietf-cuss-sip-uui-04] (16 pages) No Requests for Comments DNS-based Authentication of Named Entities (dane) ------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Ondrej Sury Warren Kumari Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Stephen Farrell Secretary: Matt Lepinski Mailing Lists: General Discussion: dane@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dane Archive: http://www.ietf.org/mail-archive/web/dane/ Description of Working Group: Objective: Specify mechanisms and techniques that allow Internet applications to establish cryptographically secured communications by using information distributed through DNSSEC for discovering and authenticating public keys which are associated with a service located at a domain name. Problem Statement: Entities on the Internet are usually identified using domain names and forming a cryptographically secured connection to the entity requires the entity to authenticate its name. For instance, in HTTPS, a server responding to a query for is expected to authenticate as "www.example.com". Security protocols such as TLS and IPsec accomplish this authentication by allowing an endpoint to prove ownership of a private key whose corresponding public key is somehow bound to the name being authenticated. As a pre-requisite for authentication, then, these protocols require a mechanism for bindings to be asserted between public keys and domain names. DNSSEC provides a mechanism for a zone operator to sign DNS information directly, using keys that are bound to the domain by the parent domain; relying parties can continue this chain up to any trust anchor that they accept. In this way, bindings of keys to domains are asserted not by external entities, but by the entities that operate the DNS. In addition, this technique inherently limits the scope of any given entity to the names in zones he controls. This working group will develop mechanisms for zone operators to present bindings between names within their control and public keys, in such a way that these bindings can be integrity-protected (and thus shown to be authentically from the zone operator) using DNSSEC and used as a basis for authentication in protocols that use domain names as identifiers. Possible starting points for these deliverables include draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, and draft-josefsson-keyassure-tls. The mechanisms developed by this group will address bindings between domain names and keys, allowing flexibility for all key-transport mechanisms supported by the application protocols addressed (e.g., both self-signed and CA-issued certificates for use in TLS). The solutions specified by this working group rely upon the security of the DNS to provide source authentication for public keys. The decision whether the chain of trust provided by DNSSEC is sufficient to trust the key, or whether additional mechanisms are required to determine the acceptability of a key, is left to the entity that uses the key material. In addition to the protections afforded by DNSSEC, the protocols and mechanisms designed by this working group require securing the "last hop" by operating a local DNS resolver or securing the connection to remote resolver - this WG will not specify new mechanisms to secure that hop, but will reference existing specifications or document existing methods in order to allow implementations to interoperate securely. Initial deliverables for this working group are limited to distribution of bindings between names within the zone operator's control and public keys. More general statements of policy for a domain are out of scope, and new tasks in this area may only be adopted through a re-chartering. The group may also create documents that describe how protocol entities can discover and validate these bindings in the execution of specific applications. This work would be done in coordination with the IETF Working Groups responsible for the protocols. Goals and Milestones: Apr 2011 - First WG draft of standards-track protocol for using DNS to associate hosts with keys for TLS and DTLS May 2011 - First WG draft of standards-track protocols for using DNS to associate hosts with IPsec Sep 2011 - Protocol for using DNS to associate domain names with keys for TLS and DTLS to IESG Sep 2011 - Protocols for using DNS to associate domain names with keys for IPsec to IESG Nov 2011 - Recharter Internet-Drafts: - Using Secure DNS to Associate Certificates with Domain Names For TLS [draft-ietf-dane-protocol-16] (27 pages) - Use Cases and Requirements for DNS-based Authentication of Named Entities (DANE) [draft-ietf-dane-use-cases-06] (12 pages) Requests for Comments: RFC6394: Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE) (12 pages) Datagram Congestion Control Protocol (dccp) ------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Thomas Phelan Pasi Sarolahti Transport Area Directors: David Harrington Martin Stiemerling Wesley Eddy Transport Area Advisor: Wesley Eddy 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 Done - Complete WGLC for draft-ietf-dccp-simul-open as PS Done - Complete WGLC draft-ietf-dccp-quickstart as Experimental Done - Complete WGLC for draft-ietf-dccp-tfrc-rtt-option as Proposed Standard Mar 2011 - Complete WGLC for draft-ietf-dccp-udpencap as Proposed Standard 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-08] (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) - Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-UDP) [draft-ietf-dccp-udpencap-10] (20 pages) - Sender RTT Estimate Option for DCCP [draft-ietf-dccp-tfrc-rtt-option-07] (25 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 * Updated by RFC6335 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) * Updated by RFC6323 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) * Updated by RFC6323 RFC5634: Quick-Start for Datagram Congestion Control Protocol (DCCP) (22 pages) RFC5595: The Datagram Congestion Control Protocol (DCCP) Service Codes (19 pages) * Updates RFC4340 * Updated by RFC6335 RFC5596: Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal (25 pages) * Updates RFC4340 RFC5762: RTP and the Datagram Congestion Control Protocol (DCCP) (17 pages) RFC6323: Sender RTT Estimate Option for the Datagram Congestion Control Protocol (DCCP) (13 pages) * Updates RFC4342 * Updates RFC5622 Decoupled Application Data Enroute (decade) ------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Richard Woundy Haibin Song Transport Area Directors: David Harrington Martin Stiemerling Wesley Eddy Transport Area Advisor: David Harrington Tech Advisor: Alexey Melnikov Mailing Lists: General Discussion: decade@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/decade Archive: http://www.ietf.org/mail-archive/web/decade/current/maillist.html Description of Working Group: Peer-to-Peer (P2P) applications, including both P2P streaming and P2P file-sharing applications, make up a large fraction of traffic in the Internet today. One way to reduce access network and/or cross-domain bandwidth usage by P2P applications is to introduce storage capabilities in the network between hosts running P2P applications. Allowing P2P applications to store and retrieve data from inside the network can reduce traffic on the last-mile uplink, as well as backbone and transit links. Existing P2P caches often implement the specific P2P application protocols to operate transparently or act as super peers to provide in-network storage. However, it is challenging for P2P cache vendors to support a variety of evolving protocols. Also, for P2P applications, closed P2P caching systems limit effective utilization of in-network storage. Some P2P protocols may be entirely unsupported by a particular caching system. Additionally, applications may be better-equipped to decide how in-network storage is used to meet their specific requirements (e.g., data placement, access control and resource control). Note that providers of in-network storage may impose their own access control or resource usage policies. Both of these challenges can be effectively addressed by using open, standard protocols to access in-network storage. P2P applications can store and retrieve content in the in-network storage, as well as control resources (e.g., bandwidth, connections) consumed by peers in a P2P application. As a simple example, a peer can choose to store content in the in-network storage, and direct other peers to retrieve from that location, reducing last-mile link usage. Furthermore, since a P2P client may have multiple peers, it can control resources used by each peer to store and retrieve content. Though there are existing data access protocols (e.g., HTTP, NFS, WebDAV), they might be lacking capabilities for fine-grained access and resource control (e.g., bandwidth and connections) that are essential for today's advanced P2P applications. The Working Group (WG) will have three primary tasks. First, the WG will identify target applications to appropriately scope the problem and requirements. P2P applications are the primary target, but suitability to other applications with similar requirements may be considered depending on additional complexity required to support such applications. Second, the WG will identify the requirements to enable target applications to utilize in-network storage. Requirements will include the ability for an application to (1) store, retrieve, and manage data, (2) indicate access control policies for storing and retrieving data suitable to an environment with users across multiple administrative and security domains (e.g., in a P2P environment), and (3) indicate resource control policies for storing and retrieving data. Third, the WG will develop an architecture within which the DECADE protocol can be specified. This architecture will identify DECADE's relationship to existing IETF protocols and where (if any) new protocol is needed or extensions to existing protocols need to be made. The architecture will not specify a protocol or extension; if development of a new protocol is needed, the WG will seek to recharter for this purpose or might ask an existing WG to work on such extensions. The WG will focus on the following work items: - A "problem statement" document. This document provides a description of the problem and common terminology. - A requirements document. This document lists the requirements for the in-network storage service (e.g., supported operations) and the protocol to support it. The service will include storing, retrieving, and managing data as well as specifying both access control and resource control policies in the in-network storage pertaining to that data. - A survey document. This document will survey existing related mechanisms and protocols (e.g., HTTP, NFS, and WebDAV), and evaluate their applicability to DECADE. - An architecture document. This document will identify DECADE's relationship with existing IETF protocols. Existing protocols will be used wherever possible and appropriate to support DECADE's requirements. In particular, data storage, retrieval, and management may be provided by an existing IETF protocols. The WG will not limit itself to a single data transport protocol since different protocols may have varying implementation costs and performance tradeoffs. However, to keep interoperability manageable, a small number of specific, targeted, data transport protocols will be identified and used. - An document describing the integration of DECADE with existing P2P applications (e.g., integration with BitTorrent). If new protocol development is deemed necessary, the WG will be rechartered. It is not expected that all work items will be ready for IESG review by that point, but WG consensus must show that documents directing eventual protocol development (Requirements and Architecture document) have stabilized. This permits adjustments to such documents as necessary to maintain consistency as protocol development is done. The following issues are considered out-of-scope for the WG: - Specification of policies regarding copyright-protected or illegal content. - Locating the "best" in-network storage location from which to retrieve content if there are more than one location can provide the same content. - Developing a new protocol for data transport between P2P applications and in-network storage. Goals and Milestones: Done - Working Group Last Call for Problem Statement Done - Submit Problem Statement to IESG as Informational Done - Working Group Last Call for Survey document Done - Submit Survey document to IESG as Informational Jul 2011 - Working Group Last Call for Requirements document Jul 2011 - Working Group Last Call for Architecture document Aug 2011 - Submit Requirements document to IESG as Informational Sep 2011 - Identify need for rechartering Sep 2011 - Submit Architecture document to IESG as Informational Sep 2011 - Working Group Last Call for DECADE Integration Examples Dec 2011 - Submit DECADE Integration Examples to IESG as Informational Internet-Drafts: - DECoupled Application Data Enroute (DECADE) Problem Statement [draft-ietf-decade-problem-statement-05] (13 pages) - A Survey of In-network Storage Systems [draft-ietf-decade-survey-07] (43 pages) - DECADE Requirements [draft-ietf-decade-reqs-05] (24 pages) - DECADE Architecture [draft-ietf-decade-arch-04] (44 pages) - Integration Examples of DECADE System [draft-ietf-decade-integration-example-02] (30 pages) Requests for Comments: RFC6392: A Survey of In-Network Storage Systems (44 pages) Dynamic Host Configuration (dhc) -------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Ted Lemon John Jason Brzozowski Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman 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-15] (26 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-12] (30 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 DHCP Server Replies [draft-ietf-dhc-client-id-01] (5 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-09] (8 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-02] (7 pages) - Guidelines for Creating New DHCP Options [draft-ietf-dhc-option-guidelines-07] (18 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-06] (13 pages) - Extensions to Layer 2 Relay Agent [draft-ietf-dhc-l2ra-extensions-01] (22 pages) - The DHCPv4 Relay Agent Identifier Suboption [draft-ietf-dhc-relay-id-suboption-10] (7 pages) - DHCPv6 options for network boot [draft-ietf-dhc-dhcpv6-opt-netboot-11] (11 pages) - Dynamic Host Configuration Protocol DHCPINFORM Message Clarifications [draft-ietf-dhc-dhcpinform-clarify-06] (9 pages) - DHCPv4 lease query by Relay Agent Remote ID [draft-ietf-dhc-leasequery-by-remote-id-10] (18 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-05] (39 pages) - Forcerenew Nonce Authentication [draft-ietf-dhc-forcerenew-nonce-03] (11 pages) - Lightweight DHCPv6 Relay Agent [draft-ietf-dhc-dhcpv6-ldra-04] (14 pages) - Secure DHCPv6 Using CGAs [draft-ietf-dhc-secure-dhcpv6-04] (16 pages) - IEEE 802.11 parameters DHCP Option [draft-ietf-dhc-80211-option-01] (5 pages) - Relay-Supplied DHCP Options [draft-ietf-dhc-dhcpv6-relay-supplied-options-10] (8 pages) - Definition of the UUID-based DHCPv6 Unique Identifier (DUID-UUID) [draft-ietf-dhc-duid-uuid-04] (6 pages) - Prefix Exclude Option for DHCPv6-based Prefix Delegation [draft-ietf-dhc-pd-exclude-04] (10 pages) - Relay Agent Encapsulation for DHCPv4 [draft-ietf-dhc-dhcpv4-relay-encapsulation-02] (22 pages) - DHCPv6 Redundancy Deployment Considerations [draft-ietf-dhc-dhcpv6-redundancy-consider-02] (16 pages) - Configuring Cryptographically Generated Addresses (CGA) using DHCPv6 [draft-ietf-dhc-cga-config-dhcpv6-01] (10 pages) - Prefix Assignment in DHCPv6 [draft-ietf-dhc-host-gen-id-01] (10 pages) - DHCPv6 Failover Requirements [draft-ietf-dhc-dhcpv6-failover-requirements-00] (19 pages) - DHCPv4 over IPv6 Transport [draft-ietf-dhc-dhcpv4-over-ipv6-00] (9 pages) - DHCPv6 through Tunnels [draft-ietf-dhc-dhcpv6-tunnel-00] (5 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 * Updated by RFC6221 * Updated by RFC6422 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) * Updated by RFC6148 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) RFC5970: DHCPv6 Options for Network Boot (11 pages) RFC6148: DHCPv4 Lease Query by Relay Agent Remote ID (13 pages) * Updates RFC4388 RFC6221: Lightweight DHCPv6 Relay Agent (17 pages) * Updates RFC3315 RFC6355: Definition of the UUID-based DHCPv6 Unique Identifier (DUID-UUID) (6 pages) RFC6422: Relay-Supplied DHCP Options (8 pages) * Updates RFC3315 Diameter Maintenance and Extensions (dime) ------------------------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Lionel Morand Jouni Korhonen Operations and Management Area Directors: Dan Romascanu Ronald Bonica Benoit Claise 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, charging in network access, provisioning of configuration information within the network, and for new AAA session management uses within the extensibility rules of the Diameter base protocol. The DIME working group plans 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. - 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. - 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. - Protocol extensions for bulk and grouped AAA session management. The aim of this work is to study and standardize a solution for handling groups of AAA sessions within the Diameter base protocol context. The solution would define how to identify and handle grouped AAA sessions in commands and operations. Additionally, Diameter-based 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, and is within the extensibility rules of Diameter and AAA scope. Coordination with other IETF working groups and other SDOs (e.g. 3GPP) will be 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 Done - Submit 'Diameter NAT Control Application' as DIME working group item Done - Submit 'Diameter Capabilities Update' as DIME working group item 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 Done - Submit 'Diameter Extended NAPTR' as DIME working group item Done - Submit 'Realm-Based Redirection In Diameter' as DIME working group item Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized Routing' as DIME working group item Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic Key Transport' as DIME working group item Done - Submit 'Diameter Priority Attribute Value Pairs' as DIME working group item Done - Submit 'Diameter IKEv2 PSK' as DIME working group item Done - Submit Revision of 'Diameter Base Protocol' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic Key Transport' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Priority Attribute Value Pairs' to the IESG for consideration as a Proposed Standard Done - Submit Revision of 'Diameter Network Access Server Application - RFC 4005bis' as DIME working group item Done - Submit 'Diameter NAT Control Application' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter IKEv2 PSK' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Extended NAPTR' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized Routing' to the IESG for consideration as a Proposed Standard Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the IESG for consideration as a Proposed Standard Mar 2012 - Submit Revision of 'Diameter Network Access Server Application - RFC 4005bis' to the IESG for consideration as a Proposed Standard May 2012 - Submit 'Diameter Application Design Guidelines' to the IESG for consideration as a BCP document Jul 2012 - Submit 'Diameter Support for EAP Re-authentication Protocol' to the IESG for consideration as a Proposed Standard Aug 2012 - Submit 'problem statement and requirements for Diameter end-to-end security framework' as Dime working group item Aug 2012 - Submit a document on 'Protocol extension for bulk and group signaling' as a working group item Dec 2012 - Submit 'problem statement and requirements for Diameter end-to-end security framework' to the IESG for consideration as an Informational RFC Aug 2013 - Submit a document on 'Protocol extension for bulk and group signaling' to the IESG for consideration as a Proposed Standard Internet-Drafts: - The Diameter API [draft-ietf-dime-diameter-api-09] (46 pages) - Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction [draft-ietf-dime-mip6-split-18] (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-29] (151 pages) - Diameter Quality of Service Application [draft-ietf-dime-diameter-qos-16] (58 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-13] (27 pages) - Traffic Classification and Quality of Service Attributes for Diameter [draft-ietf-dime-qos-attributes-16] (44 pages) - Diameter Support for the EAP Re-authentication Protocol (ERP) [draft-ietf-dime-erp-09] (16 pages) - Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server [draft-ietf-dime-pmip6-05] (21 pages) - Diameter User-Name and Realm Based Request Routing Clarifications [draft-ietf-dime-nai-routing-05] (12 pages) - Diameter Credit Control Application MIB [draft-ietf-dime-diameter-cc-appl-mib-03] (21 pages) - Diameter Base Protocol MIB [draft-ietf-dime-diameter-base-protocol-mib-06] (51 pages) - Updated IANA Considerations for Diameter Command Code Allocations [draft-ietf-dime-diameter-cmd-iana-02] (10 pages) - Realm-Based Redirection In Diameter [draft-ietf-dime-realm-based-redirect-04] (7 pages) - The Diameter Capabilities Update Application [draft-ietf-dime-capablities-update-07] (7 pages) - Diameter Network Address and Port Translation Control Application [draft-ietf-dime-nat-control-13] (59 pages) - Diameter Support for Proxy Mobile IPv6 Localized Routing [draft-ietf-dime-pmip6-lr-07] (16 pages) - Diameter S-NAPTR Usage [draft-ietf-dime-extended-naptr-10] (14 pages) - Diameter IKEv2 SK: Shared Key-based Support for IKEv2 Server to Diameter Server Interaction [draft-ietf-dime-ikev2-psk-diameter-11] (22 pages) - Diameter Attribute-Value Pairs for Cryptographic Key Transport [draft-ietf-dime-local-keytran-14] (8 pages) - Diameter Priority Attribute Value Pairs [draft-ietf-dime-priority-avps-05] (8 pages) - Diameter Network Access Server Application [draft-ietf-dime-rfc4005bis-07] (65 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) RFC5719: Updated IANA Considerations for Diameter Command Code Allocations (10 pages) * Updates RFC3588 RFC5777: Traffic Classification and Quality of Service (QoS) Attributes for Diameter (43 pages) RFC5778: Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction (34 pages) RFC5729: Clarifications on the Routing of Diameter Requests Based on the Username and the Realm (11 pages) * Updates RFC3588 RFC5779: Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server (20 pages) RFC5866: Diameter Quality of Service Application (58 pages) RFC6408: Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage (14 pages) * Updates RFC3588 Dispatch (dispatch) ------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Mary Barnes Cullen Jennings Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo 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: Internet-Drafts: No Requests for Comments Distributed Mobility Management (dmm) ------------------------------------- Charter Last Modified: 2012-01-10 Current Status: Active Chairs: Julien Laganier Jouni Korhonen Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: mext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mext Archive: http://www.ietf.org/mail-archive/web/mext Description of Working Group: The Distributed Mobility Management (DMM) working group specifies IP mobility, access network and routing solutions, which allow for setting up IP networks so that traffic is distributed in an optimal way and does not rely on centrally deployed anchors to manage IP mobility sessions. The distributed mobility management solutions aim for transparency above the IP layer, including maintenance of active transport level sessions as mobile hosts or entire mobile networks change their point of attachment to the Internet. The protocol solutions should be based on existing IP mobility protocols, either host- or network-based, such as Mobile IPv6 [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and NEMO [RFC3963]. Solutions may also focus specifically on managing the use of care-of versus home addresses in an efficient manner for different types of communications. Although the maintenance of stable home address(es) and/or prefix(es) and upper level sessions is a desirable goal when mobile hosts/routers change their point of attachment to the Internet, it is not a strict requirement. Mobile hosts/routers should not assume that IP addressing including home address(es) and/or home network prefix(es) remain the same throughout the entire upper level session lifetime, or that support for mobility functions is provided on the network side in all conditions. The distributed mobility management solutions primarily target IPv6 Deployment and should not be tailored specifically to support IPv4, in particular in situations where private IPv4 addresses and/or NATs are used. At least IPv6 is assumed to be present in both the mobile host/router and the access networks. Independent of the distributed mobility management solution, backward compatibility must be maintained. If the network or the mobile host/router do not support the distributed mobility management enabling protocol, nothing should break. Work items related to the distributed mobility management include: o Solution Requirements: Define precisely the problem of distributed mobility management and identity the requirements for a distributed mobility management solution. o Practices: Document practices for the deployment of existing mobility protocols in a distributed mobility management environment. o Gap Analysis and extensions: identify the limitations in the current practices with respect to providing the expected functionality. o If limitations are identified as part of the above deliverable, specify extensions to existing protocols that removes these limitations within a distributed mobility management environment. Goals and Milestones: Done - Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for publication as a Proposed Standard Done - Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG for publication as a Proposed Standard Done - Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for publication as a Proposed Standard. Done - Submit I-D 'Motivation for Authentication I-D' to IESG for publication as Informational. Done - Submit Multiple CoA Registration to IESG Done - Submit I-D 'Goals for AAA HA Interface' to IESG for publication as Informational. Done - Submit -00 draft on Route Optimization Needs for Automobile and Highway Deployments Done - Submit -00 draft on Route Optimization Needs for Aircraft and Spacecraft Deployments Done - Submit I-D 'Mobility Header Home Agent Switch Message' to IESG for publication as a Proposed Standard Done - Submit final doc on Route Optimization Needs for Aircraft and Spacecraft Deployments, for Informational Done - Submit 00 draft on Binding Revocation Done - Submit the final doc on MIB for NEMO Basic Support to the IESG, for Proposed Standard Done - Submit draft on Binding Revocation to IESG Done - Submit I-D(s) related to specific updates and corrections of RFC 3775 to IESG for publication as Proposed Standard. Done - Submit the final doc on Prefix Delegation for NEMO to the IESG, for Proposed Standard Aug 2012 - Submit I-D 'Solution Requirements' as a working group document. To be Informational RFC. Aug 2012 - Submit I-D 'Practices and Gap Analysis' as a working group document. To be Informational RFC. Nov 2012 - Evaluate the need for additional working group document(s) for extensions to fill the identified gaps. Jan 2013 - Submit I-D 'Solution Requirements' to the IESG for consideration as an Informational RFC. Jan 2013 - Submit I-D 'Practices ' to the IESG for consideration as an Informational RFC. Mar 2013 - Submit I-D 'Gap Analysis' to the IESG for consideration as an Informational RFC. Mar 2013 - Evaluate the need for further work based on the identified gaps and revise the milestones and/or the charter of the group Internet-Drafts: - NEMO Management Information Base [draft-ietf-nemo-mib-03] (42 pages) - Motivations and Scenarios for Using Multiple Interfaces and Global Addresses [draft-ietf-monami6-multihoming-motivation-scenario-03] (20 pages) - Mobile Network Prefix Delegation [draft-ietf-nemo-prefix-delegation-02] (22 pages) - Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6) [draft-ietf-mip6-nemo-v4traversal-06] (28 pages) - Analysis of Multihoming in Mobile IPv6 [draft-ietf-monami6-mipv6-analysis-05] (31 pages) - Multiple Care-of Addresses Registration [draft-ietf-monami6-multiplecoa-15] (44 pages) - Home Agent Reliability Protocol (HARP) [draft-ietf-mip6-hareliability-10] (44 pages) - Generic Notification Message for Mobile IPv6 [draft-ietf-mip6-generic-notification-message-00] (10 pages) - RADIUS Mobile IPv6 Support [draft-ietf-mip6-radius-06] (48 pages) - Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks [draft-ietf-mext-aero-reqs-05] (31 pages) - AAA Goals for Mobile IPv6 [draft-ietf-mext-aaa-ha-goals-02] (12 pages) - NEMO Management Information Base [draft-ietf-mext-nemo-mib-07] (44 pages) - Mobile IPv6 Support for Dual Stack Hosts and Routers [draft-ietf-mext-nemo-v4traversal-11] (48 pages) - Automotive Industry Requirements for NEMO Route Optimization [draft-ietf-mext-nemo-ro-automotive-req-02] (25 pages) - Flow Bindings in Mobile IPv6 and NEMO Basic Support [draft-ietf-mext-flow-binding-12] (38 pages) - Mobility Support in IPv6 [draft-ietf-mext-rfc3775bis-14] (177 pages) - DHCPv6 Prefix Delegation for NEMO [draft-ietf-mext-nemo-pd-08] (16 pages) - Binding Revocation for IPv6 Mobility [draft-ietf-mext-binding-revocation-15] (40 pages) - Mobile IPv6 Generic Signaling Message [draft-ietf-mext-generic-signaling-message-00] (14 pages) - Guidelines for firewall administrators regarding MIPv6 traffic [draft-ietf-mext-firewall-admin-05] (12 pages) - Guidelines for firewall vendors regarding MIPv6 traffic [draft-ietf-mext-firewall-vendor-05] (8 pages) - Traffic Selectors for Flow Bindings [draft-ietf-mext-binary-ts-06] (19 pages) - Transport Layer Security-based Mobile IPv6 Security Framework for Mobile Node to Home Agent Communication [draft-ietf-mext-mip6-tls-02] (38 pages) No Requests for Comments DNS Extensions (dnsext) ----------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Olafur Gudmundsson Andrew Sullivan Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion: dnsext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dnsext Archive: http://www.ietf.org/mail-archive/web/dnsext/ Description of Working Group: The DNS has a large installed base and repertoire of protocol specifications. The DNSEXT working 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 consider work in the following areas: * DNSSEC and TSIG/TKEY algorithm maintenance * Mechanisms that complement, or are alternatives to, TSIG and SIG(0) * Hardening DNS protocol and providing guidance to implementers * Advancing existing DNS-related Proposed Standard RFCs to Draft/Full Standard * Obsoleting DNS-related RFCs * Improving DNS zone synchronization mechanisms * Examining transport protocols, possibly adding new ones * Mechanisms to alias DNS trees or parts thereof Before formal adoption of any work item at least 5 working group participants must publicly state that the item is within charter and is a 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. 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 Done - GOST DNSKEY and DS support advanced to IESG Done - AXFR Clarify to IESG Done - DNS existing transport protocol recommendations/clarifications to IESG Apr 2011 - RFC3597-bis Unknown RR advanced to IESG for PS Done - DNSKEY Registry fixes and allocation procedure advanced to IESG Jun 2011 - EDNS0-bis update advanced to IESG Done - DNAME-bis to IESG Aug 2011 - Algorithm signaling document to IESG Oct 2011 - DNSSEC Errata document to IESG Nov 2011 - Decision about new protocol elements, if any Nov 2011 - Requirements and current state survey document to IESG for publication Dec 2011 - IXFR-only to IESG Dec 2011 - If new protocol elements, recharter 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-15] (28 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-07] (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-16] (20 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) - DNAME Redirection in the DNS [draft-ietf-dnsext-rfc2672bis-dname-25] (22 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-08] (15 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) - Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry [draft-ietf-dnsext-dnssec-registry-fixes-08] (8 pages) - Cryptographic Algorithm Identifier Allocation for DNSSEC [draft-ietf-dnsext-dnssec-alg-allocation-04] (6 pages) - Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records for DNSSEC [draft-ietf-dnsext-dnssec-gost-08] (9 pages) - Handling of Unknown DNS Resource Record (RR) Types [draft-ietf-dnsext-rfc3597-bis-03] (8 pages) - DNS Transport over TCP - Implementation Requirements [draft-ietf-dnsext-dns-tcp-requirements-04] (9 pages) - A mechanism for synchronization across name servers on zone creation [draft-ietf-dnsext-newzone-notify-02] (9 pages) - Signaling Cryptographic Algorithm Understanding in DNSSEC [draft-ietf-dnsext-dnssec-algo-signal-03] (8 pages) - Domain Name System (DNS) IANA Considerations [draft-ietf-dnsext-5395bis-04] (19 pages) - Elliptic Curve DSA for DNSSEC [draft-ietf-dnsext-ecdsa-04] (8 pages) - Problem Statement: DNS Resolution of Aliased Names [draft-ietf-dnsext-aliasing-requirements-02] (22 pages) - xNAME RCODE and Status Bits Clarification [draft-ietf-dnsext-xnamercode-00] (9 pages) - DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates [draft-ietf-dnsext-dnssec-registry-update-00] (6 pages) - Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status [draft-ietf-dnsext-dnssec-algo-imp-status-00] (6 pages) Requests for Comments: RFC2782: A DNS RR for specifying the location of services (DNS SRV) (2 pages) * Obsoletes RFC2052 * Updated by RFC6335 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 * Updated by RFC6195 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 * Updated by RFC6014 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 * Updated by RFC6014 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 * Updated by RFC6014 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) RFC5936: DNS Zone Transfer Protocol (AXFR) (29 pages) * Updates RFC1034 * Updates RFC1035 RFC5933: Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC (9 pages) RFC5966: DNS Transport over TCP - Implementation Requirements (7 pages) * Updates RFC1035 * Updates RFC1123 RFC6014: Cryptographic Algorithm Identifier Allocation for DNSSEC (6 pages) * Updates RFC4033 * Updates RFC4034 * Updates RFC4035 RFC6195: Domain Name System (DNS) IANA Considerations (17 pages) * Updates RFC1183 * Updates RFC3597 Domain Name System Operations (dnsop) ------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Peter Koch Stephen Morris Operations and Management Area Directors: Dan Romascanu Ronald Bonica Benoit Claise 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-13] (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-16] (14 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-07] (16 pages) - AS112 Nameserver Operations [draft-ietf-dnsop-as112-ops-10] (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-06] (18 pages) - DNSSEC Operational Practices, Version 2 [draft-ietf-dnsop-rfc4641bis-08] (67 pages) - DNSSEC Policy & Practice Statement Framework [draft-ietf-dnsop-dnssec-dps-framework-05] (26 pages) - DNSSEC Key Timing Considerations [draft-ietf-dnsop-dnssec-key-timing-03] (33 pages) - DNSSEC Trust Anchor History Service [draft-ietf-dnsop-dnssec-trust-history-02] (11 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) RFC6168: Requirements for Management of Name Servers for the DNS (17 pages) Data for Reachability of Inter/tra-NetworK SIP (drinks) ------------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Sumanth Channabasappa Alexander Mayrhofer Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo 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: Aug 2011 - Request publication of Use Cases and Protocol Requirements document Sep 2011 - Request publication of protocol specification Sep 2011 - Request publication of protocol specification and a protocol transport mapping Internet-Drafts: - Consolidated Provisioning Problem Statement [draft-ietf-drinks-cons-rqts-00] (12 pages) - Data for Reachability of Inter/tra-NetworK SIP (DRINKS) Use cases and Protocol Requirements [draft-ietf-drinks-usecases-requirements-07] (24 pages) - SPPP Over SOAP and HTTP [draft-ietf-drinks-sppp-over-soap-08] (87 pages) - Session Peering Provisioning Protocol Data Model [draft-ietf-drinks-spprov-13] (59 pages) - Session Peering Provisioning (SPP) Protocol over SOAP [draft-ietf-drinks-spp-protocol-over-soap-00] (87 pages) - Session Peering Provisioning Framework (SPPF) [draft-ietf-drinks-spp-framework-00] (59 pages) Requests for Comments: RFC6461: Data for Reachability of Inter-/Intra-NetworK SIP (DRINKS) Use Cases and Protocol Requirements (15 pages) Email Address Internationalization (eai) ---------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: John Klensin Joseph Yee Applications Area Directors: Pete Resnick Barry Leiba Peter Saint-Andre Applications Area Advisor: Pete Resnick Secretary: Jiankang Yao 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: The email address has two parts, local part and domain part. Email address internationalization must deal with both. This working group's previous experimental efforts investigated the use of UTF-8 as a general approach to email internationalization. That approach is based on the use of an SMTP extension to enable the use of UTF-8 in envelope address local-parts, optionally in address domain-parts, and in mail headers. The mail header contexts can include both addresses and wherever existing protocols (e.g., RFC 2231) permit the use of encoded-words. All WG deliverables specified under the original charter, particularly the experimental protocol specifications, have been completed. The core specifications have been implemented and interoperability tests performed. The WG is now being rechartered to permit advancing revised versions of those specifications and supporting documents into the standards track. As a result of implementation and testing experience, the WG has concluded to drop the model of in-transit downgrading that was a key part of the original effort. In-transit downgrading approaches simply do not work well enough and predictably enough to be worth the considerable additional complexity that accompanies them. In particular, dropping in-transit downgrading eliminates the need for the first significant change to the syntax of an email address since RFC 821 and 822 were published in 1982. Work will therefore reflect a "no fallback" approach. That approach provides a very minimal transition mechanism, but is consistent with the long-term view that email with invalid addresses or syntax should be rejected, rather than fixed up in transit between submission servers and delivery servers. Discoverable fallback addresses that could be applied before or during message submission or after SMTP "final delivery" may be investigated. The WG may also develop other materials to give advice to implementers or operators. Those efforts may lead to informational documents or best practices recommendations, but are considered independent of the core documents. Work on them will progress only under the condition that it not delay the primary standards track specifications. The WG believes that the lessons learned from implementation and testing and removal of in-transit downgrading as a goal eliminates all major areas of controversy about the core specifications and should permit very rapid progress. Such rapid progress is an explicit goal for the WG; issues resolved in the past will not be revisited unless those who wish to do so can demonstrate data, reasoning, or consequences that were not considered earlier. At the same time, any attempt to significantly extend an established and widely deployed set of protocols may uncover new consequences or side effects that need consideration and evaluation. If faced with a choice between spending time on such new considerations, the WG will favor getting things right over accelerating the schedule. Deliverables The following deliverables are foreseen in this charter. The WG chairs may (re)structure the deliverables into specific documents or document sets as needed. Adding or removing documents other than those listed below as "Required" or "Additional" will require a charter update. Required Documents (these are the "core specifications" referred to elsewhere) * Overview and Framework for Internationalized Email, replacing RFC 4952 (Informational or Proposed Standard at IESG discretion once complete) * UTF-8 SMTP extension specification, replacing RFC 5336 (Proposed Standard) * Header format specification, replacing RFC 5335 (Proposed Standard) * Internationalized DSN specification, replacing RFC 5337 (Proposed Standard) * UTF-8 POP specification, replacing RFC 5721 (Proposed Standard) * UTF-8 IMAP specification, replacing RFC 5738 (Proposed Standard) Additional possible documents suggested. While milestones are listed for most of these documents, they may be dropped by the WG with the consent of the Responsible AD. * Advice for MUA implementors (Informational or BCP) * Advice for EAI deployment (Informational or BCP) * Advice for non-ASCII and ASCII addresses for the same mailbox (Informational or BCP) * Mailinglist (Informational or Standards Track, replacing draft-eai-mailinglist) * Mailto (Proposed Standard, updating draft-duerst-mailto-bis to reflect internationalized addresses) * Protocol extensions for RFC 4409 Submission Servers or configuration advice for the MUA->Submission server interface. 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 Done - Overview/architecture draft to IESG Done - SMTP Extensions to IESG Done - Header format to IESG Done - Downgrading in SMTP to IESG Done - Downgrading in POP to IESG Done - Downgrading in IMAP to IESG Done - Discussion of Recharter for standards track at IETF 77 May 2010 - New charter approval from IESG Jul 2010 - EAI Framework to IESG Sep 2010 - Headers to IESG Sep 2010 - SMTP to IESG Sep 2010 - DSN to IESG Nov 2010 - IMAP & POP3 to IESG Dec 2010 - Decision about possible changes or comments about Submission Servers. If the decision is to generate a document, the decision will include a schedule. Jan 2011 - Advice for non-ASCII & ASCII addresses to IESG Jan 2011 - Advice for MUA implementors to IESG Jan 2011 - Advice for EAI deployment to IESG Apr 2011 - Mailinglist to IESG Apr 2011 - Mailto (Proposed Standard) to IESG Internet-Drafts: - POP3 Support for UTF-8 [draft-ietf-eai-pop-10] (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-10] (15 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-08] (12 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-01] (6 pages) - Displaying Downgraded Messages for Email Address Internationalization [draft-ietf-eai-downgraded-display-04] (15 pages) - Internationalized Delivery Status and Disposition Notifications [draft-ietf-eai-dsnbis-01] (17 pages) - Overview and Framework for Internationalized Email [draft-ietf-eai-frmwrk-4952bis-12] (30 pages) - Guidelines for Internationalized Email Clients [draft-ietf-eai-email-clients-00] (16 pages) - POP3 Support for UTF-8 [draft-ietf-eai-rfc5721bis-03] (14 pages) - SMTP Extension for Internationalized Email [draft-ietf-eai-rfc5336bis-16] (21 pages) - Internationalized Email Headers [draft-ietf-eai-rfc5335bis-13] (14 pages) - Post-delivery Message Downgrading for Internationalized Email Messages [draft-ietf-eai-popimap-downgrade-03] (19 pages) - Internationalized Delivery Status and Disposition Notifications [draft-ietf-eai-rfc5337bis-dsn-06] (19 pages) - IMAP Support for UTF-8 [draft-ietf-eai-5378bis-01] (15 pages) - IMAP Support for UTF-8 [draft-ietf-eai-5738bis-03] (14 pages) - Mailing Lists and UTF-8 Addresses [draft-ietf-eai-mailinglistbis-01] (8 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) RFC5721: POP3 Support for UTF-8 (13 pages) RFC5738: IMAP Support for UTF-8 (15 pages) * Updates RFC3501 RFC5825: Displaying Downgraded Messages for Email Address Internationalization (14 pages) RFC5983: Mailing Lists and Internationalized Email Addresses (10 pages) Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Marc Linsner Richard Barnes Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Robert Sparks 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 Done - Submit 'LoST Extension for returning Boundary Information for Services' to the IESG for consideration as an Experimental RFC Oct 2010 - Submit 'Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements' to the IESG for consideration as an Experimental RFC Nov 2010 - Submit 'Using Imprecise Location for Emergency Call Routing' to the IESG for consideration as an Informational RFC Mar 2011 - Submit 'Additional Data related to a Call for Emergency Call Purposes' to the IESG for consideration as a Standards Track RFC Apr 2011 - Submit 'Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (SIP)' to the IESG for consideration as an Experimental RFC Dec 2011 - Submit 'Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices' to the IESG for consideration as a Standards Track RFC Jan 2012 - Submit 'Trustworthy Location Information' to the IESG for consideration as an Informational RFC Mar 2012 - Submit 'Public Safety Answering Point (PSAP) Callbacks' 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-14] (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-20] (26 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-05] (11 pages) - Specifying Holes in LoST Service Boundaries [draft-ietf-ecrit-specifying-holes-04] (17 pages) - Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements [draft-ietf-ecrit-lost-sync-16] (29 pages) - IANA Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications [draft-ietf-ecrit-local-emergency-rph-namespace-04] (8 pages) - LoST Service List Boundary Extension [draft-ietf-ecrit-lost-servicelistboundary-06] (16 pages) - Using Imprecise Location for Emergency Context Resolution [draft-ietf-ecrit-rough-loc-05] (18 pages) - Additional Data related to an Emergency Call [draft-ietf-ecrit-additional-data-02] (41 pages) - Common Alerting Protocol (CAP) based Emergency Alerts using the Session Initiation Protocol (SIP) [draft-ietf-ecrit-data-only-ea-03] (22 pages) - Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices [draft-ietf-ecrit-unauthenticated-access-04] (27 pages) - Trustworthy Location Information [draft-ietf-ecrit-trustworthy-location-03] (21 pages) - Public Safety Answering Point (PSAP) Callback [draft-ietf-ecrit-psap-callback-03] (23 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) RFC5964: Specifying Holes in Location-to-Service Translation (LoST) Service Boundaries (11 pages) RFC6197: Location-to-Service Translation (LoST) Service List Boundary Extension (15 pages) RFC6443: Framework for Emergency Calling Using Internet Multimedia (38 pages) RFC6444: Location Hiding: Problem Statement and Requirements (9 pages) Energy Management (eman) ------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Benoit Claise Bruce Nordman Operations and Management Area Directors: Dan Romascanu Ronald Bonica Benoit Claise Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion: eman@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/eman Archive: http://www.ietf.org/mail-archive/web/eman Description of Working Group: Energy management is becoming an additional requirement for network management systems due to several factors including the rising and fluctuating energy costs, the increased awareness of the ecological impact of operating networks and devices, and the regulation of governments on energy consumption and production. The basic objective of energy management is operating communication networks and other equipments with a minimal amount of energy while still providing sufficient performance to meet service level objectives. A discussion of detailed requirements has already started in the OPSAWG, but further exploration in the EMAN WG is needed. Today, most networking and network-attached devices neither monitor nor allow control energy usage as they are mainly instrumented for functions such as fault, configuration, accounting, performance, and security management. These devices are not instrumented to be aware of energy consumption. There are very few means specified in IETF documents for energy management, which includes the areas of power monitoring, energy monitoring, and power state control. The OPSAWG started working on a MIB module for monitoring energy consumption and power states of energy-aware devices and found that more than just a MIB module was needed to manage energy in networks. Rather a new framework for energy management needs to be developed first. A particular difference between energy management and other management tasks is that in some cases energy consumption of a device is not measured at the device itself but reported by a different place. For example, at a Power over Ethernet (PoE) sourcing device or at a smart power strip, in which cases one device is effectively metering another remote device. This requires a clear definition of the relationship between the reporting devices and identification of remote devices for which monitoring information is provided. Similar considerations will apply to power state control of remote devices, for example, at a PoE sourcing device that switches on and off power at its ports. Another example scenario for energy management is a gateway to low resourced and lossy network devices in wireless a building network. Here the energy management system talks directly to the gateway but not necessarily to other devices in the building network. The WG will investigate existing standards such as those from the IEC, ANSI, DMTF and others, and reuse existing work as much as possible. The EMAN WG will work on the management of energy-aware devices, Covered by the following items: 1. Requirements for energy management. The EMAN WG will develop a requirements document that will specify energy management properties that will allow networks and devices to become energy aware. In addition to energy awareness requirements, the need for control functions will be discussed. Specifically the need to monitor and control properties of devices that are remote to the reporting device should be discussed. 2. Energy management framework. The EMAN WG will create a framework document that will describe extensions to current management framework, required for energy management. This includes: power and energy monitoring, power states, power state control, and potential power state transitions. The framework will focus on energy management for IP-based network equipment (routers, switches, PCs, IP cameras, phones and the like). Particularly, the relationships between reporting devices, remote devices, and monitoring probes (such as might be used in low-power and lossy networks) need to be elaborated. For the case of a device reporting on behalf of other devices and controlling those devices, the framework will address the issues of discovery and identification of remote devices. 3. Energy-aware Networks and Devices MIB document The EMAN WG will develop a MIB module for monitoring energy-aware networks and devices. The module will address devices identification, context information, and potential relationship between reporting devices, remote devices, and monitoring probes. 4. Power and Energy Monitoring MIB document The EMAN WG will develop a document defining managed objects for monitoring of power states and energy consumption/production. The monitoring of power states includes: retrieving power states, properties of power states, current power state, power state transitions, and power state statistics. The managed objects will provide means for reporting detailed properties of the actual energy rate (power) and of accumulated energy. Further, it will provide information on electrical power quality. 5. Battery MIB document The EMAN WG will develop a document defining managed objects for battery monitoring, which will provide means for reporting detailed properties of the actual charge, age, and state of a battery and of battery statistics. 6. Applicability statement The EMAN WG will develop an applicability statement, describing the variety of applications that can use the energy framework and associated MIB modules. Potential examples are building networks, home energy gateway, etc. Finally, the document will also discuss relationships of the framework to other architectures and frameworks (such as smartgrid). The applicability statement will explain the relationship between the work in this WG and the other existing standards such as those from the IEC, ANSI, DMTF, and others. Goals and Milestones: Dec 2010 - Publish Internet draft on Energy Management Requirements Dec 2010 - Publish Internet draft on Battery MIB Dec 2010 - Publish Internet draft on Energy Management Framework Dec 2010 - Publish Internet draft on Energy-aware Networks and Devices MIB Dec 2010 - Publish Internet draft on Power and Energy Monitoring MIB Mar 2012 - Publish Internet draft on Energy Management Applicability Mar 2012 - Submit Internet draft on Energy Management Requirements for publication as Informational RFC Jul 2012 - Submit Internet draft on Energy Management Framework for publication as Informational RFC Jul 2012 - Submit Internet draft on Energy-aware Networks and Devices MIB for publication as Standard Track RFC Jul 2012 - Submit Internet draft on Power and Energy Monitoring MIB for publication as Standard Track RFC Jul 2012 - Submit Internet draft on Battery MIB for publication as Standard Track RFC Jul 2012 - Submit Internet draft on Energy Management Applicability for publication as Informational RFC Internet-Drafts: - Energy Management Framework [draft-ietf-eman-framework-03] (35 pages) - Requirements for Energy Management [draft-ietf-eman-requirements-05] (34 pages) - Energy-aware Networks and Devices MIB [draft-ietf-eman-energy-aware-mib-03] (32 pages) - Definition of Managed Objects for Battery Monitoring [draft-ietf-eman-battery-mib-04] (28 pages) - Power and Energy Monitoring MIB [draft-ietf-eman-energy-monitoring-mib-01] (77 pages) - Energy Management (EMAN) Applicability Statement [draft-ietf-eman-applicability-statement-00] (31 pages) No Requests for Comments EAP Method Update (emu) ----------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Joseph Salowey Alan DeKok Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Sean Turner 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 Done - Form password based mechanism design team Done - Submit first draft of shared secret mechanism I-D Done - Submit Strong Shared Secret Mechanism to IESG Done - Submit Tunnel/Password Method Requirements to IESG Nov 2010 - Call for Tunnel/Password Method Submissions Feb 2011 - Close Tunnel/Password Method Submissions and Begin Evaluation Jun 2011 - Channel Bindings Draft WGLC Jul 2011 - Tunnel/Password Method Selection Jul 2011 - Channel Bindings Draft to IESG Aug 2011 - Tunnel/Password Method WGLC Sep 2011 - Tunnel/Password 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-09] (25 pages) - Channel Binding Support for EAP Methods [draft-ietf-emu-chbind-13] (31 pages) - Tunnel EAP Method (TEAP) Version 1 [draft-ietf-emu-eap-tunnel-method-01] (88 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) FEC Framework (fecframe) ------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chair: Greg Shepherd Transport Area Directors: David Harrington Martin Stiemerling Wesley Eddy Transport Area Advisor: David Harrington 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 Done - FEC Grouping informational draft submitted to MMUSIC Done - FEC Streaming Framework submitted as Proposed Standard Done - Usage of FEC framework with RTP submitted as Proposed Standard Done - FEC SDP Elements submitted as Proposed Standard Dec 2011 - Transfer open FEC scheme documents to TSVWG Internet-Drafts: - FECFRAME requirements [draft-ietf-fecframe-req-02] (14 pages) - Session Description Protocol Elements for FEC Framework [draft-ietf-fecframe-sdp-elements-12] (19 pages) - Forward Error Correction (FEC) Framework [draft-ietf-fecframe-framework-16] (48 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-06] (17 pages) - RTP Payload Format for 1-D Interleaved Parity FEC [draft-ietf-fecframe-interleaved-fec-scheme-10] (32 pages) - Guidelines for Implementing DVB-IPTV Application-Layer Hybrid FEC Protection [draft-ietf-fecframe-dvb-al-fec-04] (11 pages) - Raptor FEC Schemes for FECFRAME [draft-ietf-fecframe-raptor-07] (22 pages) - Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in FEC Framework [draft-ietf-fecframe-pseudo-cdp-02] (11 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-06] (25 pages) - Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME [draft-ietf-fecframe-simple-rs-02] (21 pages) - Simple LDPC-Staircase Forward Error Correction (FEC) Scheme for FECFRAME [draft-ietf-fecframe-ldpc-01] (20 pages) Requests for Comments: RFC6015: RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC) (31 pages) RFC6363: Forward Error Correction (FEC) Framework (48 pages) RFC6364: Session Description Protocol Elements for FEC Framework (19 pages) Forwarding and Control Element Separation (forces) -------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Patrick Droz Jamal Hadi Salim Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Adrian Farrel Mailing Lists: General Discussion: forces@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/forces Archive: http://www.ietf.org/mail-archive/web/forces/current/maillist.html 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-17] (132 pages) - ForCES Applicability Statement [draft-crouch-forces-applicability-01] (10 pages) - ForCES Applicability Statement [draft-ietf-forces-applicability-10] (14 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-23] (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-11] (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-09] (29 pages) - ForCES Interoperability Draft [draft-ietf-forces-interoperability-04] (34 pages) - ForCES Logical Function Block (LFB) Library [draft-ietf-forces-lfb-lib-07] (103 pages) - Implementation Report for ForCES [draft-ietf-forces-implementation-report-03] (38 pages) - ForCES Implementation Experience Draft [draft-ietf-forces-implementation-experience-01] (19 pages) - ForCES Intra-NE High Availability [draft-ietf-forces-ceha-02] (23 pages) - Interoperability Report for Forwarding and Control Element Separation (ForCES) [draft-ietf-forces-interop-03] (36 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) RFC5810: Forwarding and Control Element Separation (ForCES) Protocol Specification (124 pages) RFC5811: SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element (ForCES) Protocol (28 pages) RFC5812: Forwarding and Control Element Separation (ForCES) Forwarding Element Model (134 pages) RFC5813: Forwarding and Control Element Separation (ForCES) MIB (17 pages) RFC6041: Forwarding and Control Element Separation (ForCES) Applicability Statement (14 pages) RFC6053: Implementation Report for Forwarding and Control Element Separation (ForCES) (34 pages) FTP Extensions, 2nd edition (ftpext2) ------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Tony Hansen Anthony Bryan Applications Area Directors: Pete Resnick Barry Leiba Peter Saint-Andre Applications Area Advisor: Pete Resnick Mailing Lists: General Discussion: ftpext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ftpext Archive: http://www.ietf.org/mail-archive/web/ftpext/ Description of Working Group: The Standard File Transfer Protocol specification in RFC 959 has been updated several times with command extensions of one sort or another, including those based on the extension mechanism of RFC 2389 (a complete list appears in RFC 5797 and the corresponding IANA registry at http://www.iana.org/assignments/ftp-commands-extensions). The following are active FTP related drafts: draft-bryan-ftp-hash draft-hethmon-mcmurray-ftp-hosts FTP extensions to support IPv4/IPv6 translation scenario draft-klensin-ftp-typeu-00 - FTP Extension for Internationalized Text The Working Group will: * Review and finalize drafts listed above. * Review and confirm or reject errata of current FTP RFCs. * Investigate the differences between FTP in theory (current RFCs) and practice, and recommend future work to align them. Any future work would require rechartering of the WG. The Working Group's specification deliverables are: * A document that specifies the HOST command (Proposed Standard). * A document that specifies the HASH command (Proposed Standard). * A document that specifies FTP extensions to support IPv4/IPv6 translation scenario. * A document that specifies FTP extensions for Internationalized Text. The Working Group must not introduce a new version of FTP, e.g. an incompatible FTP 2.0. Goals and Milestones: Nov 2010 - Submit 'File Transfer Protocol HOST Command for Virtual Hosts' as working group item (draft-hethmon-mcmurray-ftp-hosts will be used as a starting point) Nov 2010 - Submit 'File Transfer Protocol HASH Command for Cryptographic Hashes' as working group item (draft-bryan-ftp-hash will be used as a starting point) Nov 2010 - Submit 'FTP extensions to support IPv4/IPv6 translation' as working group item (draft-liu-ftp64-extension will be used as a starting point) Dec 2010 - Working group Last Call of HOST document Jan 2011 - Submit 'File Transfer Protocol HOST Command for Virtual Hosts' to the IESG for consideration as a Proposed Standard Jan 2011 - Working group Last Call of HASH document Feb 2011 - Submit 'File Transfer Protocol HASH Command for Cryptographic Hashes' to the IESG for consideration as a Proposed Standard Mar 2011 - Working group Last Call of 'FTP extensions to support IPv4/IPv6 translation' document Apr 2011 - Submit 'FTP Extension for Internationalized Text' as working group item May 2011 - Submit 'FTP extensions to support IPv4/IPv6 translation' to the IESG for consideration as Proposed Standard Jul 2011 - Working group Last Call of 'FTP Extension for Internationalized Text' Aug 2011 - Submit 'FTP Extension for Internationalized Text' to the IESG for consideration as Proposed Standard Sep 2011 - Close or recharter Internet-Drafts: - File Transfer Protocol HASH Command for Cryptographic Hashes [draft-ietf-ftpext2-hash-03] (16 pages) - File Transfer Protocol HOST Command for Virtual Hosts [draft-ietf-ftpext2-hosts-05] (22 pages) - FTP TYPE Extension for Internationalized Text [draft-ietf-ftpext2-typeu-03] (11 pages) - FTP consideration for IPv4/IPv6 transition [draft-ietf-ftpext2-ftp64-02] (7 pages) No Requests for Comments Geographic Location/Privacy (geopriv) ------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Richard Barnes Alissa Cooper Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Robert Sparks Tech Advisor: Lisa Dusseault Mailing Lists: General Discussion: geopriv@ietf.org To Subscribe: https://www.ietf.org/mailman//listinfo/geopriv 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 Done - Submit an draft for DHCP geodetic location to the IESG for publication as PS to obsolete 3825 Done - Submit an Architecture for Location and Location Privacy to the IESG for publication as Informational Done - Submit a Document Format for Filtering and Reporting PIDF-LO Location Notifications to the IESG for publication as PS Done - Submit a URI scheme for directly expressing geodetic location to the IESG for publication as PS Jan 2011 - Submit a DHCP Option for a Location Uniform Resource Identifier (URI) to the IESG for publication as PS Mar 2011 - Resubmit Geolocation Policy to the IESG for publication as PS Mar 2011 - Submit civic address registry values for street name and house number prefixes to the IESG for publication as Informational Mar 2011 - Submit a Location Dereferencing Protocol for HTTP-Enabled Location Delivery (HELD) to the IESG for publication as PS. Jun 2011 - Submit recommendations for LIS discovery conducted by hosts behind residential gateways as Informational Jun 2011 - Submit a draft that defines civic address parameters to allow the expression of a location relative to a reference point to the IESG for publication as PS. Jun 2011 - Submit a method that can be used to provide location-related measurement data to a Location Information Server (LIS) within a request for location information to the IESG for publication as PS. Jun 2011 - Submit a policy control mechanism for location configuration as Proposed Standard Dec 2012 - Submit recommendations for civic address extensions as PS 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-25] (48 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-12] (25 pages) - HTTP Enabled Location Delivery (HELD) [draft-ietf-geopriv-http-location-delivery-17] (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-11] (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-12] (13 pages) - Requirements for a Location-by-Reference Mechanism [draft-ietf-geopriv-lbyr-requirements-10] (26 pages) - Discovering the Local Location Information Server (LIS) [draft-ietf-geopriv-lis-discovery-16] (18 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-04] (35 pages) - Use of Device Identity in HTTP-Enabled Location Delivery (HELD) [draft-ietf-geopriv-held-identity-extensions-07] (30 pages) - A Uniform Resource Identifier for Geographic Locations ('geo' URI) [draft-ietf-geopriv-geo-uri-08] (24 pages) - Dynamic Host Configuration Protocol Options for Coordinate-based Location Configuration Information [draft-ietf-geopriv-rfc3825bis-18] (35 pages) - An Architecture for Location and Location Privacy in Internet Applications [draft-ietf-geopriv-arch-04] (41 pages) - Prefix elements for Road and House Numbers in PIDF-LO [draft-ietf-geopriv-prefix-01] (4 pages) - A Location Dereferencing Protocol Using HELD [draft-ietf-geopriv-deref-protocol-04] (24 pages) - Using Device-provided Location-Related Measurements in Location Configuration Protocols [draft-ietf-geopriv-held-measurements-04] (74 pages) - Relative Location Representation [draft-ietf-geopriv-relative-location-02] (36 pages) - Location Configuration Extensions for Policy Management [draft-ietf-geopriv-policy-uri-04] (18 pages) - Location Information Server (LIS) Discovery using IP address and Reverse DNS [draft-ietf-geopriv-res-gw-lis-discovery-02] (19 pages) - Specifying Civic Address Extensions in PIDF-LO [draft-ietf-geopriv-local-civic-02] (20 pages) Requests for Comments: RFC3693: Geopriv requirements (27 pages) * Updated by RFC6280 RFC3694: Threat Analysis of the geopriv Protocol (18 pages) * Updated by RFC6280 RFC3825: Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information (14 pages) * OBSOLETED BY RFC6225 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 * Updated by RFC5774 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) RFC5774: Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition (33 pages) * Updates RFC4776 RFC5687: GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements (21 pages) RFC5808: Requirements for a Location-by-Reference Mechanism (14 pages) RFC5870: A Uniform Resource Identifier for Geographic Locations ('geo' URI) (23 pages) RFC5985: HTTP-Enabled Location Delivery (HELD) (47 pages) RFC5986: Discovering the Local Location Information Server (LIS) (18 pages) RFC6155: Use of Device Identity in HTTP-Enabled Location Delivery (HELD) (27 pages) RFC6225: Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information (36 pages) * Obsoletes RFC3825 RFC6280: An Architecture for Location and Location Privacy in Internet Applications (41 pages) * Updates RFC3693 * Updates RFC3694 RFC6447: Filtering Location Notifications in the Session Initiation Protocol (SIP) (19 pages) Global Routing Operations (grow) -------------------------------- Charter Last Modified: 2012-02-01 Current Status: Active Chairs: Christopher Morrow Peter Schoenmaker Operations and Management Area Directors: Dan Romascanu Ronald Bonica Benoit Claise 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-18] (37 pages) - BGP Monitoring Protocol [draft-ietf-grow-bmp-06] (17 pages) - Routing System Stability [draft-ietf-grow-rss-00] (13 pages) - MPLS Tunnels for Virtual Aggregation [draft-ietf-grow-va-mpls-00] (5 pages) - FIB Suppression with Virtual Aggregation [draft-ietf-grow-va-06] (24 pages) - Requirements for the graceful shutdown of BGP sessions [draft-ietf-grow-bgp-graceful-shutdown-requirements-08] (19 pages) - Graceful BGP session shutdown [draft-ietf-grow-bgp-gshut-03] (12 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) - Auto-Configuration in Virtual Aggregation [draft-ietf-grow-va-auto-05] (6 pages) - Simple Virtual Aggregation (S-VA) [draft-ietf-grow-simple-va-04] (10 pages) - Distribution of diverse BGP paths. [draft-ietf-grow-diverse-bgp-path-dist-06] (23 pages) - Multi-threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) routing information export format with geo-location extensions [draft-ietf-grow-geomrt-08] (15 pages) - Unique Per-Node Origin ASNs for Globally Anycasted Services [draft-ietf-grow-unique-origin-as-02] (12 pages) - Time to Remove Filters for Previously Unallocated IPv4 /8s [draft-ietf-grow-no-more-unallocated-slash8s-05] (6 pages) - Operational Requirements for Enhanced Error Handling Behaviour in BGP-4 [draft-ietf-grow-ops-reqs-for-bgp-error-handling-02] (27 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) RFC6198: Requirements for the Graceful Shutdown of BGP Sessions (20 pages) RFC6382: Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services (10 pages) RFC6396: Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format (33 pages) RFC6397: Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions (8 pages) RFC6441: Time to Remove Filters for Previously Unallocated IPv4 /8s (5 pages) Host Identity Protocol (hip) ---------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: David Ward Gonzalo Camarillo Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman 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, from which end-point identifiers are taken. The public keys are typically, but not necessarily, self generated. HIP uses existing IP addressing and forwarding for locators and packet delivery. The architecture and protocol details for these mechanisms are currently specified in the following Experimental RFCs: o HIP Architecture (RFC 4423) o Host Identity Protocol (RFC 5201) There are several publicly known interoperating implementations, some of which are open source. The HIP WG was chartered to publish protocol specifications in documents whose quality and security properties would meet the requirements for publication as standards track documents. These specifications have been published as Experimental RFCs, because the effects of the protocol on applications and on the Internet as a whole were unknown. The Experimental RFCs produced by the HIP WG allowed the community to experiment with HIP technologies and learn from these experiments. The HIP WG will now produce standards track versions of the main HIP RFCs taking as a base the existing Experimental RFCs. The WG will also specify certificate handling in HIP in a standards track RFC. Additionally, the WG will finish the WG items it was working on before starting the standards track work. These WG items relate to how to build HIP-based overlays and will result in Experimental RFCs. The following are charter items for the working group: o Revise RFCs 4423, 4843, 5201, 5202, 5203, 5204, 5205, 5206, and 5770 as standards track RFCs. o Specify in a standards track RFC 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 in an Experimental RFC how to build a HIP-based overlay using RELOAD. o Specify in an Experimental RFC how to transport HIP messages over encrypted connections that were established using HIP. Goals and Milestones: Done - Submit Native API specification to the IESG Done - Submit Framework for HIP overlays specification to the IESG Done - Submit Multi-hop routing mechanism for HIP Done - Submit Upper-layer data transport in HIP to the IESG Done - WGLC Certs in HIP base exchange specification Done - WGLC the HIP over HIP specification Done - Submit Certs in HIP base exchange to the IESG as Experimental Done - Submit the HIP over HIP specification to the IESG Mar 2011 - WGLC the specification on how to build HIP-based overlays using RELOAD Apr 2011 - Submit the specification on how to build HIP-based overlays using RELOAD to the IESG May 2011 - WGLC RFC4423bis May 2011 - WGLC RFC4843bis May 2011 - WGLC RFC5201bis May 2011 - WGLC RFC5202bis Jun 2011 - Submit RFC5201bis to the IESG Jun 2011 - Submit RFC4843bis to the IESG Jun 2011 - Submit RFC4423bis to the IESG Jun 2011 - Submit RFC5202bis to the IESG Jul 2011 - WGLC RFC5203bis Jul 2011 - WGLC RFC5204bis Jul 2011 - WGLC RFC5205bis Jul 2011 - WGLC the mobility portion of RFC5206bis Aug 2011 - Submit RFC5203bis to the IESG Aug 2011 - Submit RFC5204bis to the IESG Aug 2011 - Submit RFC5205bis to the IESG Aug 2011 - Submit the mobility portion of RFC5206bis to the IESG Sep 2011 - WGLC RFC5770bis Sep 2011 - WGLC the multihoming portion of RFC5206bis Oct 2011 - Submit RFC5770bis to the IESG Oct 2011 - Submit the multihoming portion of RFC5206bis to the IESG Nov 2011 - WGLC Certs in HIP base exchange specification (referencing RFC5201bis) Dec 2011 - Submit Certs in HIP base exchange (referencing RFC5201bis) to the IESG as PS Jan 2012 - Recharter or close the WG 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-10] (33 pages) - Basic Socket Interface Extensions for Host Identity Protocol (HIP) [draft-ietf-hip-native-api-13] (19 pages) - Host Identity Protocol Certificates [draft-ietf-hip-cert-13] (14 pages) - HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment [draft-ietf-hip-bone-08] (22 pages) - HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper- layer Protocol Signaling (HICCUPS) [draft-ietf-hip-hiccups-06] (17 pages) - Host Identity Protocol (HIP) Multi-hop Routing Extension [draft-ietf-hip-via-04] (10 pages) - Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD) [draft-ietf-hip-reload-instance-04] (10 pages) - Encrypted Signaling Transport Modes for the Host Identity Protocol [draft-ietf-hip-over-hip-07] (13 pages) - Host Identity Protocol Architecture [draft-ietf-hip-rfc4423-bis-03] (27 pages) - An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID) [draft-ietf-hip-rfc4843-bis-02] (13 pages) - Host Identity Protocol (HIP) Registration Extension [draft-ietf-hip-rfc5203-bis-02] (13 pages) - Host Identity Protocol (HIP) Rendezvous Extension [draft-ietf-hip-rfc5204-bis-02] (15 pages) - Host Identity Protocol (HIP) Domain Name System (DNS) Extension [draft-ietf-hip-rfc5205-bis-02] (17 pages) - Host Identity Protocol Version 2 (HIPv2) [draft-ietf-hip-rfc5201-bis-07] (124 pages) - Host Mobility with the Host Identity Protocol [draft-ietf-hip-rfc5206-bis-03] (33 pages) - Host Multihoming with the Host Identity Protocol [draft-ietf-hip-multihoming-00] (22 pages) - Native NAT Traversal Mode for the Host Identity Protocol [draft-ietf-hip-native-nat-traversal-02] (15 pages) - Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) [draft-ietf-hip-rfc5202-bis-00] (37 pages) Requests for Comments: RFC4423: Host Identity Protocol (HIP) Architecture (24 pages) RFC5201: Host Identity Protocol (108 pages) * Updated by RFC6253 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) RFC5770: Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators (34 pages) RFC6028: Host Identity Protocol (HIP) Multi-hop Routing Extension (10 pages) RFC6078: Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS) (17 pages) RFC6079: HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE) (21 pages) RFC6253: Host Identity Protocol Certificates (12 pages) * Updates RFC5201 RFC6261: Encrypted Signaling Transport Modes for the Host Identity Protocol (13 pages) RFC6317: Basic Socket Interface Extensions for the Host Identity Protocol (HIP) (18 pages) Handover Keying (hokey) ----------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Glen Zorn Tina Tsou (Ting ZOU) Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Stephen Farrell 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: A mobile device has to re-authenticate each time it changes its point of attachment to the network. When it goes through the full procedure of authentication it creates a series of ruptures, during which the medium cannot flow. This results in a poor user experience during handover. However, it is possible to shorten the time it takes to re-authenticate by reusing the key information developed during the initial authentication. The Handover Keying Working Group is concerned with developing procedures for key reuse and delivery, while respecting good security practice. The Handover Keying Working Group has already done work on this subject, but it has not yet developed the complete set of procedures, protocols, and changes needed for different security environment scenarios and situations. 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 exchanges. 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" or "early 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 RFC 4962 and RFC 5247. 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) Not require 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 ===================== 1) A specification of Local Domain Name Discovery for ERP. Currently the use of DHCP mechanisms to request the local domain name is unspecified. There are other useful scenarios that need to be addressed. Lower layer announcement for local domain name is unspecified. Ambiguity with using initial full EAP exchange for re-authentication needs to be clarified. Additional re-authentication scenarios, for which there is interest, need to be addressed. 2) A specification of Early Authentication solutions. These include use of EAP to pre-establish authenticated keying material on a target authenticator prior to arrival of the peer. 3) A specification for a Hokey architecture Document. It includes deployment of ERP and EAP early authentication protocol in the mobile environment. There are various useful scenarios that need to be addressed. This specification and the revision of RFC5296 should be conducted in parallel. 4) Assistance to the 802.21a group in specifying the integration of EAP pre-authentication with IEEE 802.21a. The Hokey Working Group shall perform tasks that are complementary to and do not duplicate work being done in IEEE 802.21a. 6) A specification for NAS-Authenticator interaction. NAS interaction can be used to release resources in the old NAS and achieve faster initiation of authentication. Related work in external SDOs on authenticator/NAS interaction for re-authentication may be taken into consideration. 7) A revision of RFC 5296 to eliminate unnecessary references to the home server. 8) Assistance to the radext and dime Working Groups in developing AAA support for handoff keying. 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 Done - First draft on Local Domain Name Discovery for ERP Nov 2009 - First draft on Early Authentication solutions Mar 2010 - First draft on Hokey architecture Mar 2010 - First draft on NAS-Authenticator Interaction Jul 2010 - First draft on revision of RFC 5296 Mar 2011 - Submit the Local Domain Name Discovery for ERP draft to IESG Mar 2011 - Submit the Early Authentication solutions draft to IESG Jul 2011 - Submit the NAS-Authenticator Interaction draft to IESG Nov 2011 - Submit the Hokey architecture draft to IESG Nov 2011 - Submit the revision of RFC 5296 to IESG Mar 2012 - 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-14] (13 pages) - Extensible Authentication Protocol (EAP) Early Authentication Problem Statement [draft-ietf-hokey-preauth-ps-13] (21 pages) - The ERP Local Domain Name DHCPv6 Option [draft-ietf-hokey-ldn-discovery-11] (7 pages) - EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK) [draft-ietf-hokey-erp-aak-08] (18 pages) - Handover Keying (HOKEY) Architecture Design [draft-ietf-hokey-arch-design-11] (20 pages) - EAP Extensions for EAP Re-authentication Protocol (ERP) [draft-ietf-hokey-rfc5296bis-06] (43 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) RFC5749: Distribution of EAP-Based Keys for Handover and Re-Authentication (12 pages) RFC5836: Extensible Authentication Protocol (EAP) Early Authentication Problem Statement (21 pages) RFC6440: The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option (6 pages) Home Networking (homenet) ------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Mark Townsley Ray Bellis Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman Internet Area Advisor: Ralph Droms Tech Advisor: Acee Lindem Mailing Lists: General Discussion: homenet@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/homenet Archive: http://www.ietf.org/mail-archive/web/homenet/ Description of Working Group: This working group focuses on the evolving networking technology within and among relatively small "residential home" networks. For example, an obvious trend in home networking is the proliferation of networking technology in an increasingly broad range and number of devices. This evolution in scale and diversity sets some requirements on IETF protocols. Some of the relevant trends include: o Multiple segments: While less complex L3-toplogies involving as few subnets as possible are preferred in home networks for a variety of reasons including simpler management and service discovery, the introduction of more than one subnet into a home network is enough to add complexity that needs to be addressed, and multiple dedicated segments are necessary for some cases. For instance, a common feature in modern home routers in the ability to support both guest and private network segments. Also, link layer networking technology is poised to become more heterogeneous, as networks begin to employ both traditional Ethernet technology and link layers designed for low-powered sensor networks. Finally, similar needs for segmentation may occur in other cases, such as separating building control or corporate extensions from the Internet access network for the home. Different segments may be associated with subnets that have different routing and security policies. o Service providers are deploying IPv6, and support for IPv6 is increasingly available in home gateway devices. While IPv6 resembles IPv4 in many ways, it changes address allocation principles and allows direct IP addressability and routing to devices in the home from the Internet. This is a promising area in IPv6 that has proved challenging in IPv4 with the proliferation of NAT. o End-to-end communication is both an opportunity and a concern as it enables new applications but also exposes nodes in the internal networks to receipt of unwanted traffic from the Internet. Firewalls that restrict incoming connections may be used to prevent exposure, however, this reduces the efficacy of end-to-end connectivity that IPv6 has the potential to restore. Home networks need to provide the tools to handle these situations in a manner accessible to all users of home networks. Manual configuration is rarely, if at all, possible, as the necessary skills and in some cases even suitable management interfaces are missing. The purpose of this working group is to focus on this evolution, in particular as it addresses the introduction of IPv6, by developing an architecture addressing this full scope of requirements: o prefix configuration for routers o managing routing o name resolution o service discovery o network security The task of the group is to produce an architecture document that outlines how to construct home networks involving multiple routers and subnets. This document is expected to apply the IPv6 addressing architecture, prefix delegation, global and ULA addresses, source address selection rules and other existing components of the IPv6 architecture, as appropriate. The architecture document should drive what protocols changes, if any, are necessary. Specific protocol work described below is expected to be within the scope of the working group once the architecture work is complete. However, the group is required to review its charter and milestones with the IESG and IETF community before submitting documents that make protocol changes. It is expected that the group has to discuss some of the below solutions, however, in order to complete the architecture work. The group will apply existing protocols to handle the five requirements above. For prefix configuration, existing protocols are likely sufficient, and at worst may need some small enhancements, such as new options. For automatic routing, it is expected that existing routing protocols can be used as is, however, a new mechanism may be needed in order to turn a selected protocol on by default. For name resolution and service discovery, extensions to existing multicast-based name resolution protocols are needed to enable them to work across subnets. For network security, the group shall document the concept of "advanced security" as a further development of "simple security" from RFC 6092. The main goal of this work is to enable a security policy that adapts to IPv6 threats as they emerge, taking into account not only traffic from the Internet at large, but within and leaving the home network itself. It is expected that the working group will define a set of protocol specifications to accomplish the five requirements from above. However, it is not in the scope of the working group to define entirely new routing protocols or address allocation protocols. As noted, additional options or other small extensions may be necessary to use the existing protocols in these new configuration tasks. The working group shall also not make any changes to IPv6 protocols or addressing architecture. Prefix configuration, routing, and security related work shall not cause any changes that are not backwards compatible to existing IPv6 hosts. There may be host visible changes in the work on naming and discovery protocols, however. In its design, the working group shall also consider security aspects and the impact on manageability. The main focus of the working group is home networks, but the group's results may also find applications in other small networks. The group should assume that an IPv4 network may have to co-exist alongside the IPv6 network and should take this into account insofar as alignment with IPv6 is desirable. But the group should also ensure that even IPv6-only are possible, and while IP-version agnostic work is of course desirable, IPv4-specific work is outside the scope of the group. The working group will liaise with the relevant IETF working groups. In particular, the group should work closely with the V6OPS working group, review any use or extension of DHCP with the DHC working group, and work with additional DNS requirements with the DNSEXT and DNSOP working groups. If it turns out that additional options are needed for a routing protocol, they will be developed in the appropriate Routing Area working group, with the HOMENET working group providing the architecture and requirements for such enhancements. The working group will also liason with external standards bodies where it is expected that there are normative dependencies between the specifications of the two bodies. It is expected that in the architecture definition stage liaising with the Broadband Forum, DLNA, UPnP Forum, OASIS, ZigBee Alliance and other SDOs is necessary, as is understanding existing technology from these groups. Goals and Milestones: Jul 2011 - Formation of the working group Sep 2011 - First WG draft on the architecture Dec 2011 - Submission of the architecture draft to the IESG as Informational RFC Dec 2011 - Charter re-evaluation based on the architecture work Dec 2011 - First WG draft on prefix configuration Dec 2011 - First WG draft on routing Jan 2012 - First WG draft on name resolution Feb 2012 - First WG draft on service discovery Feb 2012 - First WG draft on perimeter security Feb 2012 - Start of routing related work in the relevant routing area working group, if needed Mar 2012 - Submission of the prefix configuration draft to the IESG as Standards Track RFC Apr 2012 - Submission of the routing draft to the IESG as Informational RFC Sep 2012 - Submission of the name resolution draft to the IESG as Standards Track RFC Nov 2012 - Submission of the service discovery draft to the IESG as Standards Track RFC Dec 2012 - Submission of the perimeter security draft to the IESG as Informational RFC Internet-Drafts: - Home Networking Architecture for IPv6 [draft-ietf-homenet-arch-01] (34 pages) No Requests for Comments Hypertext Transfer Protocol Bis (httpbis) ----------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chair: Mark Nottingham Applications Area Directors: Pete Resnick Barry Leiba Peter Saint-Andre Applications Area Advisor: Peter Saint-Andre Mailing Lists: General Discussion: ietf-http-wg@w3.org To Subscribe: ietf-http-wg-request@w3.org Archive: http://lists.w3.org/Archives/Public/ietf-http-wg/ 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 mechanisms (e.g., Basic and Digest authentication, cookies, TLS) for common applications It will also incorporate the generic authentication framework from RFC 2617, without obsoleting or updating that specification's definition of the Basic and Digest schemes. Finally, it will incorporate relevant portions of RFC 2817 (in particular, the CONNECT method and advice on the use of Upgrade), so that that specification can be moved to Historic status. 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 (or set of documents) that is suitable to supersede RFC 2616 and move RFC 2817 to Historic status * A document cataloguing the security properties of HTTP Goals and Milestones: Done - First HTTP Revision Internet Draft Done - First HTTP Security Properties Internet Draft Nov 2010 - Request Last Call for HTTP Revision Nov 2010 - Request Last Call for HTTP Security Properties Apr 2011 - Submit HTTP Revision to IESG for consideration as a Draft Standard Apr 2011 - 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-18] (92 pages) - HTTP/1.1, part 2: Message Semantics [draft-ietf-httpbis-p2-semantics-18] (74 pages) - HTTP/1.1, part 3: Message Payload and Content Negotiation [draft-ietf-httpbis-p3-payload-18] (44 pages) - HTTP/1.1, part 4: Conditional Requests [draft-ietf-httpbis-p4-conditional-18] (30 pages) - HTTP/1.1, part 5: Range Requests and Partial Responses [draft-ietf-httpbis-p5-range-18] (30 pages) - HTTP/1.1, part 6: Caching [draft-ietf-httpbis-p6-cache-18] (48 pages) - HTTP/1.1, part 7: Authentication [draft-ietf-httpbis-p7-auth-18] (23 pages) - Security Requirements for HTTP [draft-ietf-httpbis-security-properties-05] (14 pages) - Initial Hypertext Transfer Protocol (HTTP) Method Registrations [draft-ietf-httpbis-method-registrations-07] (6 pages) - Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) [draft-ietf-httpbis-content-disp-10] (17 pages) - Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations [draft-ietf-httpbis-authscheme-registrations-02] (4 pages) Requests for Comments: RFC6266: Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) (14 pages) * Updates RFC2616 BiDirectional or Server-Initiated HTTP (hybi) --------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Salvatore Loreto Gabriel Montenegro Applications Area Directors: Pete Resnick Barry Leiba Peter Saint-Andre Applications Area Advisor: Peter Saint-Andre Secretary: S Moonesamy Mailing Lists: General Discussion: hybi@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/hybi Archive: http://www.ietf.org/mail-archive/web/hybi/current/maillist.html Description of Working Group: HTTP has most often been used as a request/response protocol, leading to clients polling for new data, or users hitting the refresh button in their browsers. Recent web applications are finding ways to communicate with web servers in realtime, pushing data from the server-side to the client as soon as it is available. However, these applications at present can only use a variety of HTTP mechanisms (e.g. long polling requests) to communicate with web servers bidirectionally. The Hypertext-Bidirectional (HyBi) working group will seek standardization of one approach to maintain bidirectional communications between the HTTP client, server and intermediate entities, which will provide more efficiency compared to the current use of hanging requests. A general approach is preferred, with abstract semantics that can apply to a large number of applications. The Web is the design space into which the solution will be deployed. Since the existing Web is much more complicated that it seems, the working group will document how it works first, with special attention to deployed infrastructure (e.g. web clients, intermediaries, firewalls, NATs, web servers) and programming environments. New features will be required of clients, servers, or intermediaries allowing a more scalable and robust end-to-end experience. Although multiple protocols exist as starting points, backward compatibility with these protocols is not a requirement. In particular, the working group has liaised with the W3C WebApps working group around the WebSockets protocol and the need to support the WebSocket API; as agreed by both parties, the HyBi working group will take on prime responsibility for the specification of the WebSockets protocol, taking into consideration all the requirements, needs and eventual concerns raised by the W3C WebApps working group. The draft-hixie-thewebsocketprotocol "The Web Socket protocol" is considered as the input document for the working group. Wide browser support is a goal for the bidirectional communication mechanism, however the solution should also be suitable for clients other than Web Browsers. The Working Group will work to standardize a generic solution that can work efficiently in as many of the deployed environments as possible and in particular in all the elements of the web infrastructure (e.g. web browser, generic HTTP client, HTTP server and HTTP-aware intermediaries like proxies, load balancers, caches, etc.) and it is not specific for just one. The Working Group should consider: * Implementer experience * Impact on existing implementations and deployments * Ability to achieve broad implementation * Ability to address broader use cases than those covered in the input document The Working Group will produce one or more documents suitable for consideration as Proposed Standard that will: * Define a characterization of the design space * Define a solution for the bidirectional web communication Goals and Milestones: Apr 2010 - Submit a document as a working group item describing the Web Socket requirements (draft-hixie-thewebsocketprotocol will be used as a starting point for further work.) Apr 2010 - Submit 'The Web Socket protocol' as working group item (draft-hixie-thewebsocketprotocol will be used as a starting point for further work.) Jul 2010 - Start Working Group Last Call on the WebSocket requirements Jul 2010 - Submit a document as a working group item describing the Design Space characterization Sep 2010 - Submit the 'Web Socket requirements' to the IESG for consideration as an Informational document Nov 2010 - Start Working Group Last Call on the Design Space characterization Nov 2010 - Start of discussion about Web Socket extensions the group should work on Dec 2010 - Submit the 'Design Space characterization' to the IESG for consideration as an Informational document Mar 2011 - Start Working Group Last Call on 'The Web Socket protocol' Mar 2011 - Prepare milestone update to start new work within the scope of the charter Apr 2011 - Submit the 'The Web Socket protocol' to the IESG for consideration as a Proposed Standard May 2011 - Close or recharter Internet-Drafts: - HyBi WebSocket Requirements and Features [draft-ietf-hybi-websocket-requirements-03] (9 pages) - Design Space for Bidirectional Protocols [draft-ietf-hybi-design-space-00] (9 pages) - The WebSocket protocol [draft-ietf-hybi-thewebsocketprotocol-18] (77 pages) Requests for Comments: RFC6455: The WebSocket Protocol (71 pages) Inter-Domain Routing (idr) -------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Susan Hares John Scudder Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Stewart Bryant 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, develop, and support the Border Gateway Protocol Version 4 (BGP-4) [RFC 4271] capable of supporting policy based routing for TCP/IP internets. The main objective of the working group is to support the use of BGP-4 by IP version 4 and IP version 6 networks. The working group will also continue to work on improving the robustness and scalability of BGP. IDR will review extensions made to BGP in other working groups at least at WG document adoption and during working group last calls. The IDR working group will also provide advice and guidance on BGP to other working groups as requested. Work Items: The IDR working group will work on correctness, robustness and scalability of the BGP protocol, as well as clarity and accuracy of the BGP document set. The group will also work on extensions beyond these areas when specifically added to the charter. The current additional work items are: - Relax the definition of BGP identifiers to only require AS-wide uniqueness. This change must be made in a backward compatible way. - Specify a means to non-disruptively introduce new BGP Capabilities to an existing BGP session. - Upgrade of the base BGP specification to Full Standard - Define AS_PATH based Outbound Route Filtering. - MIB v2 for BGP-4 - Augment the BGP multiprotocol extensions to support the use of multiple concurrent sessions between a given pair of BGP speakers. Each session is used to transport routes related by some session- based attribute such as AFI/SAFI. This will provide an alternative to the MP-BGP approach of multiplexing all routes onto a single connection. - Support for four-octet AS Numbers in BGP. - Revisions to the BGP 'Minimum Route Advertisement Interval' deprecating the previously recommended values and allowing for withdrawals to be exempted from the MRAI. - Advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. Each path is identified by a path identifier in addition to the address prefix. - Revised error handling rules for optional transitive BGP attributes so that a BGP speaker is no longer required to reset the session over which a malformed attribute is received. Provide guidelines for authors of documents that define new optional transitive attributes, and re-assess procedures for existing optional transitive attributes - Specify Link Bandwidth Extended Community for use in unequal cost load balancing. - The definition of an "Accumulated IGP Metric" attribute for BGP to report the sum of the metric of each link along the path. This attribute is for use in a restricted environment where: - all ASes are subject to the administrative control - some form of tunneling is used to deliver a packet to its next BGP hop - where the path for a route leads outside the AS to which the BGP speaker adding the attribute belongs. - Advertisement of the best external route in BGP to assist with resolution of the next hop in the chosen data plane. 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 Done - Prefix and ASpath ORF draft to IESG as a Proposed Standard Mar 2010 - Solicit work items for scalability improvements Aug 2010 - Submit AS-wide Unique BGP Identifier for BGP-4 to IESG as a Proposed Standard Aug 2010 - Submit Dynamic Capability for BGP-4 to IESG as a Proposed Standard Aug 2010 - Submit ASpath ORF draft to IESG as a Proposed Standard Aug 2010 - Submit MIB v2 for BGP-4 to IESG as a Proposed Standard Nov 2010 - Submit BGP Support for Four-octet AS Number Space (revised version) to IESG as a Proposed Standard Nov 2010 - Submit Revisions to the BGP 'Minimum Route Advertisement Interval' to IESG as a Proposed Standard Nov 2010 - Submit Advertisement of Multiple Paths in BGP to IESG as a Proposed Standard Nov 2010 - Submit BGP Link Bandwidth Extended Community to IESG as a Proposed Standard Nov 2010 - Submit Advertisement of the best external route in BGP to IESG as a Proposed Standard Dec 2010 - Submit Multisession BGP to IESG as a Proposed Standard Dec 2010 - Submit Error Handling for Optional Transitive BGP Attributes to IESG as a Proposed Standard Dec 2010 - Submit ASpath ORF to IESG as a Proposed Standard Dec 2010 - Revise WG charter Mar 2011 - Submit The Accumulated IGP Metric Attribute for BGP to IESG as a Proposed Standard Mar 2011 - Progress base BGP specification (RFC 4271) as Full 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-13] (45 pages) - Dynamic Capability for BGP-4 [draft-ietf-idr-dynamic-cap-14] (7 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-15] (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 (RFC1771 to RFC4271) [draft-ietf-idr-bgp-issues-05] (170 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-07] (19 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-07] (14 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-04] (4 pages) - Advertisement of Multiple Paths in BGP [draft-ietf-idr-add-paths-06] (8 pages) - Generic Subtype for BGP Four-octet AS specific extended community [draft-ietf-idr-as4octet-extcomm-generic-subtype-05] (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-04] (6 pages) - BGP Support for Four-octet AS Number Space [draft-ietf-idr-rfc4893bis-05] (11 pages) - Revised Error Handling for BGP UPDATE Messages [draft-ietf-idr-optional-transitive-04] (10 pages) - BGP Link Bandwidth Extended Community [draft-ietf-idr-link-bandwidth-03] (5 pages) - Advertisement of the best external route in BGP [draft-ietf-idr-best-external-05] (21 pages) - Multiprotocol Extensions for BGP-4 [draft-ietf-idr-rfc4760bis-03] (13 pages) - BGP Bestpath Selection Criteria Enhancement [draft-ietf-idr-bgp-bestpath-selection-criteria-05] (9 pages) - BGP Advisory Message [draft-ietf-idr-advisory-00] (7 pages) - Extended Optional Parameters Length for BGP OPEN Message [draft-ietf-idr-ext-opt-param-03] (5 pages) - Subcodes for BGP Finite State Machine Error [draft-ietf-idr-fsm-subcode-02] (5 pages) - IPv6 Extensions for Route Target Distribution [draft-ietf-idr-bgp-ipv6-rt-constrain-01] (7 pages) - Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP [draft-ietf-idr-deprecate-as-sets-07] (6 pages) - Best Practices for Advertisement of Multiple Paths in IBGP [draft-ietf-idr-add-paths-guidelines-02] (22 pages) - Assigned BGP extended communities [draft-ietf-idr-reserved-extended-communities-02] (5 pages) - BGP Optimal Route Reflection (BGP-ORR) [draft-ietf-idr-bgp-optimal-route-reflection-01] (19 pages) - Dissemination of Flow Specification Rules for IPv6 [draft-ietf-idr-flow-spec-v6-02] (8 pages) - Enhanced Route Refresh Capability for BGP-4 [draft-ietf-idr-bgp-enhanced-route-refresh-01] (6 pages) - Extended Message support for BGP [draft-ietf-idr-bgp-extended-messages-02] (5 pages) - Revised Error Handling for BGP UPDATE Messages [draft-ietf-idr-error-handling-01] (10 pages) - Codification of AS 0 processing. [draft-ietf-idr-as0-03] (7 pages) - BGP Custom Decision Process [draft-ietf-idr-custom-decision-00] (8 pages) - Notification Message support for BGP Graceful Restart [draft-ietf-idr-bgp-gr-notification-00] (8 pages) - Accelerated Routing Convergence for BGP Graceful Restart [draft-ietf-idr-enhanced-gr-00] (9 pages) - Automatic Route Target Filtering for legacy PEs [draft-ietf-idr-legacy-rtc-00] (11 pages) - Carrying next-hop cost information in BGP [draft-ietf-idr-bgp-nh-cost-00] (9 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) * OBSOLETED BY RFC5925 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 * Updated by RFC6286 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) RFC6286: Autonomous-System-Wide Unique BGP Identifier for BGP-4 (4 pages) * Updates RFC4271 RFC6472: Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP (5 pages) Internet Area Working Group (intarea) ------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Julien Laganier Suresh Krishnan Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: int-area@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/int-area Archive: http://www.ietf.org/mail-archive/web/int-area/current/maillist.html Description of Working Group: The Internet Area Working Group (INTAREA WG) acts primarily as a forum for discussing far-ranging topics that affect the entire area. Such topics include, for instance, address space issues, basic IP layer functionality, and architectural questions. The group also serves as a forum to distribute information about ongoing activities in the area, create a shared understanding of the challenges and goals for the area, and to enable coordination. The Internet Area receives occasional proposals for the development and publication of RFCs that are not in scope of an existing working group and do not justify the formation of a new working group. The INTAREA WG has a secondary role to serve as the forum for developing such work items in the IETF. The working group milestones are updated as needed to reflect the current work items and their associated milestones. New work must satisfy the following conditions: (1) WG consensus on the relevance for the Internet at large. (2) WG consensus on the suitability and projected quality of the proposed work item. (3) A core group of WG participants with sufficient energy and expertise to advance the work item according to the proposed schedule. (4) Commitment from the WG as a whole to provide sufficient and timely review of the proposed work item. (5) Agreement by the ADs, who, depending on the scope of the proposed work item, may decide that an IESG review is needed first. Goals and Milestones: May 2010 - Submission of IPID document to the IESG as PS Aug 2010 - Submission of tunneling issues document to the IESG as Info Aug 2010 - Submission of tunneling security issues document to the IESG as Info Internet-Drafts: - Tunnels in the Internet Architecture [draft-ietf-intarea-tunnels-00] (22 pages) - IP Router Alert Considerations and Usage [draft-ietf-intarea-router-alert-considerations-11] (24 pages) - Updated Specification of the IPv4 ID Field [draft-ietf-intarea-ipv4-id-update-04] (16 pages) - Issues with IP Address Sharing [draft-ietf-intarea-shared-addressing-issues-06] (29 pages) - Logging recommendations for Internet facing servers [draft-ietf-intarea-server-logging-recommendations-05] (6 pages) - IPv6 Support Required for all IP-capable Nodes [draft-ietf-intarea-ipv6-required-02] (7 pages) - Analysis of Solution Candidates to Reveal a Host Identifier in Shared Address Deployments [draft-ietf-intarea-nat-reveal-analysis-00] (18 pages) Requests for Comments: RFC6269: Issues with IP Address Sharing (29 pages) RFC6302: Logging Recommendations for Internet-Facing Servers (5 pages) RFC6398: IP Router Alert Considerations and Usage (19 pages) * Updates RFC2113 * Updates RFC2711 IP Flow Information Export (ipfix) ---------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Nevil Brownlee Juergen Quittek Operations and Management Area Directors: Dan Romascanu Ronald Bonica Benoit Claise 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. The IPFIX WG has developed a mediation framework, that defines IPFIX mediators for processing flow records for various purposes including aggregation, anonymization, etc. For configuring IPFIX devices, a YANG module has been developed. 1. Having a solid standardized base for IPFIX deployment and operation and several existing implementations, the IPFIX WG will revisit the IPFIX protocol specifications (RFC 5101) and the IPFIX information element specification (RFC 5102) in order to in order to advance them to the next stage on the standards track. All following items 2.-7. will be in line with the revised versions of the IPFIX protocol specifications and the IPFIX information model. 2. In order to provide guidelines to developers and reviewers (including IE doctors) of new IPFIX information elements and for better defining the process of registering new information elements at IANA the IPFIX WG will create an information element developers and reviewers guideline document. 3. The export of IPFIX flow records from IPFIX mediators introduces a set of potential issues at the protocol level, such as the loss of information on the original exporter, loss of base time information, loss of original options template information, etc. The IPFIX WG will define a set of specifications for applying the IPFIX protocol at mediators, including new specifications for protocol issues not envisioned by the IPFIX protocol itself. 4.In order to support the aggregation of flow records at IPFIX mediators the IPFIX WG will define how to export aggregated flow information using IPFIX. An aggregated flow is essentially an IPFIX flow representing packets from multiple original Flows sharing some set of common properties. 5. The IPFIX WG will investigate the use of the IPFIX protocol for exporting MIB objects, avoiding the need to define new IPFIX information elements for existing management information base objects that are already fully specified. This method requires the specification of new template set and options template sets to allow the export of MIB objects along with IPFIX information elements. 6. The IPFIX MIB module (RFC 5815) defined a way to register packet selector functions at IANA. The WG agreed that another method would be preferable that requires a minor change of RFC 5815. The IPFIX WG will produce a new version of RFC 5815 with small modifications of the IANA actions and DESCRIPTION clauses in the MIB modules. 7. Operational experiences showed that it would be useful to define several new information elements for data link monitoring covering frame size, type, sections of frames, and VLAN information. The IPFIX WG will create a document defining these new information elements. 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 Done - 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 Done - Submit final version of PSAMP MIB module Done - Submit Configuration Data Model draft to IESG for publication as Standards track RFC Done - 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 structuring information elements I-D to IESG for publication as Standards Track RFC Nov 2011 - Publish Internet-Draft on guidelines for IE developers and Reviewers Nov 2011 - Publish Internet-Draft on IPFIX use at mediators Nov 2011 - Publish Internet-Draft on intermediate aggregation Nov 2011 - Publish Internet-Draft on exporting MIB objects Nov 2011 - Publish Internet-Draft on data link IEs Nov 2011 - Publish Internet-Draft on revised IPFIX MIB Dec 2011 - Publish Internet-Draft revising RFC 5101 Dec 2011 - Publish Internet-Draft revising RFC 5102 Dec 2011 - Submit flow selection I-D to IESG for publication as Standards Track RFC Apr 2012 - Submit guidelines for IE developers and reviewers for publication as Informational BCP RFC Apr 2012 - Submit IPFIX use at mediators for publication as Standards track RFC Apr 2012 - Submit intermediate aggregation for publication as Standards track RFC Apr 2012 - Submit data link IEs for publication as Standards track RFC Apr 2012 - Submit revised RFC 5101 for publication as Standards track RFC Apr 2012 - Submit revised IPFIX MIB for publications as Standards track RFC Apr 2012 - Submit revised RFC 5102 for publication as Standards track RFC Sep 2012 - Submit export of MIB objects 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-11] (68 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-10] (30 pages) - IPFIX Mediation: Framework [draft-ietf-ipfix-mediators-framework-10] (34 pages) - IPFIX Export per SCTP Stream [draft-ietf-ipfix-export-per-sctp-stream-08] (23 pages) - Configuration Data Model for IPFIX and PSAMP [draft-ietf-ipfix-configuration-model-10] (126 pages) - IP Flow Anonymization Support [draft-ietf-ipfix-anon-07] (43 pages) - Definitions of Managed Objects for Packet Sampling [draft-ietf-ipfix-psamp-mib-04] (28 pages) - Export of Structured Data in IPFIX [draft-ietf-ipfix-structured-data-07] (75 pages) - Flow Selection Techniques [draft-ietf-ipfix-flow-selection-tech-09] (35 pages) - Reliability Extension for IPFIX [draft-ietf-ipfix-reliability-template-ext-00] (11 pages) - Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of IP Traffic Flow Information [draft-ietf-ipfix-protocol-rfc5101bis-00] (73 pages) - Definitions of Managed Objects for IP Flow Information Export [draft-ietf-ipfix-rfc5815bis-01] (68 pages) - Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol [draft-ietf-ipfix-a9n-01] (46 pages) - Guidelines for Authors and Reviewers of IPFIX Information Elements [draft-ietf-ipfix-ie-doctors-00] (28 pages) - Specification of the Protocol for IPFIX Mediation [draft-ietf-ipfix-mediation-protocol-00] (33 pages) - Information Model for IP Flow Information eXport (IPFIX) [draft-ietf-ipfix-information-model-rfc5102bis-00] (30 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) * Updated by RFC6313 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) * Updated by RFC6183 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) RFC5815: Definitions of Managed Objects for IP Flow Information Export (68 pages) RFC5982: IP Flow Information Export (IPFIX) Mediation: Problem Statement (25 pages) RFC6183: IP Flow Information Export (IPFIX) Mediation: Framework (29 pages) * Updates RFC5470 RFC6235: IP Flow Anonymization Support (43 pages) RFC6313: Export of Structured Data inIP Flow Information Export (IPFIX) (71 pages) * Updates RFC5102 IP Performance Metrics (ippm) ----------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Henk Uijterwaal Matthew Zekauskas Transport Area Directors: David Harrington Martin Stiemerling Wesley Eddy Transport Area Advisor: Wesley Eddy 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) Done - -00 version of SLA validation draft Done - Submit 'more TWAMP' draft to IESG Done - Initial version of process draft Done - Submit draft-ietf-ippm-twamp-session-cntrl to IESG Done - Submit draft-ietf-ippm-reflect-octets to IESG Done - Submit draft on spatial composition of metrics to the IESG Done - Submit draft on Temporal Aggregation of Metrics to the IESG Done - Submit draft on spatial decomposition and multicast metrics to the IESG Nov 2010 - Final version of process draft Nov 2010 - Implementation report based on process draft Mar 2011 - 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-17] (30 pages) - Framework for Metric Composition [draft-ietf-ippm-framework-compagg-10] (18 pages) - Reporting IP Performance Metrics to Users [draft-ietf-ippm-reporting-07] (42 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-10] (20 pages) - Individual Session Control Feature for TWAMP [draft-ietf-ippm-twamp-session-cntrl-08] (18 pages) - Reporting Metrics: Different Points of View [draft-ietf-ippm-reporting-metrics-06] (26 pages) - RFC 4148 and the IPPM Metrics Registry are Obsolete [draft-morton-ippm-rfc4148-obsolete-04] (6 pages) - Framework for TCP Throughput Testing [draft-ietf-ippm-tcp-throughput-tm-14] (24 pages) - Loss Episode Metrics for IPPM [draft-ietf-ippm-loss-episode-metrics-04] (22 pages) - IPPM standard advancement testing [draft-ietf-ippm-metrictest-05] (37 pages) - Round-trip Loss Metrics [draft-ietf-ippm-rt-loss-02] (12 pages) - Test Plan and Results for Advancing RFC 2679 on the Standards Track [draft-ietf-ippm-testplan-rfc2679-00] (27 pages) - TWAMP Value-Added Octets [draft-ietf-ippm-twamp-value-added-octets-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) * OBSOLETED BY RFC6248 RFC4656: A One-way Active Measurement Protocol (OWAMP) (56 pages) RFC4737: Packet Reordering Metrics (42 pages) * Updated by RFC6248 RFC5136: Defining Network Capacity (20 pages) RFC5357: A Two-Way Active Measurement Protocol (TWAMP) (26 pages) * Updated by RFC5618 * Updated by RFC5938 * Updated by RFC6038 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) * Updated by RFC6248 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) * Updated by RFC6248 RFC5835: Framework for Metric Composition (18 pages) RFC2498: IPPM Metrics for Measuring Connectivity (None pages) RFC5938: Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP) (17 pages) * Updates RFC5357 RFC6038: Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features (18 pages) * Updates RFC5357 RFC6049: Spatial Composition of Metrics (29 pages) * Updated by RFC6248 RFC6248: RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete (6 pages) * Obsoletes RFC4148 * Updates RFC4737 * Updates RFC5560 * Updates RFC5644 * Updates RFC6049 RFC6349: Framework for TCP Throughput Testing (27 pages) IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Paul Hoffman Yaron Sheffer Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Sean Turner 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 continues 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 to IPsec, mostly to IKEv2. The working group also serves as a focus point for other IETF Working Groups who use IPsec in their own protocols. The current work items include: In an environment with many IPsec gateways and remote clients that share an established trust infrastructure (in a single administrative domain or across multiple domains), customers want to get on-demand point-to-point IPsec capability for efficiency. However, this cannot be feasibly accomplished only with today's IPsec and IKE due to problems with address lookup, reachability, policy configuration, and so on. The IPsecME Working Group will handle this large scale VPN problem by: * Creating a problem statement document including use cases, definitions and proper requirements for discovery and updates. This document would be solution-agnostic. * Publishing a common solution for the discovery and update problems that will satisfy the requirements in the problem statement document. The working group may standardize one of the vendor solutions, a combination, an superset of such a solution, or a new protocol. * Reviewing and help publish Informational documents describing current vendor proprietary solutions. This charter will expire in January 2014 (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: Done - WG last call on IPv6 configuration payloads Done - WG last call on IPsec roadmap Done - WG last call on session resumption Done - WG last call on redirect Done - WG last call on IKEv2bis Done - WG last call on ESP NULL traffic visibility Done - WG last call on HA requirements Done - WG last call on quick crash discovery Done - WG last call on EAP-only authentication Nov 2012 - IETF Last Call on large scale VPN use cases Jun 2013 - IETF Last Call on large scale VPN protocol Internet-Drafts: - Internet Key Exchange Protocol: IKEv2 [draft-ietf-ipsecme-ikev2bis-12] (130 pages) - Redirect Mechanism for IKEv2 [draft-ietf-ipsecme-ikev2-redirect-14] (15 pages) - Wrapped ESP for Traffic Visibility [draft-ietf-ipsecme-traffic-visibility-13] (15 pages) - IKEv2 Session Resumption [draft-ietf-ipsecme-ikev2-resumption-10] (29 pages) - IPv6 Configuration in IKEv2 [draft-ietf-ipsecme-ikev2-ipv6-config-04] (36 pages) - IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap [draft-ietf-ipsecme-roadmap-11] (61 pages) - Heuristics for Detecting ESP-NULL packets [draft-ietf-ipsecme-esp-null-heuristics-08] (37 pages) - Using Advanced Encryption Standard (AES) Counter Mode with IKEv2 [draft-ietf-ipsecme-aes-ctr-ikev2-08] (10 pages) - IPsec Cluster Problem Statement [draft-ietf-ipsecme-ipsec-ha-10] (13 pages) - An Extension for EAP-Only Authentication in IKEv2 [draft-ietf-ipsecme-eap-mutual-06] (16 pages) - A Quick Crash Detection Method for IKE [draft-ietf-ipsecme-failure-detection-09] (24 pages) - Protocol Support for High Availability of IKEv2/IPsec [draft-ietf-ipsecme-ipsecha-protocol-07] (26 pages) Requests for Comments: RFC5685: Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2) (15 pages) RFC5723: Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption (29 pages) RFC5739: IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2) (32 pages) RFC5840: Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility (15 pages) RFC5879: Heuristics for Detecting ESP-NULL Packets (32 pages) RFC5930: Using Advanced Encryption Standard Counter Mode (AES) with the Internet Key Exchange version 02 (IKEv2) Protocol (6 pages) RFC5996: Internet Key Exchange Protocol Version 2 (IKEv2) (138 pages) * Obsoletes RFC4306 * Obsoletes RFC4718 * Updated by RFC5998 RFC5998: An Extension for EAP-Only Authentication in IKEv2 (16 pages) * Updates RFC5996 RFC6027: IPsec Cluster Problem Statement (12 pages) RFC6071: IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap (63 pages) * Obsoletes RFC2411 RFC6290: A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE) (22 pages) RFC6311: Protocol Support for High Availability of IKEv2/IPsec (26 pages) Internationalized Resource Identifiers (iri) -------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chair: Chris Weber Applications Area Directors: Pete Resnick Barry Leiba Peter Saint-Andre Applications Area Advisor: Peter Saint-Andre Mailing Lists: General Discussion: public-iri@w3.org To Subscribe: public-iri-request@w3.org Archive: http://lists.w3.org/Archives/Public/public-iri/ Description of Working Group: This working group will produce * A new version of RFC 3987: "Internationalized Resource Identifiers (IRIs)" using draft-duerst-iri-bis as the base * A new version of RFC 4395: "Guidelines and Registration Procedures for New URI Schemes" The new version of RFC 3987 may be split into separate documents, if, in the opinion of the chair(s), it would facilitate distribution of the workload and allow more focused reviews. For example, the following breakdown has been suggested: * Handling of Internationalized domain names in IRIs (BCP) * Internationalization Considerations in IRIs (guidelines for BIDI, character ranges to avoid, special considerations) (BCP) * Syntax, parsing, comparison of IRIs (Standards track) The working group starts with a relatively mature update to RFC 3987 in preparation; the primary focus of the group is to resolve conflicting uses, requirements and best practices for internationalized URLs/URIs/IRIs and various other forms, among many specifications and committees, while moving toward consistent use of IRIs among the wide range of Internet applications that use them. In particular: * The IRI specification(s) must (continue to) be suitable for normative reference with Web and XML standards from W3C specifications. The group should coordinate with the W3C working groups on HTML5, XML Core, and Internationalization, as well as with IETF HTTPBIS WG to ensure acceptability. * The IRI specification(s) should be follow best practices for domain names. The group should coordinate with the IETF IDNABIS working group and Unicode Consortium to assure acceptability. * Explicit review by experts on (and native speakers) of RTL languages, of the recommendations for BIDI languages, is required. The Working Group will examine at least one and possibly more URI/IRI schemes to check that the new specification(s) are appropriate for existing schemes. The exact schemes to be reviewed will be decided by the WG. Changes to RFC 3986 ("Uniform Resource Identifier (URI): Generic Syntax") are explicitly out of scope of this charter, and may only be considered with a charter update. Goals and Milestones: Feb 2010 - Publish initial version of the WG documents May 2010 - Working group Last Call of all documents Jun 2010 - Publish IRI documents as RFCs (BCP, standards track, as appropriate) Internet-Drafts: - Internationalized Resource Identifiers (IRIs) [draft-ietf-iri-3987bis-09] (40 pages) - Guidelines and Registration Procedures for New URI/IRI Schemes [draft-ietf-iri-4395bis-irireg-04] (16 pages) - Equivalence and Canonicalization of Internationalized Resource Identifiers (IRIs) [draft-ietf-iri-comparison-00] (14 pages) - Guidelines for Internationalized Resource Identifiers with Bi- directional Characters (Bidi IRIs) [draft-ietf-iri-bidi-guidelines-00] (10 pages) No Requests for Comments IS-IS for IP Internets (isis) ----------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Chris Hopps David Ward Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Stewart Bryant 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-09] (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-04] (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-05] (14 pages) - IS-IS BFD Enabled TLV [draft-ietf-isis-bfd-tlv-04] (8 pages) - Purge Originator Identification TLV for IS-IS [draft-ietf-isis-purge-tlv-06] (6 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-12] (11 pages) - IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging [draft-ietf-isis-ieee-aq-05] (40 pages) - TRILL Use of IS-IS [draft-ietf-isis-trill-06] (30 pages) - IS-IS Registry Extension for Purges [draft-ietf-isis-reg-purge-02] (5 pages) - IS-IS Operational Enhancements for Network Maintenance Events [draft-ietf-isis-oper-enhance-01] (6 pages) - IS-IS Reverse Metric TLV for Network Maintenance Events [draft-ietf-isis-reverse-metric-01] (14 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 * Updated by RFC6232 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 * Updated by RFC6232 * Updated by RFC6233 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 * Updated by RFC6001 * Updated by RFC6002 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) * Updated by RFC6232 * Updated by RFC6233 RFC6119: IPv6 Traffic Engineering in IS-IS (10 pages) RFC6165: Extensions to IS-IS for Layer-2 Systems (7 pages) RFC6213: IS-IS BFD-Enabled TLV (7 pages) RFC6232: Purge Originator Identification TLV for IS-IS (6 pages) * Updates RFC5301 * Updates RFC5304 * Updates RFC5310 RFC6233: IS-IS Registry Extension for Purges (4 pages) * Updates RFC3563 * Updates RFC5304 * Updates RFC5310 RFC6326: Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS (25 pages) Javascript Object Signing and Encryption (jose) ----------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Tony Hansen Jim Schaad Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Sean Turner Mailing Lists: General Discussion: jose@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/jose Archive: http://www.ietf.org/mail-archive/web/jose/ Description of Working Group: Javascript Object Notation (JSON) is a text format for the serialization of structured data described in RFC 4627. The JSON format is often used for serializing and transmitting structured data over a network connection. With the increased usage of JSON in protocols in the IETF and elsewhere, there is now a desire to offer security services such as encryption, digital signatures, and message authentication codes (MACs) for data that is being carried in JSON format. Different proposals for providing such security services have already been defined and implemented. This Working Group's task is to standardize two security services, integrity protection (signature and MAC) and encryption, in order to increase interoperability of security features between protocols that use JSON. The Working Group will base its work on well-known message security primitives (e.g., CMS), and will solicit input from the rest of the IETF Security Area to be sure that the security functionality in the JSON format is correct. This group is chartered to work on four documents: 1) A Standards Track document specifying how to apply JSON-structured integrity protection to data, including (but not limited to) JSON data structures. "Integrity protection" includes public-key digital signatures as well as symmetric-key MACs. 2) A Standards Track document specifying how to apply a JSON-structured encryption to data, including (but not limited to) JSON data structures. 3) A Standards Track document specifying how to encode public keys as JSON-structured objects. 4) A Standards Track document specifying mandatory-to-implement algorithms for the other three documents. The working group may decide to address one or more of these goals in a single document, in which case the concrete milestones for signing/encryption below will both be satisfied by the single document. Goals and Milestones: Jan 2012 - Submit JSON object integrity document as a WG item. Jan 2012 - Submit JSON object encryption document as a WG item. Jan 2012 - Submit JSON key format document as a WG item. Jan 2012 - Submit JSON algorithm document as a WG item. Jun 2012 - Start Working Group Last Call on JSON object integrity document. Jun 2012 - Start Working Group Last Call on JSON object encryption document. Jun 2012 - Start Working Group Last Call on JSON key format document. Jun 2012 - Start Working Group Last Call on JSON algorithm document. Jul 2012 - Submit JSON object integrity document to IESG for consideration as Standards Track document. Jul 2012 - Submit JSON object encryption document to IESG for consideration as Standards Track document. Jul 2012 - Submit JSON key format document to IESG for consideration as Standards Track document. Jul 2012 - Submit JSON algorithm document to IESG for consideration as Standards Track document. Internet-Drafts: - JSON Web Signature (JWS) [draft-ietf-jose-json-web-signature-00] (27 pages) - JSON Web Encryption (JWE) [draft-ietf-jose-json-web-encryption-00] (18 pages) - JSON Web Key (JWK) [draft-ietf-jose-json-web-key-00] (8 pages) - JSON Web Algorithms (JWA) [draft-ietf-jose-json-web-algorithms-00] (19 pages) No Requests for Comments Keying and Authentication for Routing Protocols (karp) ------------------------------------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Joel Halpern Brian Weis Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Stewart Bryant Tech Advisor: Tim Polk Mailing Lists: General Discussion: karp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/karp Archive: http://www.ietf.org/mail-archive/web/karp/current/maillist.html Description of Working Group: The KARP working group is tasked to work with the routing protocol working groups in order to improve the communication security of the packets on the wire used by the routing protocols. This working group is concerned with message authentication, packet integrity, and denial of service (DoS) protection. At present, this charter explicitly excludes confidentiality and non-repudiation concerns. Authenticating the routing peer sending a message, and message integrity protection, will be provided through the use of per-packet cryptographic message authentication. Peer authentication will protect against unrecognized peers, imposter peers, and some DoS attacks aimed at routers. Protecting against misbehavior of an otherwise allowed peer router is outside the scope of this working group. Many routing protocols (or groups of protocols) already have some method for accomplishing cryptographic message authentication. In many or most cases existing methods are vulnerable to known attack, and some employ cryptographic algorithms that have been deprecated. While much work has been done to update authentication of routing protocols, current status is not consistently up to date. It is important to review and update those mechanisms to use modern security practices. Ensuring algorithm agility within routing protocols is of particular importance. A goal of the working group is to add incremental security to existing mechanisms rather than replacing them. Better deployable solutions to which vendors and operators can migrate is more important than getting a perfect security solution. Although there are many candidate routing protocols to evaluate, KARP must by necessity begin with a restricted focus. The initial set of routing protocols in scope include BGP, OSPFv2, OSPFv3, PCE, PIM, LDP, RSVP-TE, ISIS, BFD, LMP, and MSDP. The working group must coordinate very closely with other working groups, such as: - Routing protocol working groups for any routing protocol being evaluated. This coordination will include cooperatively determining the current or already planned state of the security work in the protocol. It will also include ensuring that any proposed mechanisms are consistent with the architecture and use of the protocol. Also, any specific proposal accepted as a KARP document will be developed in cooperation with the concerned protocol working group. - Security area working groups for cryptographic advice, and/or key management protocol support. Cryptographic protocol support may be required in order to support certain KARP WG milestones. Coordination with an appropriate working group in the security area would be necessary in order to get the appropriate expertise in completing a milestone. This charter provides for preliminary work in this space, although it is expected that detailed work items will be added to the charter when the problem has been better analyzed. For example, this may include a key management protocol by which routing protcols automatically negotiate keying material and policy. More about the use of a key management protocol will be captured in a framework document described below. - OPSEC working group for advice on best practices to create and use integrity keys used with routing protocol message authentication. KARP will also coordinate with other Operations and Management area WGs and/or experts in order to identify operational impacts on existing routing protocols and to identify any management extensions that may be required. Routing protocols use a range of transport mechanisms and communication relationships. There are also differences in details among the various protocols. The working group will attempt to describe the security relevant characteristics of routings protocols, such as the use or non-use of TCP, or the frequent use of group communication versus purely pairwise communication. Using these characteristics, the working group will then provide suitable common frameworks that can be applied, and tailored, to improve the communication security of the routing protocols. In later phases, it is expected that the working group will investigate the suitably of defining conceptual structures and APIs, so as to enable further work to be more effective. Work Items: - Determine current threats to the routing protocol operation, and define general requirements for cryptographic authentication of routing protocols. A primary source for this document should be draft-lebovitz-karp-roadmap, although RFC 4393 may also be useful. - Identify deficiencies of each routing protocol in scope, and specify mechanisms that bring them in line with the general requirements. These are referred to as protocol gap analysis documents. - Define one or more frameworks describing the common elements for modern authentication in routing protocols. - Publish guidance on how to create a gap analysis for routing protocols. - Publish guidance on guidance to operators on how to create and use integrity keys used with routing protocol message authentication. - Specify automated key management needs for routing protocols. Goals and Milestones: Nov 2010 - Submit General Framework, General Requirements, and Priorities/Work-Plan documents to the IESG to be considered as Informational RFC Nov 2010 - Submit a framework document describing protocol groups and the common techniques and interfaces that apply to them to the IESG to be considered as Informational RFC Dec 2010 - ubmit a document describing best practices for creating and using protocol message authentication integrity keys as a BCP Apr 2011 - Submit specification document for OSPFv2 to the IESG to be considered as a Proposed Standard Apr 2011 - Submit specification document for BGP to the IESG to be considered as a Proposed Standard Jul 2011 - Submit specification document for OSPFv3 to the IESG to be considered as a Proposed Standard Jul 2011 - Submit specification document for LDP to the IESG to be considered as a Proposed Standard Oct 2011 - Submit specification document for PIM to the IESG to be considered as a Proposed Standard Oct 2011 - Submit specification document for RSVP-TE to the IESG to be considered as a Proposed Standard Nov 2011 - Specify automated key management needs for routing protocols using unicast techniques Jan 2012 - Submit specification document for ISIS to the IESG to be considered as a Proposed Standard Jan 2012 - Submit specification document for PCE to the IESG to be considered as a Proposed Standard Apr 2012 - Submit specification document for MSDP to the IESG to be considered as a Proposed Standard Apr 2012 - Specify automated key management needs for routing protocols using multicast techniques Apr 2012 - Submit specification document for BFD to the IESG to be considered as a Proposed Standard Jul 2012 - Submit specification document for LMP to the IESG to be considered as a Proposed Standard Internet-Drafts: - Keying and Authentication for Routing Protocols (KARP) Design Guidelines [draft-ietf-karp-design-guide-11] (31 pages) - Framework for Cryptographic Authentication of Routing Protocol Packets on the Wire [draft-ietf-karp-framework-00] (25 pages) - The Threat Analysis and Requirements for Cryptographic Authentication of Routing Protocols' Transports [draft-ietf-karp-threats-reqs-03] (27 pages) - Database of Long-Lived Symmetric Cryptographic Keys [draft-ietf-karp-crypto-key-table-02] (10 pages) - Analysis of OSPF Security According to KARP Design Guide [draft-ietf-karp-ospf-analysis-02] (11 pages) - Operations Model for Router Keying [draft-ietf-karp-ops-model-01] (23 pages) - Analysis of BGP, LDP, PCEP, and MSDP Security According to KARP Design Guide [draft-ietf-karp-routing-tcp-analysis-01] (16 pages) Requests for Comments: RFC6518: Keying and Authentication for Routing Protocols (KARP) Design Guidelines (30 pages) Common Authentication Technology Next Generation (kitten) --------------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Alexey Melnikov Tom Yu Shawn Emery Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Stephen Farrell Mailing Lists: General Discussion: kitten@ietf.org To