alto hybi calsify eai lemonade httpstate httpbis idnabis iri morg marf oauth sieve vwrap yam vcarddav ancp autoconf csi dnsext dhc hip ipdvb 16ng 6man 6lowpan l2vpn l2tpext lisp mext mipshop mip4 multimob mif ntp netext netlmm pppext pwe3 shim6 softwire savi tictoc trill adslmib bmwg capwap dime dnsop grow ipfix v6ops mboned netmod netconf opsec opsawg pmol radext avt bliss xcon drinks dispatch ecrit xmpp geopriv codec mediactrl mmusic martini p2psip sipclf simple sipcore speermint speechsc enum bfd ccamp forces isis idr l3vpn manet mpls ospf pce pim rtgwg roll sidr vrrp btns dkim emu ipsecme krb-wg kitten ltans msec nea keyprov smime syslog sasl tls hokey isms pkix behave pcn dccp fecframe ippm ledbat mptcp nfsv4 nsis rmt rohc storm tcpm tsvwg Application-Layer Traffic Optimization (alto) --------------------------------------------- Charter Last Modified: 2009-11-19 Current Status: Active Chairs: Jon Peterson Vijay Gurbani Enrico Marocco Applications Area Directors: Lisa Dusseault Alexey Melnikov Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion: alto@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/alto Archive: http://www.ietf.org/mail-archive/web/alto/current/maillist.html Description of Working Group: A significant part of the Internet traffic today is generated by peer-to-peer (P2P) applications used for file sharing, real-time communications, and live media streaming. P2P applications exchange large amounts of data, often uploading as much as downloading. In contrast to client/server architectures, P2P applications often must choose one or more suitable candidates from a selection of peers offering the same resource or service. One of the advantages of P2P systems comes from redundancy in resource availability. This requires choosing among a list of peers, yet applications have at best incomplete information to help the selection, e.g., topology of the network. Applications can sometimes obtain network information dynamically or measure link performance with respect to particular peers, but even when this is an option it takes time. The application cannot always start out with an optimal arrangement of peers, thus risking at least temporary poor performance and excessive cross-domain traffic. Providing more information for use in peer selection can improve P2P performance and lower ISP costs. The Working Group will design and specify an Application-Layer Traffic Optimization (ALTO) service that will provide applications with information to perform better-than-random initial peer selection. ALTO services may take different approaches at balancing factors such as maximum bandwidth, minimum cross-domain traffic, lowest cost to the user, etc. The WG will consider the needs of BitTorrent, tracker-less P2P, and other applications, such as content delivery networks (CDN) and mirror selection. The WG will focus on the following items: - A "problem statement" document providing a description of the problem and a common terminology. - A requirements document. This document will list requirements for the ALTO service, identifying, for example, types of information P2P applications may need for optimizing their choices. - A request/response protocol for querying the ALTO service to obtain information useful for peer selection, and a format for requests and responses If the requirements analysis identifies the need to allow clients to delegate third-parties to query the ALTO service on their behalf, the WG will ensure that the protocol provides a mechanism to assert the consent of the delegating client. - A document defining core request and response formats and semantics to communicate network preferences to applications. Since ALTO services may be run by entities with different level of knowledge about the underlying network, such preferences may have different representations. Initially the WG will consider: IP ranges to prefer and to avoid, ranked lists of the peers requested by the client, information about topological proximity and approximate geographic locations. Other usages will be considered as charter additions once the work for the initial services has been completed. - In order to query the ALTO server, clients must first know one or more ALTO servers that might provide useful information. The WG will look at service discovery mechanisms that are in use, or defined elsewhere (e.g. based on DNS SRV records or DHCP options). If such discovery mechanisms can be reused, the WG will produce a document to specify how they may be adopted for locating such servers. However, a new, general-purpose service discovery mechanism is not in scope. When the WG considers standardizing information that the ALTO server could provide, the following criteria are important to ensure real feasibility. - Can the ALTO service realistically discover that information? - Is the distribution of that information allowed by the operators of that service? - Is it information that a client will find useful? - Can a client get that information without excessive privacy concerns (e.g. by sending large lists of peers)? - Is it information that a client cannot find easily some other way? After these criteria are met, the importance of the data will be considered for prioritizing standardization work, for example the number of operators and clients that are likely to be able to provide or use that particular data. In any case, this WG will not propose standards on how congestion is signaled, remediated, or avoided, and will not deal with information representing instantaneous network state. Such issues belong to other IETF areas and will be treated accordingly by the specific area. This WG will focus solely on the communication protocol between applications and ALTO servers. Note that ALTO services may be useful in client-server environments as well as P2P environments, although P2P environments are the first focus. If, in the future, the IETF considers changes to other protocols for actually implementing ALTO services (e.g. application-layer protocols for Internet coordinate systems, routing protocol extensions for ISP-based solutions), such work will be done in strict coordination with the appropriate WGs. Issues related to the content exchanged in P2P systems are also excluded from the WG's scope, as is the issue dealing with enforcing the legality of the content. Goals and Milestones: Done - Working Group Last Call for problem statement Done - Submit problem statement to IESG as Informational Jan 2010 - Working Group Last Call for requirements document Jan 2010 - Working Group Last Call for request/response protocol Jan 2010 - Working Group Last Call for usage document for communicating network preferences Mar 2010 - Submit request/response protocol to IESG as Proposed Standard Mar 2010 - Submit usage document to IESG as Proposed Standard May 2010 - Submit requirements document to IESG as Informational May 2010 - Working Group Last Call of discovery mechanism Jul 2010 - Submit discovery mechanism to IESG as Proposed Standard Aug 2010 - Dissolve or re-charter Internet-Drafts: - Application-Layer Traffic Optimization (ALTO) Problem Statement [draft-ietf-alto-problem-statement-05] (15 pages) - Application-Layer Traffic Optimization (ALTO) Requirements [draft-ietf-alto-reqs-02] (26 pages) - ALTO Protocol [draft-ietf-alto-protocol-01] (34 pages) Requests for Comments: RFC5693: Application-Layer Traffic Optimization (ALTO) Problem Statement (15 pages) BiDirectional or Server-Initiated HTTP (hybi) --------------------------------------------- Charter Last Modified: 2010-01-26 Current Status: Active Chairs: Salvatore Loreto Joe Hildebrand Applications Area Directors: Lisa Dusseault Alexey Melnikov Applications Area Advisor: Lisa Dusseault 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: No Requests for Comments Calendaring and Scheduling Standards Simplification (calsify) ------------------------------------------------------------- Charter Last Modified: 2008-04-23 Current Status: Active Chairs: Eliot Lear Aki Niemi Applications Area Directors: Lisa Dusseault Alexey Melnikov Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion: ietf-calsify@osafoundation.org To Subscribe: http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Archive: http://lists.osafoundation.org/pipermail/ietf-calsify/ Description of Working Group: The Calendaring and Scheduling standards, defined in RFC's 2445, 2446, and 2447 were released in November 1998, and further described in RFC 3283. They were designed to progress the level of interoperability between dissimilar calendaring and scheduling systems. The Calendaring and Scheduling Core Object Specification, iCalendar, succeeded in establishing itself as the common format for exchanging calendaring information across the Internet. On the other hand, only basic interoperability has been achieved between different scheduling systems. The Calsify working group is chartered to: (1) Revise the Calendaring and Scheduling Standards to advance the state of interoperable calendaring and scheduling by addressing the known interoperability issues, errata, and problems found based on implementation experience. (2) Clarify the registration process for iCalendar extensions (i.e., the current core object specification only provides a template to register new properties). (3) Provide a means to ease transition from, and to co-exist with, the earlier iCalendar standards to the new ones. Proposing an XML representation or transformation of iCalendar objects is out of the scope of this working group. Depending on the results of the update process on the standards documents the working group will consider whether advancing the documents to draft standard is appropriate. If we decide to move the documents to draft status, milestones may get changed and/or added to allow for any additional work necessary to advance the documents. Goals and Milestones: Done - Submit iCalendar bis draft 00, with formatting changes from RFC2445. Done - Submit iTIP bis draft 00 Done - Submit iMIP bis draft 00 Done - Submit updated version of rfc2447bis draft Done - Submit updated version of rfc2446bis draft Done - Submit updated version of rfc2445bis draft Done - Working Group Last Call on rfc2445bis draft Jun 2007 - Submit rfc2445bis draft to IESG Jun 2007 - Working Group Last Call on rfc2446bis draft Jun 2007 - Working Group Last Call on rfc2447bis draft Jul 2007 - Submit rfc2446bis to IESG Jul 2007 - Submit rfc2447bis to IESG Internet-Drafts: - iCalendar Message-Based Interoperability Protocol (iMIP) [draft-ietf-calsify-rfc2447bis-08] (22 pages) - iCalendar Transport-Independent Interoperability Protocol (iTIP) [draft-ietf-calsify-2446bis-10] (135 pages) - Internet Calendaring and Scheduling Core Object Specification (iCalendar) [draft-ietf-calsify-rfc2445bis-11] (189 pages) Requests for Comments: RFC5545: Internet Calendaring and Scheduling Core Object Specification (iCalendar) (189 pages) * Obsoletes RFC2445 Email Address Internationalization (eai) ---------------------------------------- Charter Last Modified: 2010-01-26 Current Status: Active Chairs: Harald Alvestrand XiaoDong Lee Applications Area Directors: Lisa Dusseault Alexey Melnikov Applications Area Advisor: Alexey Melnikov 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: Since early in the effort to internationalize domain names, which resulted in the standards associated with IDNA, it has been understood that internationalization of email address local parts is required. At the same time, email address internationalization poses a series of special problems. Constraints on the interpretation of local-parts by any system other than the final delivery one make address encoding nearly impossible. The need to use addresses in both the email envelope and in header fields, and to do so in ways that are at least compatible, suggests that this is not a simple and isolated problem. This working group will address one basic approach to email internationalization. That approach is based on the use of an SMTP extension to enable both the use of UTF-8 in envelope address local- parts and optionally in domain-parts and the use of UTF-8 in mail headers -- both in address contexts and wherever encoded-words are permitted today. Its initial target will be a set of experimental RFCs that specify the details of this approach and provide the basis for generating and testing interoperable implementations. Its work will include examining whether "downgrading" -- transforming an internationalized message to one that is compatible with unextended SMTP clients and servers and unextended MUAs -- is feasible and appropriate and, if it is, specifying a way to do so. If it is not, the WG will evaluate whether the effort is worth taking forward. Other approaches may be considered by the formation of other working groups. Key parts of this effort include extended analyses and, if necessary, proof of concept in three areas in addition to smooth operation when all systems and components along a message path have been upgraded to support the new facilities. They are o Examination of scenarios for the appearance of these facilities to users, including ways in which alternate addresses may be specified if those are needed for downgrading. o Examination of different locations at which downgrading might be required and accomplished, differentiating between requirements and capabilities at the point of origin (at or before the submission server), those that exist while the message is in transit, and those that apply after SMTP "final delivery" or in the logical vicinity or an IMAP or POP server. o Examination of the "mailing list question", i.e., how a mixture of traditional and internationalized addresses on a mailing list will impact message flows, error reports, and delivery notifications in all plausible combinations of servers and addresses, including internationalizated and traditional reverse paths. Once the Experimental RFCs are completed and implemented, the experience gathered will be evaluated. If the approach is found to have been successful (using criteria the WG will establish as an early work item), the WG will be rechartered to update the documents for processing onto the standards track. 1.6. Deliverables The following deliverables are foreseen in this charter. The WG chairs may structure the deliverables into specific documents or document sets as needed. Adding or removing documents outside of these deliverables will require a charter update. o Overview and architecture (Info) o Interworking scenarios, including the "mailing list question" (Info) o SMTP extensions specification (Exp) o Header format specification (Exp) o Downgrading specification in SMTP (Exp) o Downgrading specification in POP servers (Exp) o Downgrading specification in IMAP servers (Exp) o Results and evaluation of experiment (Info) Going forward, it is possible that the SMTP downgrading specification will go for Informational due to the difficulty of fully specifying all necessary behavior. Additional possible documents suggested: Advice for MUA implementors (Info) Goals and Milestones: Done - Overview/architecture draft first Done - Interworking scenarios first draft Done - SMTP Extensions first draft Done - Header format first draft Done - Downgrading in SMTP first draft Done - Downgrading in IMAP first draft Done - Downgrading in POP first draft Done - Overview/architecture draft to IESG Jun 2006 - Interworking scenarios to IESG Done - SMTP Extensions to IESG Done - Header format to IESG Done - Downgrading in SMTP to IESG Sep 2006 - Downgrading in POP to IESG Sep 2006 - Downgrading in IMAP to IESG Dec 2006 - Results and evaluation first draft Mar 2007 - Results and evaluation to IESG Mar 2007 - Group recharter for standards track Internet-Drafts: - POP3 Support for UTF-8 [draft-ietf-eai-pop-09] (17 pages) - SMTP extension for internationalized email address [draft-ietf-eai-smtpext-14] (24 pages) - Downgrading mechanism for Email Address Internationalization [draft-ietf-eai-downgrade-13] (28 pages) - IMAP Support for UTF-8 [draft-ietf-eai-imap-utf8-09] (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-05] (11 pages) - Internationalized Delivery Status and Disposition Notifications [draft-ietf-eai-dsn-07] (19 pages) - An update to the mailto URI scheme for Email Address Internationalization [draft-ietf-eai-mailto-02] (6 pages) - Displaying Downgraded Messages for Email Address Internationalization [draft-ietf-eai-downgraded-display-03] (15 pages) - Internationalized Delivery Status and Disposition Notifications [draft-ietf-eai-dsnbis-02] (17 pages) - Guidelines for Internationalized Email Clients [draft-ietf-eai-email-clients-01] (16 pages) Requests for Comments: RFC4952: Overview and Framework for Internationalized Email (23 pages) * Updated by RFC5336 RFC5335: Internationalized Email Headers (14 pages) * Updates RFC2045 * Updates RFC2822 RFC5336: SMTP Extension for Internationalized Email Addresses (22 pages) * Updates RFC2821 * Updates RFC2822 * Updates RFC4952 RFC5337: Internationalized Delivery Status and Disposition Notifications (18 pages) * Updates RFC3461 * Updates RFC3464 * Updates RFC3798 RFC5504: Downgrading Mechanism for Email Address Internationalization (24 pages) Enhancements to Internet email to Support Diverse Service Environments (lemonade) --------------------------------------------------------------------------------- Charter Last Modified: 2009-08-20 Current Status: Active Chairs: Glenn Parsons Eric Burger Applications Area Directors: Lisa Dusseault Alexey Melnikov Applications Area Advisor: Alexey Melnikov Secretary: Alexey Melnikov Mailing Lists: General Discussion: lemonade@ietf.org To Subscribe: lemonade-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/lemonade/index.html Description of Working Group: Lemonade is tasked to provide a set of enhancements and profiles of Internet email submission, transport, and retrieval protocols to facilitate operation on platforms with constrained resources, or communications links with high latency or limited bandwidth. A primary goal of this work is to ensure that those profiles and enhancements continue to interoperate with the existing Internet email protocols in use on the Internet, so that these environments and more traditional Internet users have access to a seamless service. Lemonade's work is at the crossroads of a body of work related to Internet messaging, in particular work done by the VPIM, FAX, and IMAPEXT IETF working groups. Given the potentially broad scope of activities this group could engage in, the group will focus specifically on the following work items: 0. An informational RFC or RFCs will be produced on LEMONADE architecture and the issues it seeks to address. 1. Enhance the existing IMAP4 message retrieval and message submission (RFC 2476) protocols to satisfy the requirements for handling streaming multimedia content. The existing standards-track CONNEG framework will be used if content negotiation capabilities are needed. The group will employ existing protocols (such as for streaming) with IMAP4 instead of duplicating such functionality within IMAP4. 2. Enhance the existing IMAP4 message retrieval and/or message submission (RFC 2476) protocols to satisfy the requirements for forwarding a message and/or its attachments without downloading the message to the client and subsequently uploading the message to a server. 3. Refine the existing IMAP4 message retrieval protocol to facilitate its use with devices that have limited capabilities such as mobile endpoints. At most one backwards compatible profile of IMAP4 will be produced by this effort. 4. Define a format for message notifications for servers reporting message status information to other servers. Specify the method for delivery of those notifications. 5. Create a specification describing the use of Internet message services in environments where message delivery may take place using either Internet protocols or through an MMS server using WAP to communicate with the receiving user agent. Any protocols defined by this working group will include appopriate security mechanisms, including authentication, privacy, and access control. Mandatory-to-implement security mechanisms will be specified as needed in order to guarantee secure protocol interoperability. The transport area will be consulted to deal with any transport-related issues that arise, especially in regards to items 1-4 above. The IAB is currently working on the specification of general guidelines and requirements for notification services. Once complete this work will be used as input to item 4 above. The working group is aware of several related activities in other groups: - 3GPP TSG T WG2 SWG3 Messaging - W3C Mulitmodal interaction Activity - Open Mobile Alliance - 3GPP2 TSG-X The goal is to coordinate efforts with at least these groups as required. While there is obvious synergy, given the end-of-life of the VPIM and FAX work groups and the similar membership, the working group does not expect to coordinate with these other groups. Goals and Milestones: Done - Submit LEMONADE goals and use-cases specification to the IESG Done - Submit server to server notification requirements to the IESG Done - Submit translation to other messaging systems to the IESG Done - Submit IMAP/SUBMIT extensions for forward without download to IESG Done - Submit IMAP4 profile for mobile devices to the IESG Done - Submit IMAP COMPRESS Extension to the IESG Done - Submit Deployment Considerations to the IESG Done - Submit IMAP WITHIN Search extension to the IESG Done - Submit SASL-IR IMAP4 extension to the IESG Done - Submit IMAP CONVERT extension to the IESG Done - Submit Quick Reconnect extension to the IESG Done - Submit Update to RFC 2192 (IMAP URL) to the IESG Done - Submit Message Events to IESG Done - Submit contextual mailboxes extension to the IESG Done - Submit Body Conversions to IESG Done - Submit IMAP Sieve Extensions to IESG Done - Submit URLFETCH BINARY Extension to the IESG Done - Submit Notification Format to the IESG Done - Submit IMAP NOTIFY Extension to the IESG Done - Submit Notification Architecture to the IESG Done - Submit IMAP4 extensions for streaming multimedia to the IESG Done - Submit Profile bis document to the IESG Internet-Drafts: - IMAP Submit Without Download [draft-ietf-lemonade-submit-01] (14 pages) - IMAP4 Channel Transport Mechanism [draft-ietf-lemonade-imap-channel-02] (9 pages) - Goals for Internet Messaging to Support Diverse Service Environments [draft-ietf-lemonade-goals-06] (51 pages) - Internet Message Access Protocol (IMAP) CATENATE Extension [draft-ietf-lemonade-catenate-06] (11 pages) - Server To Server Notification Protocol Requirements [draft-ietf-lemonade-notify-s2s-00] (10 pages) - Lemonade Server to Client Notifications [draft-ietf-lemonade-server-to-client-notifications-00] (20 pages) - Internet Message Access Protocol (IMAP) - URLAUTH Extension [draft-ietf-lemonade-urlauth-09] (5 pages) - Lemonade Profile [draft-ietf-lemonade-profile-08] (18 pages) - IMAP Conventions for Message Context [draft-ietf-lemonade-msg-context-00] (5 pages) - IMAP4 Extensions for Quick Reconnect [draft-ietf-lemonade-reconnect-07] (24 pages) - Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail [draft-ietf-lemonade-mms-mapping-07] (34 pages) - SMTP Submission Service Extension for Future Message Release [draft-ietf-lemonade-futuredelivery-04] (12 pages) - Message Submission BURL Extension [draft-ietf-lemonade-burl-05] (14 pages) - Persistent Virtual Folder extension to the IMAP Protocol [draft-ietf-lemonade-vfolder-01] (12 pages) - WITHIN Search extension to the IMAP Protocol [draft-ietf-lemonade-search-within-06] (5 pages) - The IMAP COMPRESS Extension [draft-ietf-lemonade-compress-09] (9 pages) - Lemonade Notifications Architecture [draft-ietf-lemonade-notifications-11] (17 pages) - IMAP URL Scheme [draft-ietf-lemonade-rfc2192bis-10] (32 pages) - Internet Message Access Protocol - CONVERT extension [draft-ietf-lemonade-convert-21] (30 pages) - Realization of OMA Mobile Email (MEM) Architecture using Internet Mail [draft-ietf-lemonade-oma-mem-realization-00] (33 pages) - Support for Sieve in Internet Message Access Protocol (IMAP4) [draft-ietf-lemonade-imap-sieve-07] (24 pages) - The Lemonade Profile [draft-ietf-lemonade-profile-bis-13] (38 pages) - Deployment Considerations for Lemonade-Compliant Mobile Email [draft-ietf-lemonade-deployments-10] (12 pages) - Lemonade bindings to cross firewalls and mobile network intermediaries [draft-ietf-lemonade-firewall-binding-00] (20 pages) - IMAP4 extension for named searches (filters) [draft-melnikov-imapext-filters-09] (12 pages) - Internet Message Store Events [draft-ietf-lemonade-msgevent-08] (22 pages) - Streaming Internet Messaging Attachments [draft-ietf-lemonade-streaming-14] (34 pages) - IMAP4 Extensions for Quick Mailbox Resynchronization [draft-ietf-lemonade-reconnect-client-07] (25 pages) - Lemonade Notification protocol [draft-ietf-lemonade-notification-protocol-00] (8 pages) - The IMAP NOTIFY Extension [draft-ietf-lemonade-imap-notify-08] (23 pages) - LEMONADE Architecture - Supporting Open Mobile Alliance (OMA) Mobile Email (MEM) using Internet Mail [draft-ietf-lemonade-architecture-05] (16 pages) - Extended URLFETCH for binary and converted parts [draft-cridland-urlfetch-binary-04] (10 pages) - IMAP4 Extensions for Quick Mailbox Resynchronization [draft-ietf-lemonade-5162bis-00] (25 pages) Requests for Comments: RFC4356: Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail (34 pages) RFC4416: Goals for Internet Messaging to Support Diverse Service Environments (51 pages) RFC4469: Internet Message Access Protocol (IMAP) CATENATE Extension (11 pages) * Updates RFC3501 * Updates RFC3502 * Updated by RFC5550 RFC4467: Internet Message Access Protocol (IMAP) - URLAUTH Extension (5 pages) * Updated by RFC5092 * Updated by RFC5550 RFC4468: Message Submission BURL Extension (14 pages) * Updates RFC3463 * Updated by RFC5248 RFC4550: Internet Email to Support Diverse Service Environments (Lemonade) Profile (18 pages) * OBSOLETED BY RFC5550 RFC4978: The IMAP COMPRESS Extension (9 pages) RFC5032: WITHIN Search extension to the IMAP Protocol (5 pages) * Updates RFC3501 RFC5092: IMAP URL Scheme (32 pages) * Obsoletes RFC2192 * Updates RFC4467 RFC5162: IMAP4 Extensions for Quick Mailbox Resynchronization (25 pages) RFC5259: Internet Message Access Protocol - CONVERT extension (30 pages) RFC5383: Deployment Considerations for Lemonade-Compliant Mobile Email (12 pages) RFC5465: The IMAP NOTIFY Extension (22 pages) * Updates RFC5267 RFC5466: IMAP4 Extension for Named Searches (Filters) (9 pages) RFC5442: LEMONADE Architecture - Supporting Open Mobile Alliance (OMA) Mobile Email (MEM) using Internet Mail (15 pages) RFC5423: Internet Message Store Events (17 pages) RFC5524: Extended URLFETCH for Binary and Converted Parts (10 pages) RFC5550: The Internet Email to Support Diverse Service Environments (Lemonade) Profile (41 pages) * Obsoletes RFC4550 * Updates RFC4469 * Updates RFC4467 RFC5551: Lemonade Notifications Architecture (12 pages) RFC5616: Streaming Internet Messaging Attachments (34 pages) HTTP State Management Mechanism (httpstate) ------------------------------------------- Charter Last Modified: 2009-12-11 Current Status: Active Chairs: Jeff Hodges Eran Hammer-Lahav Applications Area Directors: Lisa Dusseault Alexey Melnikov Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion: http-state@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/http-state Archive: http://www.ietf.org/mail-archive/web/http-state/current/maillist.html Description of Working Group: The HTTP State Management Mechanism (aka Cookies) was originally created by Netscape Communications in their informal Netscape cookie specification ("cookie_spec.html"), from which formal specifications RFC 2109 and RFC 2965 evolved. The formal specifications, however, were never fully implemented in practice; RFC 2109, in addition to cookie_spec.html, more closely resemble real-world implementations than RFC 2965, even though RFC 2965 officially obsoletes the former. Compounding the problem are undocumented features (such as HTTPOnly), and varying behaviors among real-world implementations. The working group will create a new RFC that: * obsoletes RFC 2109, * updates RFC 2965 to the extent it overlaps or voids RFC 2109, and * specifies Cookies as they are actually used in existing implementations and deployments. Where commonalities exist in the most widely used implementations, the working group will specify the common behavior. Where differences exist among the most widely used implementations, the working group will document the variations and seek consensus to reduce variation by selecting among the most widely used variations. The working group must not introduce any new syntax or new semantics not already in common use. The working group's specific deliverables are: * A standards-track document that is suitable to supersede RFC 2109 (likely based on draft-abarth-cookie) * An informational document cataloguing the differences between major implementations In doing so, the working group should consider: * cookie_spec.html - Netscape Cookie Specification http://web.archive.org/web/20070805052634/http://wp.netscape.com/newsref/std/cookie_spec.html * RFC 2109 - HTTP State Management Mechanism (Obsoleted by RFC 2965) http://tools.ietf.org/html/rfc2109 * RFC 2964 - Use of HTTP State Management http://tools.ietf.org/html/rfc2964 * RFC 2965 - HTTP State Management Mechanism (Obsoletes RFC 2109) http://tools.ietf.org/html/rfc2965 * I-D - HTTP State Management Mechanism v2 http://tools.ietf.org/html/draft-pettersen-cookie-v2 * I-D - Cookie-based HTTP Authentication http://tools.ietf.org/html/draft-broyer-http-cookie-auth * Widely Implemented - HTTPOnly http://www.owasp.org/index.php/HTTPOnly * Browser Security Handbook - Cookies http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_cookies * HTTP Cookies: Standards, Privacy, and Politics by David M. Kristol http://arxiv.org/PS_cache/cs/pdf/0105/0105018v1.pdf Goals and Milestones: Mar 2010 - Feature-complete Internet-Draft of Cookie specification May 2010 - Feature-complete test suite of Cookie specification Jun 2010 - Feature-complete draft of deviation description Jul 2010 - First fully conforming implementation in a major browser Sep 2010 - Last Call for Cookie specification Oct 2010 - Last Call for deviation description Dec 2010 - Second fully conforming implementation in a major browser Jan 2011 - Submit Cookie specification to IESG for consideration as a Draft Standard Jan 2011 - Submit deviation description to IESG for consideration as Informationa Mar 2011 - Close or recharter Internet-Drafts: - HTTP State Management Mechanism [draft-ietf-httpstate-cookie-02] (28 pages) No Requests for Comments Hypertext Transfer Protocol Bis (httpbis) ----------------------------------------- Charter Last Modified: 2008-08-21 Current Status: Active Chair: Mark Nottingham Applications Area Directors: Lisa Dusseault Alexey Melnikov Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion: ietf-http-wg@w3.org To Subscribe: http://lists.w3.org/Archives/Public/ietf-http-wg/ Archive: Description of Working Group: HTTP is one of the most successful and widely-used protocols on the Internet today. However, its specification has several editorial issues. Additionally, after years of implementation and extension, several ambiguities have become evident, impairing interoperability and the ability to easily implement and use HTTP. The working group will refine RFC2616 to: * Incorporate errata and updates (e.g., references, IANA registries, ABNF) * Fix editorial problems which have led to misunderstandings of the specification * Clarify conformance requirements * Remove known ambiguities where they affect interoperability * Clarify existing methods of extensibility * Remove or deprecate those features that are not widely implemented and also unduly affect interoperability * Where necessary, add implementation advice * Document the security properties of HTTP and its associated echanisms (e.g., Basic and Digest authentication, cookies, TLS) for common applications In doing so, it should consider: * Implementer experience * Demonstrated use of HTTP * Impact on existing implementations and deployments The Working Group must not introduce a new version of HTTP and should not add new functionality to HTTP. The WG is not tasked with producing new methods, headers, or extension mechanisms, but may introduce new protocol elements if necessary as part of revising existing functionality which has proven to be problematic The Working Group's specification deliverables are: * A document that is suitable to supersede RFC 2616 * A document cataloguing the security properties of HTTP Goals and Milestones: Done - First HTTP Revision Internet Draft Feb 2008 - First HTTP Security Properties Internet Draft Jun 2008 - Request Last Call for HTTP Revision Jul 2008 - Request Last Call for HTTP Security Properties Oct 2008 - Submit HTTP Revision to IESG for consideration as a Draft Standard Oct 2008 - Submit HTTP Security Properties to IESG for consideration as Informational Internet-Drafts: - HTTP/1.1, part 1: URIs, Connections, and Message Parsing [draft-ietf-httpbis-p1-messaging-08] (86 pages) - HTTP/1.1, part 2: Message Semantics [draft-ietf-httpbis-p2-semantics-08] (58 pages) - HTTP/1.1, part 3: Message Payload and Content Negotiation [draft-ietf-httpbis-p3-payload-08] (47 pages) - HTTP/1.1, part 4: Conditional Requests [draft-ietf-httpbis-p4-conditional-08] (26 pages) - HTTP/1.1, part 5: Range Requests and Partial Responses [draft-ietf-httpbis-p5-range-08] (26 pages) - HTTP/1.1, part 6: Caching [draft-ietf-httpbis-p6-cache-08] (40 pages) - HTTP/1.1, part 7: Authentication [draft-ietf-httpbis-p7-auth-08] (16 pages) - Security Requirements for HTTP [draft-ietf-httpbis-security-properties-04] (11 pages) - Initial Hypertext Transfer Protocol (HTTP) Method Registrations [draft-ietf-httpbis-method-registrations-03] (5 pages) No Requests for Comments Internationalized Domain Names in Applications, Revised (idnabis) ----------------------------------------------------------------- Charter Last Modified: 2009-09-01 Current Status: Active Chair: Vinton Cerf Applications Area Directors: Lisa Dusseault Alexey Melnikov Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion: idna-update@alvestrand.no To Subscribe: http://www.alvestrand.no/mailman/listinfo/idna-update Archive: http://www.alvestrand.no/pipermail/idna-update/ Description of Working Group: The original Internationalized Domain Name (IDN) WG specified rules for the use of characters other than Latin A(a)-Z(z), digits 0-9 and the hyphen (-) in domain names in RFC3490, RFC3491 and RFC3492 in 2002 (published in 2003 and often referenced collectively as "IDNA2003"). These documents depend on RFC 3454 and were tied to Unicode version 3.2. An update to the current version (5.x) is required to accommodate additional scripts. In addition, experience has shown that significant improvements could be made in the protocol as presently specified. This WG is chartered to decouple IDNA from specific versions of Unicode using algorithms that define validity based on Unicode properties. It is recognized that some explicit exceptions may be necessary in any case, but attempts will be made to minimize these exceptions. Additional goals: - Separate requirements for valid IDNs at registration time (insertion of names into DNS zone files), vs. at resolution time (looking up those names) - Review, and if necessary revise, the algorithms and rules for handling right to left character sequences in an IDN context to allow labels based on additional scripts and languages and to make presentation as predictable as reasonably possible. - Permit use of some scripts that were inadvertently excluded by the original protocols. - Ensure practical stability of validity algorithms for IDNs. The constraints of the original IDN WG still apply to IDNABIS, namely to avoid disturbing the current use and operation of the domain name system, and for the DNS to continue to allow any system to resolve any domain name in a consistent way. The client-based approach of the original IDN work will be maintained -- substantially new protocols or mechanisms are not in scope. In particular, IDNs continue to use the "xn--" prefix and the same ASCII-compatible encoding, and the bidirectional algorithm follows the same basic design. The specifications are initially organized as four documents: overview and rationale, protocol, table algorithm, and improvements to the bidirectional algorithm. These documents are to be used as the basis for the discussion of the general direction of the work. This working group will be providing extended public review of the output of a design team that has been working on improvement of the IDNA specifications. This review-based approach is being used in part because of the way the work was undertaken by the team; in particular, the design team has been working with IETF visibility and has solicited and received significant amounts of technical review already from IETF participants and from others including experts in the Unicode specifications and the use of scripts in languages. If the public review provided by this Working Group confirms the basic method outlined in the input documents, it is expected that the working group will be able to respond with any needed changes and close in a short period of time. If technical issues arise that indicate a fundamentally different approach must be taken from the one outlined above, it is anticipated that this working group would close, and a new one with an appropriate charter would be considered. This work is intended to specify an improved means to produce and use stable and unambiguous IDN identifiers. There are a variety of generally unsolvable problems, notably the problem of characters that are confusingly similar in appearance (often known as the "phishing" problem) that are not specifically part of the scope of the WG although some of the preliminary results of the design team suggest that the improvements contemplated in the specifications might mitigate some of the ways in which the current IDNA specifications can be abused for phishing purposes. While it is referenced from the original IDNA2003 package, the original Stringprep specification, RFC 3454, is not formally part of the IDNA package and will not be altered by this work. The work will update or obsolete RFC 3490. It is not expected to continue to use Nameprep (RFC 3491). Nameprep is used by other specifications; determining how (or whether) to update those specifications and, consequently, the long-term status of Nameprep, are not part of this effort. The method for ASCII-compatible ("ACE") encoding of IDNs, "Punycode" (RFC 3492) will not be revised by this WG. Subject to the more general constraints described above, the WG is permitted to consider changes that are not strictly backwards- compatible. For any such change that is recommended, it is expected to document the reasons for the change, the characters affected, and possible transition strategies. The assumptions outlined above are considered critical to the WG constituted by this charter. The WG will stop work and recommend that a new charter be generated if it concludes that any of the following are necessary to meet its goals: (i) A change to the "punycode" algorithm or to the ACE approach to encoding names in the DNS. (ii) A change to the ACE prefix from "xn--" (iii) A change to the basic approach taken in the design team documents (Namely: independence from Unicode version and reduction of dependency on character mapping ) Goals and Milestones: Apr 2008 - WG formation May 2008 - Decision on form and structure of the WG document set Sep 2008 - WG Last Call on WG document set Nov 2008 - IETF Last Call on WG document set Internet-Drafts: - The Unicode code points and IDNA [draft-ietf-idnabis-tables-09] (67 pages) - Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale [draft-ietf-idnabis-rationale-17] (50 pages) - Internationalized Domain Names in Applications (IDNA): Protocol [draft-ietf-idnabis-protocol-18] (24 pages) - Right-to-left scripts for IDNA [draft-ietf-idnabis-bidi-07] (21 pages) - Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework [draft-ietf-idnabis-defs-13] (28 pages) - Mapping Characters in IDNA [draft-ietf-idnabis-mappings-05] (5 pages) No Requests for Comments Internationalized Resource Identifiers (iri) -------------------------------------------- Charter Last Modified: 2010-01-29 Current Status: Active Chair: Ted Hardie <> Applications Area Directors: Lisa Dusseault Alexey Melnikov Applications Area Advisor: Alexey Melnikov 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-00] (58 pages) No Requests for Comments Message Organization (morg) --------------------------- Charter Last Modified: 2009-04-03 Current Status: Active Chairs: Randall Gellens Timo Sirainen Applications Area Directors: Lisa Dusseault Alexey Melnikov Applications Area Advisor: Alexey Melnikov Secretary: Barry Leiba Mailing Lists: General Discussion: morg@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/morg Archive: http://www.ietf.org/mail-archive/web/morg/current/maillist.html Description of Working Group: The IETF Message Organization extensions Working Group will work on IMAP extensions that improve clients' ability to find messages or groups of messages in an IMAP mailstore. As a secondary goal, the WG will design its extensions so as to minimize client/server round trips and bandwidth overhead. In particular the Working Group is chartered to finalize and publish the following IMAP extensions as proposed standards: (a) A SORT extension specifying new sort criteria for header fields containing email addresses. This extension will be based on draft-karp-morg-sortdisplay-00.txt. (b) A SEARCH extension specifying new search criteria for header fields containing email addresses. (c) A LIST extension for returning STATUS information in LIST responses. This extension will be based on draft-melnikov-imapext-status-in-list-00.txt. (d) An extension that formalizes a way to return message counters by message context using STATUS and SEARCH commands. (e) An extension that specifies Internet-search-engine-like searching. Such searches would be more flexible (and less formally defined) than substring-based searches, and may return their results in a significant order. They may include "relevance" scores or similar information that could be useful to the user. (f) New collation algorithms such as "ignore whitespace" and "numeric, ignoring punctuation". The WG group will determine which collations are needed, taking into consideration the needs of the protocols that use the collation framework. (g) An extension that allows searching for messages within a message thread. This extension will be based on draft-gulbrandsen-imap-inthread-03.txt. (h) An extension that allows searching of multiple mailboxes at the same time (based on draft-melnikov-imapext-multimailbox-search-03.txt), or of multiple mailbox views. The WG will determine which approach (mailboxes or views) is more suitable as part of its work. Additional documents may be added this list, but only via a charter revision. There must also be demonstrable willingness in the IMAP development community to actually implement a given extension before it can be added to this charter. Revising or replacing the base IMAP4rev1 specification (RFC 3501) is out of the scope of this WG. This WG will ensure that all extensions it proposes take into account any existing problems in the base specification of IMAP, and do not make them worse nor make the problems harder to address in the future. Goals and Milestones: Internet-Drafts: - IMAP4 Multimailbox SEARCH Extension [draft-ietf-morg-multimailbox-search-02] (10 pages) - The IMAP SEARCH=INTHREAD and THREAD=REFS Extensions [draft-ietf-morg-inthread-00] (8 pages) - Display-based Address Sorting for the IMAP4 SORT Extension [draft-ietf-morg-sortdisplay-02] (6 pages) - The IMAP SEARCH=ADDRESS Extension [draft-ietf-morg-address-search-00] (7 pages) - IMAP4 Extension for returning STATUS information in extended LIST [draft-ietf-morg-status-in-list-01] (6 pages) - Additional collation algorithms for use in IMAP and Sieve [draft-ietf-morg-collations-01] (6 pages) - IMAP4 Extension for Fuzzy Search [draft-ietf-morg-fuzzy-search-02] (6 pages) - IMAP LIST extension for special-use mailboxes [draft-ietf-morg-list-specialuse-01] (10 pages) No Requests for Comments Messaging Abuse Reporting Format (marf) --------------------------------------- Charter Last Modified: 2010-01-26 Current Status: Active Chairs: Barry Leiba Murray Kucherawy Applications Area Directors: Lisa Dusseault Alexey Melnikov Applications Area Advisor: Alexey Melnikov Mailing Lists: General Discussion: marf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/marf Archive: http://www.ietf.org/mail-archive/web/marf/ Description of Working Group: Messaging anti-abuse operations between independent services often requires sending reports on observed fraud, spam, virus or other abuse activity. A standardized report format enables automated processing. The Abuse Reporting Format (ARF) specification has gained sufficient popularity to warrant formal codification, to ensure and encourage future interoperability with new implementations. The primary function of this working group will be to solicit review and refinement of the existing specification. A report format is amenable to processing by humans or software, with the latter requiring the format to be standardized, to permit interoperability between automated services, particularly without prior arrangement. ARF was developed as a community effort within the context of a messaging trade organization independent of the IETF (MAAWG, http://www.maawg.org), and uses a format similar to a Delivery Status Notification (DSN, RFC3464) to report fraud, spam, viruses or other abusive activity in the email system. ARF as initially defined is already in widespread use at large ISPs, so interoperability can be demonstrated. Some tools already exist for processing ARF messages, a few of which are open source. In order to preserve the installed base, the working group will make the minimum changes necessary to the existing specification and will seek to have backward compatibility. Furthermore, some extensions to the current proposal are of interest to the community, such as the means for an operator to advertise an email address to which abuse reports using ARF should be sent. The working group will take on the task of considering and specifying such a mechanism. Existing ARF usage employs draft-shafranovich-feedback-report-08, which will provide the working group's starting point. The working group should consider such factors as: * implementation experience * ability to achieve broad implementation and interoperability * existing uses of ARF * internationalization * ability to address a wider range of uses Thus, the working group's specific tasks are as follows: 1) The group will first produce a Proposed Standard track specification of ARF. This will document current use, removing any portions that are not implemented and/or not required for a minimum implementation (these may be considered for extensions at some later date if demand warrants). This will include not only the format of an ARF message, but must also include appropriate documentation of security considerations and creation of IANA registries for elements of ARF to support future extensions, as well as informational sections conveying current best practices. 2) The group will produce an informational document detailing guidelines for deploying and using ARF, including descriptions of current practices and their rationales. 3) The group will specify the integration of ARF into DKIM-aware environments, with draft-kucherawy-dkim-reporting-06 as its input. It contains extensions to DKIM that are related to ARF as a means of reporting DKIM-related failures which include phishing ("fraud") and as such are relevant to the ARF effort. The group will produce Proposed Standard track specification for these ARF and DKIM extensions. 4) The group will finally consider a means for publishing the address to which ARF reports should be sent. Not all ARF participants wish to use abuse@(domain), which is the current standard (RFC2142), as the place to send automated ARF-formatted reports. The group will either conclude that the industry should continue to use this de facto standard (and thus no specification is appropriate), or will produce a Proposed Standard track document identifying the means by which that address should be advertised. The group may consider re-chartering to cover related work, including consideration of items removed since earlier versions of ARF as possible extensions, once these deliverables have been achieved. The working group is aware of related activities in other SDOs, namely the Open Mobile Alliance (http://www.openmobilealliance.org) "MWG-SpamRep" effort and a similar as-yet-unnamed effort inside the GSM Alliance (GSMA, http://www.gsm.org). The working group will coordinate efforts with those groups, and with MAAWG, as required. Goals and Milestones: Jun 2010 - Submit ARF specification for IETF approval Sep 2010 - Submit ARF guidelines document for IETF approval Mar 2011 - Submit DKIM reporting specification for IETF approval Sep 2011 - Submit ARF address advertising specification for IETF approval Internet-Drafts: - An Extensible Format for Email Feedback Reports [draft-ietf-marf-base-00] (31 pages) No Requests for Comments Open Authentication Protocol (oauth) ------------------------------------ Charter Last Modified: 2009-05-15 Current Status: Active Chairs: Peter Saint-Andre Blaine Cook Applications Area Directors: Lisa Dusseault Alexey Melnikov Applications Area Advisor: Lisa Dusseault Tech Advisor: Hannes Tschofenig Mailing Lists: General Discussion: oauth@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/oauth Archive: http://www.ietf.org/mail-archive/web/oauth/current/maillist.html Description of Working Group: OAuth allows a user to grant a third-party Web site or application access to their resources, without necessarily revealing their credentials, or even their identity. For example, a photo-sharing site that supports OAuth would allow its users to use a third-party printing Web site to access their private pictures, without gaining full control of the user account. OAuth consists of: * A mechanism for a user to authorize issuance of credentials which a third party can use to access resources on their behalf. * Mechanism for using the issued credential to authenticate HTTP requests (called "signatures" in current OAuth). The Working Group will produce one or more documents suitable for consideration as Proposed Standard that will: * Improve the terminology used. * Embody good security practice, or document gaps in its capabilities, and propose a path forward for addressing the gap. * Promote interoperability. * Provide guidelines for extensibility. This specifically means that as a starting point for the working group OAuth 1.0 (i.e., draft-hammer-oauth), which is a copy of the original OAuth specification in IETF draft format, is used and the available extension points are going to be utilized. In completing its work to update OAuth 1.0 to become OAuth 1.1, the group will strive to retain backwards compatibility with the OAuth 1.0 specification. However, changes that are not backwards compatible might be accepted if the group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. Furthermore, OAuth 1.0 defines three "signature" methods used to protect requests, namely PLAINTEXT, HMAC-SHA1, and RSA- SHA1. The group will work on new authentication ("signature") methods and will describe the environments where new security requirements justify their usage. Existing signature methods will not be modified but may be dropped as part of the backwards compatible profiling activity. The applicability of existing and new authentication methods to protocols other than HTTP will be investigated. The Working Group should consider: * Implementer experience. * The end-user experience, including internationalization. * Existing uses of OAuth. * Ability to achieve broad implementation. * Ability to address broader use cases than may be contemplated by the original authors. After delivering OAuth 1.1, the Working Group may consider defining additional functions and/or extensions, for example (but not limited to): * Discovery of OAuth configuration, e.g., http://oauth.net/discovery/1.0. * Comprehensive message integrity, e.g., http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/draf ts/1/spec.html. * Recommendations regarding the structure of the token. * Localization, e.g., http://oauth.googlecode.com/svn/spec/ext/language_preferenc e/1.0/drafts/2/spec.html. * Session-oriented tokens, e.g., http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts /1/spec.html. * Alternate token exchange profiles, e.g., draft-dehora- farrell-oauth-accesstoken-creds-00. The work on extensions is within the scope of the working group charter and requires consensus within the group to add new milestones. The Working Group will also define a generally applicable HTTP authentication mechanism (i.e., browser-based "2-leg" scenerio). Goals and Milestones: Apr 2009 - Submit 'OAuth: HTTP Authorization Delegation Protocol' as working group item (draft-hammer-oauth will be used as a starting point for further work.) Jul 2009 - Submit a document as a working group item providing the functionality of the 2-legged HTTP authentication mechanism Jul 2009 - Start of discussion about OAuth extensions the group should work on Oct 2009 - Start Working Group Last Call on 'OAuth: HTTP Authorization Delegation Protocol' Nov 2009 - Submit 'OAuth: HTTP Authorization Delegation Protocol' to the IESG for consideration as a Proposed Standard Nov 2009 - Start Working Group Last Call on the 2-legged HTTP authentication mechanism document Nov 2009 - Prepare milestone update to start new work within the scope of the charter Dec 2009 - Submit 2-legged HTTP authentication mechanism document to the IESG for consideration as a Proposed Standard Internet-Drafts: - The OAuth Protocol: Authentication [draft-ietf-oauth-authentication-02] (21 pages) - The OAuth Protocol: Web Delegation [draft-ietf-oauth-web-delegation-02] (18 pages) No Requests for Comments Sieve Mail Filtering Language (sieve) ------------------------------------- Charter Last Modified: 2009-08-21 Current Status: Active Chairs: Cyrus Daboo Aaron Stone Applications Area Directors: Lisa Dusseault Alexey Melnikov Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion: sieve@ietf.org To Subscribe: sieve-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/sieve/current/maillist.html Description of Working Group: The SIEVE email filtering language is specified in RFC 5228, together with a number of extensions. The SIEVE working group is being re-chartered to: (1) Finish work on existing in-progress Working Group documents: (a) Notify mailto (draft-ietf-sieve-notify-mailto) (c) Mime loops (draft-ietf-sieve-mime-loop) (d) Refuse/reject (draft-ietf-sieve-refuse-reject) (2) Finalize and publish the following SIEVE extensions as proposed standards: (a) iHave (draft-freed-sieve-ihave) (b) Notary (draft-freed-sieve-notary) (c) SIEVE in XML (draft-freed-sieve-in-xml) (d) Notify-sip (draft-melnikov-sieve-notify-sip-message) (e) ManageSIEVE (draft-martin-managesieve) (f) RegEx (draft-ietf-sieve-regex) (g) Meta-data (draft-melnikov-sieve-imapext-metadata) (h) Include/multi-script (draft-daboo-sieve-include) (i) Address data (draft-melnikov-sieve-external-lists) (j) Support for Sieve in IMAP (draft-ietf-lemonade-imap-sieve) Additional drafts may be added to this list, but only via a charter revision. There must also be demonstrable willingness in the SIEVE development community to actually implement a given extension before it can be added to this charter. (3) Work on a specification to describe how EAI/IDN issues should be handled in SIEVE. (4) Work on a "Benefits of SIEVE" guide for client and server vendors that: (a) Describes the SIEVE protocol and its suite of extensions. (b) Explains the benefits of server-side filtering in practical terms. (c) Shows how client-side filtering can be migrated to SIEVE. (5) Produce one or more informational RFCs containing a set of test scripts and test email messages that are to be filtered by the scripts, and the expected results of that filtering. This will serve as the basis of a interoperability test suite to help determine the suitability of moving the base specification and selected extensions to Draft status. Goals and Milestones: Done - Submit revised variables draft. Done - Submit revised vacation draft. Done - WG last call for variables draft. Done - Initial submission of RFC 3028bis. Done - WG last call for RFC 3028bis. Done - Initial submission of revised relational draft. Done - Initial submission of revised subaddress draft. Done - Initial submission of revised spamtest/virustest draft. Done - Submit revised editheader draft. Done - Submit revised imapflags draft. Done - WG last call of revised subaddress draft. Done - Submit revised body test draft. Done - Submit revised reject before delivery draft. Done - WG last call for editheader draft. Done - WG last call for body test draft. Done - WG last call for refuse draft Done - WG last call of revised spamtest draft Done - Submit variables draft to IESG Done - Submit revised loop draft Done - Submit revised notification action draft Done - WG last call of revised relational draft Done - WG last call for imap-flags draft Done - WG last call for vacation draft Done - WG last call of revised subaddress draft Done - Submit revised relational draft to IESG Done - Submit vacation draft to IESG Done - Submit revised subaddress draft to IESG Done - Submit imapflags draft to IESG Done - Submit revised spamtest draft to IESG Done - Submit 3028bis to IESG Done - Submit editheader draft to IESG Done - Submit body test draft to IESG Done - WG last call for notification action draft Done - Submit notification action draft to IESG Done - Submit refuse-reject to IESG Done - Submit notify-mailto to IESG Done - Submit mime-loops to IESG Done - WGLC iHave Done - WGLC Notary Done - Submit iHave to IESG Done - Submit Notary to IESG Done - WGLC sieve-in-xml Done - Submit sieve-in-xml to IESG Done - WGLC ManageSIEVE Done - Submit ManageSIEVE to IESG Done - WGLC Notify-sip Jan 2009 - Submit Notify-sip to IESG Done - WGLC Metadata Done - Submit Metadata to IESG Feb 2009 - WGLC RegEx Mar 2009 - Submit RegEx to IESG Mar 2009 - WGLC Include/multi-script Apr 2009 - Submit Include/multi-script to IESG Apr 2009 - WGLC external-lists May 2009 - Submit external-lists to IESG May 2009 - WGLC eai-issues Jun 2009 - Submit eai-issues to IESG Jun 2009 - WGLC benefits Jul 2009 - Submit benefits to IESG Jul 2009 - Submit benefits to IESG Aug 2009 - Submit test-scripts to IESG Internet-Drafts: - Sieve Email Filtering: Reject and Extended Reject Extensions [draft-ietf-sieve-refuse-reject-10] (15 pages) - Sieve Extension: Variables [draft-ietf-sieve-variables-09] (16 pages) - SIEVE Email Filtering: Spamtest and Virustest Extensions [draft-ietf-sieve-spamtestbis-06] (16 pages) - Sieve Email Filtering: Body Extension [draft-ietf-sieve-body-10] (13 pages) - Sieve Email Filtering: Editheader Extension [draft-ietf-sieve-editheader-12] (12 pages) - SIEVE Email Filtering: IMAP flag Extension [draft-ietf-sieve-imapflags-06] (0 pages) - Sieve Email Filtering -- Subaddress Extension [draft-ietf-sieve-rfc3598bis-06] (13 pages) - Sieve: An Email Filtering Language [draft-ietf-sieve-3028bis-14] (45 pages) - Sieve Extension: Relational Tests [draft-ietf-sieve-3431bis-05] (15 pages) - Sieve Email Filtering: Vacation Extension [draft-ietf-sieve-vacation-08] (16 pages) - SIEVE Email Filtering: Extension for Notifications [draft-ietf-sieve-notify-13] (23 pages) - Sieve Extension: Externally Stored Lists [draft-ietf-sieve-external-lists-01] (8 pages) - Sieve Notification Mechanism: mailto [draft-ietf-sieve-notify-mailto-11] (17 pages) - Sieve Notification Mechanism: xmpp [draft-ietf-sieve-notify-xmpp-10] (15 pages) - Sieve Email Filtering -- Regular Expression Extension [draft-ietf-sieve-regex-00] (15 pages) - Sieve Email Filtering: MIME part Tests, Iteration, Extraction, Replacement and Enclosure [draft-ietf-sieve-mime-loop-10] (22 pages) - The Sieve mail filtering language - extensions for checking mailbox status and accessing mailbox metadata [draft-melnikov-sieve-imapext-metadata-09] (10 pages) - Sieve Email Filtering: Ihave Extension [draft-freed-sieve-ihave-05] (7 pages) - Sieve Email Filtering: Delivery Status Notifications and Deliver-By Extensions [draft-freed-sieve-notary-06] (11 pages) - Sieve Email Filtering: Sieves and display directives in XML [draft-freed-sieve-in-xml-07] (33 pages) - A Protocol for Remotely Managing Sieve Scripts [draft-ietf-sieve-managesieve-09] (52 pages) - Sieve Notification Mechanism: SIP MESSAGE [draft-ietf-sieve-notify-sip-message-02] (9 pages) - Sieve Email Filtering: Include Extension [draft-ietf-sieve-include-04] (14 pages) - Support for Sieve in Internet Message Access Protocol (IMAP4) [draft-ietf-sieve-imap-sieve-00] (24 pages) Requests for Comments: RFC5228: Sieve: An Email Filtering Language (45 pages) * Updated by RFC5229 * Updated by RFC5429 RFC5235: SIEVE Email Filtering: Spamtest and Virustest Extensions (16 pages) * Obsoletes RFC3685 RFC5229: Sieve Email Filtering: Variables Extension (16 pages) * Updates RFC5228 * Updated by RFC5173 RFC5230: Sieve Email Filtering: Vacation Extension (16 pages) RFC5231: Sieve Email Filtering: Relational Extension (15 pages) * Obsoletes RFC3431 RFC5232: SIEVE Email Filtering: IMAP4flag Extension (0 pages) RFC5233: Sieve Email Filtering: Subaddress Extension (13 pages) * Obsoletes RFC3598 RFC5173: Sieve Email Filtering: Body Extension (13 pages) * Updates RFC5229 RFC5293: Sieve Email Filtering: Editheader Extension (9 pages) RFC5435: SIEVE Email Filtering: Extension for Notifications (17 pages) RFC5436: Sieve Notification Mechanism: mailto (17 pages) * Updates RFC3834 RFC5437: Sieve Notification Mechanism: xmpp (14 pages) RFC5463: Sieve Email Filtering: Ihave Extension (6 pages) RFC5429: Sieve Email Filtering: Reject and Extended Reject Extensions (15 pages) * Obsoletes RFC3028 * Updates RFC5228 RFC5490: The Sieve Mail-Filtering Language -- Extensions for Checking Mailbox Status and Accessing Mailbox Metadata (8 pages) RFC5703: Sieve Email Filtering: MIME part Tests, Iteration, Extraction, Replacement and Enclosure (22 pages) Virtual World Region Agent Protocol (vwrap) ------------------------------------------- Charter Last Modified: 2009-09-29 Current Status: Active Chairs: Barry Leiba Joshua Bell Applications Area Directors: Lisa Dusseault Alexey Melnikov Applications Area Advisor: Alexey Melnikov Mailing Lists: General Discussion: ogpx@ietf.org To Subscribe: ogpx-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/ogpx/current/maillist.html Description of Working Group: The working group will define the Virtual World Region Agent Protocol (VWRAP) for a collaborative 3-dimensional virtual environment. The protocol permits users to interact as digital representations called "avatars". An avatar exists in at most one location within a shared virtual space. Conforming client applications use the protocol to manipulate and move the user's avatar, create virtual objects, interact with other users and their surroundings, consume and create media and information from sources inside and outside their simulated environment. A virtual space can be partitioned into "regions" to facilitate the computational and communication load balancing required to simulate the virtual environment. A region provides the service environment in which inhabitants and objects can interact. A region uniquely represents a partition of the virtual space; they are not a mechanism for load balancing by having multiple instances of the same space. Different regions may be administered by different organizations. The state of a virtual world is independent of the client applications that access it and may persist between user sessions. Within a VWRAP virtual environment, services may be deployed by multiple organizations having varying policies and trust domains. The VWRAP protocol will provide the mechanisms for these services to interoperate, when permitted by policy. The working group may document examples of policies applicable to a VWRAP environment. Foundational components of the protocol include the publication of: * an abstract type system, suitable for describing the application protocol in an implementation neutral manner, * a security model describing trust relationships between participating entities, * guidelines for the use of existing authentication and confidentiality mechanisms, * an application-layer protocol for establishing the user's avatar in a region, * an application-layer protocol for changing an avatar's position, including moving between regions, * format descriptions for objects and avatars, and * an application-layer protocol for identifying entities, and requesting information about them. The protocol defined by this group will carry information about the virtual environment, its contents and its inhabitants. It is an application layer protocol, independent of transport, based partially on these previously published internet drafts: * http://tools.ietf.org/html/draft-hamrick-ogp-intro * http://tools.ietf.org/html/draft-hamrick-llsd * http://tools.ietf.org/html/draft-hamrick-ogp-auth * http://tools.ietf.org/html/draft-hamrick-ogp-launch * http://tools.ietf.org/html/draft-lentczner-ogp-base * http://tools.ietf.org/html/draft-levine-ogp-clientcap * http://tools.ietf.org/html/draft-levine-ogp-layering The protocol should describe interaction semantics independent of transport, leveraging existing standards where practical. It should define interoperability expectations for server to server interactions as well as client-server interactions. Though the protocol is independent of transport, early interoperability trials used HTTP(S) for non-real-time messages. The working group will define specific features that must be replicated in other transports and will define the use of HTTP(S) as a transport of protocol messages. Goals and Milestones: Feb 2010 - 'Introduction and Goals' to the IESG as an Informational RFC Feb 2010 - 'Abstract Type System for the Transmission of Dynamic Structured Data' to the IESG as Proposed Standard Jun 2010 - 'Foundational Concepts and Transport Expectations' to the IESG as Proposed Standard Jun 2010 - 'Client Application Launch Message' to the IESG as an Informational RFC Oct 2010 - 'Trust Model and User Authentication' to the IESG as Proposed Standard Oct 2010 - 'Voice and Text Communication Channel Establishment' to the IESG as Proposed Standard Feb 2011 - 'Agent Presence Establishment' to the IESG as Proposed Standard Feb 2011 - 'Region Description Format' to the IESG as Proposed Standard Jun 2011 - 'Digital Asset Access' to the IESG as Proposed Standard Jun 2011 - 'Primitive Object Format' to the IESG as Proposed Standard Oct 2011 - 'Avatar Format' to the IESG as Proposed Standard Oct 2011 - 'Entity Identifiers' to the IESG as Proposed Standard Feb 2012 - 'Time Sensitive Messages' to the IESG as Proposed Standard Internet-Drafts: No Requests for Comments Yet Another Mail (yam) ---------------------- Charter Last Modified: 2009-08-04 Current Status: Active Chairs: Tony Hansen Chris Newman Applications Area Directors: Lisa Dusseault Alexey Melnikov Applications Area Advisor: Alexey Melnikov Secretary: S Moonesamy Mailing Lists: General Discussion: yam@ietf.org To Subscribe: yam-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/yam/index.html Description of Working Group: The Yet Another Mail (YAM) WG will revise existing Internet Mail specifications currently at Draft Standard to advance them to Full Standard. YAM will focus strictly on advancing email-related specifications for which the community already has some years of experience with deployment and interoperability. Its function is not to reopen or reconsider protocols - if a specification is found to need significant technical work, YAM will remove it from the WG's agenda. This charter's scope of work is the set of email-related RFCs that are currently at Draft Standard. Each document will be examined, along with its errata, and a recommendation made as to whether it is suitable for advancement to Full Standard. If it is not, the WG may recommend whether it should be republished at Draft Standard, moved to Historic, or recycled to Proposed Standard. However, any actual work to facilitate publication of a document at other than Full Standard is outside the WG's scope. If the WG cannot quickly reach consensus about further work on a document, it will drop the documents from its agenda without further comment or effort. The purpose of this working group is to work on protocols that are already recognized as effectively full standards, improving their written specifications to align with that status. The working group does not intend to revise the actual protocols in any way and will avoid document changes that might even accidentally introduce protocol changes, destabilize a protocol, or introduce semantic or syntactic changes. In particular, it will avoid adding new document sections that were not previously required and making BNF grammar changes that didn't originate from interoperability problems or difficulties in comprehension by implementors. If an existing protocol implementation is conforming to the Draft Standard version of the protocol specification, it must also be conforming to the resulting Full Standard version. Hence, specification changes that create a violation of this requirement are out of scope of the working group charter. On a case by case basis, substantive changes may be considered, if they will modify text to match existing conforming implementations -- that is, implementations that are already deployed with significant use. Specifically, such changes will be permitted to relax requirements or to fix BNF bugs where the intent is and has been clear. The WG will consult with the IESG about proposed changes before it starts working on them. Once the document is done by the WG, approval proceeds using the normal IETF approval process. The two step approach is proposed in order to save both IESG and WG time and to avoid late surprises when a document is considered done by the WG. After the tasks of this charter are completed, the WG will consider rechartering to move selected mature specifications that are still at Proposed Standard to higher maturity levels, or to work on those documents previously identified as needing to be republished at Draft Standard or Proposed Standard. The underpinnings of this WG effort are: (1) Wide deployment and use of interoperable implementations of an existing standards-track protocol demonstrates a presumption that the existing specification is adequate. The burden of demonstrating the contrary lies with those who believe that they see significant technical or documentation defects. (2) It is generally in the best interest of the IETF and the Internet community to see specifications of mature protocols advance on the standards track, eliminating any uncertainty as to whether the protocols have been adequately understood and tested. To that end, YAM will avoid modification of documents simply to adjust them to match contemporary IETF notational or linguistic norms. Obviously, updating of references, boilerplate, and the equivalent are exceptions to this, but success in the WG requires that there be a good-faith commitment by both its participants and the IESG to avoid seeking changes that (a) do not contribute in a substantial and substantive way to the quality and comprehensibility of the specification, or that (b) force a change to the existing protocol. The steps to be followed by the WG are, approximately: o The WG will start work by analyzing the following email related documents which are currently Draft Standards, removing any that have significant technical defects or whose advancement may be controversial under the advancement criteria specified in RFC 2026: RFC 1652 8BITMIME RFC 1864 Content-MD5 RFC 2045, 2046, 2047, 2049 MIME base specs RFC 3282 Content-language RFC 3461 DSNs RFC 3462 Multipart/Report RFC 3463 Enhanced Status Codes RFC 3464 Message Format for DSNs RFC 3798 Message Disposition Notification RFC 4409 Message Submission RFC 5321 SMTP RFC 5322 Internet Message Format o Form review and editing teams for each document to be advanced. o Formulate a list of proposed changes (stated in general terms, rather than specific wording). o Obtain WG consensus and consult with IESG on these changes. o Post I-Ds for WG consideration and consensus formation. o Recommend resulting documents to IESG for publication processing. o Rinse and repeat. Goals and Milestones: Sep 2009 - Produce the initial list of documents to consider for advancement to Full Standard Nov 2010 - Recharter or conclude Internet-Drafts: - Preliminary Evaluation of RFC 1652 for Advancement to Full Standard [draft-ietf-yam-rfc1652bis-pre-evaluation-02] (6 pages) - THIS INTERNET DRAFT IS NOT MEANT TO BE PUBLISHED AS AN RFC, BUT IS WRITTEN TO FACILITY PROCESSING WITHIN THE IESG. [draft-ietf-yam-pre-evaluation-template-02] (4 pages) - Preliminary Evaluation of RFC5321, Simple Mail Transfer Protocol (SMTP), for advancement from Draft Standard to Full Standard by the YAM Working Group [draft-ietf-yam-5321bis-smtp-pre-evaluation-03] (10 pages) - SMTP Service Extension for 8-bit MIME Transport [draft-ietf-yam-rfc1652bis-01] (7 pages) No Requests for Comments vCard and CardDAV (vcarddav) ---------------------------- Charter Last Modified: 2009-04-03 Current Status: Active Chairs: Marc Blanchet Kurt Zeilenga Applications Area Directors: Lisa Dusseault Alexey Melnikov Applications Area Advisor: Alexey Melnikov Mailing Lists: General Discussion: vcarddav@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/vcarddav Archive: http://www.ietf.org/mail-archive/web/vcarddav Description of Working Group: A personal address book (PAB) contains a read/write copy of attributes describing a user's interpersonal contacts. This is distinct from a directory which contains a primarily read-only copy of users within an organization. While these two data objects share a large number of common attributes, their use and access patterns are fundamentally different. The IETF has a standards-track data format (vCard) which has been successfully used to interchange both personal-address-book and user directory entry data objects. However, due to the lack of a standard access control model for LDAP, the lack of a standard LDAP schema and DIT-model for vCard PAB objects, and the different access patterns for PAB data (as opposed to directory data), the use of LDAP as an access protocol for PABs has had mixed results in practice. Moreover, the vCard format has been extended by many parties and the current specification is ambiguous for some objects. If the deployed protocols related to interpersonal communication are viewed as a component-based system, there are a number of points in the system that would benefit from a standards track access protocol for personal address book data. This includes: * Mail User Agents use PAB data to assist outgoing email addressing and may use vCard attachments to transport PAB data between users. * Calendar User Agents use PAB data to invite attendees to events * Instant Messaging User Agents can provide additional information about a user's buddies if they can be associated with a user's PAB entry. * A server-side Sieve engine with the spamtest/virustest extension would benefit from access to a user's PAB to provide per-user white list capabilities. * Various deployed challenge-response mechanisms for email present in Mail Transfer Agents, such as TMDA, would be improved by a PAB-based white list. * Mobile device synchronization software might be simplified by a single cross-platform PAB access protocol. * A voice conference or IP telephony system could access a user's PAB to provide name-based or nickname-based dialing. This WG will produce the following outputs: (1) A revision of the vCard specification (RFC2426) at proposed standard status. This revision shall include other vCard standardized extensions (RFC 2739, 4770) and extensions assisting synchronization technologies (for example, a per-entry UUID or per-attribute sequence number). Other extensions shall be considered either in the base specification or in additional documents. (2) An address book access protocol leveraging the vCard data format. The Internet-draft draft-daboo-carddav will be the starting point. The WG is explicitly cautioned to keep the base specification feature set small with an adequate extension mechanism, as failure to do so was a problem for previous PAB efforts (ACAP). The WG will consider arguments of the form "feature X must be in the base feature set because ..." with great skepticism. These documents will consider security implications carefully. The WG will consider developing a mechanism that provides the ability to check if an email address (or im address, etc) is in the user's PAB without providing unrestricted access to all of the user's PAB data. The WG should also consider developing a mechanism that allows the user to grant this limited permission to a third-party service (such as a server-based Sieve engine) for white-list purposes. Once the primary outputs are complete, the WG will consider the following secondary outputs: (3) An XML schema which is semantically identical to vCard in all ways and can be mechanically translated to and from vCard format without loss of data. While vCard has deployed successfully and will remain the preferred interchange format, a standard XML schema which preserves vCard semantics might make vCard data more accessible to XML- centric technologies such as AJAX and XSLT. Such a standard format would be preferable to multiple proprietary XML schemas, particularly if vCard semantics were lost by some of them and a lossy gateway problem resulted. (4) Identifying useful deployed vCard vendor extensions and creating standards track versions of those extensions. (5) Cooperate with the Sieve WG to produce a Sieve extension for address book Sieve tests. (6) LDAP mapping to the new vCard format without loss of data. Goals and Milestones: Mar 2008 - Address book access protocol draft Mar 2008 - vCard new revision draft Jun 2008 - submit to IESG both drafts Jun 2008 - XML schema Jun 2008 - LDAP schema Sep 2008 - vcard extensions Dec 2008 - submit to IESG remaining drafts Internet-Drafts: - vCard Extensions to WebDAV (CardDAV) [draft-ietf-vcarddav-carddav-10] (56 pages) - vCard Format Specification [draft-ietf-vcarddav-vcardrev-09] (75 pages) - Extended MKCOL for WebDAV [draft-ietf-vcarddav-webdav-mkcol-07] (13 pages) - vCard XML Schema [draft-ietf-vcarddav-vcardxml-01] (15 pages) Requests for Comments: RFC5689: Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV) (13 pages) * Updates RFC4791 * Updates RFC4918 Access Node Control Protocol (ancp) ----------------------------------- Charter Last Modified: 2009-10-13 Current Status: Active Chairs: Matthew Bocci Wojciech Dec Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Tech Advisor: Dan Romascanu Mailing Lists: General Discussion: ancp@ietf.org To Subscribe: ancp-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/ancp/current/maillist.html Description of Working Group: Purpose: The purpose of the ANCP WG is to standardize an IP-based Access Node Control Protocol (ANCP) for use in service provider Digital Subscriber Line (DSL) and Passive Optical Network (PON) access and aggregation networks. ANCP operates between an Access Node (AN) and Network Access Server (NAS). Necessary Terminology: Access Node (AN) - Network device, usually located at a service provider central office or street cabinet, that terminates access loop connections from Subscribers. In DSL, this is often referred to as a Digital Subscriber Line Access Multiplexer (DSLAM). In PON, this is usually comprised of an Optical Network Termination (ONT) / Optical Network Unit (ONU) and an Optical Line Termination (OLT). Network Access Server (NAS) - Network device which aggregates multiplexed Subscriber traffic from a number of Access Nodes. The NAS plays a central role in per-subscriber policy enforcement and QoS. This is often referred to as a Broadband Network Gateway (BNG) or Broadband Remote Access Server (BRAS). A detailed definition of the NAS is given in RFC2881. Goals: ANCP is intended to address the requirement for a bidirectional, IP- based, control protocol that operates across multiple types (i.e., Ethernet, ATM) of DSL and PON access and aggregation networks. The goal of an ANCP message exchange is to convey status and control information between one or more ANs and one or more NASs without going through intermediate element managers. The ANCP WG will address the following four use-cases: 1. Dynamic Access Loop Attributes Various queuing and scheduling mechanisms are used in access networks to avoid congestion while dealing with multiple flows and distinct QoS profiles. Communicating the access-loop status, attributes and current DSL synchronization rate between the AN and Subscriber up to the NAS is desirable, particularly when the NAS is providing QoS for individual flows and subscribers. ANCP will provide a mechanism to communicate dynamic access-loop attributes from the AN to the NAS. 2. Access Loop Configuration In additional to reporting Access Loop characteristics from the AN to the NAS, ANCP will allow a NAS to send loop-specific configuration information to an AN based on the results of subscriber authentication and authorization (e.g., after AAA responses have been received at the NAS). 3. Remote Connectivity Test Traditional DSL access and aggregation networks employ point-to-point ATM circuits between the AN and NAS for each subscriber, allowing troubleshooting of the local loop from the NAS via ATM OAM tools. With the increasing deployment of Ethernet in the access and aggregation network, operators require consistent methods to test and troubleshoot connectivity for mixed Ethernet and ATM access networks (including the local loop). ANCP will allow a remote procedure for a local loop connectivity test to be triggered from the NAS with results communicated back to the NAS. 4. Multicast When multicast replication for subscriber-bound traffic is performed at the AN, it offloads the network between the AN and NAS. However, a subscriber's policy and configuration for multicast traffic may only be known at the NAS. ANCP will provide a mechanism to communicate the necessary information exchange between the AN and NAS so as to allow the AN to perform subscriber bound multicast group replication in line with the subscriber's policy and configuration, and also allow the NAS to follow each subscriber's multicast group membership. Non-Goals: ANCP is an IP-based protocol that operates between the AN and NAS. It will not address setup or configuration of circuits or connections in the access and aggregation network itself. The focus of this WG is on one very specific application space. While the design of the protocol must be general as to not preclude other uses in the future should a need arise, it is not a goal of this WG to address specific requirements outside of service provider broadband (such as xDSL, xPON) access and aggregation networks. Security: The ANCP working group will provide a threat analysis and address the associated security aspects of the control protocol. Resiliency and Scalability: A graceful restart mechanism will be defined to enable the protocol to be resilient to network failures between the AN and NAS. Scalability at the NAS is of primary concern, as it may be aggregating traffic from a large number of ANs, which in turn may be serving a large number of Subscribers. ANCP traffic should not become a denial of service attack on the NAS control plane. Format of messages, pacing, transport over UDP or TCP, etc. will be considered with this in mind. For reasons of aggregation network scalability, some use cases require that aspects of NAS or AN functionality may be distributed in nodes in the aggregation network. In these cases, ANCP can run between these nodes. Deliverables: The working group will define a basic framework and requirements document intended for Informational publication, focusing on the four use-cases outlined in this charter. This document will include a security threat analysis and associated requirements. The WG will then investigate and define a solution for an IP based control protocol meeting these requirements. There are early interoperable implementations of an ANCP-like protocol which are based on an extended subset of the GSMPv3 protocol. This running code will be the the starting point for the working group solution, and will be abandoned only if the WG determines it is not adequate to meet requirements going forward. Coordination with other Working Groups or Organizations: The working group will coordinate with the ADSL MIB working group so the management framework and MIB modules are consistent for DSL access environments. The working group will re-use, as far as possible, standard MIB modules that have already been defined. The remote connectivity test use case may require coordination with ITU-T Ethernet OAM and PON work and with IEEE 802.1ag. Goals and Milestones: Done - Accept WG I-D for ANCP Framework and Requirements Done - Accept WG I-D for Access Node Control Protocol (ANCP) Done - Accept WG ID for Security Threats analysis Done - Accept WG I-D for ANCP MIB Done - Security Threats Analysis last call Done - Framework and Requirements last call Done - Accept WG I-D for ANCP Multicast Extensions Nov 2009 - Accept WG I-D for ANCP applicability to PON Jan 2010 - Access Node Control Protocol (ANCP) Last Call Jan 2010 - ANCP MIB Last Call Jan 2010 - ANCP Multicast Extensions last call Apr 2010 - ANCP applicability to PON last call Jul 2010 - Re-charter or conclude Working Group Internet-Drafts: - Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks [draft-ietf-ancp-framework-13] (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-08] (59 pages) - Access Node Control Protocol (ANCP) MIB module for Access Nodes [draft-ietf-ancp-mib-an-05] (36 pages) - Additional Multicast Control Extensions for ANCP [draft-ietf-ancp-mc-extensions-01] (91 pages) Requests for Comments: RFC5713: Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) (18 pages) Ad-Hoc Network Autoconfiguration (autoconf) ------------------------------------------- Charter Last Modified: 2009-04-02 Current Status: Active Chairs: Ryuji Wakikawa Thomas Clausen Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: autoconf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf Archive: http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html Description of Working Group: In order to communicate among themselves, ad hoc nodes (refer to RFC 2501) need to configure their network interface(s) with local addresses that are valid within an ad hoc network. Ad hoc nodes may also need to configure globally routable addresses, in order to communicate with devices on the Internet. From the IP layer perspective, an ad hoc network presents itself as a L3 multi-hop network formed over a collection of links. The main purpose of the AUTOCONF WG is to describe the addressing model for ad hoc networks and how nodes in these networks configure their addresses. It is required that such models do not cause problems for ad hoc-unaware parts of the system, such as standard applications running on an ad hoc node or regular Internet nodes attached to the ad hoc nodes. This group's effort may include the development of new protocol mechanisms, should the existing IP autoconfiguration mechanisms be found inadequate. However, the first task of the working group is to describe one practical addressing model for ad hoc networks. Once this sole work item is completed, the group can be rechartered to work on additional issues. Goals and Milestones: Done - Submit an initial 'MANET architecture' WG document Done - Submit an initial 'terminology and problem statement' WG document Done - Submit 'MANET architecture' document to IESG for publication as an informational RFC Apr 2009 - Submit initial draft on addressing model in ad hoc networks Sep 2009 - Submit addressing model draft to IESG as Informational or close WG Internet-Drafts: - Mobile Ad hoc Network Architecture [draft-ietf-autoconf-manetarch-07] (20 pages) - Address Autoconfiguration for MANET: Terminology and Problem Statement [draft-ietf-autoconf-statement-04] (22 pages) - IP Addressing Model in Ad Hoc Networks [draft-ietf-autoconf-adhoc-addr-model-02] (8 pages) No Requests for Comments Cga & Send maIntenance (csi) ---------------------------- Charter Last Modified: 2009-04-13 Current Status: Active Chairs: Marcelo Bagnulo Gabriel Montenegro Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion: cga-ext@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/cga-ext Archive: http://www.ietf.org/mail-archive/web/cga-ext/current/maillist.html Description of Working Group: The Secure Neighbor Discovery (SEND) protocol defined by RFC 3971 provides security mechanisms protecting different functions of the Neighbor Discovery (ND) protocol defined by RFC 2461. This includes address resolution (discovering link layer address of another node attached to the link), router discovery (discovering routers attached to the link), and neighbor unreachability detection (detecting that a node attached to the link is no longer reachable). SEND protection of address resolution and neighbor unreachability detection functions relies on IPv6 address proof-of-ownership and message integrity protection provided respectively via Cryptographically Generated Addresses (CGAs) and RSA Digital Signatures. CGAs are defined in RFC 3972, and are extended with a CGA extension format defined in RFC 4581, and a support for multiple hash functions defined in RFC 4982. While CGAs were originally defined for the SEND protocol, they have proved to be a useful security tool in other environments too, and its usage has been proposed to secure other protocols such as the Shim6 multihoming protocol and the Mobile IPv6 protocol. While there is very little deployment of SEND to date, there are a number of implementations, recommendations in the NIST and DOD profiles call for use of SEND, and operating system vendors are considering adding SEND to their next releases. As a result, it is desirable to review the current state of the SEND and CGA specifications, maintain and complement them where necessary. Up to date cryptographic algorithms are needed, and the protocols need to be able to deal with certain common situations currently not supported. Specifically, the WG will look at the following issues: - Develop an informational document analyzing the implications of recent attacks on hash functions used by SeND protocol. Current SeND specification uses the SHA-1 hash algorithm and does not provides support for hash algorithm agility, hence the critical need for understanding the impact of the attacks on the SeND protocol. In addition, if as a result of the aforementioned analysis it is deemed necessary, standard-track extensions to the SeND protocol to support multiple hash algorithms will be defined. - Specify a standards-track CGA and SeND extensions to support multiple public key algorithms. As currently defined CGA and SeND can only use RSA keys, and they lack support for other public key algorithms (e.g. Elliptic Curve Cryptography -- ECC). - Develop X.509 certificate management tools for SeND. SeND utilizes X.509v3 certificates for performing router authorization. It uses the X.509 extension for IP addresses to verify whether the router is authorized to advertise the mentioned IP addresses. Since the IP addresses extension does not explicitly mention what functions the node can perform for the IP addresses it becomes impossible to know the reason for which the certificate was allowed. In order to facilitate issuance of certificates for specific functions, we need to encode the functions permitted for the certificate into the certificate itself. The WG will develop a certificate profile, including a definition of X.509 Extended Key Usage for SeND . In addition, the WG will recommend best practices for (1) enrollment, (2) revocation checking, and (3) publishing of certificates. This WG will ensure that the profile and recommended practices will cover usage by hosts in addition to routers. The working group will coordinate this activity with the PKIX and SIDR WGs. Prior to IESG submission of the certificate profile, the working group will seek input from and coordinate with other groups enabling cryptographic identification of device-related properties (e.g., IEEE 802.1ar, IEEE 802.16, WiMAX Forum, IETF CAPWAP WG). - Develop a standard track document defining a mechanism to perform SeND certificate provisioning for routers. SeND protocol as defined in RFC3971 specifies how IPv6 nodes can trust the prefixes advertised by a router. The solution is based on the use of the IP Address Delegation extension (RFC3779) in X.509 v3 certificates (RFC3280). This work will provide the tools require to provision with the certificates to the routers in an automatic manner. The working will coordinate this activity with the PKIX WG. - Produce a problem statement document for Neighbor Discovery Proxies and then specify standards-track SEND Extensions to support Neighbor Discovery Proxies: SEND protocol as currently defined in RFC 3971 lacks of support for ND Proxies defined in RFC 3775 and RFC 4389. Extensions to the SEND protocol will be defined in order to provide equivalent SEND security capabilities to ND Proxies. - Develop an informational document analysing different approaches to allow SeND and CGAs to be used in conjunction with DHCP, and making recommendations on which are the best suited. Recharter based on the result of the analysis. - Update base specifications (RFC 3971 and 3972). Goals and Milestones: Jun 2008 - WG last-call on analysis of hash related threats in SeND Jul 2008 - Submit draft on analysis of hash related threats in SeND to IESG Aug 2008 - WG last-call on Proxy-SeND problem statement Sep 2008 - Submit draft on Proxy-SeND problem statement to IESG Dec 2008 - WG last-call on multiple hash function support in SeND, if required Dec 2008 - WG last-call on multiple public key algorithm support for CGA Dec 2008 - WG last-call on multiple public key algorithm support for SeND Dec 2008 - WG last-call on certificate profile definition for SeND Jan 2009 - WG last-call on Proxy SeND Jan 2009 - Submit draft on multiple hash function support in SeND to IESG, if required Jan 2009 - Submit draft on multiple public key algorithm support for CGA to IESG Jan 2009 - Submit draft on multiple public key algorithm support for SeND to IESG Jan 2009 - Submit draft on certificate profile definition for SeND to IESG Feb 2009 - Submit draft on Proxy SeND to IESG Jun 2009 - WG last-call on certificate provision mechanism for SeND routers Jun 2009 - WG last-call on certificate management best practices for SeND routers Jul 2009 - WG last-call on CGA-DHCP interaction Jul 2009 - Submit draft on certificate provision mechanism for SeND routers to IESG Jul 2009 - Submit draft on certificate management best practices for SeND routers to IESG Aug 2009 - Submit draft on CGA-DHCP interaction to IESG Nov 2009 - WG last-call on updated SeND specification Dec 2009 - Submit draft on updated SeND specification to IESG Dec 2009 - Submit draft on updated CGA specification to IESG Internet-Drafts: - SeND Hash Threat Analysis [draft-ietf-csi-hash-threat-05] (12 pages) - Securing Neighbor Discovery Proxy: Problem Statement [draft-ietf-csi-sndp-prob-04] (22 pages) - Secure Proxy ND Support for SEND [draft-ietf-csi-proxy-send-02] (22 pages) - Certificate profile and certificate management for SEND [draft-ietf-csi-send-cert-01] (14 pages) - DHCPv6 and CGA Interaction: Problem Statement [draft-ietf-csi-dhcpv6-cga-ps-01] (9 pages) - SEND Name Type field Registry [draft-ietf-csi-send-name-type-registry-01] (10 pages) No Requests for Comments DNS Extensions (dnsext) ----------------------- Charter Last Modified: 2010-01-11 Current Status: Active Chairs: Olafur Gudmundsson Andrew Sullivan Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion: namedroppers@ops.ietf.org To Subscribe: namedroppers-request@ops.ietf.org Archive: http://ops.ietf.org/lists/namedroppers/ Description of Working Group: The DNS has a large installed base and repertoire of protocol specifications. The DNSEXT WG group will actively advance DNS protocol-related RFCs on the standards track while thoroughly reviewing further proposed extensions. The scope of the DNSEXT WG is confined to the DNS protocol, particularly changes that affect DNS protocols "on the wire" or the internal processing of DNS data. DNS operations are out of scope for the WG. The WG will limit itself to review of proposals for new extensions and clarification to the DNS protocol, including DNSSEC. Adoption of new work targeted for standards track will require changes to this charter. The working group can nevertheless undertake work in following subjects without a charter change: DNSSEC and TSIG/TKEY algorithm maintenance Hardening DNS protocol and providing guidance to implementors Advancing existing Proposed Standard RFCs to Draft/Full Standard Obsoleting RFCs. Maintaining a Wiki containing a guide to DNS protocol RFC's. Improving DNS zone synchronization mechanisms Examining transport protocols, possibly adding new ones. Before formal adoption of any such items at least 5 working group participants must publicly state that the item is within charter and is worthwhile item for further study. The DNSEXT WG will conduct the specified RFC5395 review of RR templates as they are posted, and EDNS0 Option templates if EDNS0-bis updates registration requirements. The WG will review DNS protocol related work which may originate elsewhere in the IETF, including AD-sponsored submissions or drafts in other working group. The WG does not intend to hold face to face meetings, though may do so if deemed necessary for resolution of a specific issue at hand. Goals and Milestones: Done - Forward NSEC rdata to IESG for Proposed Standard Done - Forward RFC2535-bis to IESG for proposed standard Done - Forward Case Insensitive to IESG for Proposed Standard Done - Forward LLMNR to IESG for Proposed Standard Done - Update boilerplate text on OPT-IN Done - Forward Wildcard clarification to IESG for proposed standard Done - Finalize Zone Enumeration Requirements Done - RFC2538 (CERT RR) to Draft Standard Done - Forgery Resilience advanced to IESG Done - GOST DNSKEY and DS support advanced to IESG Jan 2010 - DNSKEY Registry fixes and allocation procedure advanced to IESG Jan 2010 - AXFR Clarify to IESG Feb 2010 - DNS existing transport protocol recommendations/clarifications to IESG Feb 2010 - RFC3597-bis Unknown RR advanced to IESG for PS Feb 2010 - TSIG/MD5 Obsoleting to IESG. Feb 2010 - DNSSEC Errata document to IESG Mar 2010 - EDNS0-bis update advanced to IESG Internet-Drafts: - Secret Key Transaction Authentication for DNS (TSIG) [draft-ietf-dnsind-tsig-13] (14 pages) - Extensions to DNS (EDNS1) [draft-ietf-dnsext-edns1-03] (4 pages) - A DNS RR for specifying the location of services (DNS SRV) [draft-ietf-dnsind-rfc2052bis-06] (10 pages) - A DNS RR Type for Lists of IP Address Prefixes (APL RR) [draft-ietf-dnsind-apl-rr-03] (6 pages) - Simple Secure Domain Name System (DNS) Dynamic Update [draft-ietf-dnsind-simple-secure-update-02] (8 pages) - Secret Key Establishment for DNS (TKEY RR) [draft-ietf-dnsind-tkey-03] (18 pages) - Domain Name System (DNS) IANA Considerations [draft-ietf-dnsind-iana-dns-04] (13 pages) - DNS Request and Transaction Signatures ( SIG(0)s ) [draft-ietf-dnsind-sig-zero-01] (10 pages) - DNS SIGALGOPT [draft-ietf-dnsind-sigalgopt-00] (3 pages) - A DNS RR for encoding DHCP information [draft-ietf-dnsind-dhcp-rr-00] (4 pages) - DNS Security Extension Clarification on Zone Status [draft-ietf-dnsind-zone-status-00] (9 pages) - Domain Name System Security (DNSSEC) Signing Authority [draft-ietf-dnsext-signing-auth-03] (7 pages) - Secure Domain Name System (DNS) Dynamic Update [draft-ietf-dnsext-simple-secure-update-03] (9 pages) - DNS Security Extension Clarification on Zone Status [draft-ietf-dnsext-zone-status-05] (9 pages) - Secret Key Establishment for DNS (TKEY RR) [draft-ietf-dnsext-tkey-05] (17 pages) - Domain Name System (DNS) IANA Considerations [draft-ietf-dnsext-iana-dns-02] (12 pages) - A Proposed Enhancement to the EDNS0 Version Mechanism [draft-ietf-dnsext-edns0dot5-02] (6 pages) - DNS Request and Transaction Signatures ( SIG(0)s ) [draft-ietf-dnsext-sig-zero-03] (9 pages) - A DNS RR Type for Lists of Address Prefixes (APL RR) [draft-ietf-dnsext-apl-rr-02] (7 pages) - Secret Key Transaction Authentication for DNS (TSIG) [draft-ietf-dnsext-tsig-01] (15 pages) - DNS Zone Transfer Protocol (AXFR) [draft-ietf-dnsext-axfr-clarify-13] (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-09] (12 pages) - Domain Name System (DNS) IANA Considerations [draft-ietf-dnsext-2929bis-08] (21 pages) - Derivation of DNS Name Predecessor and Successor [draft-ietf-dnsext-dns-name-p-s-02] (26 pages) - Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) [draft-ietf-dnsext-ds-sha256-06] (9 pages) - Requirements related to DNSSEC Trust Anchor Rollover [draft-ietf-dnsext-rollover-requirements-05] (11 pages) - Update to DNAME Redirection in the DNS [draft-ietf-dnsext-rfc2672bis-dname-18] (17 pages) - Measures for making DNS more resilient against forged answers [draft-ietf-dnsext-forgery-resilience-11] (26 pages) - The Modern DNS Implementation Guide [draft-ietf-dnsext-dns-protocol-profile-01] (26 pages) - Extension Mechanisms for DNS (EDNS0) [draft-ietf-dnsext-rfc2671bis-edns0-03] (11 pages) - Deprecation of HMAC-MD5 in DNS TSIG and TKEY Resource Records [draft-ietf-dnsext-tsig-md5-deprecated-04] (6 pages) - DNS Proxy Implementation Guidelines [draft-ietf-dnsext-dnsproxy-07] (14 pages) - DNS Security (DNSSEC) DNSKEY IANA Registry Algorithm Status Addition [draft-ietf-dnsext-dnssec-registry-fixes-01] (6 pages) - Cryptographic Algorithm Identifier Allocation for DNSSEC [draft-ietf-dnsext-dnssec-alg-allocation-02] (6 pages) - Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records for DNSSEC [draft-ietf-dnsext-dnssec-gost-06] (9 pages) - Handling of Unknown DNS Resource Record (RR) Types [draft-ietf-dnsext-rfc3597-bis-01] (7 pages) - DNS Transport over TCP [draft-ietf-dnsext-dns-tcp-requirements-02] (8 pages) - A mechanism for synchronization across name servers on zone creation [draft-ietf-dnsext-newzone-notify-02] (9 pages) Requests for Comments: RFC2782: A DNS RR for specifying the location of services (DNS SRV) (2 pages) * Obsoletes RFC2052 RFC2845: Secret Key Transaction Authentication for DNS (TSIG) (15 pages) * Updates RFC1035 * Updated by RFC3645 RFC2929: Domain Name System (DNS) IANA Considerations (12 pages) * OBSOLETED BY RFC5395 RFC2930: Secret Key Establishment for DNS (TKEY RR) (16 pages) RFC2931: DNS Request and Transaction Signatures ( SIG(0)s ) (10 pages) * Updates RFC2535 RFC3007: Secure Domain Name System (DNS) Dynamic Update (9 pages) * Updates RFC2137 * Obsoletes RFC2535 * Obsoletes RFC2136 * Updated by RFC4033 * Updated by RFC4034 * Updated by RFC4035 RFC3008: Domain Name System Security (DNSSEC) Signing Authority (7 pages) * Updates RFC2535 * Updated by RFC3658 * OBSOLETED BY RFC4033 * OBSOLETED BY RFC4034 * OBSOLETED BY RFC4035 RFC3090: DNS Security Extension Clarification on Zone Status (11 pages) * Updated by RFC3658 * OBSOLETED BY RFC4033 * OBSOLETED BY RFC4034 * OBSOLETED BY RFC4035 RFC3110: RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) (7 pages) RFC3123: A DNS RR Type for Lists of Address Prefixes (APL RR) (8 pages) RFC3225: Indicating Resolver Support of DNSSEC (6 pages) * Updated by RFC4033 * Updated by RFC4034 * Updated by RFC4035 RFC3226: DNSSEC and IPv6 A6 aware server/resolver message size requirements (6 pages) * Updates RFC2874 * Updates RFC2535 * Updated by RFC4033 * Updated by RFC4034 * Updated by RFC4035 RFC3363: Representing IPv6 addresses in DNS (6 pages) * Updates RFC2673 * Updates RFC2874 RFC3364: Tradeoffs in DNS support for IPv6 (11 pages) * Updates RFC2874 RFC3197: Applicability Statement for DNS MIB Extensions (5 pages) RFC3425: Obsoleting IQUERY (5 pages) * Updates RFC1035 RFC3445: Limiting the Scope of the KEY Resource Record out (10 pages) * Updates RFC2535 * OBSOLETED BY RFC4033 * OBSOLETED BY RFC4034 * OBSOLETED BY RFC4035 RFC3597: Handling of Unknown DNS Resource Record (RR) Types (8 pages) * Updated by RFC4033 * Updated by RFC4034 * Updated by RFC4035 * Updated by RFC5395 RFC3596: DNS Extensions to support IP version 6 (7 pages) RFC3645: GSS Algorithm for TSIG (GSS-TSIG) (22 pages) * Updates RFC2845 RFC3655: Redefinition of DNS AD bit (7 pages) * Obsoletes RFC2535 * OBSOLETED BY RFC4033 * OBSOLETED BY RFC4034 * OBSOLETED BY RFC4035 RFC3658: Delegation Signer Resource Record (19 pages) * Updates RFC3090 * Updates RFC3008 * Updates RFC2535 * Updates RFC1035 * Updated by RFC3755 * OBSOLETED BY RFC4033 * OBSOLETED BY RFC4034 * OBSOLETED BY RFC4035 RFC3755: Legacy Resolver Compatibility for Delegation Signer (5 pages) * Updates RFC3658 * Updates RFC2535 * Updated by RFC3757 * OBSOLETED BY RFC4033 * OBSOLETED BY RFC4034 * Updated by RFC3845 * OBSOLETED BY RFC4035 RFC3757: KEY RR Secure Entry Point Flag (10 pages) * Updates RFC3755 * Updates RFC2535 * OBSOLETED BY RFC4033 * OBSOLETED BY RFC4034 * OBSOLETED BY RFC4035 RFC3845: DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format (9 pages) * Updates RFC3755 * Updates RFC2535 * OBSOLETED BY RFC4035 * OBSOLETED BY RFC4034 * OBSOLETED BY RFC4033 RFC3833: Threat Analysis Of The Domain Name System (16 pages) RFC4033: DNS Security Introduction and Requirements (26 pages) * Updates RFC1034 * Updates RFC1035 * Updates RFC2136 * Updates RFC2181 * Updates RFC2308 * Updates RFC3225 * Updates RFC3007 * Updates RFC3597 * Updates RFC3226 * Obsoletes RFC2535 * Obsoletes RFC3008 * Obsoletes RFC3090 * Obsoletes RFC3445 * Obsoletes RFC3655 * Obsoletes RFC3658 * Obsoletes RFC3755 * Obsoletes RFC3757 * Obsoletes RFC3845 RFC4034: Resource Records for the DNS Security Extensions (33 pages) * Obsoletes RFC3845 * Obsoletes RFC2535 * Obsoletes RFC3008 * Obsoletes RFC3090 * Obsoletes RFC3445 * Obsoletes RFC3655 * Obsoletes RFC3658 * Obsoletes RFC3755 * Obsoletes RFC3757 * Updates RFC1034 * Updates RFC1035 * Updates RFC2136 * Updates RFC2181 * Updates RFC2308 * Updates RFC3225 * Updates RFC3007 * Updates RFC3597 * Updates RFC3226 * Updated by RFC4470 RFC4035: Protocol Modifications for the DNS Security Extensions (58 pages) * Obsoletes RFC3845 * Updates RFC1034 * Updates RFC1035 * Updates RFC2136 * Updates RFC2181 * Updates RFC2308 * Updates RFC3225 * Updates RFC3007 * Updates RFC3597 * Updates RFC3226 * Obsoletes RFC2535 * Obsoletes RFC3008 * Obsoletes RFC3090 * Obsoletes RFC3445 * Obsoletes RFC3655 * Obsoletes RFC3658 * Obsoletes RFC3755 * Obsoletes RFC3757 * Updated by RFC4470 RFC4343: Domain Name System (DNS) Case Insensitivity Clarification (13 pages) * Updates RFC1034 * Updates RFC1035 * Updates RFC2181 RFC4398: Storing Certificates in the Domain Name System (DNS) (17 pages) * Obsoletes RFC2538 RFC4470: Minimally Covering NSEC Records and DNSSEC On-line Signing (11 pages) * Updates RFC4035 * Updates RFC4034 RFC4509: Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) (9 pages) RFC4592: The Role of Wildcards in the Domain Name System (30 pages) * Updates RFC1034 * Updates RFC2672 RFC4471: Derivation of DNS Name Predecessor and Successor (26 pages) RFC4635: HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers (9 pages) RFC4701: A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR) (12 pages) * Updated by RFC5494 RFC4795: Link-local Multicast Name Resolution (LLMNR) (29 pages) RFC4955: DNS Security (DNSSEC) Experiments (15 pages) RFC4956: DNS Security (DNSSEC) Opt-In (16 pages) RFC5001: DNS Name Server Identifier Option (NSID) (16 pages) RFC4986: Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover (11 pages) RFC5011: Automated Updates of DNS Security (DNSSEC) Trust Anchors (13 pages) RFC5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence (52 pages) RFC5395: Domain Name System (DNS) IANA Considerations (17 pages) * Obsoletes RFC2929 * Updates RFC1183 * Updates RFC3597 RFC5452: Measures for Making DNS More Resilient against Forged Answers (18 pages) * Updates RFC2181 RFC5625: DNS Proxy Implementation Guidelines (12 pages) RFC5702: Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC (10 pages) Dynamic Host Configuration (dhc) -------------------------------- Charter Last Modified: 2009-04-16 Current Status: Active Chairs: Ted Lemon John Jason Brzozowski Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion: dhcwg@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/dhcwg Archive: http://www.ietf.org/mail-archive/web/dhcwg/current/maillist.html Description of Working Group: The dhc working group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCPv4 is currently a "Draft Standard" and is documented in RFC 2131 and RFC 2132. DHCPv6 is currently a "Proposed Standard" and is documented in RFC 3315. Subsequent RFCs document additional options and other enhancements to the specifications. The DHC WG is responsible for reviewing DHCP options or other extensions (for both IPv4 and IPv6). The DHC WG is expected to review all proposed extensions to DHCP to ensure that they are consistent with the DHCP specification and other option formats, that they do not duplicate existing mechanisms, etc. Generally speaking, the DHC WG will not be responsible for evaluating the semantic content of proposed options. Similarly, the ownership of specifications typically belongs the relevant working group that needs more functionality from DHCP, not the DHC WG. The DHC WG coordinates reviews of the proposed options together with those working groups. It is required that those working groups have consensus to take on the work and that the work is within their charter. Exceptionally, with AD agreement, this same process can also be used for Individual Submissions originating outside WGs. However, the DHC WG can in some cases develop its own options that relate to either maintenance of existing specifications or improvements in the operation of the DHCP infrastructure itself. The DHC WG has the following main objectives: * Develop extensions to the DHCP infrastructure as required to meet new applications and deployments of DHCP. The topics currently in development are: - Subnet allocation mechanisms - Virtual subnet identification option - Option for passing DNS domain information in DHCPv6 - DHCP relay agent assignment notification in DHCPv6 - Option for DHCPv6 server reply sequence numbers - Rebinding capability for DHCPv6 Reconfigure messages - Behavior of layer 2 relay agents The adoption of new items requires explicit agreement from the AD or rechartering. * Write analyses of the DHCPv4 and DHCPv6 specifications, including RFC 2131, RFC 2132, RFC 3315 and other RFCs defining additional options, which identifies ambiguities, contradictory specifications and other obstacles to development of interoperable implementations. Recommend a process for resolving identified problems and incorporating the resolutions into the DHCP specification. Secondly, advance DHCPv4 (RFC 2131 and RFC 2132) and DHCPv6 (RFC 3315) in IETF Standards Track. Thirdly, specify guidelines for creating new DHCP options, and report on the status of DHCPv4 option reclassification. * Assess the requirements for a dual-stack host to use DHCP to obtain configuration settings for both IPv4 and IPv6. Hosts that include implementations of both IPv4 and IPv6 ("dual-stack hosts") may use DHCP to obtain configuration settings (including assigned addresses) for both IPv4 and IPv6. The DHCPv4 and DHCPv6 specifications (RFC 2131, RFC 2132, RFC 3315 and subsequent RFCs) do not explicitly explain how a dual-stack host uses DHCP to obtain configuration settings for both IP stacks. The DHC WG will evaluate solutions for configuration of dual-stack hosts through DHCP and select a solution that will be developed and published by the WG. * Hold a discussion whether on-link prefix information and default router information is needed in DHCP in addition to router advertisements. Actual solutions are out of scope for the WG, however. Goals and Milestones: Done - WG Last Call on DHCP Options for Internet Storage Name Service (draft-ietf-dhc-isnsoption-03.txt) Done - WG Last Call on Load Balancing for DHCPv6 (draft-ietf-dhc-dhcpv6-loadb-02.txt) Done - WG Last Call on Time Configuration Options for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt) Done - WG Last Call on IPv6 Prefix Options for DHCPv6 (draft-troan-dhcpv6-opt-prefix-delegation-02.txt) Done - WG Last Call on DNS Configuration options for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-dnsconfig-01.txt) Done - WG Last Call on NIS Configuration Options for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt) Done - Resubmit draft-ietf-dhc-dhcpv6-28.txt to IESG Done - Identify DHCPv4 authentication design team Done - Identify DHCPv4 specification review design team Done - Identify DHCPv4 relay agent message authentication design team Done - Submit DHCP Options for Internet Storage Name Service to IESG (draft-ietf-dhc-isnsoption) Done - Submit DNS Configuration options for DHCPv6 to IESG (draft-ietf-dhc-dhcpv6-opt-dnsconfig) Done - Submit NIS Configuratio Options for DHCPv6 to IESG (draft-ietf-dhc-dhcpv6-opt-nisconfig) Done - Submit IPv6 Prefix Options for DHCPv6 to IESG (draft-troan-dhcpv6-opt-prefix-delegation) Done - Submit 'Detection of Network Attachment (DNA) in IPv4' to IESG (draft-ietf-dhc-dna-ipv4) Done - Resolve IPR issues around 'Rapid Commit Option for DHCPv4' Done - Publish report on dual-stack issues in DHCP (draft-ietf-dhc-dual-stack) Done - Publish report on requirements for renumbering using stateless DHCPv6 (draft-ietf-dhc-stateless-dhcpv6-renumbering) Done - Submit 'Lifetime Option for DHCPv6' to IESG (draft-ietf-dhc-lifetime) Done - Submit 'Rapid Commit Option for DHCPv4' to IESG (draft-ietf-dhc-rapid-commit-opt) Done - Submit DDNS/DHCP documents to IESG Done - Submit 'Node-Specific Client Identifiers for DHCPv4' to IESG (draft-ietf-dhc-3315id-for-v4) Done - WG last call for 'Subnet Allocation Option' Done - WG last call on 'Virtual Subnet Selection Option' Oct 2007 - Submit 'Subnet Allocation Option' (draft-ietf-dhc-subnet-alloc-04) to IESG for Proposed Standard Nov 2007 - WG last call on 'Guidelines for Creating New DHCP Options' (draft-ietf-dhc-option-guidelines) Nov 2007 - Submit 'Virtual Subnet Selection Option', (draft-ietf-dhc-vpn-option) and (draft-ietf-dhc-agent-vpn-id) to IESG for Proposed Standard Dec 2007 - WG last call for 'Domain Suffix Option for DHCPv6' (draft-ietf-dhc-dhcpv6-opt-dnsdomain) Jan 2008 - Submit 'Domain Suffix Option for DHCPv6' (draft-ietf-dhc-dhcpv6-opt-dnsdomain) to IESG for Proposed Standard Jan 2008 - Submit 'Guidelines for Creating New DHCP Options' (draft-ietf-dhc-option-guidelines) to IESG for Best Current Practice Jan 2008 - Develop plan for advancing DHCPv4 and DHCPv6 plan to include completion of DHCPv4 specification review report, 'Implementation Issues with RFC 2131' (draft-ietf-dhc-implementation) for Informational Feb 2008 - WG last call for 'Status of Reclassifying DHCPv4 Options' (draft-ietf-dhc-status-3942) Feb 2008 - WG last call for 'Dual-stack clients and merging of data from DHCPv4 and DHCPv6' (draft-ietf-dhc-dual-stack-merge); waiting for more experience with IPv6 deployment Feb 2008 - WG last call for 'Rebind Capability in DHCPv6 Reconfigure Messages' (draft-ietf-dhc-dhcpv6-reconfigure-rebind) Mar 2008 - Submit 'Status of Reclassifying DHCPv4 Options' (draft-ietf-dhc-status-3942) to IESG for Informational Apr 2008 - 2nd WG last call for 'DHCP Relay Agent Assignment Notification Option (draft-ietf-dhc-dhcpv6-agentopt-delegate) and 'DHCPv6 Server Reply Sequence Number Option' (draft-ietf-dhc-dhcpv6-srsn-option) May 2008 - Submit 'Rebind Capability in DHCPv6 Reconfigure Messages' (draft-ietf-dhc-dhcpv6-reconfigure-rebind) to IESG for Proposed Standard Jun 2008 - WG last call on 'Layer 2 Relay Agent Behaviour' (draft-ietf-dhc-layer2-relay-agent) Jul 2008 - Submit 'Layer 2 Relay Agent Behaviour' to IESG (draft-ietf-dhc-layer2-relay-agent) for Informational Jul 2008 - Submit 'DHCP Relay Agent Assignment Notification Option' (draft-ietf-dhc-dhcpv6-agentopt-delegate) and 'DHCPv6 Server Reply Sequence Number Option' (draft-ietf-dhc-dhcpv6-srsn-option) to IESG for Proposed Standard Jul 2008 - Recharter, if needed Internet-Drafts: - Dynamic Configuration of Internet Hosts [draft-ietf-dhc-problem-stmt-00] (0 pages) - Clarifications and Extensions for the Bootstrap Protocol [draft-ietf-dhc-bootp-02] (27 pages) - Dynamic Host Configuration Protocol [draft-ietf-dhc-protocol-07] (38 pages) - DHCP Options and BOOTP Vendor Extensions [draft-ietf-dhc-options-04] (27 pages) - Interoperation Between DHCP and BOOTP [draft-ietf-dhc-between-bootp-03] (4 pages) - Dynamic Host Configuration Protocol [draft-ietf-dhc-dhcp-09] (45 pages) - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-ietf-dhc-dhcpv6-28] (89 pages) - DHCP Options and BOOTP Vendor Extensions [draft-ietf-dhc-options-1533update-06] (38 pages) - Options for DHCPv6 [draft-ietf-dhc-v6opts-00] (15 pages) - Procedure for Defining New DHCP Options [draft-ietf-dhc-new-options-06] (6 pages) - Interaction between DHCP and DNS [draft-ietf-dhc-dhcp-dns-12] (19 pages) - Authentication for DHCP Messages [draft-ietf-dhc-authentication-16] (17 pages) - An Extension to the DHCP Option Codes [draft-ietf-dhc-options-opt127-03] (3 pages) - An option for FQDNs in DHCP options [draft-ietf-dhc-fqdn-opt-03] (4 pages) - Extensions for the Dynamic Host Configuration Protocol for IPv6 [draft-ietf-dhc-dhcpv6exts-12] (39 pages) - Graceful renumbering of networks with DHCP [draft-ietf-dhc-renumbering-00] (8 pages) - DHCP Options for Service Location Protocol [draft-ietf-dhc-slp-08] (5 pages) - The User Class Option for DHCP [draft-ietf-dhc-userclass-11] (5 pages) - DHCP Options for Novell Directory Services [draft-provan-dhcp-options-dir-serv-02] (3 pages) - DHCP Option for IEEE 1003.1 POSIX Timezone Specifications [draft-ietf-dhc-timezone-03] (3 pages) - An Inter-server Protocol for DHCP [draft-ietf-dhc-interserver-02] (89 pages) - DHCP Relay Agent Information Option [draft-ietf-dhc-agent-options-12] (15 pages) - Multicast Address Allocation Configuration Options [draft-ietf-dhc-multopt-03] (5 pages) - Multicast address allocation extensions to the Dynamic Host Configuration Protocol [draft-ietf-dhc-mdhcp-03] (14 pages) - Subnet Configuration Option Set for DHCP [draft-ietf-dhc-dyn-subnet-conf-02] (14 pages) - The Server Identification Option for DHCP [draft-ietf-dhc-sio-00] (6 pages) - The Server Selection Option for DHCP [draft-ietf-dhc-sso-03] (14 pages) - Security Architecture for DHCP [draft-ietf-dhc-security-arch-01] (14 pages) - An Inter-server Protocol for DHCP [draft-ietf-dhc-interserver-alt-00] (53 pages) - The Named Pool Request Option for DHCP [draft-ietf-dhc-namedpool-00] (4 pages) - Netware/IP Domain Name and Information [draft-ietf-dhc-netware-options-01] (6 pages) - Securing DHCP [draft-ietf-dhc-securing-dhc-00] (5 pages) - The Domain Search Option for DHCP [draft-ietf-dhc-domsrch-02] (4 pages) - Subnet Selection Option for DHCP [draft-ietf-dhc-subsel-00] (5 pages) - DHCP Failover Protocol [draft-ietf-dhc-failover-12] (133 pages) - DHCP Continuation Option Code [draft-ietf-dhc-options-cont-01] (3 pages) - The Autonomous System Option for DHCP [draft-ietf-dhc-asnum-00] (5 pages) - The Server Range Option for DHCP [draft-ietf-dhc-range-00] (2 pages) - DHCP Safe Failover Protocol [draft-ietf-dhc-safe-failover-proto-00] (29 pages) - Security Requirements for the DHCP protocol [draft-ietf-dhc-security-requirements-00] (12 pages) - Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Server MIB [draft-ietf-dhc-server-mib-10] (37 pages) - DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients [draft-ietf-dhc-autoconfig-05] (9 pages) - DHCP Option for User Authentication Protocol [draft-ietf-dhc-options-uap-03] (3 pages) - Automatically Choosing an IP Address in an Ad-Hoc IPv4 Network [draft-ietf-dhc-ipv4-autoconfig-05] (8 pages) - DHCP Use of the User Class Option for Address Assignment [draft-ietf-dhc-useraddr-00] (5 pages) - The Subnet Selection Option for DHCP [draft-ietf-dhc-subnet-option-08] (6 pages) - DHCP Options for Call Control Servers [draft-ietf-dhc-callcontrolserv-00] (4 pages) - The Name Service Search Option for DHCP [draft-ietf-dhc-nsso-06] (4 pages) - New Option Review Guidelines and Additional Option Namespace [draft-ietf-dhc-option-review-and-namespace-02] (14 pages) - DHCP Schema for LDAP [draft-ietf-dhc-schema-02] (23 pages) - Interpreting Client Options for the Dynamic Host Configuration Protocol [draft-ietf-dhc-client-options-00] (24 pages) - DHC load balancing algorithm [draft-ietf-dhc-loadb-03] (9 pages) - The Migration Agent List Option for DHCP [draft-ietf-dhc-migagntlist-00] (4 pages) - DHCP Next Server Option [draft-ietf-dhc-nextserver-02] (0 pages) - The Classless Static Route Option for DHCP [draft-ietf-dhc-csr-08] (0 pages) - DHCP reconfigure extension [draft-ietf-dhc-pv4-reconfigure-06] (6 pages) - Authentication, Authorization, and Accounting Requirements for Roaming Nodes using DHCP [draft-ietf-dhc-aaa-requirements-00] (8 pages) - Requirements for Extending DHCP into New Environments [draft-ietf-dhc-enhance-requirements-00] (15 pages) - DHCP Option for CableLabs Client Configuration [draft-ietf-dhc-packetcable-06] (12 pages) - Procedure for Defining New DHCP Options and Message Types [draft-ietf-dhc-new-opt-msg-03] (7 pages) - The DHCP Client FQDN Option [draft-ietf-dhc-fqdn-option-14] (17 pages) - Resolution of FQDN Conflicts among DHCP Clients [draft-ietf-dhc-ddns-resolution-13] (14 pages) - New Option Review Guidelines for DHCP [draft-ietf-dhc-new-opt-review-00] (8 pages) - The DOCSIS Device Class DHCP Relay Agent Information Sub-option [draft-ietf-dhc-agentoptions-device-class-04] (5 pages) - DHCP Lease Query [draft-ietf-dhc-leasequery-10] (27 pages) - Triggering AAA from DHCP Relay Agents [draft-ietf-dhc-aaa-ra-00] (7 pages) - Encoding Long Options in DHCPv4 [draft-ietf-dhc-concat-05] (0 pages) - Extensions to DHCP for Roaming Users [draft-ietf-dhc-dhcproam-00] (15 pages) - LDAP Schema for DHCP [draft-ietf-dhc-ldap-schema-00] (18 pages) - Link Selection sub-option for the Relay Agent Information Option for DHCPv4 [draft-ietf-dhc-agent-subnet-selection-04] (8 pages) - Virtual Subnet Selection Sub-Option for the Relay Agent Information Option for DHCPv4 [draft-ietf-dhc-agent-vpn-id-06] (11 pages) - Virtual Subnet Selection Options for DHCPv4 and DHCPv6 [draft-ietf-dhc-vpn-option-11] (20 pages) - Wireless Key Management using DHCP [draft-ietf-dhc-key-management-00] (0 pages) - DSTM Options for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-dstm-01] (7 pages) - DNS Configuration Options for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-dnsconfig-05] (8 pages) - RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option [draft-ietf-dhc-agentopt-radius-09] (9 pages) - Load Balancing for DHCPv6 [draft-ietf-dhc-dhcpv6-loadb-02] (6 pages) - DSTM Ports Option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-dstm-ports-01] (4 pages) - NIS Configuration Options for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-nisconfig-06] (6 pages) - Time Configuration Options for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-timeconfig-03] (8 pages) - Considerations for the use of the Host Name option [draft-ietf-dhc-host-option-considerations-02] (8 pages) - The IPv4 DHCP Options for the Internet Storage Name Service [draft-ietf-dhc-isnsoption-14] (14 pages) - Unused DHCP Option Codes [draft-ietf-dhc-unused-optioncodes-08] (11 pages) - Extending DHCP Options Codes [draft-ietf-dhc-extended-optioncodes-00] (9 pages) - Client Preferred Prefix option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-cliprefprefix-01] (6 pages) - The Authentication Suboption for the DHCP Relay Agent Option [draft-ietf-dhc-auth-suboption-06] (15 pages) - KDC Server Address Sub-option [draft-ietf-dhc-suboptions-kdc-serveraddress-05] (5 pages) - IPv6 Prefix Options for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-prefix-delegation-06] (20 pages) - DHCP Option for Mobile IP Mobility Agents [draft-ietf-dhc-mipadvert-opt-02] (15 pages) - DHCP Subscriber ID Suboption for the DHCP Relay Agent Option [draft-ietf-dhc-subscriber-id-08] (10 pages) - PacketCable Security Ticket Control Sub-option for the the DHCP CableLabs Client Configuration Option [draft-ietf-dhc-pktc-kerb-tckt-03] (7 pages) - DHCP Server Identifier Override Suboption [draft-ietf-dhc-server-override-06] (12 pages) - Results from Interoperability Tests of DHCPv6 Implementations [draft-ietf-dhc-dhcpv6-interop-01] (12 pages) - Subnet Allocation Option [draft-ietf-dhc-subnet-alloc-10] (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 server replies [draft-ietf-dhc-client-id-00] (4 pages) - DHCP Option for Proxy Server Configuration [draft-ietf-dhc-proxyserver-opt-05] (8 pages) - Configured Tunnel End Point Option for DHCPv6 [draft-ietf-dhc-dhcpv6-ctep-opt-02] (6 pages) - DHCPv6 Support for Remote Boot [draft-ietf-dhc-dhcpv6-opt-rboot-00] (6 pages) - The Extended Remote Boot Option for DHCPv4 [draft-ietf-dhc-opt-extrboot-00] (7 pages) - DHCP: IPv4 and IPv6 Dual-Stack Issues [draft-ietf-dhc-dual-stack-05] (14 pages) - Information Refresh Time Option for DHCPv6 [draft-ietf-dhc-lifetime-04] (8 pages) - Renumbering Requirements for Stateless DHCPv6 [draft-ietf-dhc-stateless-dhcpv6-renumbering-03] (8 pages) - Vendor-Specific Information Suboption for the DHCP Relay Agent Option [draft-ietf-dhc-vendor-suboption-01] (9 pages) - The DHCPv6 Client FQDN Option [draft-ietf-dhc-dhcpv6-fqdn-06] (15 pages) - Clarifications on DHCPv6 Authentication [draft-ietf-dhc-dhcpv6-clarify-auth-01] (14 pages) - DHCPv4 Options for Broadcast and Multicast Control Servers [draft-ietf-dhc-bcmcv4-option-00] (12 pages) - DHCPv6 Options for Broadcast and Multicast Control Servers [draft-ietf-dhc-bcmcv6-option-00] (14 pages) - Service-Oriented Address Assignment using DHCPv6 [draft-ietf-dhc-soa-option-00] (9 pages) - DHCPv6 Relay agent RADIUS Attribute Option [draft-ietf-dhc-v6-relay-radius-02] (12 pages) - DHCP Options for Broadcast and Multicast Control Servers [draft-ietf-dhc-bcmc-options-06] (15 pages) - DHCPv6 Relay Agent Subscriber-ID Option [draft-ietf-dhc-dhcpv6-subid-02] (8 pages) - DHCPv6 Relay Agent Remote ID Option [draft-ietf-dhc-dhcpv6-remoteid-02] (8 pages) - Dual-stack clients and merging of data from DHCPv4 and DHCPv6 [draft-ietf-dhc-dual-stack-merge-01] (8 pages) - DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents [draft-ietf-dhc-paa-option-06] (9 pages) - Domain Suffix Option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-dnsdomain-04] (7 pages) - DHCPv6 Relay Agent Assignment Notification (RAAN) Option [draft-ietf-dhc-dhcpv6-agentopt-delegate-05] (8 pages) - Time Protocol Servers and Time Offset Options for IPv6 DHCP [draft-ietf-dhc-dhcpv6-rfc868-servers-00] (6 pages) - A Timezone Option for DHCP [draft-ietf-dhc-timezone-option-06] (11 pages) - DHCPv4 Relay Agent Flags Suboption [draft-ietf-dhc-relay-agent-flags-04] (8 pages) - Dynamic Host Configuration Protocol Options Used by PXELINUX [draft-ietf-dhc-pxelinux-04] (14 pages) - Rebind Capability in DHCPv6 Reconfigure Messages [draft-ietf-dhc-dhcpv6-reconfigure-rebind-07] (6 pages) - DHCPv6 Leasequery [draft-ietf-dhc-dhcvp6-leasequery-01] (21 pages) - DHCPv6 Leasequery [draft-ietf-dhc-dhcpv6-leasequery-02] (23 pages) - DHCPv6 Relay Agent Echo Request Option [draft-ietf-dhc-dhcpv6-ero-02] (7 pages) - DHCPv6 Server Reply Sequence Number Option [draft-ietf-dhc-dhcpv6-srsn-option-02] (7 pages) - Guidelines for Creating New DHCP Options [draft-ietf-dhc-option-guidelines-06] (17 pages) - Container Option for Server Configuration [draft-ietf-dhc-container-opt-05] (10 pages) - DHCPv6 Bulk Leasequery [draft-ietf-dhc-dhcpv6-bulk-leasequery-07] (18 pages) - Layer 2 Relay Agent Information [draft-ietf-dhc-l2ra-05] (18 pages) - Extensions to Layer 2 Relay Agent [draft-ietf-dhc-l2ra-extensions-02] (22 pages) - The DHCPv4 Relay Agent Identifier Suboption [draft-ietf-dhc-relay-id-suboption-07] (7 pages) - DHCPv6 option for network boot [draft-ietf-dhc-dhcpv6-opt-netboot-08] (11 pages) - Dynamic Host Configuration Protocol DHCPINFORM Message Clarifications [draft-ietf-dhc-dhcpinform-clarify-04] (11 pages) - DHCPv4 Leasequery by relay agent remote ID [draft-ietf-dhc-leasequery-by-remote-id-04] (25 pages) - DHCPv6 Vendor-specific Message [draft-ietf-dhc-dhcpv6-vendor-message-01] (6 pages) - DHCPv4 Vendor-specific Message [draft-ietf-dhc-dhcpv4-vendor-message-01] (7 pages) - Bulk DHCPv4 Lease Query [draft-ietf-dhc-dhcpv4-bulk-leasequery-01] (38 pages) - Forcerenew Nonce Authentication [draft-ietf-dhc-forcerenew-nonce-01] (11 pages) - Lightweight DHCPv6 Relay Agent [draft-ietf-dhc-dhcpv6-ldra-01] (15 pages) Requests for Comments: RFC2131: Dynamic Host Configuration Protocol (34 pages) * Obsoletes RFC1541 * Obsoletes RFC1533 * Updated by RFC3396 * Updated by RFC4361 * Updated by RFC5494 RFC2132: DHCP Options and BOOTP Vendor Extensions (34 pages) * Obsoletes RFC1533 * Updated by RFC3442 * Updated by RFC3942 * Updated by RFC4361 * Updated by RFC4833 * Updated by RFC5494 RFC1542: Clarifications and Extensions for the Bootstrap Protocol (23 pages) * Obsoletes RFC1532 RFC1541: Dynamic Host Configuration Protocol (39 pages) * Obsoletes RFC1531 * OBSOLETED BY RFC2131 RFC1532: Clarifications and Extensions for the Bootstrap Protocol (22 pages) * Obsoletes RFC951 * OBSOLETED BY RFC1542 RFC1534: Interoperation Between DHCP and BOOTP (4 pages) RFC1533: DHCP Options and BOOTP Vendor Extensions (30 pages) * Obsoletes RFC1497 * OBSOLETED BY RFC2132 * OBSOLETED BY RFC2131 RFC1531: Dynamic Host Configuration Protocol (39 pages) * OBSOLETED BY RFC1541 RFC2241: DHCP Options for Novell Directory Services (5 pages) RFC2242: Netware/IP Domain Name and Information (6 pages) RFC2485: DHCP Option for The Open Group's User Authentication Protocol (4 pages) RFC2489: Procedure for Defining New DHCP Options (5 pages) * OBSOLETED BY RFC2939 RFC2610: DHCP Options for Service Location Protocol (6 pages) RFC2939: Procedure for Defining New DHCP Options and Message Types (7 pages) * Obsoletes RFC2489 RFC2937: The Name Service Search Option for DHCP (5 pages) RFC3004: The User Class Option for DHCP (6 pages) RFC3011: The Subnet Selection Option for DHCP (6 pages) RFC3046: DHCP Relay Agent Information Option (14 pages) RFC2563: DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients (9 pages) RFC3074: DHC load balancing algorithm (10 pages) RFC3118: Authentication for DHCP Messages (17 pages) RFC3203: DHCP reconfigure extension (6 pages) RFC3256: The DOCSIS Device Class DHCP Relay Agent Information Sub-option (5 pages) RFC3396: Encoding Long Options in DHCPv4 (9 pages) * Updates RFC2131 RFC3442: The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4 (9 pages) * Updates RFC2132 RFC3495: Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration (13 pages) RFC3527: Link Selection sub-option for the Relay Agent Information Option for DHCPv4 (9 pages) RFC3315: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (101 pages) * Updated by RFC4361 * Updated by RFC5494 RFC3594: PacketCable Security Ticket Control Sub-option for the the DHCP CableLabs Client Configuration (CCC)Option (7 pages) RFC3646: DNS Configuration Options for DHCPv6 (8 pages) RFC3633: IPv6 Prefix Options for DHCPv6 (20 pages) RFC3634: KDC Server Address Sub-option (5 pages) RFC3679: Unused DHCP Option Codes (8 pages) RFC3736: Stateless DHCP Service for IPv6 (10 pages) RFC3898: NIS Configuration Options for DHCPv6 (6 pages) RFC3925: Vendor-Identifying Vendor Options for DHCPv4 (10 pages) RFC3942: Reclassifying DHCPv4 Options (8 pages) * Updates RFC2132 RFC4014: RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option (9 pages) RFC3993: DHCP Subscriber ID Suboption for the DHCP Relay Agent Option (10 pages) RFC4030: The Authentication Suboption for the DHCP Relay Agent Option (15 pages) RFC4039: Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4) (12 pages) RFC4075: Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6 (5 pages) RFC4076: Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (8 pages) RFC4174: The IPv4 Dynamic Host Configuration Protocol (DHCP) Options for the Internet Storage Name Service (14 pages) RFC4242: Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (8 pages) RFC4280: Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers (15 pages) RFC4243: Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option (9 pages) RFC4361: Node-Specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4) (11 pages) * Updates RFC2131 * Updates RFC2132 * Updates RFC3315 * Updated by RFC5494 RFC4388: Dynamic Host Configuration Protocol (DHCP) Leasequery (27 pages) RFC4436: Detecting Network Attachment in IPv4 (DNAv4) (16 pages) RFC4477: Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues (14 pages) RFC4580: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option (8 pages) RFC4649: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option (8 pages) RFC4704: The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option (15 pages) RFC4703: Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients (14 pages) RFC4702: The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option (17 pages) RFC4578: Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE) (8 pages) RFC4833: A Timezone Option for DHCP (11 pages) * Updates RFC2132 RFC5010: The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption (8 pages) RFC5007: DHCPv6 Leasequery (23 pages) RFC4994: DHCPv6 Relay Agent Echo Request Option (7 pages) RFC5071: Dynamic Host Configuration Protocol Options Used by PXELINUX (14 pages) RFC5107: DHCP Server Identifier Override Suboption (12 pages) RFC5192: DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents (8 pages) RFC5460: DHCPv6 Bulk Leasequery (18 pages) Host Identity Protocol (hip) ---------------------------- Charter Last Modified: 2009-12-21 Current Status: Active Chairs: David Ward Gonzalo Camarillo Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion: hipsec@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/hipsec Archive: http://www.ietf.org/mail-archive/web/hipsec/current/maillist.html Description of Working Group: The Host Identity Protocol (HIP) provides a method of separating the end-point identifier and locator roles of IP addresses. It introduces a new Host Identity (HI) name space, based on public keys. The public keys are typically, but not necessarily, self generated. The specifications for the architecture and protocol details for these mechanisms consist of: HIP Architecture (RFC 4423) Host Identity Protocol (RFC 5201) There are several publicly known interoperating implementations, some of which are open source. Currently, the HIP base protocol works well with any pair of co-operating end-hosts. However, to be more useful and more widely deployable, HIP needs some support from the existing infrastructure, including the DNS, and a new piece of infrastructure, called the HIP rendezvous server. +-------------------------------------------------------+ | The purpose of this Working Group is to define the | | minimal infrastructure elements that are needed for | | HIP experimentation on a wide scale. | +-------------------------------------------------------+ At this point, the missing elements for running such wide-scale experiments are a NAT traversal solution, a description on the interactions between legacy (i.e., HIP unaware) applications and HIP, and a native API for HIP. Additionally, the working group will specify, also in Experimental RFCs, how to build HIP-based overlays. HIP-based overlays have received a lot of attention in different fora and are seen as a key area for HIP experimentation where the benefits HIP brings may be most relevant. Note that even though the specifications are chartered for Experimental, it is understood that their quality and security properties should match the standards track requirements. The main purpose for producing Experimental documents instead of standards track ones are the unknown effects that the mechanisms may have on applications and on the Internet at large. In parallel to this working group, there is an IRTF Research Group with a broader scope that includes efforts both on developing the more forward looking aspects of the HIP architecture and on exploring the effects that HIP may have on the applications and the Internet. The following are charter items for the working group: o Specify how legacy (i.e., HIP unaware) applications can be made to work with HIP. o Specify a solution for HIP to traverse legacy (i.e., HIP unaware) NATs. This solution will be based on existing NAT traversal mechanisms such as ICE (Interactive Connectivity Establishment). o Specify a native HIP socket API. o Specify a framework to build HIP-based overlays. This framework will describe how HIP can perform some of the tasks needed to build an overlay and how technologies developed somewhere else (e.g., a peer protocol developed in the P2PSIP WG) can complement HIP by performing the tasks HIP was not designed to perform. o Specify how to carry certificates in the base exchange. This was removed from the base HIP spec so that the mechanism is specified in a stand-alone spec. o Specify how to carry upper-layer data over specified HIP packets. These include some of the existing HIP packets and possibly new HIP packets (e.g., a HIP packet that occurs outside a HIP base exchange). o Specify a mechanism to implement multi-hop routing in HIP. Goals and Milestones: Done - First version of the HIP basic mobility and multi-homing mechanism specification. Done - First version of the HIP DNS resource record(s) specification. Done - First version of the HIP basic rendezvous mechanism specification. Done - WGLC on the HIP architecture specification Done - Submit the HIP architecture specification to the IESG Done - WG LC on the base protocol specification Done - WG LC on the ESP usage specification Done - WGLC the HIP registration extensions specification Done - WGLC the HIP DNS resource record(s) specification Done - WG LC on the basic HIP rendezvous mechanism specification. Done - Submit the ESP usage specification to the IESG for Experimental Done - Submit the base protocol specification to the IESG for Experimental Done - WG LC on the HIP basic mobility and multi-homing specification. Done - Submit the HIP registration extensions specification for Experimental Done - Submit the HIP DNS resource record(s) specification to the IESG for Experimental. Done - Submit the HIP basic mobility and multihoming specification to the IESG for Experimental. Done - Submit the basic HIP rendezvous mechanism specification to the IESG for Experimental. Done - WGLC Legacy Application Interworking specification Done - Submit the Legacy Application Interworking specification to the IESG Done - WGLC Legacy NAT traversal specification Done - WGLC Native API specification Done - Submit the Legacy NAT traversal specification to the IESG Done - Submit Native API specification to the IESG Feb 2010 - WGLC Framework for HIP overlays specification Feb 2010 - WGLC Multi-hop routing mechanism for HIP Feb 2010 - WGLC Certs in HIP base exchange specification Feb 2010 - WGLC Upper-layer data transport in HIP Apr 2010 - Submit Framework for HIP overlays specification to the IESG Apr 2010 - Submit Multi-hop routing mechanism for HIP Apr 2010 - Submit Certs in HIP base exchange specification to the IESG Apr 2010 - Submit Upper-layer data transport in HIP to the IESG Apr 2010 - 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-09] (33 pages) - Basic Socket Interface Extensions for Host Identity Protocol (HIP) [draft-ietf-hip-native-api-12] (19 pages) - HIP Certificates [draft-ietf-hip-cert-02] (10 pages) - HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment [draft-ietf-hip-bone-04] (20 pages) - HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper- layer Protocol Signaling (HICCUPS) [draft-ietf-hip-hiccups-01] (15 pages) - Host Identity Protocol (HIP) Multi-hop Routing Extension [draft-ietf-hip-via-00] (7 pages) - Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD) [draft-ietf-hip-reload-instance-00] (10 pages) Requests for Comments: RFC4423: Host Identity Protocol (HIP) Architecture (24 pages) RFC5201: Host Identity Protocol (108 pages) RFC5205: Host Identity Protocol (HIP) Domain Name System (DNS) Extensions (21 pages) RFC5203: Host Identity Protocol (HIP) Registration Extension (14 pages) RFC5202: Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) (37 pages) RFC5204: Host Identity Protocol (HIP) Rendezvous Extension (15 pages) RFC5206: End-Host Mobility and Multihoming with the Host Identity Protocol (48 pages) RFC5338: Using the Host Identity Protocol with Legacy Applications (14 pages) IP over DVB (ipdvb) ------------------- Charter Last Modified: 2009-05-26 Current Status: Active Chair: Gorry Fairhurst Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Secretary: Martin Stiemerling Mailing Lists: General Discussion: ipdvb@erg.abdn.ac.uk To Subscribe: majordomo@erg.abdn.ac.uk Archive: http://www.erg.abdn.ac.uk/ipdvb/archive/ Description of Working Group: The WG will develop new protocols and architectures to enable better deployment of IP over MPEG-2 transport and provide easier interworking with IP networks. Specific properties of this subnetwork technology include link-layer support for unicast and multicast, large numbers of down-stream receivers, and efficiency of transmission. These properties resemble those in some other wireless networks. The specific focus of the group is on the use of MPEG-2 transport (examples include the Digital Video Broadcast (DVB) standards: DVB-RCS; DVB-S and DVB-T and related ATSC Specifications) in next generation networks and is not concerned with the development, replacement, or retention of existing protocols on the existing generation of networks. The WG will endeavour to reuse existing open standard technologies, giving guidance on usage in IP networks, whenever they are able to fulfill requirements. For instance, we acknowledge the existing Multiprotocol Encapsulation (MPE) [ATSC A/90;ETSI EN 301192] and that this will continue to be deployed in the future to develop new markets. Any alternative encapsulation would need to co-exist with MPE. Appropriate standards will be defined to support transmission of IPv4 and IPv6 datagrams between IP networks connected using MPEG-2 transport subnetworks. This includes options for encapsulation, dynamic unicast address resolution for IPv4/IPv6, and the mechanisms needed to map routed IP multicast traffic to the MPEG-2 transport subnetwork. The standards will be appropriate to both MPE and any alternative encapsulation method developed. The developed protocols may also be applicable to other multicast enabled subnetwork technologies supporting large numbers of directly connected systems. The current list of work items is: Specify the requirements and architecture for supporting IPv4/IPv6 via MPEG-2 transmission networks. Such requirements should consider the range of platforms currently (or anticipated to be) in use. This draft will be an Informational RFC. Define a standards-track RFC defining an efficient encapsulation method. The design will consider the need for MAC addresses, the potential need for synchronisation between streams, support for a wide range of IPv4/IPv6 and multicast traffic. Provide an Informational RFC describing a framework for unicast and multicast address resolution over MPEG-2 transmission networks. The document will describe options for the address resolution process, relating these to appropriate usage scenarios and suggesting appropriate protocol mechanisms for both the existing Multi-Protocol Encapsulation (MPE) and the efficient encapsulation (2). Consideration will be paid to existing standards, and the cases for IPv6 and IPv4 will be described. Define standards-track RFC(s) to specify procedures for dynamic address resolution for IPv4/IPv6. This will describe the protocol and syntax of the information exchanged to bind unicast and multicast flows to the MPEG-2 TS Logical Channels. This will include specific optimisations appropriate for networks reaching large numbers of down-stream systems. Goals and Milestones: Done - Draft of a WG Architecture ID describing usage of MPEG-2 transport for IP transmission. Done - Draft of a WG ID on the new Encapsulation. Done - Submit Architecture to IESG Done - Draft of a WG ID on the AR Framework, specifying mechanisms to perform address resolution. Done - Submit Encapsulation to IESG Done - Draft of a WG ID defining Security Requirements for the ULE protocol Done - Submit AR Framework to IESG Apr 2006 - Draft of a WG ID defining an IP Address Resolution (AR) protocol Jan 2007 - Submit AR Protocol to IESG Done - Submit Extension Header Formats to IESG for publication as PS Done - Submit ULE Security Requirements to IESG Dec 2007 - Progress the Encapsulation RFC along the IETF standards track Internet-Drafts: - Unidirectional Lightweight Encapsulation (ULE) for transmission of IP datagrams over an MPEG-2 Transport Stream [draft-ietf-ipdvb-ule-07] (49 pages) - A Framework for transmission of IP datagrams over MPEG-2 Networks [draft-ietf-ipdvb-arch-05] (39 pages) - Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks [draft-ietf-ipdvb-ar-07] (0 pages) - Security requirements for the Unidirectional Lightweight Encapsulation (ULE) protocol [draft-ietf-ipdvb-sec-req-10] (30 pages) - Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE) [draft-ietf-ipdvb-ule-ext-08] (19 pages) Requests for Comments: RFC4259: A Framework for transmission of IP datagrams over MPEG-2 Networks (39 pages) RFC4326: Unidirectional Lightweight Encapsulation (ULE) for transmission of IP datagrams over an MPEG-2 Transport Stream (49 pages) RFC4947: Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks (0 pages) RFC5163: Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE) (19 pages) RFC5458: Security Requirements for the Unidirectional Lightweight Encapsulation (ULE) Protocol (26 pages) IP over IEEE 802.16 Networks (16ng) ----------------------------------- Charter Last Modified: 2009-10-05 Current Status: Active Chairs: Gabriel Montenegro Soohong Daniel Park Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Tech Advisors: Maximilian Riegel Dave Thaler Secretary: Jihoon Lee Mailing Lists: General Discussion: 16ng@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/16ng Archive: http://www.ietf.org/mail-archive/web/16ng Description of Working Group: Broadband Wireless Access Networks address the inadequacies of low bandwidth wireless communication for user requirements such as high quality data/voice service, wide coverage, etc. The IEEE 802.16 Working Group on Broadband Wireless Access Standards develops standards and recommended practices to support the development and deployment of Broadband Wireless Metropolitan Area Networks. A particularity of IEEE 802.16 is that it does not include a rigid upper edge MAC service interface. Instead, it provides multiple "convergence sublayers (CS)" with the assumption that the choice and configuration of the upper edge will be done in accordance with the needs of a specific deployment environment (which might be DSL replacement, mobile access, 802.11 or CDMA backhaul etc.). Specifically, immediately subsequent to network entry, an 802.16 subscriber station has no capability whatsoever for data (as opposed to management) connectivity. Especially, in IP CS case, the criteria by which the Base Station (or other headend elements) sets up the 802.16 MAC connections for data transport are not part of the 802.16 standard, and depend on the type of data services being offered (e.g., the set up of link layer connections will be different for IPv4 and IPv6 services). Additionally - as IEEE 802.16 is a point-to-multipoint network - an 802.16 subscriber station is not capable of multicasting (e.g., for neighbor discovery, ARP, IP multicasting services, etc.) or direct communication to the other nodes attached to the same Base Station within the same subnet (prefix). Unlike 3G or xDSL technologies, IEEE 802.16 is not part of an end-to- end system definition. Currently, the WiMAX Forum, and, in particular, its NWG (Network Working Group) is defining a network architecture based on IEEE 802.16. The principal objective of the 16ng working group is to specify the operation of IPv4 and IPv6 over IEEE 802.16, taking into account the IPv4, IPv6 and Ethernet Convergence Sublayers. The working group may issue recommendations to IEEE 802.16 and WiMax aiming at improving support for IP. The scope of this working group is as follows (WG Deliverables); - Produce "16ng Problem Statement, Goal and Requirement" to identify the specific gaps in the 802.16 MAC for IPv4/IPv6 support, describe possible network models (ie. point-to-point, broadcast etc.), and provide 16ng related terminology to be used for the base guideline while defining solution frameworks. [Informational RFC] - Produce "IPv6 over IEEE 802.16 Networks in conjunction with IPv6 CS" to define IPv6 operation including the transmission of IPv6 over IEEE 802.16 link, Neighbor Discovery Protocol, Stateful (DHCPv6) and Stateless Address Configuration, Broadcast, Multicast, etc. [Proposed Standard RFC] - Produce "IPv6 over IEEE 802.16 Networks in conjunction with Ethernet CS" to define IPv6 operation including the transmission of IPv6 over IEEE 802.16 link, Neighbor Discovery Protocol, Stateful (DHCPv6) and Stateless Address Configuration, Broadcast, Multicast, etc. [Proposed Standard RFC] - Produce "IPv4 over IEEE 802.16 Networks in conjunction with IPv4 CS" to define IPv4 operation including the transmission of IPv4 over IEEE 802.16 links, ARP operation, Stateful Address Configuration (DHCPv4), Broadcast, Multicast, etc [Proposed Standard RFC] - Produce "IPv4 over IEEE 802.16 Networks in conjunction with Ethernet CS" to define IPv4 operation including the transmission of IPv4 over IEEE 802.16 links, ARP operation, Stateful Address Configuration (DHCPv4), Broadcast, Multicast, etc [Proposed Standard RFC] - Produce "IP deployment over IEEE 802.16 Networks" to illustrate the IP deployment scenarios including IP CS and Ethernet CS considerations over IEEE 802.16 networks based on the WiMAX and WiBro. [Informational RFC] This working group will take dual stack operation into account in its specifications, and reuse existing specifications whenever reasonable and possible. The ability to negotiate the used Convergence Sublayer is required, as no single mandatory CS can be specified for the clients. Work based on the Ethernet CS needs to take into account interoperability with existing hosts and other devices that employ Ethernet, to allow bridging. 16ng will not initially consider other work items than the ones listed above; however, other related work may occur in other WGs, and 16ng will participate and help such efforts. Goals and Milestones: Done - Working Group Last Call on 16ng problem statement, goal and requirement Done - Working Group Last Call on IPv6 over IPv6 CS transmission over IEEE 802.16 networks Done - Working Group Last Call on IPv6 subnet model analysis Done - Submit IPv6 over IPv6 CS transmission over IEEE 802.16 networks to IESG for publication as Proposed Standard RFC Done - Submit IPv6 subnet model analysis to IESG for publication as Informational RFC Done - Submit 16ng problem statement, goal and requirement to IESG for publication as Informational RFC Done - Working Group Last Call on IP over Ethernet CS transmission over IEEE 802.16 networks Done - Review on draft-ietf-mipshop-fh80216e to be ready to IESG in conjunction with MIPSHOP WG Done - Working Group Last Call on IPv4 over IPv4 CS transmission over IEEE 802.16 networks Done - Submit IPv4 over IPv4 CS transmission over IEEE 802.16 networks to IESG for publication as Proposed Standard RFC Done - Re-submit IP over Ethernet CS transmission over IEEE 802.16 networks to IESG for publication as Proposed Standard RFC (initial IESG submission was: 24-Jun-08) Internet-Drafts: - Analysis of IPv6 Link Models for 802.16 based Networks [draft-ietf-16ng-ipv6-link-model-analysis-04] (17 pages) - IP over 802.16 Problem Statement and Goals [draft-ietf-16ng-ps-goals-05] (14 pages) - Transmission of IPv6 via the IPv6 CS over IEEE 802.16 Networks [draft-ietf-16ng-ipv6-over-ipv6cs-12] (22 pages) - Transmission of IP over Ethernet over IEEE 802.16 Networks [draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-13] (20 pages) - Transmission of IPv4 packets over IEEE 802.16's IP Convergence Sublayer [draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-06] (14 pages) Requests for Comments: RFC4968: Analysis of IPv6 Link Models for 802.16 Based Networks (17 pages) RFC5121: Transmission of IPv6 via the IPv6 CS over IEEE 802.16 Networks (22 pages) RFC5154: IP over IEEE 802.16 Problem Statement and Goals (14 pages) RFC5692: Transmission of IP over Ethernet over IEEE 802.16 Networks (21 pages) IPv6 Maintenance (6man) ----------------------- Charter Last Modified: 2008-12-16 Current Status: Active Chairs: Robert Hinden Brian Haberman Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: ipv6@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipv6 Archive: http://www.ietf.org/mail-archive/web/ipv6 Description of Working Group: The 6man working group is responsible for the maintenance, upkeep, and advancement of the IPv6 protocol specifications and addressing architecture. It is not chartered to develop major changes or additions to the IPv6 specifications. The working group will address protocol limitations/issues discovered during deployment and operation. It will also serve as a venue for discussing the proper location for working on IPv6-related issues within the IETF. The working group's work items are as follows: o Complete work on RA Flags Option o Complete work on RH0 Deprecation o Complete work on IPv6 over PPP Compression Negotiation o Complete work on Centrally Allocated Unique Local Addresses (ULA-C) All new work items not listed above require the approval of the working group and the sponsoring Area Director before they will be taken on by the working group. Goals and Milestones: Done - Submit RH0 Deprecation specification to IESG as a Proposed Standard Jan 2008 - Submit PPP Compression Negotiation specification to IESG as a Proposed Standard Mar 2008 - Determine way forward for ULA-C specification Internet-Drafts: - Centrally Assigned Unique Local IPv6 Unicast Addresses [draft-ietf-ipv6-ula-central-02] (11 pages) - Negotiation for IPv6 datagram compression using IPv6 Control Protocol [draft-ietf-ipv6-compression-nego-v2-03] (8 pages) - IPv6 Node Requirements RFC 4294-bis [draft-ietf-6man-node-req-bis-04] (21 pages) - Reserved IPv6 Interface Identifiers [draft-ietf-6man-reserved-iids-04] (12 pages) - Solution approaches for address-selection problems [draft-ietf-6man-addr-select-sol-03] (20 pages) - IPv6 Subnet Model: the Relationship between Links and Subnet Prefixes [draft-ietf-6man-ipv6-subnet-model-07] (13 pages) - Handling of overlapping IPv6 fragments [draft-ietf-6man-overlap-fragment-03] (7 pages) - A Recommendation for IPv6 Address Text Representation [draft-ietf-6man-text-addr-representation-04] (14 pages) - IANA Allocation Guidelines for the IPv6 Routing Header [draft-ietf-6man-iana-routing-header-00] (3 pages) - Considerations for IPv6 Address Selection Policy Changes [draft-ietf-6man-addr-select-considerations-00] (18 pages) Requests for Comments: RFC5172: Negotiation for IPv6 datagram compression using IPv6 Control Protocol (8 pages) * Obsoletes RFC2472 RFC5453: Reserved IPv6 Interface Identifiers (12 pages) IPv6 over Low power WPAN (6lowpan) ---------------------------------- Charter Last Modified: 2009-04-13 Current Status: Active Chairs: Carsten Bormann Geoffrey Mulligan Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion: 6lowpan@lists.ietf.org To Subscribe: 6lowpan-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/6lowpan/current/maillist.html Description of Working Group: Background/Introduction: Well-established fields such as control networks, and burgeoning ones such as "sensor" (or transducer) networks, are increasingly being based on wireless technologies. Most (but certainly not all) of these nodes are amongst the most constrained that have ever been networked wirelessly. Extreme low power (such that they will run potentially for years on batteries) and extreme low cost (total device cost in single digit dollars, and riding Moore's law to continuously reduce that price point) are seen as essential enablers towards their deployment in networks with the following characteristics: * Significantly more devices than current local area networks * Severely limited code and ram space (e.g., highly desirable to fit the required code--MAC, IP and anything else needed to execute the embedded application--in, for example, 32K of flash memory, using 8-bit microprocessors) * Unobtrusive but very different user interface for configuration (e.g., using gestures or interactions involving the physical world) A chief component of these devices is wireless communication technology. In particular, the IEEE 802.15.4 standard is very promising for the lower (physical and link) layers. As for higher layer functions, there is considerable interest from non-IETF groups in using IP technology. The IEEE 1451.5 standard for wireless transducers has a chapter for 6LoWPAN and the ISA SP100 standard for wireless industrial networks has adopted 6LoWPAN for their network layer. This working group is expected to coordinate and interact with such groups. Description of Working Group: ----------------------------- The Working Group has completed two RFCs: "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" (RFC4919) that documents and discusses the problem space and "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" (RFC4944) which defines the format for the adaptation between IPv6 and 802.15.4. The Working Group will generate the necessary documents to ensure interoperable implementations of 6LoWPAN networks and will define the necessary security and management protocols and constructs for building 6LoWPAN networks, paying particular attention to protocols already available. 6lowpan will work closely with the Routing Over Low power and Lossy networks (roll) working group which is developing IPv6 routing solutions for low power and lossy networks (LLNs). Work Items: ----------- 1. Produce "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations" to define limited extensions to IPv6 Neighbor Discovery [RFC4861] for use specifically in low-power networks. This document (or documents) will define how to bootstrap a 6LoWPAN network and explore ND optimizations such as reusing the structure of the 802.15.4 network (e.g., by using the coordinators), and reduce the need for multicast by having devices talk to coordinators (without creating a single point-of-failure, or changing the semantics of the IPv6 ND multicasts). This document or documents will be a proposed standard. 2. Produce "6LoWPAN Improved Header Compression" to describe mechanisms to allow enhancements to the 6LoWPAN headers. Specifically this document will describe compression of addresses that are not link-local. Additionally this document may include other enhancements or optimizations of the HC1 or HC2 6LoWPAN headers. This document will be a proposed standard. 3. Produce "6LoWPAN Architecture" to describe the design and implementation of 6LoWPAN networks. This document will cover the concepts of "Mesh Under" and "Route Over", 802.15.4 design issues such as operation with sleeping nodes, network components (both battery- and line-powered), addressing, and IPv4/IPv6 network connections. This document will be informational. 4. As a separate Internet Draft, "6LoWPAN Routing Requirements" will describe 6LoWPAN-specific requirements on routing protocols used in 6LoWPANs, addressing both the "route-over" and "mesh-under" approach. This document will be created and owned by this working group but is expected to be reviewed by the ROLL WG. This document will be informational. 5. Produce "Use Cases for 6LoWPAN" to define, for a small set of applications with sufficiently unique requirements, how 6LoWPANs can solve those requirements, and which protocols and configuration variants can be used for these scenarios. The use cases will cover protocols for transport, application layer, discovery, configuration and commissioning. This document will be informational. 6. Produce "6LoWPAN Security Analysis" to define the threat model of 6LoWPANs, to document suitability of existing key management schemes and to discuss bootstrapping/installation/commissioning/setup issues. This document will be referenced from the "security considerations" of the other 6LoWPAN documents. This document will be informational. The working group will continue to reuse existing protocols and mechanisms whenever reasonable and possible. Non-milestone work items: ------------------------- The Working Group will keep two running, often-respun documents: -- implementers guide, collecting clarifying information based on input from implementers, in particular as it becomes available from interoperability events. -- interoperability guide, providing information for interoperability events, such as temporary interoperability testing strategies or information about test harnesses used for interoperability testing. Both documents will be WG documents, but their disposition is not decided at this point (one example for such a document became RFC 4815 after five years of maintenance and 22 revisions). Goals and Milestones: Done - Working group last call on draft-ietf-lowpan-goals-assumptions-xx.txt Done - Submit draft-ietf-lowpan-goals-assumptions-xx.txt to IESG for consideration of publication as Informational Done - Working Group Last Call on draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt Done - Submit draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt to IESG for consideration of publication as Proposed Standard Aug 2008 - Submit Improved Header Compression document to IESG for consideration as a proposed standard Aug 2008 - Submit Security Analysis document to IESG for consideration as an Informational RFC Sep 2008 - Submit Architecture document to IESG for consideration as an Informational RFC Sep 2008 - Submit Routing Requirements document to IESG for consideration as an Informational RFC Nov 2008 - Submit Bootstrapping and ND Optimizations document to IESG to be considered as a Proposed Standard Dec 2008 - Submit Use Case document to IESG as an Informational RFC Internet-Drafts: - Transmission of IPv6 Packets over IEEE 802.15.4 Networks [draft-ietf-6lowpan-format-14] (31 pages) - 6LoWPAN: Overview, Assumptions, Problem Statement and Goals [draft-ietf-6lowpan-problem-09] (13 pages) - Compression Format for IPv6 Datagrams in 6LoWPAN Networks [draft-ietf-6lowpan-hc-06] (20 pages) - Design and Application Spaces for 6LoWPANs [draft-ietf-6lowpan-usecases-05] (30 pages) - 6LoWPAN Neighbor Discovery [draft-ietf-6lowpan-nd-08] (46 pages) - Problem Statement and Requirements for 6LoWPAN Routing [draft-ietf-6lowpan-routing-requirements-05] (32 pages) Requests for Comments: RFC4919: IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals (13 pages) RFC4944: Transmission of IPv6 Packets over IEEE 802.15.4 Networks (31 pages) Layer 2 Virtual Private Networks (l2vpn) ---------------------------------------- Charter Last Modified: 2009-10-19 Current Status: Active Chairs: Shane Amante Giles Heron Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Tech Advisor: Alex Zinin Mailing Lists: General Discussion: l2vpn@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/l2vpn Archive: http://www.ietf.org/mail-archive/web/l2vpn/current/maillist.html Description of Working Group: The L2VPN working group is responsible for defining and specifying a limited number of solutions for supporting provider-provisioned Layer-2 Virtual Private Networks (L2VPNs). Layer-2 VPN's comprise the following: 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that emulates an Ethernet (V)LAN across an IP or an MPLS-enabled IP Packet Switched Network (PSN). 2. Virtual Private Wire Service (VPWS) -- A Layer 2 service that provides point-to-point connectivity for a variety of link layers, including Frame Relay, ATM, Ethernet, PPP, etc., across an IP or MPLS-enabled IP PSN. 3. Virtual Private Multicast Service (VPMS) -- A Layer 2 service that Provides point-to-multipoint connectivity for a variety of link layers, including Frame Relay, ATM, Ethernet, PPP, etc., across an IP or MPLS-enabled IP PSN. 4. IP-only L2VPN -- A point-to-point or point-to-multipoint "IP-only" service over an IP or MPLS-enabled PSN. This service is similar to VPWS because it supports a variety of link-layer protocols on the Attachment Circuits, including Frame Relay, ATM, Ethernet, PPP, etc. IP-only L2VPN's are different from both VPLS and VPWS because unicast Layer-2 frames containing IP data packets, either IPv4 or IPv6, are de- encapsulated leaving only the IP data packet to be transmitted over the PSN. An IP-only L2VPN service also differs from L3VPN service, since no routing protocol operates between the PE and CE; furthermore, connectivity from CE to CE is provided via an emulated Layer-2 service over the PSN, which results in the CE's appearing to be directly attached to each other at Layer-2. The WG will address two specific types of IP-only L2VPN: a) Those with Attachment Circuits (ACs) that use the same Layer 2 framing at all attachment points in the same L2VPN; and, b) Those with ACs that use different Layer 2 framing at various attachment points in the same L2VPN. For (b), inter-working between link-layers is strictly out of scope beyond that which is minimally necessary to ensure that IP packets are transported from an AC of one type, across the IP or MPLS-enabled IP PSN, and to an AC of another type in as transparent a manner as possible to the CEs on both sides of the service. VPLS, VPWS and VPMS operate over Pseudowires (PWs) as defined by the PWE3 WG. As with a single PW, an L2VPN emulates a "native" service over a PSN that is reasonably faithful to, but may not be entirely indistinguishable from, the native service itself. Further, following in the "edge-to-edge" nature of the PWs that it uses, the L2VPN WG will not define any new mechanisms which exert control over the underlying PSN. When necessary it may, however, recommend or require the use of existing PSN QoS and path control mechanisms between PW endpoints which make up the L2VPN. L2VPN's will make use of existing IETF specified mechanisms unless there are technical reasons why the existing mechanisms are insufficient or unnecessary. The L2VPN WG is responsible for specification of the discovery and membership of PE's participating in a VPLS, VPWS or IP-only L2VPN as well as the membership of CE devices to a specific instance of a L2VPN. The L2VPN WG will provide extensions of existing protocols that will be discussed in protocol-specific WG's. In particular, the L2VPN WG may define extensions to pseudowire management mechanisms (including OAM), specifically Pseudowire Virtual Circuit Connectivity Verification (VCCV), for VPLS. Those VCCV extensions will be reviewed by PWE3 to ensure they are inline with the overall design/architecture of VCCV and MPLS. The L2VPN WG will not define new encapsulations, control (set-up, configuration, maintenance or tear-down), or resiliency mechanisms specifically related to pseudowires, because those must be defined by the PWE3 WG. Furthermore, the L2VPN WG will not define protocol inter- working between a VPLS or VPWS and native service-layer control, OAM or or resiliency mechanisms, as those will be defined by the PWE3 WG. On the other hand, the L2VPN WG may define how to operate native service- layer control, IEEE 802.1 OAM or resiliency mechanisms on top of a VPLS or VPWS service. The L2VPN WG scope includes the following: 1. Discovery of PE's participating in a Layer-2 VPN and the associated topology required for connectivity of the VPLS or VPWS service. 2. Signaling of information related to the discovery and membership of PE's within a L2VPN. These procedures must use PWE3 control and management procedures, or define requirements for extensions of PWE3 protocols to suit the needs of an L2VPN. Once those requirements are reviewed by the L2VPN WG, they should be provided to the PWE3 WG to derive solutions. 3. MIB's for Layer-2 VPN solutions. 4. Specification of requirements and framework that will define Operations Administration and Management (OAM) procedures for VPLS and VPWS VPN's, related to the operation of VPLS and VPWS VPN's over IP/MPLS PSN's. In addition, the L2VPN WG will define OAM solutions for VPLS and VPWS VPN's. 5. Mechanisms to permit optimization of multicast data traffic within a VPLS or VPWS VPN over an IP/MPLS PSN. 6. Improved service convergence for multi-homed CE's to VPLS PE's. Specifically, upon failure of a primary path from a CE to VPLS PE, initiate a rapid switch-over to an alternate path. If required, interactions with native service-layer resiliency mechanisms will be provided via solutions from other IETF WG's such as PWE3. 7. Enhancements to increase the scalability of the Control Plane and Data Plane (e.g.: number of PW's and MAC Forwarding Database, respectively) of VPLS PE nodes. 8. Define requirements and solutions for Auto-Discovery and Signaling of Inter-AS VPLS and VPWS L2VPN's, in addition to Inter-AS solutions for multicast-optimized VPLS and VPMS Layer-2 VPN's. The L2VPN WG currently works on the following tasks: - Define MIB's appropriate for each type of Layer-2 VPN. - Specification of Operations Administration and Management (OAM) mechanisms for VPLS, VPWS and IP-only VPN's. - Specification of procedures to permit optimization of L2VPN multicast data traffic within the PSN. - Define enhancements to increase scalability of VPLS PE nodes, to provide aggregation of learned customer MAC addresses at VPLS PE's. - Identify requirements for multi-homing of CE's to VPLS PE's. elements. Based on these requirements, define solutions for achieving fast convergence after a switchover to an alternate path, for example through optimized MAC flushing within a VPLS domain. - Identify requirements for Inter-AS VPLS and VPWS services. Define Inter-AS enhancements to VPLS and VPWS based on these requirements. - Include extensions to L2VPN protocols and RFC's necessary to create an MPLS Transport Profile (MPLS-TP). The work on the MPLS TP needs to be coordinated between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) that are chartered to do MPLS TP work. Where necessary, the WG will coordinate its activities with IEEE 802.1 and ITU. Goals and Milestones: Done - Submit an I-D describing MIB for VPLS Done - Submit an I-D describing MIB for VPWS Done - Submit an I-D on OAM requirements for VPLS Done - Submit an I-D on OAM requirements for VPWS Done - Submit L2 requirements to IESG for publication as Informational RFC Done - Submit L2 framework to IESG for publication as Informational RFC Done - Identify VPLS and VPWS solutions for the WG Done - Submit VPLS solution documents to IESG Done - Submit VPWS solution documents to IESG Done - Submit Auto-Discovery and Signaling for Intra-AS and Inter-AS VPLS and VPWS Layer-2 VPN's Nov 2008 - Submit IP-only L2VPN solution documents to IESG Mar 2009 - Submit OAM solutions for VPWS to IESG Mar 2009 - Submit OAM solutions for VPLS to IESG Mar 2009 - Submit signaling solution for multicast-optimized VPLS to IESG Mar 2009 - Submit I-D on Virtual Private Multicast Service (VPMS) requirements to IESG Mar 2009 - Submit PIM snooping solution for VPLS to IESG Mar 2009 - Submit OAM solutions for IP-only L2VPN to IESG Jul 2009 - Submit MIB for VPLS to IESG Jul 2009 - Submit MIB for VPWS to IESG Jul 2009 - Submit MIB for IP-only L2VPN to IESG Nov 2009 - Submit scalability solutions for VPLS Data-Plane to IESG Nov 2009 - Submit scalability solutions for VPLS Control-Plane to IESG Nov 2009 - Submit Auto-Discovery solution for VPMS to IESG Jul 2010 - Submit VPLS service convergence improvement solutions to IESG Jul 2010 - Submit VPLS multi-homing solutions to IESG Internet-Drafts: - Requirements for Virtual Private LAN Services (VPLS) [draft-ietf-l2vpn-vpls-requirements-00] (16 pages) - Framework for Layer 2 Virtual Private Networks (L2VPNs) [draft-ietf-l2vpn-l2-framework-06] (45 pages) - Service Requirements for Layer 2 Provider Provisioned Virtual Private Networks [draft-ietf-l2vpn-requirements-08] (26 pages) - Virtual Private LAN Service (VPLS) Using BGP for Auto-discovery and Signaling [draft-ietf-l2vpn-vpls-bgp-09] (37 pages) - Virtual Private LAN Services Using LDP [draft-ietf-l2vpn-vpls-ldp-10] (27 pages) - Provisioning, Autodiscovery, and Signaling in L2VPNs [draft-ietf-l2vpn-signaling-08] (39 pages) - IP-Only LAN Service (IPLS) [draft-ietf-l2vpn-ipls-08] (23 pages) - Radius/L2TP Based VPLS [draft-ietf-l2vpn-l2tp-radius-vpls-00] (9 pages) - Using RADIUS for PE-Based VPN Discovery [draft-ietf-l2vpn-radius-pe-discovery-02] (18 pages) - L2VPN OAM Requirements and Framework [draft-ietf-l2vpn-oam-req-frmk-10] (36 pages) - ARP Mediation for IP Interworking of Layer 2 VPN [draft-ietf-l2vpn-arp-mediation-13] (30 pages) - VPLS Applicability [draft-ietf-l2vpn-vpls-ldp-applic-00] (20 pages) - OAM Procedures for VPWS Interworking [draft-ietf-l2vpn-vpws-iw-oam-01] (24 pages) - Requirements for Multicast Support in Virtual Private LAN Services [draft-ietf-l2vpn-vpls-mcast-reqts-08] (31 pages) - Multicast in VPLS [draft-ietf-l2vpn-vpls-mcast-06] (44 pages) - VPLS Interoperability with CE Bridges [draft-ietf-l2vpn-vpls-bridge-interop-04] (19 pages) - PIM Snooping over VPLS [draft-ietf-l2vpn-vpls-pim-snooping-01] (37 pages) - Virtual Private Lan Services (VPLS) Management Information Base [draft-ietf-l2vpn-vpls-mib-02] (41 pages) - Framework and Requirements for Virtual Private Multicast Service (VPMS) [draft-ietf-l2vpn-vpms-frmwk-requirements-02] (26 pages) - Extensions to VPLS PE model for Provider Backbone Bridging [draft-ietf-l2vpn-pbb-vpls-pe-model-01] (14 pages) - LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS [draft-ietf-l2vpn-vpls-ldp-mac-opt-01] (16 pages) - VPLS Interoperability with Provider Backbone Bridges [draft-ietf-l2vpn-vpls-pbb-interop-01] (23 pages) - BGP based Multi-homing in Virtual Private LAN Service [draft-ietf-l2vpn-vpls-multihoming-00] (19 pages) - VPLS Interoperability with Provider Backbone Bridges [draft-ietf-l2vpn-pbb-vpls-interop-00] (23 pages) Requests for Comments: RFC4665: Service Requirements for Layer 2 Provider Provisioned Virtual Private Networks (26 pages) RFC4664: Framework for Layer 2 Virtual Private Networks (L2VPNs) (45 pages) RFC4762: Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling (27 pages) RFC4761: Virtual Private LAN Service (VPLS) Using BGP for Auto-discovery and Signaling (37 pages) * Updated by RFC5462 RFC5501: Requirements for Multicast Support in Virtual Private LAN Services (31 pages) Layer Two Tunneling Protocol Extensions (l2tpext) ------------------------------------------------- Charter Last Modified: 2009-06-25 Current Status: Active Chairs: Ignacio Goyret Carlos Pignataro Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion: l2tpext@ietf.org To Subscribe: l2tpext-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/l2tpext/index.html Description of Working Group: This group is responsible for extensions to the Layer 2 Tunneling Protocol. Examples of L2TP "extensions" include any changes to the L2TP encapsulation, control messages, or new AVPs sent in IETF standard control messages. I. L2TP Background: L2TP (RFC2661) provides a means for tunneling PPP over IP. Because PPP can effectivly carry any traffic (e.g., IP (RFC 1332), IPX (RFC 1552), etc.) it can effectively be used to tunnel arbitrary protocols over IP. L2TP provides: - An extensible control protocol for dynamic setup, maintenance, and teardown of multiple layer 2 tunnels between two logical endpoints. - An encapsulation method for tunneling PPP frames between each endpoint. This includes multiplexing of multiple, discrete, PPP streams between each endpoint. L2TP looks (in most ways) like just another point-to-point link to PPP and may thereby take advantage of the work done for any protocol defined for use over a traditional PPP WAN link. It should be noted, however, that the ability to dynamically establish a PPP connection between any two IP connected endpoints brings new applications and challenges of scale to existing PPP implementations and protocol definitions that must be considered. As high-speed broadband access to the home replaces traditional dialup infrastructure, L2TP has been utilized as one standard method for aggregation and delivery of PPP connections over packet networks. Thus, rather than a relatively small scale or low speed circuit-switched connection such as an analog modem or ISDN connection at the L2TP Access Concentrator (LAC), we see PPP being received over ATM PVCs which are generally higher speed and "always-on" vs. temporally connected. Further, there are non-IETF standard PPP tunneling protocols that have been developed and deployed, including PPPoE (RFC 2516) and the 3GPP2 Wireless GPRS Tunneling Protocol Standard (http://www.3gpp.org) that interface with L2TP at various points in the network. While it is unfortunate that there is more than one standard method for tunneling PPP defined, each of these have their own installed bases and specific application-driven nuances. Proper integration with these various tunneling methods as they "hand-off" to the L2TP portion of the network must be ensured. II. L2TP Interaction with PWE3 for Pseudo-Wire Transport: In addition to tunneling PPP, L2TPEXT will develop protocol extensions necessary for the tunneling of specific "pseudo-wires" as defined in the PWE3 WG. Specific milestone identification for this activity is currently subject to ongoing work and results from PWE3. III. WG Activities The Working Group is currently focussed on the following activities: - RFC2661 bundles data transport, protocol signaling, and PPP emulation methods into a single document. This working group will separate RFC2661 into stand-alone documents for greater modularity. This will consist of a base L2TP document defining common tunneling constructs and encapsulation, and a PPP document defining the use of these constructs for tunneling of PPP sessions as defined in RFC2661. Documents for tunneling of pseudo-wires defined in PWE3 will be forthcoming as well. As RFC2661 is rewritten to separate the tunnel setup and maintenance sections for support of new applications and increased modularity, some modifications to the base protocol may be necessary. This includes addition of a Pseudo Wire AVP to identify the pseudo wire being carried (with PPP identified as 0). In all cases, these will follow the extensible models offered in the L2TP base protocol design, with as much attention to backwards compatibility as possible given the new requirements. In addition to its broader scope, L2TPEXT has ongoing work to complete from its inception as a tunneling protocol for PPP only. While RFC2661 will ultimately be made obsolete by a new L2TP base specification and companion PPP over L2TP specification, documents based on RFC2661 which do not require this new degree of modularity will still be published in the near term. These include: - Identification of specific parameters and modes of IPsec in order to aid interoperability when IPsec is used to secure L2TP traffic. - An L2TP MIB for network management. - An L2TP Differentiated Services Extension to negotiate DSCP parameters to be set for packets associated with a given L2TP tunnel, sessions within a tunnel, or L2TP control traffic which may need differentiated QoS settings. - Extensions to L2TP for additional or more robust control information for informational or operational purposes as deemed necessary based on operational experience. These include better transfer of L2TP PPP LCP Information between tunnel endpoints when such state needs to be shared, PPP Disconnect codes within L2TP control messages for better debugging, and L2TP session information for enhanced logging, billing, and error reporting. - Standard methods for operation over such packet networks such as Frame Relay and AAL5. - L2TP defines a base encapsulation for operation in typical environments for tunneling PPP at the time RFC2661 was being developed. In cases where bandwidth cost is at a premium, the size of the L2TP header becomes more significant. L2TP will define a compressed version of the L2TP header for these environments that takes advantage of the L2TP control plane to establish operational parameters allowing removal of information from individual packets. Goals and Milestones: Done - Submit L2TP over Frame Relay to IESG for consideration as a Proposed Standard Done - Submit L2TP Security to IESG for consideration as a Proposed Standard Done - Submit L2TP PPP Disconnect Information to IESG for consideration as a Proposed Standard Done - Submit L2TP ATM extensions to IESG for consideration as a Proposed Standard Done - Submit L2TP MIB to IESG for consideration as a Proposed Standard Done - Submit L2TP Link Information to IESG for consideration as a Proposed Standard Done - Submit L2TP Session Info to IESG for consideration as a Proposed Standard Done - Submit L2TP Differentiated Services to IESG for consideration as a Proposed Standard Done - Submit L2TP over AAL5 to IESG for consideration as a Proposed Standard Done - Submit initial Internet-Draft of L2TP Base Specification Done - Submit initial Internet-Draft of PPP over L2TP Done - Submit final Internet-Draft of L2TPv3 Base Specification to IESG Done - Submit Internet-Draft of HDLC over L2TPv3 to IESG Done - Submit Internet-Draft of Frame Relay over L2TPv3 to IESG Done - Submit L2VPN Extensions for L2TP to IESG Done - Submit Internet-Draft of Ethernet over L2TPv3 to IESG Done - WG Last Call on L2TP Failover Done - WG Last Call on L2TP Tunnel Switching Mar 2008 - WG Last Call on L2TP Proxy Authenticate Extensions for EAP Mar 2008 - Submit Internet-Draft of PPP over L2TPv3 to IESG Mar 2008 - WG Last Call on L2TP Tunnel Switching Jun 2008 - WG Last Call on L2TP RADIUS and Infomsg Extensions Done - WG Last Call on TDM over L2TPv3 Jun 2008 - WG Last Call on IP over L2TPv3 Internet-Drafts: - Layer Two Tunneling Protocol 'L2TP' Management Information Base [draft-ietf-pppext-l2tp-mib-05] (68 pages) - Securing L2TP using IPSEC [draft-ietf-pppext-l2tp-security-05] (14 pages) - Layer Two Tunneling Protocol ''L2TP'' IP Differential Services Extension [draft-ietf-pppext-l2tp-ds-03] (5 pages) - Layer Two Tunneling Protocol ''L2TP'' Multi-Protocol Label Switching Extension [draft-ietf-pppext-l2tp-mpls-02] (5 pages) - Layer Two Tunneling Protocol (L2TP) over Frame Relay [draft-ietf-pppext-l2tp-fr-02] (7 pages) - L2TP Over AAL5 and FUNI [draft-ietf-pppext-l2tp-atm-02] (11 pages) - Layer Two Tunnelling Protocol : ATM access network extensions. [draft-ietf-pppext-l2tp-atmext-01] (14 pages) - L2TP Alternate Data Channel ('ADC') [draft-ietf-l2tpext-adc-00] (4 pages) - L2TP Session Information (``SESINFO'') [draft-ietf-l2tpext-sesinfo-04] (4 pages) - Layer Two Tunnelling Protocol : ATM access network extensions [draft-ietf-l2tpext-atmext-04] (19 pages) - L2TP Over AAL5 [draft-ietf-l2tpext-l2tp-atm-03] (12 pages) - Layer-Two Tunneling Protocol (L2TP) Extensions for PPP Link Control P[rotocol (LCP) Negotiation [draft-ietf-l2tpext-link-07] (10 pages) - L2TP Header Compression ('L2TPHC') [draft-ietf-l2tpext-l2tphc-06] (7 pages) - Securing L2TP using IPSEC [draft-ietf-l2tpext-security-08] (27 pages) - L2TP IP Differentiated Services Extension [draft-ietf-l2tpext-ds-05] (10 pages) - Layer Two Tunneling Protocol 'L2TP' Multi-Protocol Label Switching Extension [draft-ietf-l2tpext-mpls-00] (5 pages) - Layer Two Tunneling Protocol 'L2TP' Management Information Base [draft-ietf-l2tpext-l2tp-mib-04] (86 pages) - L2TP Disconnect Cause Information [draft-ietf-l2tpext-ppp-discinfo-04] (9 pages) - Layer Two Tunneling Protocol (L2TP) over Frame Relay [draft-ietf-l2tpext-fr-01] (7 pages) - Layer Two Tunneling Protocol 'L2TP' [draft-ietf-l2tpext-l2tpbis-01] (77 pages) - L2TP Service Type [draft-ietf-l2tpext-svctype-01] (7 pages) - Ethernet Service Type for Layer Two Tunneling Protocol [draft-ietf-l2tpext-eth-00] (6 pages) - Extensions to support efficient carrying of multicast traffic in Layer-2 Tunneling Protocol (L2TP) [draft-ietf-l2tpext-mcast-06] (25 pages) - L2TP Active Discovery Relay for PPPoE [draft-dasilva-l2tp-relaysvc-09] (16 pages) - Layer Two Tunneling Protocol (Version 3) [draft-ietf-l2tpext-l2tp-base-16] (93 pages) - PPP Tunneling Using Layer Two Tunneling Protocol Version 3 (L2TPv3) [draft-ietf-l2tpext-l2tp-ppp-08] (44 pages) - PPP over L2TP Tunnel Switching [draft-ietf-l2tpext-tunnel-switching-08] (16 pages) - Frame-Relay over L2TPv3 [draft-ietf-l2tpext-pwe3-fr-08] (14 pages) - L2TP IANA Considerations Update [draft-ietf-l2tpext-rfc2661-iana-01] (5 pages) - Fail Over extensions for L2TP "failover" [draft-ietf-l2tpext-failover-13] (22 pages) - Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP) [draft-ietf-l2tpext-v92-moh-05] (13 pages) - HDLC Frames over L2TPv3 [draft-ietf-l2tpext-pwe3-hdlc-08] (12 pages) - Layer Two Tunneling Protocol : ATM Access Network Extensions [draft-ietf-l2tpext-atmext-rfc3301-bis-00] (18 pages) - Layer Two Tunneling Protocol (Version 3) "L2TPv3" Management Information Base [draft-ietf-l2tpext-l2tpmib-base-02] (55 pages) - Transport of Ethernet Frames over L2TPv3 [draft-ietf-l2tpext-pwe3-ethernet-10] (15 pages) - L2VPN Extensions for L2TP [draft-ietf-l2tpext-l2vpn-08] (15 pages) - ATM over L2TPv3 [draft-ietf-l2tpext-pwe3-atm-05] (21 pages) - Layer Two Tunneling Protocol version 3 - Setup of Time-Division Multiplexing (TDM) Pseudowires [draft-ietf-l2tpext-tdm-08] (10 pages) - Signaling and Encapsulation for the Transport of IP over L2TPv3 [draft-ietf-l2tpext-pwe3-ip-05] (20 pages) - L2TP Proxy Authenticate Extensions for EAP [draft-ietf-l2tpext-proxy-authen-ext-eap-02] (11 pages) - RADIUS & L2TP Extended NAS-Port AVPs [draft-ietf-l2tpext-radius-ext-nas-port-02] (14 pages) - L2TPv3 Extended Circuit Status Values [draft-ietf-l2tpext-circuit-status-extensions-06] (12 pages) - Layer Two Tunneling Protocol - Setup of TDM Pseudowires [draft-ieft-l2tpext-tdm-04] (8 pages) Requests for Comments: RFC3070: Layer Two Tunneling Protocol (L2TP) over Frame Relay (7 pages) RFC3145: L2TP Disconnect Cause Information (10 pages) RFC3193: Securing L2TP using IPSEC (28 pages) RFC3301: Layer Two Tunnelling Protocol : ATM access network extensions (19 pages) RFC3355: L2TP Over AAL5 (13 pages) RFC3371: Layer Two Tunneling Protocol 'L2TP' Management Information Base (70 pages) RFC3308: L2TP IP Differentiated Services Extension (10 pages) RFC3438: L2TP IANA Considerations Update (5 pages) RFC3437: Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation (10 pages) RFC3573: Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP) (13 pages) RFC3817: L2TP Active Discovery Relay for PPPoE (16 pages) RFC3931: Layer Two Tunneling Protocol (Version 3) (93 pages) * Updated by RFC5641 RFC4045: Extensions to support efficient carrying of multicast traffic in Layer-2 Tunneling Protocol (L2TP) (25 pages) RFC4349: High-Level Data Link Control (HDLC) Frames over Layer 2 Tunneling Protocol, Version 3 (L2TPv3) (12 pages) * Updated by RFC5641 RFC4454: Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3) (21 pages) * Updated by RFC5641 RFC4591: Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3) (14 pages) * Updated by RFC5641 RFC4667: Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP) (15 pages) RFC4719: Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3) (15 pages) * Updated by RFC5641 RFC4951: Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) (22 pages) RFC5611: Layer Two Tunneling Protocol version 3 - Setup of Time-Division Multiplexing (TDM) Pseudowires (10 pages) RFC5641: Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values (12 pages) * Updates RFC3931 * Updates RFC4349 * Updates RFC4454 * Updates RFC4591 * Updates RFC4719 Locator/ID Separation Protocol (lisp) ------------------------------------- Charter Last Modified: 2009-12-01 Current Status: Active Chairs: Joel Halpern Terry Manderson <> Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: lisp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lisp Archive: http://www.ietf.org/mail-archive/web/lisp/current/maillist.html Description of Working Group: The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system and the impending exhaustion of the IPv4 address space. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the "locator/identifier separation". The basic idea behind the separation is that the Internet architecture combines two functions, routing locators, (where you are attached to the network) and identifiers (who you are) in one number space: The IP address. Proponents of the separation architecture postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system. The separation aims to decouple locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. LISP supports the separation of the IPv4 and IPv6 address space following a network-based map-and-encapsulate scheme (RFC 1955). In LISP, both identifiers and locators are IP addresses. In LISP, identifiers are composed of two parts: a "global" portion that uniquely identifies a particular site and a "local" portion that identifies an interface within a site. The "local" portion may be subdivided to identify a particular network within the site. For a given identifier, LISP maps the "global" portion of the identifier into a set of locators that can be used by de-capsulation devices to reach the identified interface; as a consequence a host would typically change identifiers when it moves from one site to another or whenever it moves from one subnet to another within an site. Typically, the same IP address will not be used as an identifier and locator in LISP. LISP requires no changes to end-systems or to most routers. LISP aims for an incrementally deployable protocol. A number of approaches are being looked at in parallel in the IRTF and IETF. At this time, these proposals are at an early stage. All proposals (including LISP) have potentially harmful side-effects to Internet traffic carried by the involved routers, have parts where deployment incentives may be lacking, and are NOT RECOMMENDED for deployment beyond experimental situations at this stage. Many of the proposals have components (such as the identifier to locator mapping system) where it is not yet known what kind of design alternative is the best one among many. However, despite these issues it would be valuable to write concrete protocol specifications and develop implementations that can be used to understand the characteristics of these designs. The LISP WG is chartered to work on the LISP base protocol (draft-farinacci-lisp-12.txt), the LISP+ALT mapping system (draft-fuller-lisp-alt-05.txt), LISP Interworking (draft-lewis-lisp-interworking-02.txt), LISP Map Server (draft-fuller-lisp-ms-00.txt), and LISP multicast (draft-farinacci-lisp-multicast-01.txt) for these purposes, with the given drafts as a starting point. The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. The Working Group will also develop security profiles for the ALT and/or other mapping systems. It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF (e.g., the Routing Research Group) that attempts to understand which type of a solution is optimal. The LISP WG is NOT chartered to develop the final or standard solution for solving the routing scalability problem. Its specifications are Experimental and labeled with accurate disclaimers about their limitations and not fully understood implications for Internet traffic. In addition, as these issues are understood, the working group will analyze and document the implications of LISP on Internet traffic, applications, routers, and security. This analysis will explain what role LISP can play in scalable routing. The analysis should also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on (draft-meyer-loc-id-implications) as well as the manageability and operability of LISP. Goals and Milestones: Mar 2010 - Submit base LISP specification to the IESG as Experimental Mar 2010 - Submit base ALT specification to the IESG as Experimental Mar 2010 - Submit the LISP Interworking specification to the IESG as Experimental Jun 2010 - Submit the LISP Map Server specification to the IESG as Experimental Jun 2010 - Submit Recommendations for Securing the LISP Mapping System to the IESG as Experimental Jul 2010 - Submit LISP for Multicast Environments to the IESG as Experimental Dec 2010 - Submit a preliminary analysis as Informational Dec 2010 - Re-charter or close. Internet-Drafts: - LISP for Multicast Environments [draft-ietf-lisp-multicast-02] (34 pages) - Locator/ID Separation Protocol (LISP) [draft-ietf-lisp-06] (75 pages) - Interworking LISP with IPv4 and IPv6 [draft-ietf-lisp-interworking-01] (15 pages) - LISP Alternative Topology (LISP+ALT) [draft-ietf-lisp-alt-02] (26 pages) - LISP Map Server [draft-ietf-lisp-ms-04] (13 pages) No Requests for Comments Mobility EXTensions for IPv6 (mext) ----------------------------------- Charter Last Modified: 2009-08-06 Current Status: Active Chairs: Marcelo Bagnulo Julien Laganier Internet Area Directors: Ralph Droms Jari Arkko 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: Mobile IPv6 specifies routing support which permits an IPv6 host to continue using its home address as it moves around the Internet, enabling continuity of sessions. Mobile IPv6 supports transparency above the IP layer, including maintenance of active transport level sessions. In addition, network mobility (NEMO) mechanisms built on top of Mobile IPv6 allow managing the mobility of an entire network, as it changes its point of attachment to the Internet. The base specifications consist of: o RFC 3775 (Mobile IPv6) o RFC 3963 (NEMO) o RFC 4877 (Mobile IPv6 Operation with IKEv2) The MEXT Working Group continues the work of the former MIP6, NEMO, and MONAMI6 Working Groups. The primary goal of MEXT will be to (A) enhance base IPv6 mobility by continuing work on developments that are required for wide-scale deployments and specific deployment scenarios. Additionally, (B) the working group will ensure that any issues identified by implementation and interoperability experience are addressed, and that the base specifications are maintained. (C) The group will also produce informational documentation, such as design rationale documents or description of specific issues within the protocol. Deployment considerations call for (A.1) solutions to enable dual-stack operation, (A.2) mechanisms to support high-availability home agents, (A.3) allowing the use of multiple interfaces in mobile nodes, (A.4) ways to employ Mobile IPv6 in the presence of firewalls, (A.5) address the specific needs of automotive and aviation communities for route optimisation in network mobility, (A.6) support for AAA is needed as a continuation of earlier work on bootstrapping, (A.7) revocation of binding, (A.8) generic notification message format and (A.9) extended DMSIP home network support . Work items related to large scale deployment include: (A.1) A Solution for Mobile IPv6 and NEMO session continuity for dual stack hosts which attach to IPv4 access networks. Additionally provide a mechanism for carrying IPv4 packets via the Home agent for Mobile IPv6 or NEMO capable dual-stack hosts. (A.2) A protocol based solution for enhancing the reliability of home agents and a method to force a host/router to switch home agents. A mechanism to force an MN to switch the HA that is currently serving it. This is required in deployments where the HA needs to be taken offline for maintenance. (A.3) Use of multiple interfaces. Today, the protocols do not provide suppport for simultaneous differentiated use of multiple access technologies. Several proposals exist for such support, and some of them have been implemented and tested. When a mobile host/router uses multiple network interfaces simultaneously, or when multiple prefixes are available on a single network interface, the mobile host/router would end up with multiple Care-of Addresses (CoAs). In addition, the Home Agent might be attached to multiple network interfaces, or to a single network interface with multiple prefixes, hence resulting in the option to use multiple IP addresses for the Home Agent. This could result in the possibility of using a multitude of bi-directional tunnels between pairs of {Home Agent address, CoA} and a number of associated issues: establishment, selection and modification of multiple simultaneous tunnels. The objective of the WG is to produce a clear problem statement and to produce standard track specifications to the problems associated with the simultaneous use of multiple addresses for either mobile hosts using Mobile IPv6 or mobile routers using NEMO Basic Support and their variants (FMIPv6, HMIPv6, etc). Where the effects of having multiple prefixes on a single interface is identical to the effects of having multiple interfaces each with a single prefix, the WG will consider a generalized approach to cater for multiple prefixes available to a mobile host/router. The WG uses existing tunneling mechanisms defined for Mobile IPv6. The involved nodes need to select which tunnel instance to use when multiple ones are available due to multiple addresses on either end. But the WG does not plan to define a new mechanism for this, but rather document how to use existing mechanisms based upon preferences or policies. In particular, the WG will consider that a tunnel is alive as long as packets can be exchanged with the corresponding peer. In addition, local information, such as interface up/down events, or other failure detection mechanisms can be used to quickly detect failure of tunnel(s). Deliverables related to this include - A document explaining the motivations for a node using multiple interfaces and the scenarios where it may end up with multiple global addresses on its interfaces [Informational] - An analysis document explaining what are the limitations for mobile hosts using multiple simultaneous Care-of Addresses and Home Agent addresses using Mobile IPv6, whether issues are specific to Mobile IPv6 or not [Informational]. - A protocol extension to support the registration of multiple Care-of Addresses at a given Home Agent address [Standard Track]. - A "Flow/binding policies exchange" solution for an exchange of policies from the mobile host/router to the Home Agent and from the Home Agent to the mobile host/router influencing the choice of the Care-of Address and Home Agent address. The solution involves two specifications, one for the policy format and another for its transport [both Standard Track]. (A.4) Work on solutions to deal with firewalls and the problems that firewalls cause as identified in RFC 4487. (A.5) Route optimization of network mobility. Three use cases have been identified for this. These are called the Aviation case, the Automotive case, and the Personal Mobile Router (consumer electronics) case, though the actual technical problems are characterized by the type of movements and environments more than by the specific industry using the technology. The group will explore these cases to gather requirements and proceed with solving the open issues. (1) Airline and spacecraft community, who are deploying NEMO for control systems, as well as Internet connectivity and entertainment systems. This use case is characterized by fast (~ 1000 km/h) moving objects over large distances (across continents). The main technical problem is that tunneling-based solutions imply a roundtrip to another continent and that BGP based solutions imply significant churn in the global Internet routing table. (2) Automotive industry who are deploying NEMO for in-car communication, entertainment, and data gathering, possible control systems use, and communication to roadside devices. This use case is characterized by moderately fast (~ 100-300 km/h) moving objects that employ local or cellular networks for connectivity. (3) Personal Mobile Routers, which are consumer devices that allow the user to bring a NEMO network with the user while mobile, and communicate with peer NEMO Basic Support nodes and nodes served by them. After gathering the requirements for these types of deployments, the working group will evaluate what type of route optimization needs to be performed (if any), and formulate a solution to those problems. If no requirements for those scenarios can be collected by the deadline, it will be assumed that the work is premature, and that type of deployment will be dropped from the WG. The group will only consider airline and spacecraft solutions that combine tunneling solutions for small movements with either federated tunnel servers or slowly changing end host prefixes. The group will only consider personal mobile router requirements about optimized routes to another mobile router belonging to the same operator. The group will only consider automotive industry requirements to allow MR-attached hosts to directly access the network where MR has attached to. Work on automotive and personal mobile router solutions requires rechartering. The WG will not consider extensions to routing protocols. The group will not consider general multi-homing problems that are not related to the deployment and maintenance of Mobile IPv6 or NEMO Basic Support protocols. The group will also not consider general route optimization, or other problems that are not related to the deployment and maintenance of NEMO Basic Support protocols. Similarly, the group will not consider or rely on the results of general routing architecture, Internet architecture, or identifier-locator split issues that are discussed in separate, long term efforts elsewhere in the IETF. Finally, the group will not consider solutions that require changes from correspondent nodes in the general Internet (A.6) Bootstrapping mechanisms developed earlier in the MIP6 WG require AAA support for Mobile IPv6. Part of this work is already being done in the DIME WG, but the MEXT WG is chartered to complete a design for RADIUS. (A.7) Binding Revocation for IP Mobility: Define a binding revocation mechanism for Mobile IPv6 and its extensions. This mechanism can be used by any entity involved in the base Mobile IPv6 protocol or one of its extensions to request its corresponding entity to terminate either one, multiple or all binding cache entries. (A.8) Generic Notification Message for Mobile IPv6: A proposal for defining generic notification framework that can be used by the mobility entities for sending and receiving asynchronous notification messages was proposed and the same was adopted by the WG. (A.9) Extended DSMIPv6 Home Network Support: DSMIPv6 assumes the home network to be dual stack providing simultaneous IPv6 and IPv4 network access. It is proposed to extend DSMIPv6 to support home networks which provides IPv4, or IPv6 respectively, direct network access only, but where virtual IPv6 home network connectivity, or virtual IPv4 home network connectivity respectively, may be obtained by tunneling to the HA. The latter shall be obtained by DSMIPv6 operation using the v4HoA address as Care-of-address for the v6HoA address, and vice versa, the v6HoA address as care-of-address for the v4HoA address. Work items related to base specification maintenance include: (B.1) Create and maintain issue lists that are generated on the basis of implementation and interoperability experience. Address specific issues with specific updates or revisions of the base specification. One specific area of concern that should be analyzed and addressed relates to multilink subnets. This work item relates only to corrections and clarifications. The working group shall not revisit design decisions or change the protocol. (B.2) Update the IANA considerations of RFC 3775 to allow extensions for experimental purposes as well passing of optional vendor-specific information. (B.3) Finish working group documents that are currently in process, and submit for RFC. This includes prefix delegation protocol mechanism for network mobility, and a MIB for NEMO Basic Support. Work items related to informational documentation include: (C.1) Produce a design rationale that documents the historical thinking behind the introduction of an alternative security mechanism, the Authentication Protocol (RFC 4285). (C.2) Virtual Home Link configuration for Mobile IPv6: A proposal has been made on Mobile IPv6 home link configuration on virtual links. The proposal does not describe any new protocol, but provides the operational and configuration details and additionally provides implementation guidance for achieving this configuration. The group employs IPsec and IKE as a security mechanism. The group shall refrain, however, from making generic extensions to these protocols. Any proposed extension must be reviewed by the INT and SEC ADs before it can be accepted as a part of a work item. 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. Feb 2008 - Submit -00 draft on Route Optimization needs for Personal Mobile Router 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 Mar 2008 - Submit the final doc on Prefix Delegation for NEMO to the IESG, for Proposed Standard Done - Submit I-D 'Mobility Header Home Agent Switch Message' to IESG for publication as a Proposed Standard May 2008 - Submit final doc on Route Optimization needs for Personal Mobile Router, for Informational May 2008 - Submit final doc on Route Optimization Needs for Automobile and Highway Deployments, for Informational Done - Submit final doc on Route Optimization Needs for Aircraft and Spacecraft Deployments, for Informational May 2008 - Submit -00 draft for solution to aircraft/spacecraft problem Jun 2008 - Determine how to proceed with remaining automotive/Personal Mobile Router solutions Jun 2008 - Submit the I-D 'RADIUS Mobile IPv6 Support' to IESG for publication as a proposed standard. Done - Submit 00 draft on Binding Revocation Jul 2008 - Submit Analysis of the use of Multiple Simultaneous Care-of Addresses and Home Agent addresses, for Informational Jul 2008 - Submit Multiple Interfaces Motivations and Scenario to IESG, for Informational Aug 2008 - Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication as Informational. Done - Submit the final doc on MIB for NEMO Basic Support to the IESG, for Proposed Standard Oct 2008 - Submit Flow/binding policy transport to IESG, for Proposed Standard Oct 2008 - Submit Flow/binding policy format to IESG, for Proposed Standard Done - Submit draft on Binding Revocation to IESG Oct 2008 - Submit 00 draft on Generic Notification Nov 2008 - Submit final doc for solution to aircraft/spacecraft problem to the IESG, for Proposed Standard Nov 2008 - Recharter to work on the remaining automotive/Personal Mobile Router solutions Dec 2008 - Submit I-D(s) related to specific updates and corrections of RFC 3775 to IESG for publication as Proposed Standard. Dec 2008 - Submit I-D 'Home agent reliability' to IESG for publication as a Proposed Standard. Dec 2008 - Submit 00 draft on Extended DSMIPv6 Home Network support Dec 2008 - Submit 00 draft on Virtual Home link configuration Jan 2009 - Submit draft on Generic Notification to IESG Mar 2009 - Submit draft on Virtual Home link configuration to IESG May 2009 - Submit draft on Extended DSMIPv6 Home Network support to IESG 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 [draft-ietf-mip6-hareliability-06] (47 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-05] (37 pages) - Mobility Support in IPv6 [draft-ietf-mext-rfc3775bis-05] (174 pages) - DHCPv6 Prefix Delegation for NEMO [draft-ietf-mext-nemo-pd-03] (13 pages) - Binding Revocation for IPv6 Mobility [draft-ietf-mext-binding-revocation-14] (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-02] (12 pages) - Guidelines for firewall vendors regarding MIPv6 traffic [draft-ietf-mext-firewall-vendor-02] (8 pages) - Traffic Selectors for Flow Bindings [draft-ietf-mext-binary-ts-03] (19 pages) Requests for Comments: RFC5488: Network Mobility (NEMO) Management Information Base (44 pages) RFC5555: Mobile IPv6 Support for Dual Stack Hosts and Routers (41 pages) RFC5637: Authentication, Authorization, and Accounting (AAA) Goals for Mobile IPv6 (12 pages) RFC5648: Multiple Care-of Addresses Registration (44 pages) RFC5522: Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks (31 pages) Mobility for IP: Performance, Signaling and Handoff Optimization (mipshop) -------------------------------------------------------------------------- Charter Last Modified: 2009-05-22 Current Status: Active Chairs: Stefano Faccin Vijay Devarapalli Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: mipshop@ietf.org To Subscribe: mipshop-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/mipshop/index.html Description of Working Group: Mobile IPv6 enables IPv6 mobile nodes to continue a session using a given "home address" in spite of changes in its point of attachment to the network. These changes may cause delay, packet loss, and also represent signaling overhead traffic on the network. The MIPSHOP WG has so far worked on two technologies to address these issues. Hierarchical Mobile IPv6 (HMIPv6) reduces the amount and latency of signaling between a MN, its Home Agent and one or more correspondent nodes. Mobile IPv6 Fast Handovers (FMIPv6) reduces packet loss by providing fast IP connectivity as soon as the mobile node establishes a new point of attachment at a new link. The MIPSHOP WG will continue to work on HMIPv6 and FMIPv6, and the necessary extensions to improve these protocols. The MIPSHOP WG will also identify missing components that are required for deploying these protocols and standardize the necessary extensions. The WG will also address using these protocols to provide fast handovers for network-based mobility management protocols like Proxy Mobile IPv6. The IEEE 802.21 Media Independent Handover (MIH) working group aims at providing services to assist with handoffs between heterogeneous link-layer technologies, and across IP subnet boundaries. MIH services can be delivered through link-layer specific solutions and/or through a "layer 3 or above" protocol. MIPSHOP will define the delivery of information for MIH services for this latter case. A L3 based mechanism to identify a valid information server is also required. The MIPSHOP will work on developing a protocol for transport of MIH services information and mechanisms for discovering the MIH server. Security for the transport of MIH information will also be addressed. The MOBOPTS Research Group in the IRTF is chartered to work on optimizations related to Mobile IPv6 and IP handoffs among other things. The MIPSHOP WG will take mature proposals from the MOBOPTS group and standardize them in the IETF on a case-by-case basis. The MIPSHOP WG will also consider and standardize optimizations for the Mobile IPv6 protocol and IP mobility in general. Scope of MIPSHOP: The working group will work on: 1. FMIPv6 Mobile Node - Access Router security using the AAA infrastructure Currently MIPSHOP has produced a standards track protocol for setting up security between the mobile node and access router for security FMIPv6 signaling messages. However, the protocol depends on SeND (Secure Neighbor Discovery) to be available on the mobile node and the access router. An alternate mechanism that leverages the AAA infrastructure would be useful. Many target systems where FMIPv6 is likely to be used use a AAA infrastructure to authenticate and authorize network access. The working group will work on a Informational document describing how the AAA infrastructure could be used for setting up security associations between the mobile node and the access router. 2. Prefix Management for point-to-point links with FMIPv6 Using FMIPv6 over point-to-points like requires some additional considerations with respect to managing and allocating prefixes for the mobile node on these point-to-point links. Therefore the WG will work on an Informational document to address the issues. 3. Handover optimizations when Proxy Mobile IPv6 is used for handovers Proxy Mobile IPv6 (PMIPv6) is a network-based mobility management protocol where a node in the access network, called the Mobile Access Gateway (MAG) handles mobility on behalf of the mobile node. It has been proposed to use FMIPv6 to optimize the handover in terms of reducing the packet loss and transferring relevant context from the old MAG to the new MAG. The working group will also work on other optimizations like the use of a transient binding cache entry for improving a PMIPv6-based handover. 4. Work on protocols and extensions for transporting information related to IEEE 802.21: The work includes the layer 3 protocol for transporting MIH related information and DHCP and DNS extensions for discovering the information servers. Goals and Milestones: Done - Working Group Last Call on draft-ietf-mipshop-hmip-xx.txt Done - Working Group Last Call on draft-ietf-mipshop-lmm-requirements-XX.txt Done - Working Group Last Call on draft-ietf-mipshop-fmipv6-xx.txt Done - Discuss Last Call comments and security analyses at IETF 58 Done - Submit draft draft-ietf-mipshop-lmm-requirements-XX.txt to IESG for consideration of publication as Informational Done - Submit draft-ietf-mipshop-hmip-xx.txt to IESG for consideration of publication as Experimental Done - Submit draft-ietf-mipshop-fmipv6-xx.txt to IESG for consideration of publication as Experimental Done - Working Group Last Call on draft-ietf-mipshop-80211fh-xx.txt for Informational Done - Submit draft-ietf-mipshop-80211fh-xx.txt to IESG for consideration of publication as Informational Done - Working Group Last Call on draft-ietf-mipshop-cga-cba-XX.txt Done - Working Group Last Call on draft-ietf-mipshop-mis-ps Done - Submit draft-ietf-mipshop-cga-cba to IESG for publication as Proposed Standard Done - Working Group Last Call on draft-ietf-mipshop-fmipv6-rfc4068bis Done - Working Group Last Call on draft-ietf-mipshop-handover-key-send Done - Submit draft-ietf-mipshop-mis-ps to IESG for publication as Informational RFC Done - Working Group Last Call on draft-ietf-mipshop-rfc4041bis Done - Working Group Last Call on draft-ietf-mipshop-3gfh Done - Working Group Last Call on draft-ietf-mipshop-fh80216e Done - Submit draft-ietf-mipshop-fmipv6-rfc4068bis to IESG for publication as Proposed Standard Done - Submit draft-ietf-mipshop-handover-key-send to IESG for publication as Proposed Standard Done - Submit draft-ietf-mipshop-3gfh to IESG for publication as Informational RFC Done - Submit draft-ietf-mipshop-fh80216e to IESG for publication as Informational RFC Done - Working Group Last Call on draft-ietf-mipshop-mih-support Done - Submit draft-ietf-mipshop-mih-support to IESG for publication as Proposed Standard Done - Working Group Last Call on draft-ietf-mipshop-mos-dns-discovery Done - Working Group Last Call on draft-ietf-mipshop-mos-dhcp-options Done - Submit draft-ietf-mipshop-mos-dhcp-options to the IESG for publication as Proposed Standard May 2009 - Working Group Last Call on draft-ietf-mipshop-pfmipv6 Jun 2009 - Working Group Last Call on draft-ietf-mipshop-transient-bce-pmipv6 Jun 2009 - Submit draft-ietf-mipshop-pfmipv6 to the IESG for publication as Proposed Standard Jul 2009 - Submit draft-ietf-mipshop-transient-bce-pmipv6 to the IESG for publication as Experimental Aug 2009 - Working group last call on draft-ietf-mipshop-fmipv6-ptp Sep 2009 - Submit draft-ietf-mipshop-fmipv6-ptp to the IESG for publication as Informational Internet-Drafts: - Hierarchical Mobile IPv6 mobility management (HMIPv6) [draft-ietf-mipshop-hmipv6-05] (28 pages) - Fast Handovers for Mobile IPv6 [draft-ietf-mipshop-fast-mipv6-04] (42 pages) - Mobile IPv6 Fast Handovers for 802.11 Networks [draft-ietf-mipshop-80211fh-05] (16 pages) - Localized Mobility Management Goals [draft-ietf-mipshop-lmm-requirements-03] (21 pages) - Fast Handovers for Mobile IPv6 [draft-ietf-mipshop-fmipv6-rev-00] (41 pages) - Mobile IPv6 Fast Handovers over IEEE 802.16e Networks [draft-ietf-mipshop-fh80216e-08] (23 pages) - Mobile IPv6 Fast Handovers for 3G CDMA Networks [draft-ietf-mipshop-3gfh-08] (27 pages) - Mobile IPv6 Fast Handovers [draft-ietf-mipshop-fmipv6-rfc4068bis-08] (48 pages) - Enhanced Route Optimization for Mobile IPv6 [draft-ietf-mipshop-cga-cba-04] (60 pages) - Distributing a Symmetric Fast Mobile IPv6 (FMIPv6) Handover Key Using SEcure Neighbor Discovery (SEND) [draft-ietf-mipshop-handover-key-04] (14 pages) - Mobility Services Transport: Problem Statement [draft-ietf-mipshop-mis-ps-06] (20 pages) - Hierarchical Mobile IPv6 Mobility Management [draft-ietf-mipshop-4140bis-06] (32 pages) - IEEE 802.21 Mobility Services Framework Design (MSFD) [draft-ietf-mipshop-mstp-solution-13] (25 pages) - Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery [draft-ietf-mipshop-mos-dhcp-options-15] (14 pages) - Locating IEEE 802.21 Mobility Servers using DNS [draft-ietf-mipshop-mos-dns-discovery-08] (9 pages) - Fast Handovers for Proxy Mobile IPv6 [draft-ietf-mipshop-pfmipv6-12] (41 pages) - Transient Binding for Proxy Mobile IPv6 [draft-ietf-mipshop-transient-bce-pmipv6-05] (42 pages) - Mobile IPv6 Fast Handovers [draft-ietf-mipshop-rfc5268bis-02] (51 pages) Requests for Comments: RFC4068: Fast Handovers for Mobile IPv6 (42 pages) * OBSOLETED BY RFC5268 RFC4140: Hierarchical Mobile IPv6 mobility management (HMIPv6) (28 pages) * OBSOLETED BY RFC5380 RFC4260: Mobile IPv6 Fast Handovers for 802.11 Networks (16 pages) RFC4866: Enhanced Route Optimization for Mobile IPv6 (60 pages) RFC5164: Mobility Services Transport: Problem Statement (20 pages) RFC5268: Mobile IPv6 Fast Handovers (48 pages) * Obsoletes RFC4068 RFC5269: Distributing a Symmetric Fast Mobile IPv6 (FMIPv6) Handover Key Using SEcure Neighbor Discovery (SEND) (14 pages) RFC5271: Mobile IPv6 Fast Handovers for 3G CDMA Networks (22 pages) RFC5270: Mobile IPv6 Fast Handovers over IEEE 802.16e Networks (18 pages) RFC5380: Hierarchical Mobile IPv6 Mobility Management (32 pages) * Obsoletes RFC4140 RFC5568: Mobile IPv6 Fast Handovers (51 pages) RFC5677: IEEE 802.21 Mobility Services Framework Design (MSFD) (25 pages) RFC5678: Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery (14 pages) RFC5679: Locating IEEE 802.21 Mobility Services Using DNS (9 pages) Mobility for IPv4 (mip4) ------------------------ Charter Last Modified: 2009-08-18 Current Status: Active Chairs: Henrik Levkowetz Pete McCann Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: mip4@ietf.org To Subscribe: mip4-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/mip4/index.html Description of Working Group: IP mobility support for IPv4 nodes (hosts and routers) is specified in RFC3344. RFC 3344 mobility allows a node to continue using its "permanent" home address as it moves around the Internet. The Mobile IP protocols support transparency above the IP layer, including maintenance of active TCP connections and UDP port bindings. Besides the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal with concerns such as optimization, security, extensions, AAA support, and deployment issues. MIPv4 is currently being deployed on a wide basis (e.g., in cdma2000 networks). The scope of the deployment is on a fairly large scale and accordingly, the MIP4 WG will focus on deployment issues and on addressing known deficiencies and shortcomings in the protocol that have come up as a result of deployment experience. Specifically, the working group will complete the work items to facilitate interactions with AAA environments, interactions with enterprise environments when MIPv4 is used therein, and updating existing protocol specifications in accordance with deployment needs and advancing those protocols that are on the standards track. Work expected to be done by the MIP4 WG as proposed by this charter is as follows: 1. MIPv4 has been a Proposed Standard for several years. It has been adopted by other standard development organizations and has been deployed commercially. One of the next steps for the WG is to advance the protocol to draft standard status. As part of advancing base Mobile IP specifications to Draft Standard, the MIPv4 NAI RFC (2794) will be revised to reflect implementation experience. 2. The WG will complete the MIB specifications for the Mobile IPv4 base protocol and the UDP tunneling extension. 3. A requirements document for RADIUS MIP4 support was previously completed and published as RFC 5030. Based on these requirements, the WG will complete the specification of MIPv4 RADIUS attributes, solicit feedback from the RADEXT WG, adjust, and submit this for publication. Note that the work may require extensions to the RADIUS attribute space which will be handled outside the MIP4 WG. 4. Like fixed nodes, mobile nodes sometimes need to be dynamically configured with parameters such as DNS server IP addresses. Previous work in the WG proposed to put a generic container for host configuration options into Mobile IPv4 signaling. However, it may be easier for mobile nodes to implement the already existing DHCP specification, and to run DHCP over the tunnel established with an initial registration. The WG will take on a draft describing any modifications to Mobile IPv4 that may be needed to facilitate this mode of operation, and submit for publication as a Proposed Standard or Best Current Practice as appropriate. 5. The proliferation of devices with multiple interface technologies and the desire to use each interface for the type of traffic most appropriate to it (even simultaneously with other interfaces active at the same time) has led to requirements for supporting multiple simultaneous tunnels between the Home Agent and Mobile Node. The WG will adopt and take to publication as an Experimental RFC one draft that describes how to manage such tunnels and how to direct traffic to use the appropriate tunnel when multiple choices are available. This work will be coordinated with similar Mobile IPv6 work ongoing in the mext working group. In particular, we will strive to converge on a consistent set of architectural decisions (such as which entities are responsible for signaling flow-to-tunnel bindings) and we will share protocol definitions wherever practical (such as the layout of packet flow filters). 6. The WG has published a basic Network Mobility (NEMO) specification as RFC 5177. The WG has taken up an extension to NEMO that will allow for dynamic home network prefix allocation to a moving network. The WG will finish work on this draft and publish as a Proposed Standard. 7. Route optimization has been the focus of a large amount of effort in the Mobile IPv6 WG. For Mobile IPv4, however, the usage case is less clear due to a variety of factors, including the inability to modify already deployed correspondent nodes. Recently a specific use case has been proposed involving route optimization for a more closed network where modifications are made to site routers and a centralized Home Agent to enable offloading of traffic from the Home Agent. The WG will take on and publish a draft on this topic as a Experimental RFC. 8. The use of GRE tunneling with Mobile IPv4 enables support for multiple overlapping private address spaces within the same mobility agent. However, to distinguish flows from two different mobile nodes that happen to share the same (private) IP address, the GRE Key field needs to be populated with a unique identifier that will enable the mobility agent to demultiplex the flows. The value used for the Key needs to be signaled at the time of tunnel establishment, which means a new Mobile IPv4 extension is needed for this purpose. The WG will take on an publish a draft on this topic as a Proposed Standard. 9. Support for multicast and broadcast packets in Mobile IPv4 as specified in RFC 3024 currently requires encapsulated delivery style for all packets. This leads to inefficiencies on the MN-to-FA link because even unicast packets must be encapsulated. Eliminating this inefficiency is possible if there is a mechanism to negotiate a mode of operation where only multicast/broadcast packets are encapsulated, while unicast packets can use direct delivery style. The WG will take on a draft to solve this problem and publish as a Proposed Standard. Goals and Milestones: Done - AAA Keys for MIPv4 to IESG Done - MIPv4 VPN interaction problem statement to IESG Done - Low latency handover to experimental Done - Experimental MIPv4 message and extensions draft to IESG Done - Dynamic Home Agent assignment protocol solution to IESG Done - Revised MIPv4 Challenge/Response (3012bis) to IESG Done - Regional registration document to IESG Done - Generic Strings for MIPv4 (Proposed Std.) to the IESG Done - MIPv4 Mobike interaction (BCP) to the IESG Done - MIPv4 RADIUS Extensions Requirements to the IESG Done - MIPv4 Extension for Config. Options (Proposed Std.) to the IESG Done - FMIPv4 (Experimental) to the IESG Done - MIPv4 VPN interaction (BCP) to the IESG Done - Base MIPv4 Mobile Network Support (Draft Std.) to IESG Done - Dual-stack MIPv4 (Draft Std.) to IESG Done - Notification Mechanism (Draft Std.) to IESG Jul 2009 - Revised MIPv4 specification (Proposed Std.) to IESG Jul 2009 - Revised MIB for MIPv4 (Proposed Std.) to IESG Aug 2009 - NEMO Dynamic Address Assignment (Proposed Std.) to IESG Nov 2009 - GRE Key Extension (Proposed Std) to IESG Nov 2009 - Revised rfc2794bis (NAI extension) (Proposed Std.) to the IESG Nov 2009 - RADIUS Extensions for MIPv4 to the RADEXT WG for comment Dec 2009 - MIB for UDP encapsulation (Proposed Std.) to IESG Feb 2010 - RADIUS Extensions for MIPv4 (Proposed Std.) to the IESG Mar 2010 - Home Agent Assisted Route Optimization (Experimental) to the IESG Apr 2010 - Multiple/Broadcast delivery style (Proposed Std.) to IESG May 2010 - Multiple tunnel support and flow binding (Experimental) to IESG Internet-Drafts: - Low Latency Handoffs in Mobile IPv4 [draft-ietf-mobileip-lowlatency-handoffs-v4-12] (56 pages) - IP Mobility Support for IPv4, revised [draft-ietf-mip4-rfc3344bis-09] (109 pages) - Mobile IPv4 Traversal Across IPsec-based VPN Gateways [draft-ietf-mobileip-vpn-problem-solution-03] (49 pages) - Mobile IPv4 Extension for AAA Network Access Identifiers [draft-ietf-mip4-aaa-nai-03] (10 pages) - The Definitions of Managed Objects for IP Mobility Support using SMIv2, revised [draft-ietf-mip4-rfc2006bis-07] (112 pages) - AAA Registration Keys for Mobile IPv4 [draft-ietf-mip4-aaa-key-07] (29 pages) - Problem Statement: Mobile IPv4 Traversal of VPN Gateways [draft-ietf-mip4-vpn-problem-statement-04] (19 pages) - Mobile IPv4 Challenge/Response Extensions (revised) [draft-ietf-mip4-rfc3012bis-06] (33 pages) - Experimental Message, Extension and Error Codes for Mobile IPv4 [draft-ietf-mip4-experimental-messages-03] (12 pages) - Mobile IPv4 Dynamic Home Agent Assignment [draft-ietf-mip4-dynamic-assignment-08] (24 pages) - Mobile IPv4 Traversal across IPsec-Based VPN Gateways [draft-ietf-mip4-vpn-problem-solution-06] (39 pages) - Foreign Agent Error Extension for Mobile IPv4 [draft-ietf-mip4-faerr-03] (6 pages) - Mobile IPv4 Regional Registration [draft-ietf-mip4-reg-tunnel-05] (35 pages) - Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE) [draft-ietf-mip4-mobike-connectivity-04] (15 pages) - Mobile IPv4 Message String Extension [draft-ietf-mip4-message-string-ext-04] (12 pages) - Mobile IPv4 RADIUS requirements [draft-ietf-mip4-radius-requirements-05] (10 pages) - Mobile IPv4 Fast Handovers [draft-ietf-mip4-fmipv4-08] (28 pages) - Mobile IPv4 Extension for Configuration Options Exchange [draft-ietf-mip4-gen-ext-04] (13 pages) - Dual Stack Mobile IPv4 [draft-ietf-mip4-dsmipv4-11] (22 pages) - Network Mobility (NEMO) Extensions for Mobile IPv4 [draft-ietf-mip4-nemo-v4-base-12] (30 pages) - Generic Notification Message for Mobile IPv4 [draft-ietf-mip4-generic-notification-message-13] (34 pages) - Dynamic Prefix Allocation for NEMOv4 [draft-ietf-mip4-nemov4-dynamic-03] (10 pages) - FA extensions to NEMOv4 Base [draft-ietf-mip4-nemov4-fa-03] (10 pages) - The Definitions of Managed Objects for Mobile IP UDP Tunneling [draft-ietf-mip4-udptunnel-mib-03] (14 pages) - IPv4 Mobility Extension for Multicast and Broadcast Packets [draft-ietf-mip4-mcbc-00] (13 pages) Requests for Comments: RFC3846: Mobile IPv4 Extension for AAA Network Access Identifiers (10 pages) RFC3957: Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4 (29 pages) RFC4064: Experimental Message, Extension and Error Codes for Mobile IPv4 (12 pages) RFC4093: Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways (19 pages) RFC4433: Mobile IPv4 Dynamic Home Agent Assignment (24 pages) RFC4636: Foreign Agent Error Extension for Mobile IPv4 (6 pages) RFC4721: Mobile IPv4 Challenge/Response Extensions (Revised) (33 pages) RFC4857: Mobile IPv4 Regional Registration (35 pages) RFC4917: Mobile IPv4 Message String Extension (12 pages) RFC4881: Low-Latency Handoffs in Mobile IPv4 (56 pages) RFC5030: Mobile IPv4 RADIUS requirements (10 pages) RFC4988: Mobile IPv4 Fast Handovers (28 pages) RFC5177: Network Mobility (NEMO) Extensions for Mobile IPv4 (30 pages) RFC5265: Mobile IPv4 Traversal across IPsec-Based VPN Gateways (39 pages) RFC5266: Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE) (15 pages) RFC5454: Dual-Stack Mobile IPv4 (22 pages) Multicast Mobility (multimob) ----------------------------- Charter Last Modified: 2009-09-09 Current Status: Active Chairs: Behcet Sarikaya Stig Venaas Behcet Sarikaya Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: multimob@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/multimob Archive: http://www.ietf.org/mail-archive/web/multimob/current/maillist.html Description of Working Group: The Multicast mobility (multimob) working group provides guidance for supporting multicast in a mobile environment. The scope of work will be limited to Proxy Mobile IPv6, IGMPv3/MLDv2 protocols and listener mobility. Work requiring modifications to mobility protocols and IGMPv3/MLDv2 is out of scope in this first stage of this working group. Modifications to multicast routing protocols are out of scope. Specific goals for the group are: - Document how multicast can be supported in a Proxy Mobile IPv6 environment - Document the configuration of IGMPv3/MLDv2 in mobile environments The Proxy Mobile IPv6 (PMIPv6) specification as defined in RFC 5213 does not describe how to support multicast. Some forms of multicast support can, however, be built in the involved nodes by using existing capabilities of multicast protocols and the underlying mobility protocols. The first task of the working group is to document such solutions for PMIPv6. This work will not require any additions or changes to message types and parameters specified in RFC 5213, and must assume an unmodified mobile host. The work will employ the remote subscription model. This is a mechanism by which a mobile node joins a multicast group and receives multicast data forwarded via the local mobility anchor. IGMPv3/MLDv2 has been specified for wired networks with shared links. Mobile nodes have needs that are specific to wireless networks and mobility (e.g. entering a dormant mode to conserve battery power, minimizing the latency for joining and leaving a group in support of movement). The second task of the WG is to assess existing solutions for group management, and determine to what extent these methods are sufficient in a mobile environment. This will include recommending appropriate selection of timer values and protocol parameters. In performing its work, the working group will work closely with both the mobility community (NETLMM and NETEXT WGs) and the multicast community (MBONED WG). The group will consider both source specific multicast and any source multicast multicast models. Future work, subject to rechartering, may study/evaluate extensions to support PMIPv6 optimizations to address the avalanche problem and fast handover and extensions to IGMPv3/MLDv2 to support better operation in mobile environments. Goals and Milestones: Nov 2009 - Initial version of a document explaining the use of multicast in PMIPv6 Nov 2009 - Initial version of a document on how to tune IGMPv3/MLDv2 for mobility Apr 2010 - Submit a document explaining the use of multicast in PMIPv6, for publication as either Informational or Best Current Practice Apr 2010 - Submit a document on how to tune IGMPv3/MLDv2 for mobility, for publication as either Informational or Best Current Practice Jun 2010 - Decision to include additional optimization work involving extensions to PMIPv6 Jun 2010 - Decision to include additional optimization work involving extensions to IGMPv3 or MLDv2 Jun 2010 - Recharter based on the above decisions (or close the group if no new work is needed) Internet-Drafts: No Requests for Comments Multiple Interfaces (mif) ------------------------- Charter Last Modified: 2009-10-19 Current Status: Active Chairs: Margaret Wasserman Hui Deng Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: mif@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mif Archive: http://www.ietf.org/mail-archive/web/mif Description of Working Group: Many hosts have the ability to attach to multiple networks simultaneously. This can happen over multiple physical network interfaces, a combination of physical and virtual interfaces (VPNs or tunnels), or even indirectly through multiple default routers being on the same link. For instance, current laptops and smartphones typically have multiple access network interfaces. A host attached to multiple networks has to make decisions about default router selection, address selection, DNS server selection, choice of interface for packet transmission, and the treatment of configuration information received from the various networks. Some configuration objects are global to the node, some are local to the interface, and some are related to a particular prefix. Various issues arise when contradictory configuration objects that are global to the node are received on different interfaces. At best, decisions about these matters have an efficiency effect. At worst, they have more significant effects such as security impacts, or even lead to communication not being possible at all. A number of operating systems have implemented various techniques to deal with attachments to multiple networks. Some devices employ only one interface at a time and some allow per-host configuration of preferences between the interfaces but still use just one at a time. Other systems allow per-application preferences or implement sophisticated policy managers that can be configured by users or controlled externally. The purpose of the MIF working group is to describe the issues of attaching to multiple networks on hosts and document existing practice. The group shall also analyze the impacts and effectiveness of these existing mechanisms. The WG shall employ and refer to existing IETF work in this area, including, for instance, strong/weak models (RFC 1122), address selection (RFC 3484), ICE and other mechanisms higher layers can use for address selection, DHCP mechanisms, Router Advertisement mechanisms, and DNS recommendations. The focus of the working group should be on documenting the system level effects to host IP stacks and identification of gaps between the existing IETF recommendations and existing practice. The working group shall address both IPv4 and IPv6 as well as stateless and stateful configuration. Network discovery and selection on lower layers as defined by RFC 5113 is out of scope. Also, the group shall not develop new protocol or policy mechanisms; recommendations and gap analysis from the group are solely based on existing solutions. The group shall not assume any software beyond basic IP protocol support on its peers or in network nodes. No work will be done to enable traffic flows to move from one interface to another. The group recognizes existing work on mechanisms that require peer or network support for moving traffic flows such as RFC 5206, RFC 4980 and the use of multiple care-of addresses in Mobile IPv6. This group does not work on or impact such mechanisms. Once the group has completed its work items, the IETF can make an informed decision about rechartering the working group to define new mechanisms or asking other, specialized working groups (such as DHC or 6MAN) to deal with specific issues. Goals and Milestones: Done - WG chartered Done - Initial draft on problem statement adopted by the WG Done - Initial draft on existing practices adopted by the WG Dec 2009 - Initial draft on analysis of existing practices adopted by the WG Mar 2010 - Problem statement draft submitted to the IESG for publication as an Informational RFC Jul 2010 - Existing practices draft submitted to the IESG for publication as an Informational RFC Sep 2010 - Analysis draft submitted to the IESG for publication as an Informational RFC Oct 2010 - Recharter or close Internet-Drafts: - Multiple Interfaces Problem Statement [draft-ietf-mif-problem-statement-01] (13 pages) - Current Practices for Multiple Interface Hosts [draft-ietf-mif-current-practices-00] (16 pages) No Requests for Comments Network Time Protocol (ntp) --------------------------- Charter Last Modified: 2009-08-04 Current Status: Active Chairs: Karen O'Donoghue Brian Haberman Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion: ntpwg@lists.ntp.isc.org To Subscribe: https://lists.ntp.isc.org/mailman/listinfo/ntpwg Archive: http://lists.ntp.isc.org/pipermail/ntpwg Description of Working Group: The Network Time Protocol (NTP) is widely deployed and used in the Internet. However, the standardization status of this protocol has lagged in the IETF. RFC 1305 (NTP version 3) was published in March 1992 and remains unchanged and at Draft Standard status. RFC 1305 represents the majority of full NTP implementations deployed today. RFC 2030 (SNTP version 4) was published as an Informational RFC in October 1996 as a lightweight version of NTP for deployments not requiring the full functionality of NTP. SNTP now represents the majority of both NTP traffic and NTP implementation issues on the Internet. A good deal of work has been produced in the NTP community updating both NTPv3 and SNTPv4. This work is ongoing and available through the collaborative development effort in the NTP community, but it has not been reflected back into the NTP specifications. The goal of this working group is to document NTPv4 based on the extensive work of the NTP community and to advance the standardization status of NTP. It is an explicit goal of this effort to have NTPv4 interoperate with the deployed base avoiding any backwards-incompatible changes. A number of topics have been raised as potential work items for an update to NTP including support for IPv6, security considerations including authentication, automatic configuration including possible requirements for DHCP, and algorithm improvements. This working group will focus first on delivering NTPv4 and will defer additional development efforts until after the delivery of NTPv4. Support for IPv6 and defining mechanisms for securing NTP transactions is considered part of the core NTPv4 functionality. Potential further modifications and additions to the NTP protocol will be documented for possible further work beyond the initial NTPv4 effort. The working group will initially focus on the following deliverables: 1. NTPv4 Scope and Requirements Document (documenting the scope of the NTPv4 update and identifying issues deferred for future work). 2. NTPv4 Protocol Specification (documenting the protocol on the wire) 3. NTPv4 Architecture and Algorithms Specification (documenting the architecture, mathematical algorithms, and behavior of NTP servers and clients) 4. NTPv4 MIB (provision for management and monitoring of NTP via SNMP) Goals and Milestones: Done - NTP BOF at IETF 61 Done - NTP WG Charter Approved Done - Draft of Scope and Requirements Document Done - Draft of NTP Protocol Specification Done - Draft of MIB Specification Done - Draft of NTP Algorithms Specification Done - Draft of NTP Autokey Specification - Informational RFC Dec 2007 - WG Last Call NTP Protocol Specification Dec 2007 - WG Last Call NTP MIB Specification Dec 2007 - Draft of NTP Control Protocol - Informational RFC Mar 2008 - WG Last Call NTP Autokey Specification - Informational RFC Mar 2008 - WG Last Call NTP Control Protocol - Informational RFC Internet-Drafts: - Network Time Protocol Version 4 Protocol And Algorithms Specification [draft-ietf-ntp-ntpv4-proto-13] (112 pages) - Requirements for Network Time Protocol Version 4 [draft-ietf-ntp-reqs-01] (16 pages) - The Network Time Protocol Version 4 Algorithm Specification [draft-ietf-ntp-ntpv4-algorithms-01] (25 pages) - Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4) [draft-ietf-ntp-ntpv4-mib-06] (27 pages) - Network Time Protocol Version 4 Autokey Specification [draft-ietf-ntp-autokey-07] (53 pages) - Network Time Protocol (NTP) Server Option for DHCPv6 [draft-ietf-ntp-dhcpv6-ntp-opt-06] (10 pages) No Requests for Comments Network-Based Mobility Extensions (netext) ------------------------------------------ Charter Last Modified: 2010-02-09 Current Status: Active Chairs: Basavaraj Patil Rajeev Koodli Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: netext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netext Archive: http://www.ietf.org/mail-archive/web/netext/current/maillist.html Description of Working Group: Proxy Mobile IPv6, specified in RFC 5213, is a network-based mobility protocol. It uses a Mobile Access Gateway (MAG) and a Local Mobility Anchor (LMA) to allow hosts to move around within a domain while keeping their address or address prefix stable. Proxy Mobile IPv6 has been incorporated into a number of products and deployments are starting. Certain deployment considerations, including localized routing and bulk refresh of lifetime are already emerging. The working group will focus on the following topics relevant for network-based mobility: Localized Routing: a specification for routing traffic between the MAG(s) without involving the LMA. That is, allow the MAGs to route traffic between hosts from one MAG to another, without being tunneled all the way to the LMA. This reduces latency and backhaul load. Applications such as voice can benefit from the reduced latency. The working group will produce a problem statement and a specification of the localized routing mechanism. Bulk Refresh: a specification of improving the signaling load for binding lifetime refresh. The current specifications call for the handling of each mobility session independent of each other. When a large number of hosts are served by a single MAG, a periodic refresh of the binding lifetimes can lead to a signaling storm. The purpose of the Bulk Refresh feature is to construct a protocol feature that allows such refreshes to occur on a per-MAG basis. LMA Redirection: a specification for allowing an LMA to redirect a MAG to another LMA. This is primarily needed as a way to perform load balancing. This functionality is complementary to implementation techniques that allow distributed MAG implementations to move tasks around without a visible impact at the protocol level, and the initial LMA discovery work in the NETLMM WG. An applicability statement describing the situations where the new functionality is or is not applicable has to be included in the specification. Hiding access technology changes from host IP layer: Proxy mobility is based on the assumption that changes in host IP stacks are undesirable. However, link layer implementations can hide the actually used physical interfaces from the IP stack. For instance, a "logical interface" at the IP layer may enable packet transmission and reception over different physical media. Such techniques can be used to achieve inter-access handovers or flow mobility, i.e., the movement of selected flows from one access technology to another. It is assumed that an IP layer interface can simultaneously and/or sequentially attach to multiple MAGs (possibly over multiple media). The hiding mechanisms also need to work together with existing RFC 5213 handover hint mechanisms. The specification of any actual link layer mechanisms is outside the scope of the working group, but the group works on the following: - Informational applicability statement that analyzes the issues involved with this approach and characterizes the contexts in which such use is or is not appropriate. - The working group will determine what protocol extensions are required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to support the ability for an interface (at the IP layer) to transmit packets over different media, the ability to distribute specific traffic flows on different media components of that interface, and making this work with the handover hints in the base protocol. The relevant protocol extensions will be developed as necessary. Radius Extensions to PMIP6: In order to enable network based mobility using PMIP6, the policy profile needs to signal a set of attributes and policies to the MAG and LMA. New Radius attributes need to be specified that are relevant to PMIP6 based mobility. This work item will specify Radius extensions and attributes specific to PMIP6. The work in this charter is entirely internal to the network and does not affect host IP stack operation in any way (except perhaps through impacting packet forwarding capacity visible to the hosts). The working group is not allowed to specify new IP layer protocol mechanisms to signal mobility related events between the host and the network. The proposed activity will be complementary to the existing IETF Working Groups, notably the NETLMM and MEXT WGs. The NETEXT working group will also act as the primary forum where new extensions on top of the Proxy Mobile IPv6 protocol can be developed. The addition of such new extensions to the working group involves addition of the extension to this charter through the normal rechartering process. Goals and Milestones: Done - WG chartered Done - Initial WG draft on Bulk Refresh Done - Decision on the inclusion of possible additional work items Done - Initial WG draft on LMA Redirection Done - Initial WG draft on Localized Routing Problem Statement Mar 2010 - Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC Mar 2010 - Submit LMA Redirection to IESG for publication as a Proposed Standard RFC Mar 2010 - Initial WG document on RADIUS extensions to PMIP6 May 2010 - Submit Localized Routing Problem Statement to IESG for publication as an Informational RFC May 2010 - Initial WG draft on Localized Routing Solution Jul 2010 - Initial WG document on Applicability Statement on Logical Interface over Multiple Physical Interfaces Jul 2010 - WG decision on what Proxy Mobile IPv6 mechanisms are needed to support flow mobility and inter-access handovers on a logical interface over multiple physical interfaces Oct 2010 - Initial WG document(s) on Proxy Mobile IPv6 Extensions to Support Flow Mobility and Inter-access Handovers on a Logical Interface over Multiple Physical Interfaces Dec 2010 - Submit RADIUS extensions to PMIP6 to IESG for publication as a Proposed Standard Dec 2010 - Submit Applicability Statement on Logical Interface over Multiple Physical Interfaces to IESG for publication as Informational RFC Feb 2011 - Submit Proxy Mobile IPv6 Extensions to Support Flow Mobility and Inter-access Handovers on a Logical Interface over Multiple Physical Interfaces for publication as Proposed Standard RFC(s) Feb 2011 - Submit Localized Routing Solution to IESG for publication as a Proposed Standard RFC Internet-Drafts: - PMIPv6 Localized Routing Problem Statement [draft-ietf-netext-pmip6-lr-ps-02] (17 pages) - Bulk Re-registration for Proxy Mobile IPv6 [draft-ietf-netext-bulk-re-registration-00] (16 pages) - Runtime LMA Assignment Support for Proxy Mobile IPv6 [draft-ietf-netext-redirect-00] (24 pages) No Requests for Comments Network-based Localized Mobility Management (netlmm) ---------------------------------------------------- Charter Last Modified: 2008-12-16 Current Status: Active Chairs: Jonne Soininen Vidya Narayanan Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: netlmm@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/netlmm Archive: http://www.ietf.org/mail-archive/web/netlmm Description of Working Group: The IETF has defined both local and global mobility management protocols that are intended to handle IP mobility for nodes. All IP mobility management protocols defined thus far require the involvement of the mobile node in order to accomplish mobility. This working group is tasked with defining a network-based local mobility management protocol, where local IP mobility is handled without involvement from the mobile node. The idea is that the mobile node may move across multiple access routers without encountering a change in its IP address, thereby hiding the mobility from the IP layer and above. As part of the first phase of efforts in this working group, a protocol for such network-based local mobility has been developed. This protocol, Proxy Mobile IPv6 (PMIPv6), has been developed based on Mobile IPv6, after considering other alternative approaches. With this protocol, unmodified IP nodes may change access routers without having to change the IP address on an interface, within a given administrative domain. This is accomplished by having Mobile Access Gateways (MAGs), often part of the access routers in a network, send binding updates on behalf of mobile nodes attached to them, to a Local Mobility Anchor (LMA). The LMA manages the mobility of the mobile nodes across the MAGs within a given PMIPv6 domain. The PMIPv6 protocol is being adopted as part of several wide-area wireless network (e.g., 3GPP, 3GPP2, WiMAX) and local area network environments. The current charter of this working group involves specification of some necessary features that make the deployment of this protocol feasible in these various environments. As part of this effort, it is essential to support mobility for IPv4 end nodes. Some means of dealing with overlapping private IPv4 addresses of mobile nodes and supporting separation of flows between the MAG and LMA is also required. Further, given that local and global mobility management protocols are likely to be deployed in some combination in various environments, it is necessary to clearly define the interactions between PMIPv6 and MIPv6. Interactions with AAA protocols such as RADIUS and Diameter may be required for authorization or provisioning purposes. When multiple LMAs are present, an automated LMA discovery mechanism may be needed to facilitate deployment. The above items are in scope of the current charter. The MAG and LMA are considered to be IPv6 capable for all efforts of this protocol. Also, all features defined must work with unmodified IP nodes. Specifying any changes to mobile nodes is out of scope of the current charter. Handoff and route optimizations are also out of scope. There is, however, considerable interest in optimization work, for instance, and a future recharter of this working group is likely to address this in some manner. NETLMM WG Deliverables ---------------------- 1) Interface between a PMIPv6 MAG and MN: This interface will define the interaction between a regular IP node and a MAG that will be used to trigger various mobility management actions on the MAG. This is necessary for the MAG to properly trigger binding updates to the LMA and create appropriate mobility management state. 2) IPv4 Support for PMIPv6: This will define the support for IPv4 nodes in PMIPv6. This will also define the protocol operation over an IPv4 transport between the MAG and LMA, by employing protocol extensions already developed in the MEXT WG. 3) Interactions between Mobile IPv6 and Proxy Mobile IPv6: This will highlight the interactions required between these protocols in various methods of co-existence of these in a system, with a view to documenting the best practices to be used. The scenarios considered will include a hierarchical model of local and global mobility management using PMIPv6 and MIPv6 respectively, a mixed mode of the two with some nodes supporting MIPv6 and others not, and the use of MIPv6 upon movement of nodes outside a PMIPv6 domain. 4) GRE Keying option for PMIPv6: This will define a mechanism using GRE keys to support separation of flows between a MAG and LMA. 5) RADIUS support for PMIPv6: This will define the interactions between RADIUS and PMIPv6 to support policy provisioning and authorization. 6) Automatic LMA discovery: This will define the ability for MAGs to automatically discover and use an LMA within a PMIPv6 domain. The scope of this effort may include specifying the use of DNS or DHCP based LMA discovery or LMA discovery using policy information retrieved via AAA protocols. 7) MIB for PMIPv6: This will define the MIB for the protocol for interoperability purposes. 8) PMIPv6 path management and failure detection: This will define an extension to the PMIPv6 protocol allowing PMIPv6 peers to verify bidirectional reachability with their peer, detect failure of their peer, and signal their own failure to their peer. Goals and Milestones: Done - Charter Working Group Done - Working Group Last Call on Problem Statement and Requirements documents Done - Discuss Last Call comments on Problem Statement and Requirements documents Done - Submit Problem Statement and Requirements documents to IESG for publication as Informational RFCs Done - Working Group Last Call on Threat Model documents. Submit Threat Model document to SAAG for review Done - Working Group Last Call on Threat Model document Done - IETF 66, Discuss Last Call comments on Threat Model document Done - Submit Threat Model document to IESG for publication as an Informational RFC Done - Main protocol decision completed Done - Initial version of the Protocol draft submitted Done - Working Group Last Call on Mobile Node to Access Router document Aug 2008 - Initial version of the PMIP6-MIP6 Interactions document Aug 2008 - Working Group Last Call on the IPv4 support document Aug 2008 - Initial version of GRE keying document Aug 2008 - Working Group Last Call on MAG-MN Interface document Oct 2008 - Initial version of RADIUS support document Oct 2008 - Submit IPv4 support and MAG-MN Interface documents for AD review Oct 2008 - Initial version of path management document Nov 2008 - Working Group Last Call on the PMIP6-MIP6 Interactions document Nov 2008 - Working Group Last Call on GRE Keying document Nov 2008 - Initial version of LMA Discovery document Nov 2008 - Initial version of the MIB document Dec 2008 - Working Group Last Call on path management document Jan 2009 - Submit PMIP6-MIP6 Interactions document for AD review Jan 2009 - Submit GRE Keying document for AD review Jan 2009 - Working Group Last Call on RADIUS support document Jan 2009 - Submit path management document for AD review Mar 2009 - Submit RADIUS support document for AD review Mar 2009 - Working Group Last Call on LMA Discovery document Mar 2009 - Working Group Last Call on the MIB document May 2009 - Submit LMA Discovery document for AD review May 2009 - Submit the MIB document for AD review Jul 2009 - Re-charter Internet-Drafts: - Goals for Network-based Localized Mobility Management (NETLMM) [draft-ietf-netlmm-nohost-req-06] (13 pages) - Problem Statement for Network-based Localized Mobility Management [draft-ietf-netlmm-nohost-ps-06] (12 pages) - Security Threats to Network-Based Localized Mobility Management [draft-ietf-netlmm-threats-05] (18 pages) - Interface between a Proxy MIPv6 Mobility Access Gateway and a Mobile Node [draft-ietf-netlmm-mn-ar-if-03] (25 pages) - Proxy Mobile IPv6 [draft-ietf-netlmm-proxymip6-19] (91 pages) - IPv4 Support for Proxy Mobile IPv6 [draft-ietf-netlmm-pmip6-ipv4-support-17] (62 pages) - GRE Key Option for Proxy Mobile IPv6 [draft-ietf-netlmm-grekey-option-09] (24 pages) - Heartbeat Mechanism for Proxy Mobile IPv6 [draft-ietf-netlmm-pmipv6-heartbeat-07] (12 pages) - Interactions between PMIPv6 and MIPv6: scenarios and related issues [draft-ietf-netlmm-mip-interactions-04] (20 pages) - LMA Discovery for Proxy Mobile IPv6 [draft-ietf-netlmm-lma-discovery-02] (10 pages) - Proxy Mobile IPv6 Management Information Base [draft-ietf-netlmm-pmipv6-mib-02] (63 pages) Requests for Comments: RFC4832: Security Threats to Network-Based Localized Mobility Management (NETLMM) (18 pages) RFC4831: Goals for Network-based Localized Mobility Management (NETLMM) (13 pages) RFC4830: Problem Statement for Network-based Localized Mobility Management (NETLMM) (12 pages) RFC5213: Proxy Mobile IPv6 (92 pages) Point-to-Point Protocol Extensions (pppext) ------------------------------------------- Charter Last Modified: 2009-06-09 Current Status: Active Chair: James Carlson Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: pppext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/pppext Archive: http://www.ietf.org/mail-archive/web/pppext/index.html Description of Working Group: The Point-to-Point Protocol (PPP, RFC 1661) is a mature protocol with a large number of subprotocols, encapsulations and other extensions. The PPPEXT working group exists to provide a forum for asking clarifications about the existing specifications and to defend against enhancements of questionable value. The group is not expected to create new specifications, and if a need for such work comes up, a recharter is required. The group may, however, advance existing specifications to the next level in the standards track, if a need for that comes up. Similarly, the group may classify existing specifications as Historic where this is appropriate. Goals and Milestones: Done - Advance SDL draft to Experimental Done - Add VLAN support to BCP (RFC 1638) and recycle at Proposed Standard Internet-Drafts: - The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol [draft-ietf-pppext-bridgemib-04] (23 pages) - Point-to-Point Protocol Extensions for Bridging [draft-ietf-pppext-bridging-02] (0 pages) - The Point-to-Point Protocol Configuration Options: Negotiation of 32-bit FCS [draft-ietf-ppp-32bitconfig-01] (0 pages) - The Point-to-Point Protocol: LLC over PPP [draft-ietf-ppp-llcoverppp-01] (0 pages) - The PPP DECnet Phase IV Control Protocol (DNCP) [draft-ietf-pppext-decnet-04] (8 pages) - The Point-to-Point Protocol for the Transmission of Multi-Protocol Datagrams Over Point-to-Point Links [draft-ietf-pppext-lcp-03] (68 pages) - The PPP Internet Protocol Control Protocol (IPCP) [draft-ietf-pppext-ipcp-03] (13 pages) - The PPP AppleTalk Control Protocol (ATCP)) [draft-ietf-pppext-appletalk-04] (20 pages) - The PPP OSI Network Layer Control Protocol (OSINLCP) [draft-ietf-pppext-osinlcp-03] (12 pages) - PPP Authentication Protocols [draft-ietf-pppext-authentication-07] (20 pages) - PPP Link Quality Monitoring [draft-ietf-pppext-lqm-02] (16 pages) - The PPP Internetwork Packet Exchange Control Protocol (IPXCP) [draft-ietf-pppext-ipxcp-05] (19 pages) - The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol [draft-ietf-pppext-ipcpmib-05] (18 pages) - The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol [draft-ietf-pppext-lcpmib-04] (34 pages) - The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol [draft-ietf-pppext-secmib-04] (21 pages) - Compressing IPX Headers Over WAN Media (CIPX) [draft-ietf-pppext-cipx-05] (27 pages) - PPP LCP Extensions [draft-ietf-pppext-lcpext-05] (22 pages) - PPP over ISDN [draft-ietf-pppext-isdn-04] (7 pages) - PPP in Frame Relay [draft-ietf-pppext-frame-relay-04] (8 pages) - PPP over SONET/SDH [draft-ietf-pppext-sonet-02] (5 pages) - PPP in X.25 [draft-ietf-pppext-x25-03] (7 pages) - PPP in HDLC Framing [draft-ietf-pppext-hdlc-framing-03] (20 pages) - The Point-to-Point Protocol (PPP) [draft-ietf-pppext-lcp-main-03] (62 pages) - PPP Bridging Control Protocol (BCP) [draft-ietf-pppext-for-bridging-05] (31 pages) - The PPP Multilink Protocol (MP) [draft-ietf-pppext-multilink-13] (25 pages) - Requirements for an Internet Standard Point-to-Point Protocol [draft-ietf-pppext-requirements-02] (21 pages) - The PPP NetBIOS Frames Control Protocol (NBFCP) [draft-ietf-pppext-netbios-fcp-08] (14 pages) - PPP Reliable Transmission [draft-ietf-pppext-reliable-01] (10 pages) - PPP Predictor Compression Protocol [draft-ietf-pppext-predictor-01] (9 pages) - PPP Stac LZS Compression Protocol [draft-ietf-pppext-stacker-11] (18 pages) - The PPP Compression Control Protocol (CCP) [draft-ietf-pppext-compression-05] (12 pages) - PPP Gandalf FZA Compression Protocol [draft-ietf-pppext-gandalf-01] (6 pages) - PPP Hewlett-Packard Packet-by-Packet Compression (HP PPC) Protocol [draft-ietf-pppext-hpppc-00] (5 pages) - PPP BSD Compression Protocol [draft-ietf-pppext-bsd-compress-06] (27 pages) - PPP LCP Option for Data Encapsulation Selection [draft-ietf-pppext-dataencap-03] (6 pages) - PPP in HDLC-like Framing [draft-ietf-pppext-hdlc-fs-03] (25 pages) - The Point-to-Point Protocol (PPP) [draft-ietf-pppext-lcp-fs-03] (52 pages) - The Generic Athentication Protocol (GAP) [draft-ietf-pppext-gap-auth-00] (8 pages) - The Arbitrary Handshake Authentication (AHA) protocol [draft-ietf-pppext-aha-auth-00] (16 pages) - PPP Magnalink Variable Resource Compression [draft-ietf-pppext-magnalink-02] (6 pages) - PPP Kerberos Authentication Protocol (KAP) [draft-ietf-pppext-kap-auth-00] (15 pages) - Proposal for Callback Control Protocol (CBCP). [draft-ietf-pppext-callback-cp-02] (9 pages) - PPP Serial Data Transport Protocol (SDTP) [draft-ietf-pppext-sdtp-01] (19 pages) - The PPP AppleTalk Control Protocol (ATCP) [draft-ietf-pppext-atcp2-00] (21 pages) - The PPP Banyan Vines Control Protocol (BVCP) [draft-ietf-pppext-vines-02] (10 pages) - PPP Kerberos version 4 Authentication Protocol (KAPv4) [draft-ietf-pppext-kapv4-auth-00] (19 pages) - The PPP XNS IDP Control Protocol (XNSCP) [draft-ietf-pppext-xnscp-01] (5 pages) - The PPP Encryption Control Protocol (ECP) [draft-ietf-pppext-encryption-05] (11 pages) - PPP LZS-DCP Compression Protocol (LZS-DCP) [draft-ietf-pppext-lzs-dcp-02] (15 pages) - PPP for Data Compression in Data Circuit-Terminating Equipment (DCE) [draft-ietf-pppext-dce-compress-01] (9 pages) - The PPP DECnet Phase IV Control Protocol (DNCP) [draft-ietf-pppext-dncp-01] (7 pages) - The PPP Internet Protocol Control Protocol (IPCP) [draft-ietf-pppext-ipcp-network-04] (13 pages) - PPP Extensible Authentication Protocol (EAP) [draft-ietf-pppext-eap-auth-03] (18 pages) - PPP Public Key Encryption Based Authentication [draft-ietf-pppext-public-key-00] (10 pages) - The PPP DES Encryption Protocol (DESE) [draft-ietf-pppext-des-encrypt-02] (10 pages) - PPP Deflate Protocol [draft-ietf-pppext-deflate-01] (11 pages) - PPP WAN Compression Protocol [draft-ietf-pppext-wcp-00] (20 pages) - PPP EAP RSA Public Key Authentication Protocol [draft-ietf-pppext-eaprsa-07] (14 pages) - PPP Challenge Handshake Authentication Protocol (CHAP) [draft-ietf-pppext-chap-ds-01] (14 pages) - PPP Link Quality Monitoring [draft-ietf-pppext-lqm-ds-01] (15 pages) - The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP) [draft-ietf-pppext-bacp-06] (22 pages) - The PPP SNA Control Protocol (SNACP) [draft-ietf-pppext-snacp-02] (8 pages) - PPP Protocol Spoofing Control Protocol (PSCP) [draft-ietf-pppext-spoof-00] (26 pages) - PPP LCP Extensions [draft-ietf-pppext-lcpext-ds-03] (7 pages) - PPP Vendor Extensions [draft-ietf-pppext-vendor-01] (6 pages) - Point-to-Point Tunneling Protocol (PPTP) [draft-ietf-pppext-pptp-11] (57 pages) - Microsoft Point-To-Point Compression (MPPC) Protocol [draft-ietf-pppext-mppc-01] (9 pages) - Layer Two Tunneling Protocol 'L2TP' [draft-ietf-pppext-l2tp-17] (75 pages) - Proposal for LCP Authentication Option [draft-ietf-pppext-linknegot-00] (7 pages) - Proposal for LCP Authentication Option [draft-ietf-pppext-link-negot-00] (7 pages) - Mobile-IPv4 Configuration Option for PPP IPCP [draft-ietf-pppext-ipcp-mip-03] (18 pages) - Semi Connected Mode for PPP links [draft-ietf-pppext-scm-01] (20 pages) - Proposal for a PPP Network Layer Entity Selection Protocol [draft-ietf-pppext-nles-00] (7 pages) - PPP over AAL5 [draft-ietf-pppext-aal5-06] (11 pages) - Layer Two Tunneling Protocol (L2TP) over AAL5 and FUNI [draft-ietf-pppext-l2tp-aal5-funi-00] (7 pages) - PPP LCP CallBack [draft-ietf-pppext-callback-ds-02] (7 pages) - IP Header Compression over PPP [draft-engan-ip-compress-03] (9 pages) - Layer Two Tunneling Protocol 'L2TP' Security Extensions for Non-IP networks [draft-ietf-pppext-l2tp-sec-04] (13 pages) - The PPP DES Encryption Protocol, Version 2 (DESE-bis) [draft-ietf-pppext-des-encrypt-v2-03] (11 pages) - The PPP Triple-DES Encryption Protocol (3DESE) [draft-ietf-pppext-3des-encrypt-01] (8 pages) - PPP LCP Self Describing Padding [draft-ietf-pppext-padding-ds-01] (6 pages) - PPP Over FUNI [draft-ietf-pppext-funi-06] (10 pages) - PPP EAP TLS Authentication Protocol [draft-ietf-pppext-eaptls-07] (25 pages) - PPP over SONET/SDH [draft-ietf-pppext-pppsonet-scrambler-00] (14 pages) - L2TP Header Compression (''L2TPHC'') [draft-ietf-pppext-l2tphc-01] (6 pages) - Multi-link Multi-node PPP [draft-ietf-pppext-mmp-discovery-03] (8 pages) - PPP over SONET/SDH [draft-ietf-pppext-sonet-ds-01] (12 pages) - PPP Consistent Overhead Byte Stuffing (COBS) [draft-ietf-pppext-cobs-00] (27 pages) - PPP EAP ISAKMP Authentication Protocol [draft-ietf-pppext-eapisakmp-00] (19 pages) - PPP EAP KEA Public Key Authentication Protocol [draft-ietf-pppext-eapkea-01] (18 pages) - PPP Fortezza Encryption Encapsulation Protocol [draft-ietf-pppext-feep-01] (12 pages) - PPP EAP DSS Public Key Authentication Protocol [draft-ietf-pppext-eapdss-01] (13 pages) - PPP Certificate Exchange Protocol [draft-ietf-pppext-crtxchg-01] (16 pages) - PPP with Framing Conversion [draft-ietf-pppext-conversion-01] (4 pages) - PPP in Frame Relay [draft-ietf-pppext-framerelay-ds-01] (8 pages) - PPP in X.25 [draft-ietf-pppext-x25-ds-01] (8 pages) - L2TP-over-IP Path MTU Discovery (''L2TPMTU'') [draft-ietf-pppext-l2tpmtu-00] (26 pages) - L2TP Alternate Data Channel (``L2TPADC'') [draft-ietf-pppext-l2tpadc-00] (3 pages) - Microsoft PPP CHAP Extensions [draft-ietf-pppext-mschap-01] (19 pages) - Microsoft Point-To-Point Encryption (MPPE) Protocol [draft-ietf-pppext-mppe-05] (12 pages) - PPP LCP Internationalization Configuration Option [draft-ietf-pppext-lcp-charset-08] (5 pages) - PPP Link Balancing Detection (LBD) [draft-ietf-pppext-lbd-03] (5 pages) - L2TP Dynamic Data Window Adjustment [draft-ietf-pppext-l2tpdwin-01] (7 pages) - Applicability Statement for PPP over SONET/SDH [draft-ietf-pppext-sonet-as-00] (21 pages) - PPP in Ether-like Framing [draft-ietf-pppext-ether-00] (6 pages) - Deriving MPPE Keys From MS-CHAP V1 Credentials [draft-ietf-pppext-mschapv1-keys-00] (7 pages) - Microsoft PPP CHAP Extensions, Version 2 [draft-ietf-pppext-mschap-v2-05] (21 pages) - Deriving MPPE Keys From MS-CHAP V2 Credentials [draft-ietf-pppext-mschapv2-keys-02] (10 pages) - PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing [draft-ietf-pppext-sdl-06] (29 pages) - Framework for L2TP Message Extensions [draft-ietf-pppext-l2tpmsgext-00] (5 pages) - Mobile PPP (MPPP) [draft-ietf-pppext-mppp-01] (15 pages) - Always On Dynamic ISDN (AODI). [draft-ietf-pppext-aodi-03] (15 pages) - L2TP Link Extensions [draft-ietf-pppext-l2tp-link-00] (6 pages) - PPP over SONET/SDH [draft-ietf-pppext-pppoversonet-update-05] (9 pages) - Derivating Keys for use with Microsoft Point-to-Point Encryption (MPPE) [draft-ietf-pppext-mppe-keys-03] (20 pages) - PPP over Simple Data Link (SDL) using raw lightwave channels with ATM-like framing [draft-ietf-pppext-sdl-pol-00] (25 pages) - Extending PPP over SONET/SDH, with virtual concatenation, high order and low order payloads [draft-ietf-pppext-posvcholo-06] (8 pages) - QoS Mapping Extensions to Multilink PPP [draft-ietf-pppext-mp-qos-00] (13 pages) - Secure Remote Access with L2TP [draft-ietf-pppext-secure-ra-00] (18 pages) - PPP Bridging Control Protocol (BCP) [draft-ietf-pppext-bcp-05] (38 pages) - PPP Multiplexed [draft-ietf-pppext-pppmux-03] (8 pages) - PPP EAP SRP-SHA1 Authentication Protocol [draft-ietf-pppext-eap-srp-03] (25 pages) - PPP over ATM Adaptation Layer 2 [draft-ietf-pppext-ppp-over-aal2-03] (0 pages) - Class Extensions for PPP over ATM Adaptation Layer 2 [draft-ietf-pppext-ppp-over-aal2-class-03] (0 pages) - EAP Tunneled TLS Authentication Protocol (EAP-TTLS) [draft-ietf-pppext-eap-ttls-05] (52 pages) - The One Time Password (OTP) and Generic Token Card Authentication Protocols [draft-ietf-pppext-otp-00] (12 pages) - Extensible Authentication Protocol (EAP) [draft-ietf-pppext-rfc2284bis-10] (40 pages) - PPP Bridging Control Protocol (BCP) [draft-ietf-pppext-rfc2878bis-01] (38 pages) - PPP IPV6 Control Protocol Extensions for DNS Server Addresses [draft-ietf-pppext-ipv6-dns-addr-03] (7 pages) - IANA Considerations for the Point-to-Point Protocol (PPP) [draft-schryver-pppext-iana-02] (4 pages) - PPP Vendor Protocol [draft-ietf-pppext-vendor-protocol-03] (11 pages) - Accommodating an MTU of 1500 in PPPoE [draft-ietf-pppext-pppoe-mtu-1500-00] (0 pages) - Accommodating an MTU/MRU greater than 1492 in PPPoE [draft-arberg-pppoe-mtu-gt1492-04] (10 pages) - PPP TRILL Protocol Control Protocol [draft-ietf-pppext-trill-protocol-00] (6 pages) Requests for Comments: RFC1762: The PPP DECnet Phase IV Control Protocol (DNCP) (7 pages) * Obsoletes RFC1376 RFC1990: The PPP Multilink Protocol (MP) (24 pages) * Obsoletes RFC1717 RFC1989: PPP Link Quality Monitoring (16 pages) * Obsoletes RFC1333 RFC1549: PPP in HDLC Framing (20 pages) * OBSOLETED BY RFC1662 RFC1994: PPP Challenge Handshake Authentication Protocol (CHAP) (12 pages) * Obsoletes RFC1334 * Updated by RFC2484 RFC1548: The Point-to-Point Protocol (PPP) (62 pages) * Obsoletes RFC1331 * Updated by RFC1570 * OBSOLETED BY RFC1661 RFC1547: Requirements for an Internet Standard Point-to-Point Protocol (21 pages) RFC1979: PPP Deflate Protocol (10 pages) RFC1963: PPP Serial Data Transport Protocol (SDTP) (20 pages) RFC1976: PPP for Data Compression in Data Circuit-Terminating Equipment (DCE) (10 pages) RFC1967: PPP LZS-DCP Compression Protocol (LZS-DCP) (18 pages) RFC1975: PPP Magnalink Variable Resource Compression (6 pages) RFC1977: PPP BSD Compression Protocol (27 pages) RFC1969: The PPP DES Encryption Protocol (DESE) (10 pages) * OBSOLETED BY RFC2419 RFC1974: PPP Stac LZS Compression Protocol (20 pages) RFC1978: PPP Predictor Compression Protocol (9 pages) RFC2118: Microsoft Point-To-Point Compression (MPPC) Protocol (9 pages) * Updated by RFC3078 RFC2153: PPP Vendor Extensions (6 pages) * Updates RFC1962 * Updates RFC1661 * Updated by RFC5342 RFC1993: PPP Gandalf FZA Compression Protocol (6 pages) RFC1763: The PPP Banyan Vines Control Protocol (BVCP) (10 pages) RFC1717: The PPP Multilink Protocol (MP) (21 pages) * OBSOLETED BY RFC1990 RFC1764: The PPP XNS IDP Control Protocol (XNSCP) (5 pages) RFC2125: The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP) (24 pages) RFC1962: The PPP Compression Control Protocol (CCP) (9 pages) * Updated by RFC2153 RFC1968: The PPP Encryption Control Protocol (ECP) (11 pages) RFC1973: PPP in Frame Relay (8 pages) RFC2097: The PPP NetBIOS Frames Control Protocol (NBFCP) (13 pages) RFC2043: The PPP SNA Control Protocol (SNACP) (7 pages) RFC1334: PPP Authentication Protocols (16 pages) * OBSOLETED BY RFC1994 RFC1376: The PPP DECnet Phase IV Control Protocol (DNCP) (6 pages) * OBSOLETED BY RFC1762 RFC1333: PPP Link Quality Monitoring (17 pages) * OBSOLETED BY RFC1989 RFC1332: The PPP Internet Protocol Control Protocol (IPCP) (14 pages) * Obsoletes RFC1172 * Updated by RFC3241 RFC1331: The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links (69 pages) * Obsoletes RFC1171 * OBSOLETED BY RFC1548 RFC1378: The PPP AppleTalk Control Protocol (ATCP) (16 pages) RFC1377: The PPP OSI Network Layer Control Protocol (OSINLCP) (10 pages) RFC1553: Compressing IPX Headers Over WAN Media (CIPX) (27 pages) RFC1570: PPP LCP Extensions (22 pages) * Updates RFC1548 * Updated by RFC2484 RFC1552: The PPP Internetwork Packet Exchange Control Protocol (IPXCP) (19 pages) RFC1663: PPP Reliable Transmission (7 pages) RFC1598: PPP in X.25 (8 pages) RFC1638: PPP Bridging Control Protocol (BCP) (28 pages) * Obsoletes RFC1220 * OBSOLETED BY RFC2878 RFC1619: PPP over SONET/SDH (5 pages) * OBSOLETED BY RFC2615 RFC1618: PPP over ISDN (7 pages) RFC1473: The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol (9 pages) RFC1472: The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol (11 pages) RFC1471: The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol (25 pages) RFC1220: Point-to-Point Protocol Extensions for Bridging (18 pages) * OBSOLETED BY RFC1638 RFC1474: The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol (15 pages) RFC1661: The Point-to-Point Protocol (PPP) (54 pages) * Obsoletes RFC1548 * Updated by RFC2153 RFC1662: PPP in HDLC-like Framing (27 pages) * Obsoletes RFC1549 RFC2290: Mobile-IPv4 Configuration Option for PPP IPCP (17 pages) * Updates RFC2002 * OBSOLETED BY RFC2794 RFC2284: PPP Extensible Authentication Protocol (EAP) (15 pages) * Updated by RFC2484 * OBSOLETED BY RFC3748 RFC2363: PPP Over FUNI (12 pages) RFC2364: PPP over AAL5 (12 pages) RFC2419: The PPP DES Encryption Protocol, Version 2 (DESE-bis) (12 pages) * Obsoletes RFC1969 RFC2420: The PPP Triple-DES Encryption Protocol (3DESE) (8 pages) RFC2433: Microsoft PPP CHAP Extensions (20 pages) RFC2484: PPP LCP Internationalization Configuration Option (5 pages) * Updates RFC2284 * Updates RFC1994 * Updates RFC1570 RFC2509: IP Header Compression over PPP (10 pages) * OBSOLETED BY RFC3544 RFC2615: PPP over SONET/SDH (10 pages) * Obsoletes RFC1619 RFC2661: Layer Two Tunneling Protocol 'L2TP' (77 pages) RFC2701: Multi-link Multi-node PPP (9 pages) RFC2716: PPP EAP TLS Authentication Protocol (24 pages) * OBSOLETED BY RFC5216 RFC2759: Microsoft PPP CHAP Extensions, Version 2 (20 pages) RFC2823: PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing (28 pages) RFC2878: PPP Bridging Control Protocol (BCP) (38 pages) * Obsoletes RFC1638 * OBSOLETED BY RFC3518 RFC3078: Microsoft Point-To-Point Encryption (MPPE) Protocol (12 pages) * Updates RFC2118 RFC3153: PPP Multiplexed (9 pages) RFC3255: Extending PPP over SONET/SDH, with virtual concatenation, high order and low order payloads (8 pages) RFC3336: PPP over Asynchronous Transfer Mode Adaptation Layer 2 (16 pages) RFC3518: Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP) (40 pages) * Obsoletes RFC2878 RFC3772: PPP Vendor Protocol (11 pages) RFC3818: IANA Considerations for the Point-to-Point Protocol (PPP) (4 pages) RFC3337: Class Extensions for PPP over ATM Adaptation Layer 2 (0 pages) RFC4638: Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE) (10 pages) Pseudowire Emulation Edge to Edge (pwe3) ---------------------------------------- Charter Last Modified: 2009-04-13 Current Status: Active Chairs: Stewart Bryant Matthew Bocci Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Tech Advisor: David Black Secretary: David Sinicrope Mailing Lists: General Discussion: pwe3@ietf.org To Subscribe: pwe3-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/pwe3/index.html Description of Working Group: Network transport service providers and their users are seeking to rationalize their networks by migrating their existing services and platforms onto IP or MPLS enabled IP packet switched networks (PSN). This migration requires communications services that can emulate the essential properties of traditional communications links over a PSN. Some service providers wish to use MPLS technology to replace existing transport network infrastructure, relying upon pseudowire technology is an integral component of these network convergence architectures. Pseudowire Emulation Edge to Edge (PWE3) will specify the encapsulation, transport, control, management, interworking and security of services emulated over IETF-specified PSNs. A pseudowire emulates a point-to-point or point-to-multipoint link, and provides a single service which is perceived by its user as an unshared link or circuit of the chosen service. It is not intended that an emulated service will be indistinguishable from the service that is being emulated. The emulation need only be sufficient for the satisfactory operation of the service. Emulation necessarily involves a degree of cost-performance trade-off. In some cases it may be necessary to design more than one emulation mechanism in order to resolve these design conflicts. All emulated service definitions must include an applicability statement describing the faithfulness of the emulation. Switching, multiplexing, modification or other operation on the traditional service, unless required as part of the emulation, is out of the scope of the PWE3 WG. PWE3 will make use of existing IETF-specified mechanisms unless there are technical reasons why the existing mechanisms are insufficient or unnecessary. PWE3 operates "edge to edge" and will not exert control on the underlying PSN, other than to use any existing QoS or path control mechanism to provide the required connectivity between the endpoints of the PW. PWE3 will co-ordinate this with the AVT and TICTOC WGs. Where AVT or TICTOC require extensions to PWs to support time or frequency transfer this work will be undertaken by the PWE3 WG in co-ordination with the these WGs. A PW operating over a shared PSN does not necessarily have the same intrinsic security as a dedicated, purpose built, network. In some cases this is satisfactory, while in other cases it will be necessary to enhance the security of the PW to emulate the intrinsic security of the emulated service. PW specifications MUST include a description of how they are to be operated over a shared PSN with adequate security. PWE3 will work with the MPLS, L2VPN and other relevant WGs for definitions of common solutions for the secure operation of pseudowires. Whilst a service provider may traffic engineer their network in such a way that PW traffic will not cause significant congestion, a PW deployed by an end-user may cause congestion of the underlying PSN. Suitable congestion avoidance mechanisms are therefore needed to protect the Internet from the unconstrained deployment of PWs. Congestion avoidance may be more difficult with P2MP pseudowires than P2P pseudowires. The WG will consider both cases. PWE3 will work closely with the L2VPN WG to ensure a clear demarcation is defined for where PWE3 stops and L2VPN starts, in particular in defining point-multipoint (P2MP) PWs. PWE3 will work with MPLS and L2VPN to enhance the OAM suite for transport applications. PWE3 will coordinate very closely with any WG that is responsible for protocols which PWE3 intends to extend (e.g., the MPLS WG for LDP), as well as foster interaction with WGs that intend to extend PWE3 protocols. The IETF PWE3 WG is the design authority for pseudo-wire over IP/MPLS PSN technology. An entity or individual that wishes to propose extensions or changes to this technology must bring the corresponding proposals to the PWE3 WG that would treat them via a process similar to one described in RFC 4929 for the MPLS/GMPLS change process. WG Objectives: Specify the following PW types: Most of the initial specific PW types have been specified (e.g., Frame Realy, Ethernet, ATM). Investigation into and specification of a "generic PW" type and/or MPLS PW should be undertaken. PWE3 will specify a PW type for the special case where the access service payloads at both ends are known to consist entirely of IP packets. PWE3 will not specify mechanisms by which a PW connects two different access services unless the Network Layer protocol is IP or MPLS. Specify the control and management functions of chartered PW types, to include PW setup, configuration, maintenance and tear-down. The PWE3 WG will do this in its entirety for MPLS PSNs, and the L2TPEXT WG will develop the L2TP specifics for L2TPv3-based PWs. Specify Operations and Management (OAM) mechanisms for all PW types, suitable for operation over both IP/L2TPv3 and MPLS PSNs, and capable of providing the necessary interworking with the OAM mechanisms of the emulated service. Define requirements for and mechanisms to provide interconnection of PWs (to include inter-domain PWs). Define requirements for and mechanisms to provide protection and restoration of PWs. Publish document outlining PW-specific congestion avoidance and response guidelines. Publish document outlining PW-specific security considerations. Specify requirements and mechanisms for P2MP functionality for PWs. This work will be coordinated with the L2VPN and MPLS working groups. Publish requirements and specification for PW to take advantage of multiple PSN paths that exist between PEs. Publish requirements and specification for enhanced OAM. Include extensions to the PWE3 protocols and RFCs necessary to create an MPLS Transport Profile (MPLS-TP). The work on the MPLS TP needs to be coordinated between three primary working groups (MPLS, PWE3, L2VPN and CCAMP) that are chartered to do MPLS TP work. Goals and Milestones: Done - PWE3 WG started, organize editing teams. Done - Hold interim meeting, including discussion of priority of service-specific documents and consider pruning some deliverables Done - Accept drafts of service-specific documents as WG items Done - PW Requirements Document Last Call Done - TDM Circuit Documents Last Call Done - ATM Documents Last Call Done - Ethernet Documents Last Call Done - Fragmentation LC Done - TDM Requirements LC Done - SONET Documents Last Call Done - TDM Documents Last Call Done - Frame Relay Documents Last Call Done - FCS retention Last Call Done - Multi-Segment PW Requirements LC Done - VCCV LC Done - PWE3 Services MIBs LC Done - PPP/HDLC PW LC Done - Wildcard FEC LC Done - TDM Signaling LC Jul 2008 - Multi-Segment Architecture LC Done - Basic Pseudowire MIBs LC Sep 2008 - Fiber Channel Encap LC Sep 2008 - PW OAM Mapping LC Sep 2008 - Congestion Framework LC Oct 2008 - Multi-Segment PW LC Dec 2008 - PW Protection and Restoration Requirements LC Dec 2008 - PW Congestion Response LC Dec 2008 - Generic PW Requirements Jan 2009 - Dynamic MS PW LC Mar 2009 - PW Protection and Restoration Architecture Mar 2009 - Multipath PW LC Mar 2009 - Generic Associated Channel Header LC Apr 2009 - MPLS PW LC Jul 2009 - PW Protection and Restoration LC Jul 2009 - Multisegment PW MIB Jul 2009 - Congestion Solution LC Jul 2009 - Security Considerations LC Jul 2009 - P2MP Requirements LC Dec 2009 - Enhanced PW OAM Dec 2009 - VCCV Extensions for MPLS-TP Dec 2009 - Tandem Connection Monitoring for PWs Internet-Drafts: - Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3) [draft-ietf-pwe3-requirements-09] (20 pages) - Framework for Pseudo Wire Emulation Edge-to-Edge (PWE3) [draft-ietf-pwe3-framework-01] (24 pages) - Protocol Layering in PWE3 [draft-ietf-pwe3-protocol-layer-00] (33 pages) - Pseudowire (PW) Management Information Base (MIB) [draft-ietf-pwe3-pw-mib-15] (68 pages) - Pseudowire (PW) over MPLS PSN Management Information Base (MIB) [draft-ietf-pwe3-pw-mpls-mib-15] (32 pages) - Definitions of Textual Conventions for Pseudowires (PW) Management [draft-ietf-pwe3-pw-tc-mib-16] (11 pages) - SONET/SDH Circuit Emulation over Packet (CEP) [draft-ietf-pwe3-sonet-15] (55 pages) - TDM Service Specification for Pseudo-Wire Emulation Edge to Edge (PWE3) [draft-ietf-pwe3-sonet-vt-00] (36 pages) - Encapsulation Methods for Transport of Ethernet Over MPLS Networks [draft-ietf-pwe3-ethernet-encap-12] (23 pages) - Pseudowire Setup and Maintenance using the Label Distribution Protocol [draft-ietf-pwe3-control-protocol-18] (35 pages) - SONET/SDH Circuit Emulation Service Over Packet (CEP) Management Information Base (MIB) Using SMIv2 [draft-ietf-pwe3-cep-mib-12] (71 pages) - Ethernet Pseudowire (PW) Management Information Base (MIB) [draft-ietf-pwe3-enet-mib-15] (23 pages) - PWE3 Architecture [draft-ietf-pwe3-arch-08] (44 pages) - PWE3 Fragmentation and Reassembly [draft-ietf-pwe3-fragmentation-11] (15 pages) - Encapsulation Methods for Transport of Frame Relay Over MPLS Networks [draft-ietf-pwe3-frame-relay-08] (21 pages) - Encapsulation Methods for Transport of ATM Over MPLS Networks [draft-ietf-pwe3-atm-encap-12] (40 pages) - IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3) [draft-ietf-pwe3-iana-allocation-16] (10 pages) - Requirements for Edge-to-Edge Emulation of TDM Circuits over Packet Switching Networks [draft-ietf-pwe3-tdm-requirements-09] (25 pages) - Encapsulation Methods for Transport of PPP/HDLC Over MPLS Networks [draft-ietf-pwe3-hdlc-ppp-encap-mpls-10] (16 pages) - Pseudowire Virtual Circuit Connectivity Verification (VCCV) A Control Channel for Pseudowires [draft-ietf-pwe3-vccv-16] (32 pages) - Structure-Agnostic TDM over Packet (SAToP) [draft-ietf-pwe3-satop-06] (22 pages) - PWE3 Frame Check Sequence Retention [draft-ietf-pwe3-fcs-retention-05] (8 pages) - Managed Objects for ATM over Packet Switched Network (PSN) [draft-ietf-pwe3-pw-atm-mib-07] (41 pages) - Structure-aware TDM Circuit Emulation Service over Packet Switched Network (CESoPSN) [draft-ietf-pwe3-cesopsn-08] (31 pages) - TDM over IP [draft-ietf-pwe3-tdmoip-07] (49 pages) - Managed Objects for Structure-Agnostic TDM over Packet Network [draft-ietf-pwe3-satop-mib-03] (20 pages) - Managed Objects for TDM over Packet Switched Network (PSN) [draft-ietf-pwe3-tdm-mib-12] (48 pages) - PWE3 ATM Transparent Cell Transport Service [draft-ietf-pwe3-cell-transport-07] (5 pages) - Pseudo Wire (PW) OAM Message Mapping [draft-ietf-pwe3-oam-msg-map-12] (40 pages) - PWE3 Control Word for use over an MPLS PSN [draft-ietf-pwe3-cw-07] (12 pages) - Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3) [draft-ietf-pwe3-ms-pw-requirements-08] (30 pages) - Segmented Pseudowire [draft-ietf-pwe3-segmented-pw-13] (43 pages) - Control Protocol Extensions for the Setup of Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks [draft-ietf-pwe3-tdm-control-protocol-extensi-08] (16 pages) - Dynamic Placement of Multi Segment Pseudo Wires [draft-ietf-pwe3-dynamic-ms-pw-10] (20 pages) - An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge [draft-ietf-pwe3-ms-pw-arch-08] (25 pages) - Wildcard Pseudowire Type [draft-ietf-pwe3-wildcard-pw-type-03] (7 pages) - AII Types for Aggregation [draft-ietf-pwe3-aii-aggregate-03] (8 pages) - Encapsulation Methods for Transport of Fibre Channel frames Over MPLS Networks [draft-ietf-pwe3-fc-encap-09] (17 pages) - Pseudowire Congestion Control Framework [draft-ietf-pwe3-congestion-frmwk-03] (26 pages) - Application of Ethernet Pseudowires to MPLS Transport Networks [draft-ietf-pwe3-mpls-transport-04] (13 pages) - Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV) [draft-ietf-pwe3-vccv-bfd-07] (14 pages) - Flow Aware Transport of Pseudowires over an MPLS PSN [draft-ietf-pwe3-fat-pw-03] (19 pages) - Preferential Forwarding Status bit definition [draft-ietf-pwe3-redundancy-bit-02] (29 pages) - Pseudowire (PW) Redundancy [draft-ietf-pwe3-redundancy-02] (15 pages) - Requirements for Point-to-Multipoint Pseudowire [draft-ietf-pwe3-p2mp-pw-requirements-02] (19 pages) - Reliable Fibre Channel Transport Over MPLS Networks [draft-ietf-pwe3-fc-flow-00] (30 pages) - LDP extensions for AII reachability [draft-ietf-pwe3-ldp-aii-reachability-03] (10 pages) - MPLS and Ethernet OAM Interworking [draft-ietf-pwe3-mpls-eth-oam-iwk-01] (16 pages) - Inter-Chassis Communication Protocol for L2VPN PE Redundancy [draft-ietf-pwe3-iccp-02] (63 pages) Requests for Comments: RFC3916: Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3) (20 pages) RFC3985: PWE3 Architecture (44 pages) * Updated by RFC5462 RFC4197: Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks (25 pages) RFC4385: Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN (12 pages) * Updated by RFC5586 RFC4446: IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3) (10 pages) RFC4447: Pseudowire Setup and Maintenance using the Label Distribution Protocol (LDP) (35 pages) RFC4448: Encapsulation Methods for Transport of Ethernet Over MPLS Networks (23 pages) * Updated by RFC5462 RFC4553: Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP) (22 pages) RFC4623: Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly (15 pages) RFC4619: Encapsulation Methods for Transport of Frame Relay Over MPLS Networks (21 pages) RFC4618: Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks (16 pages) RFC4720: Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention (8 pages) RFC4717: Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks (40 pages) RFC4816: Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service (5 pages) RFC4842: Synchronous Optical Network/Synchronous Digital Hierarchy SONET/SDH) Circuit Emulation over Packet (CEP)) (55 pages) * Obsoletes RFC5143 RFC4863: Wildcard Pseudowire Type (7 pages) RFC5003: Attachment Individual Identifier (AII) Types for Aggregation (8 pages) RFC5087: Time Division Multiplexing over IP (TDMoIP) (49 pages) RFC5086: Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN) (31 pages) RFC5085: Pseudowire Virtual Circuit Connectivity Verification (VCCV) A Control Channel for Pseudowires (32 pages) * Updated by RFC5586 RFC5287: Control Protocol Extensions for the Setup of Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks (16 pages) RFC5254: Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3) (30 pages) RFC5542: Definitions of Textual Conventions for Pseudowires (PW) Management (11 pages) RFC5602: Pseudowire (PW) over MPLS PSN Management Information Base (MIB) (32 pages) RFC5603: Ethernet Pseudowire (PW) Management Information Base (MIB) (23 pages) RFC5601: Pseudowire (PW) Management Information Base (MIB) (68 pages) RFC5604: Managed Objects for Time Division Multiplexing (TDM) over Packet Switched Networks (48 pages) RFC5605: Managed Objects for ATM over Packet Switched Networks (PSNs) (36 pages) RFC5659: An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge (25 pages) Site Multihoming by IPv6 Intermediation (shim6) ----------------------------------------------- Charter Last Modified: 2010-01-05 Current Status: Active Chairs: Kurt Lindqvist Geoff Huston Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Tech Advisor: Thomas Narten Mailing Lists: General Discussion: shim6@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/shim6 Archive: http://www.ietf.org/mail-archive/web/shim6/current/maillist.html Description of Working Group: Earlier efforts in this working group completed the Shim6 protocol specification, documented in RFCs 5533 through 5535. This protocol is a layer 3 shim for providing locator agility with failover capabilities for IPv6 nodes. Hosts that employ Shim6 use multiple IPv6 address prefixes and setup state with peer hosts. This state can later be used to failover to a different set of locators, should the original locators stop working. The Shim6 approach has a number of advantages, such as enabling small sites to be multihomed without requiring a provider independent IPv6 address prefix for the site. But the approach has also been criticized, e.g., for the operational impacts that the use of multiple prefixes causes. At this time there is no clear view on how well Shim6 works in practice. Implementation and deployment in select networks is needed to determine its true characteristics. The Shim6 working group is chartered to track the implementation and testing or deployment efforts. The group is also expected to shepherd to completion a few remaining informational documents that complement the existing protocol specifications. The specific work items of the group are: o Write an implementation and/or deployment experience report. o Specify socket API extensions. This API enables interactions between applications and the Shim6 layer for advanced locator management, and access to information about failure detection and path exploration. It also enables some applications to turn Shim6 off. o Complete the work on the applicability draft. This draft explains in detail in which types of networks Shim6 is applicable, and what its advantages and disadvantages are. The draft will also explain how firewalls are impacted by the use of Shim6. Finally, the draft will also explain how Shim6 can be used in situations where native IPv6 connectivity is not available, such as using Shim6 over 6to4. The group will also work in co-operation with the 6MAN working group as they continue their efforts in improving IPv6 address selection mechanisms. The group shall not work on extensions to the Shim6 protocol itself at this time. However, new work items can be added through rechartering as others get completed. Goals and Milestones: Done - First draft of architectural document Done - First draft of protocol document Done - First draft on cryptographic locators, if required Done - First draft on multi-homing triggers description Done - First draft on applicability statement document Done - WG last-call on protocol document Done - WG last-call on cryptographic locators, if required Done - WG last-call on multihoming triggers description Done - Submit document on cryptographic locators to the IESG, if required Done - Submit protocol document to the IESG Done - Submit draft on multihoming triggers description to the IESG Sep 2009 - Next revision of the API document Nov 2009 - First WG draft on an implementation report Jan 2010 - Submit API document to IESG for publication as Informational RFC Jan 2010 - Next revision of the applicability document Dec 2010 - Submit implementation report to IESG for publication as Informational RFC Dec 2010 - Submit applicability document to IESG for publication as Informational RFC Dec 2010 - Close or re-charter Internet-Drafts: - Architectural Commentary on Site Multi-homing using a Level 3 Shim [draft-ietf-shim6-arch-00] (16 pages) - Shim6 Application Referral Issues [draft-ietf-shim6-app-refer-00] (12 pages) - Multihoming L3 Shim Approach [draft-ietf-shim6-l3shim-00] (30 pages) - Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming [draft-ietf-shim6-failure-detection-14] (46 pages) - Applicability Statement for the Level 3 Multihoming Shim Protocol (Shim6) [draft-ietf-shim6-applicability-04] (22 pages) - Hash Based Addresses (HBA) [draft-ietf-shim6-hba-06] (28 pages) - Shim6 Reachability Detection [draft-ietf-shim6-reach-detect-01] (6 pages) - Functional decomposition of the multihoming protocol [draft-ietf-shim6-functional-dec-00] (19 pages) - Shim6: Level 3 Multihoming Shim Protocol for IPv6 [draft-ietf-shim6-proto-13] (137 pages) - Default Locator-pair selection algorithm for the SHIM6 protocol [draft-ietf-shim6-locator-pair-selection-04] (11 pages) - Ingress filtering compatibility for IPv6 multihomed sites [draft-ietf-shim6-ingress-filtering-00] (18 pages) - Socket Application Program Interface (API) for Multihoming Shim [draft-ietf-shim6-multihome-shim-api-12] (42 pages) Requests for Comments: RFC5533: Shim6: Level 3 Multihoming Shim Protocol for IPv6 (124 pages) RFC5534: Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming (36 pages) RFC5535: Hash-Based Addresses (HBA) (25 pages) Softwires (softwire) -------------------- Charter Last Modified: 2009-04-13 Current Status: Active Chairs: David Ward Alain Durand Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Tech Advisor: Xing Li Mailing Lists: General Discussion: softwires@ietf.org To Subscribe: softwires-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/softwires/current/maillist.html Description of Working Group: The Softwires Working Group is specifying the standardization of discovery, control and encapsulation methods for connecting IPv4 networks across IPv6 networks and IPv6 networks across IPv4 networks in a way that will encourage multiple, inter-operable implementations. For various reasons, native IPv4 and/or IPv6 transport may not be available in all cases, and there is a need to tunnel IPv4 in IPv6 or IPv6 in IPv4 to cross a part of the network which is not IPv4 or IPv6 capable. The Softwire Problem Statement, RFC 4925, identifies two distinct topological scenarios that the WG will provide solutions for, "Hubs and Spokes" and "Mesh." In the former case, hosts or "stub" networks are attached via individual, point-to-point, IPv4 over IPv6 or IPv6 over IPv4 softwires to a centralized Softwire Concentrator. In the latter case (Mesh), network islands of one Address Family (IPv4 or IPv6) are connected over a network of another Address Family via point to multi-point softwires among Address family Border Routers (AFBRs). The focus of this WG is to: Document the softwire encapsulation and control protocol usage for one Address Family (IPv6 or IPv4) over another within the defined problem spaces set out in RFC 4925. Define "Dual-Stack Lite" which uses softwires and IPv4 NAT functions to reduce the amount of Global and RFC 1918 Local IPv4 addressing necessary for a Service Provider with an IPv6-enabled network to continue delivering IPv4 reachability to its customers. The WG will reuse existing technologies as much as possible and only when necessary, create additional protocol building blocks. For generality, all base SOFTWIRE encapsulation mechanisms should support all combinations of IP versions over one other (IPv4 over IPv6, IPv6 over IPv4, IPv4 over IPv4, IPv6 over IPv6). IPv4 to IPv6 translation mechanisms (NAT-PT), new addressing schemes, and block address assignments are out of scope. DHCP options developed in this group will be reviewed jointly with the DHC WG. BGP and other routing and signaling protocols developed in this group will be reviewed jointly with the proper working groups and other workings that may take interest (e.g. IDR, L3VPN, PIM, LDP, SAAG, etc). Goals and Milestones: Done - Submit a problem statement to the IESG to be considered as an Informational RFC Nov 2008 - Submit Mesh softwire encapsulation and control protocol to the IESG to be considered as a Proposed Standard Nov 2008 - Submit H&S softwire encapsulation and control protocol to the IESG to be considered as a Proposed Standard Mar 2009 - Submit dual-stack lite to the IESG to be considered as a Proposed Standard. The initial basis for this solution is described in draft-durand-dual-stack-lite-00.txt and draft-droms-softwires-snat-01.txt. Dec 2009 - Submit softwires MIB to the IESG to be considered as Proposed Standard Internet-Drafts: - IPv4 unicast/multicast VPNs over an IPv6 core [draft-ietf-softwire-4over6vpns-00] (7 pages) - Softwire Problem Statement [draft-ietf-softwire-problem-statement-04] (29 pages) - Dual-stack lite broadband deployments post IPv4 exhaustion [draft-ietf-softwire-dual-stack-lite-03] (36 pages) - Softwire Hub & Spoke Deployment Framework with L2TPv2 [draft-ietf-softwire-hs-framework-l2tpv2-14] (42 pages) - Softwire Security Analysis and Requirements [draft-ietf-softwire-security-requirements-10] (28 pages) - Softwire Mesh Framework [draft-ietf-softwire-mesh-framework-07] (32 pages) - BGP Traffic Engineering Attribute [draft-ietf-softwire-bgp-te-attribute-05] (7 pages) - BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute [draft-ietf-softwire-encaps-safi-06] (14 pages) - BGP IPsec Tunnel Encapsulation Attribute [draft-ietf-softwire-encaps-ipsec-04] (9 pages) - Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop [draft-ietf-softwire-v4nlri-v6nh-03] (12 pages) - Load Balancing for Mesh Softwires [draft-ietf-softwire-lb-04] (7 pages) - IPv6 via IPv4 Service Provider Networks "6rd" [draft-ietf-softwire-ipv6-6rd-04] (16 pages) - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Options for Dual- Stack Lite [draft-ietf-softwire-ds-lite-tunnel-option-01] (9 pages) Requests for Comments: RFC4925: Softwire Problem Statement (29 pages) RFC5512: The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute (13 pages) RFC5549: Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop (12 pages) RFC5543: BGP Traffic Engineering Attribute (7 pages) RFC5566: BGP IPsec Tunnel Encapsulation Attribute (8 pages) RFC5565: Softwire Mesh Framework (31 pages) RFC5571: Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2(L2TPv2) (41 pages) RFC5619: Softwire Security Analysis and Requirements (28 pages) RFC5640: Load Balancing for Mesh Softwires (7 pages) Source Address Validation Improvements (savi) --------------------------------------------- Charter Last Modified: 2009-12-15 Current Status: Active Chairs: Bill Fenner Christian Vogt Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Tech Advisor: Jianping Wu Secretary: Jun Bi Mailing Lists: General Discussion: savi@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/savi Archive: http://www.ietf.org/mail-archive/web/savi/current/maillist.html Description of Working Group: While ingress filtering [RFC 2827, BCP 38] provides a way to validate IP source addresses at an aggregated level, there is not yet a standardized mechanism for IP source address validation at a finer granularity. Having a finer granularity would be helpful in a number of situations, including filtering traffic from customer interfaces implemented as ports in a layer 3 aware bridge or a router, general improvements in filtering accuracy in enterprise networks, etc. Depending on the situation, there may be a requirement for blocking spoofed packets or merely logging packets that appear to be spoofed. Partial solutions exist to prevent nodes from spoofing the IP source address of another node in the same IP link (e.g., the "IP source guard"), but are proprietary. The purpose of the proposed "Source Address Validation Improvements" working group is to standardize mechanisms that prevent nodes attached to the same IP link from spoofing each other's IP addresses. The scope of the WG is as follows: - The working group considers only solutions implemented on systems located on the same IP link as a to-be-verified node. The goal of the working group is the LAN environment and solutions running in routers or layer 3 aware Ethernet bridges. - Both IPv4 and IPv6 need to be covered. - The first goal of the working group is on unicast traffic, but using the same mechanisms to police multicast traffic is also within the scope. - All address assignment mechanisms need to be supported, including stateless, stateful, and manual configuration; as well as privacy and cryptographically generated addresses. - Solutions are preferably based on observing user traffic, or on observing or using existing signaling protocols. Examples of protocols that can be useful to observe/use are ARP, Neighbor Discovery, DHCP, and DHCP Prefix Delegation protocols. Observing addresses in IP headers can also be useful. The gathered information is used to determine what IP source addresses in packets are appropriate. Where automatic operation is impossible or would lead to sub-optimal validation results, solutions may require manual configuration. - Interdomain scenarios (across Autonomous Systems) that require information from routing protocols like BGP are out of scope. Nevertheless, solution may observe routing protocol signaling to detect that a device is a router. - Tracking other protocols is not within the scope of the WG. - No changes to hosts are allowed. - The WG is prohibited from creating its own protocols or extensions/modifications of current protocols. These limitations in the scope may be relaxed through later rechartering. For instance, solutions tailored for PPP links and specific environments may be added later, or solutions involving co-operation of the nodes on the link may be developed once the baseline solutions have been completed. However, the WG is already chartered to work also on a solution for Ethernet-based broadband access networks that are used in DSL environments. This work is a specialization of the working group's primary LAN-based solution. In order to reach a result that is widely usable and unlikely to disturb existing network practices, the working group needs to take into account - nodes that use static addresses, - nodes with multiple IP addresses on the same interface, - nodes that use multiple link-layer addresses on the same interface, - nodes that have multiple interfaces to the same link, - attachment of another bridge at a bridge port, - presence of routers, NATs, and other similar devices on the same link, including their distinction from hosts with multiple interfaces or hosts with multiple IP addresses on a single interface, - use of SEcure Neighbor Discovery in some networks, - nodes that move to another port on the same link, and - hosts with anycast addresses. However, should such wide applicability turn out to be impossible, the working group will document the limitations of the solutions in due manner. In particular, it is likely that anycast addressing and nodes that employ multiple interfaces for load balancing at link layer are indistinguishable from an actual spoofing attack. There may also be a difference in the applicability between blocking and merely logging spoofed packets. In any case, the solutions may require to be explicitly turned on for each network or interface where they are applicable. For background information, the working group will also develop a threats analysis document that describes what threats the solutions from the WG protect against. This document also contrasts SAVI to existing solutions. Goals and Milestones: Jul 2008 - WG approval Aug 2008 - First WG draft on threats document Oct 2008 - First WG draft on SLAAC solution Dec 2008 - First WG draft on SeND solution Dec 2009 - First WG draft on DHCP solution Dec 2009 - First WG draft on protocol framework Mar 2010 - Submit document on threats to IESG for Informational RFC Mar 2010 - First WG draft on solution for Ethernet-based broadband access networks Dec 2010 - Submit Ethernet-based broadband access network solution to IESG for Proposed Standard Dec 2010 - Submit protocol framework to IESG for Informational RFC Dec 2010 - Submit SLAAC solution to IESG for Proposed Standard Dec 2010 - Submit SeND solution to IESG for Proposed Standard Dec 2010 - Submit DHCP solution to IESG for Proposed Standard Internet-Drafts: - SAVI Threat Scope [draft-ietf-savi-threat-scope-02] (22 pages) - A Solution Space Analysis for First-Hop IP Source Address Validation [draft-ietf-savi-rationale-00] (6 pages) - FCFS-SAVI: First-Come First-Serve Source-Address Validation for Locally Assigned Addresses [draft-ietf-savi-fcfs-02] (19 pages) - SEND-based Source-Address Validation Implementation [draft-ietf-savi-send-02] (19 pages) - SAVI Solution for DHCPv4/v6 [draft-ietf-savi-dhcp-00] (20 pages) No Requests for Comments Timing over IP Connection and Transfer of Clock (tictoc) -------------------------------------------------------- Charter Last Modified: 2009-04-13 Current Status: Active Chairs: Stewart Bryant Yaakov Stein Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion: tictoc@ietf.org To Subscribe: TICTOC-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/tictoc Description of Working Group: The Timing over IP Connections and Transfer Of Clock (TICTOC) WG is concerned with highly accurate time and frequency distribution over native IP and MPLS-enabled IP Packet Switched Networks (PSNs). While this need arises from a variety of sources (see draft-bryant-tictoc-probstat-01.txt), the application areas of focus for this WG are: (1) Network infrastructures with the need for highly accurate time and frequency distribution within well-engineered service provider or enterprise campus networks. On-path support with specialized hardware may be expected to be available at one or more hops on a given path. (2) Individual hosts and devices on the public Internet requiring functionality or performance not currently available in NTP. On-path support may be utilized if available, but is not expected. This application brings additional requirements beyond improved accuracy, for example, the traceable and authenticated distribution of UTC time, including correct handling of leap seconds. The NTP Working Group is currently standardizing the fourth version of NTP for time distribution over IP networks. The NTP WG has focused its deliverables largely on standardizing the currently deployed NTPv4, while collecting requirements for future extensions. These requirements will transition to the tictoc WG for further development. Meeting those requirements may include revision of the protocol to a new version level. However, in all cases backwards compatibility and coexistence with currently deployed NTPv4 is a paramount concern. An applicability statement will describe the use cases for which any extension of NTP is targeted. The IEEE Test and Measurement Society is in the closing stages of standardizing a second version of IEEE1588. This is unofficially known as IEEE1588v2 and is expected to be published as IEEE1588-2008. IEEE1588v2 is emerging as a viable solution for time transfer over service provider and campus Ethernet networks, and for which on-path hardware support is becoming available. IEEE1588v2 specifically encourages other standards organizations to adapt it to their requirements, and provides guidelines for doing so. TICTOC will determine whether a profile for IEEE1588v2 over IP or MPLS-enabled IP networks would be suitable for (1), and if so will produce a profile within the guidelines provided in the IEEE1588v2 specification. An applicability statement will describe the use cases for which any profile of IEEE1588v2 is targeted. Time and Frequency distribution is considered by many to be a complex and often esoteric subject area. The WG will develop a modular framework in order to map out components within the solution space, define terminology, and identify common areas of protocol work that can be capitalized upon. TICTOC will also consider the co-existence of IEEE1588v2 and NTP in the same network. In doing so, TICTOC will first verify that the data model of NTP can be accommodated by IEEE1588v2 protocol operation and document any deficiencies compared to NTP. If there is a need to map the data models, it will produce a specification for how to utilize IEEE 1588 in a localized region as one portion of an NTP-based system. TICTOC protocols will be applicable to a variety of link layer technologies. To get the highest quality time and frequency transfer the user should take advantage of two types of on-path service where they are available: Link based frequency transfer, and hop-by-hop delay correction (for time). Examples of link based frequency support are SONET/SDH, TDM, Synchronous Ethernet and DSL with timing reference support. The main types of support that can be provided by a network element are boundary clock (where the clock is regenerated at the node in a multistage master slave relationship) and transparent clock where corrections are applied to time transfer packets as they pass through to compensate for the queuing delay, and where known for asymmetry in the link delay. Transparent clock (queue delay correction) requires routers to identify a time transfer packet, record the queuing delay, and either apply an on the fly correction to the packet, or to generate a follow-up packet with the necessary time correction information. TICTOC will ensure that any transparent clock design is acceptable in an Internet environment. On-path support is not a given, and TICTOC will investigate methods for automatically discovering when this support is available and when it is not. TICTOC will transfer time and frequency over both IP and IP enabled MPLS PSNs. One of the major users of TICTOC technology is the service provider community, where MPLS enabled IP networks are common. If necessary, TICTOC may take advantage of the path control properties of MPLS and the ability to signal modifications to per packet forwarding behavior. The security of time transfer, including the authentication of the time reference is an important consideration and must be designed in from the beginning. The ultimate system-level accuracy of time and frequency transfer depends on a number of factors outside the scope of the protocols themselves. Thus, even if it is possible for TICTOC to make a number of improvements at the protocol level to facilitate more accurate time and frequency transfer, it is impossible for the WG to provide system-level accuracy guarantees on its own. The TICTOC WG will co-ordinate with the PWE3 and NTP WGs in the IETF, as well as IEEE1588, IEEE 802.1AS and ITU-T SG15 Q13. It is also expected that active individuals in the TICTOC WG will propose the formation of an IRTF RG to study more advanced aspects of time and frequency distribution. First phase Objectives: - To develop a time and frequency distribution requirements document for the two cases listed above, including coexistence of the two as appropriate. - To develop a document defining the modular breakdown of functionality within the solution space. - To determine the extent to which these requirements can be satisfied using IEEE1588v2 and NTPv4 within each use case, along with an associated gap analysis for what requirements are not met without adaptation or extension of these protocols. - To develop an IEEE1588v2 profile as necessary for time and frequency distribution, with primary focus on (1). This profile will include a MIB module for IEEE1588v2. - To develop extensions to NTPv4 as necessary for time and frequency distribution, with primary focus on (2). - If required, to develop mechanisms for coexistence of IEEE1588v2 and NTP. - To document threat analyses and security mechanisms for all protocols developed by the WG. - To document media mappings for link layer technologies of interest. Second phase Objectives (requiring re-charter of the WG): To propose and document algorithms, protocols and mechanisms for transport, frequency acquisition, ranging, and packet selection/discard, master clock selection, path selection, OAM, synchronization status messaging, performance monitoring, security, and network management. Goals and Milestones: Sep 2008 - Problem statement document exits WGLC Nov 2008 - Modular Framework documentation document exits WGLC Jan 2009 - Requirements analysis for use cases, including gap analysis for NTPv4 and 1588v2 document exits WGLC Apr 2009 - 1588v2 profile, if needed, document exits WGLC Apr 2009 - NTPv4 extensions, if needed, document exits WGLC Apr 2009 - Security document(s) document exits WGLC Aug 2009 - MIB for IEEE 1588v2 profile and NTPv4 extensions (TICTOC MIB) document exits WGLC Aug 2009 - Prioritize second phase deliverables and add milestones or re-charter document exits WGLC Internet-Drafts: - TICTOC Problem Statement [draft-bryant-tictoc-probstat-02] (16 pages) - Architecture for the Transmission of Timing over Packet Networks [draft-stein-tictoc-modules-03] (22 pages) - TICTOC Requirement [draft-ietf-tictoc-requirements-01] (32 pages) No Requests for Comments Transparent Interconnection of Lots of Links (trill) ---------------------------------------------------- Charter Last Modified: 2009-05-07 Current Status: Active Chairs: Erik Nordmark Donald Eastlake 3rd Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion: rbridge@postel.org To Subscribe: http://www.postel.org/mailman/listinfo/rbridge Archive: http://www.postel.org/pipermail/rbridge Description of Working Group: The TRILL WG will design a solution for shortest-path frame routing in multi-hop IEEE 802.1-compliant Ethernet networks with arbitrary topologies, using an existing link-state routing protocol technology. This work will initially be based on draft-perlman-rbridge-03.txt. The design should have the following properties: - Minimal or no configuration required - Load-splitting among multiple paths - Routing loop mitigation (possibly through a TTL field) - Support of multiple points of attachment - Support for broadcast and multicast - No significant service delay after attachment - No less secure than existing bridged solutions Any changes introduced to the Ethernet service model should be analyzed and clearly documented. To ensure compatibility with IEEE VLANs and the Ethernet service model, the WG will request an IEEE liaison relationship with IEEE 802.1, and IEEE 802.1 will be asked to review the architecture document and specification(s) before they are submitted to the IESG. It is not an explicit requirement that the solution should be able to run on existing IP routers or IEEE 802 switches as a software upgrade. However, the working group should take deployment considerations into account, to ensure that the solution can interwork with bridges in a flexible manner (e.g., to allow incremental deployment into LANs that currently use 802.1D bridges). The TRILL working will work with the L2VPN WG to develop interworking between TRILL and 802.1D bridges at the edge, such that a bridged sub-cloud could be attached to TRILL devices in more than one place for redundancy. The solution must not interfere with the end-to-end transparency of the Internet architecture or with end-to-end congestion control and QOS mechanisms. The WG will work on the following items: (1) Develop a problem statement and architecture document that describes the high-level TRILL architecture, discusses the scalability of that architecture, describes the threat model and security impacts of the TRILL solution, and describes the expected impacts (if any) of the TRILL solution on the Ethernet service model. (2) Define the requirements for a TRILL-capable routing protocol, and select one or more existing routing protocols that could meet those requirements. (3) Work with the appropriate Routing area working group to extend an existing routing protocol to meet the TRILL working group requirements. Note: The TRILL working group is not chartered to develop a new routing protocol or to make substantial modifications to an existing routing protocol. If, during the requirements definition and selection phase, the TRILL working group discovers that no existing routing protocol will meet their needs, we will need to re-assess the TRILL WG charter to determine how/if this work should proceed. (4) Produce a (set of) TRILL specification(s) for standards track publication that define(s) what information must be carried in an encapsulation header for data packets. Although this work will initially be undertaken only for 802.1-compliant links, it may later be expanded to non-802.1 links, so the design should be link-layer agnostic to whatever extent possible. The TRILL working group is chartered to undertake all of the above tasks and may begin work on more than one of these tasks in parallel. However, the problem statement and architecture document should be completed before the details of the base protocol are finalized, while there is still time to consider changes to the architecture without major impacts on established specifications. Goals and Milestones: Done - Accept base protocol specification as a WG document Done - Accept problem statement and applicability as a WG work item Done - Start work with routing area WG(s) to undertake TRILL extensions Done - Accept architecture document as a WG work item Done - Accept routing protocol requirements as a WG work item Done - Choose routing protocol(s) that can meet the requirements Done - Submit problem statement and applicability to IESG for Informational RFC May 2009 - Submit base protocol specification to IEEE/IETF expert review Jun 2009 - Base protocol specification submitted to the IESG for publication as a Proposed Standard RFC Aug 2009 - First draft showing what is needed for MIB Jul 2010 - Re-charter or shut down the WG Internet-Drafts: - The Architecture of an RBridge Solution to TRILL [draft-ietf-trill-rbridge-arch-05] (36 pages) - Rbridges: Base Protocol Specification [draft-ietf-trill-rbridge-protocol-15] (113 pages) - Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement [draft-ietf-trill-prob-07] (18 pages) - TRILL Routing Requirements in Support of RBridges [draft-ietf-trill-routing-reqs-02] (11 pages) - RBridge VLAN Mapping [draft-ietf-trill-rbridge-vlan-mapping-01] (12 pages) - RBridges: TRILL Header Options [draft-ietf-trill-rbridge-options-00] (17 pages) Requests for Comments: RFC5556: Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement (17 pages) ADSL MIB (adslmib) ------------------ Charter Last Modified: 2009-08-24 Current Status: Active Chairs: Michael Sneed Menachem Dodge Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Tech Advisor: Randy Presuhn Editors: Faye Ly Greg Bathrick Bob Ray Rajesh Abbi Scott Baillie Menachem Dodge Clay Sikes Moti Morgenstern Umberto Bonollo Mailing Lists: General Discussion: adslmib@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/adslmib Archive: http://www.ietf.org/mail-archive/web/adslmib/current/maillist.html Description of Working Group: The working group will define: 1. A set of managed objects to be used for management of newer versions of Digital Subscriber Line (xDSL) as defined in ITU-T Recommendation G.997.1 (02/2006). 2. A set of managed objects to handle the bonding of xDSL lines according to the ITU-T Recommendations G.998.1 (ATM), G.998.2 (Ethernet) and G.998.3 (TDIM). A common MIB module will be developed to handle the common objects and three specific MIB modules will be developed to handle the three separate layer-2 technologies. Use will be made of the ifStack and ifInvStack Tables defined in RFC 2863 and RFC 2864 respectively. Use will also be made of the ifAvailableStack and ifInvAvailableStack tables as defined by the Hubmib WG. The MIB modules defined by this group will be generated using SMIv2, will be consistent with the SNMP management framework, and will describe the relationship of the objects defined to existing MIBs such as those described in other work products of this Working Group, the interfaces MIB, the Ethernet MIB modules and the AToM MIB. The working group will consider the input of the DSL forum and the ITU in the definition of these MIBs. Goals and Milestones: Done - Submit Internet-Draft to cover subscriber equipment Done - Meet at Chicago IETF to review Internet-Drafts Done - Submit Internet-Draft to IESG for consideration as Proposed Standard. Done - Meet at Oslo IETF to review new Internet-Drafts and discuss implementation experience on initial MIB Done - Submit supplementary Internet-Draft to IESG for consideration as Proposed Standard. Done - Produce Internet-Draft covering HDSL2 management objects. Done - Submit updated HDSL2/SHDSL Internet-Draft Done - Complete WG last call for HDSL2/SHDSL management objects Done - Collect implementation reports for ADSL MIB Done - Submit HDSL2/SHDSL MIB to IESG for consideration as Proposed Standard Done - Submit initial Internet-Draft VDSL MIB Done - Complete WG last call on VDSL MIB Done - Submit updated VDSL MIB Internet-Draft Done - Submit final VDSL MIB Internet-Draft Done - Submit VDSL MIB to IESG for consideration as Proposed Standard Done - New WG I-Ds for the LCS MCM and SCM MIB modules Done - Initial WG Internet-Draft covering ADSL2 management objects Done - Integrate working group changes and produce revised draft Done - Complete WG last call on ADSL2 MIB Done - Submit ADSL2 MIB to IESG for consideration as Proposed Standard Done - Re-charter or close down Done - Initial WG Internet-Draft covering VDSL2 management objects Done - Inform the ITU-T and DSL Forum that work on the VDSL2 MIB has begun Done - Integrate working group changes and produce revised VDSL2 MIB draft Done - Post Initial Drafts of all the xDsl Bonding MIB drafts Done - Post Vdsl2 draft version 03 Done - Post Vdsl2 draft version 04. Dec 2007 - Complete the work on all the four G.Bond documents. Jan 2008 - Working Group Last Call on all the G. Bond documents. Done - Complete Thorough Working Group Reviews of the Vdsl2 draft and produce version 05. Feb 2008 - Early MIB Doctor Review of all G.Bond documents. Done - Working Group Last Call for the Vdsl2 document. Done - Early MIB Doctor Reviews of the Vdsl2 draft. Mar 2008 - Make Corrections to the G.Bond drafts following the review. Apr 2008 - Working Group Last Call for G.Bond documents following corrections. Done - Make Correction to the draft following the review. May 2008 - Present the four G. Bond documents to the IESG. Done - Working Group Last Call for the Vdsl2 document following corrections. Done - Present the Vdsl2 document to the IESG. Internet-Drafts: - Definitions of Managed Objects for the ADSL Lines [draft-ietf-adslmib-adsllinemib-10] (113 pages) - Definitions of Extension Managed Objects for Asymmetric Digital Subscriber Lines [draft-ietf-adslmib-adslext-12] (36 pages) - Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2) [draft-ietf-adslmib-vdsl2-08] (215 pages) - Definitions of Managed Objects for HDSL2 and SHDSL Lines [draft-ietf-adslmib-hdsl2-12] (61 pages) - Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL) [draft-ietf-adslmib-vdsl-13] (68 pages) - High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals [draft-ietf-adslmib-hc-tc-08] (10 pages) - Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Single Carrier Modulation (SCM) Line Coding [draft-ietf-adslmib-vdsl-ext-scm-09] (18 pages) - Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding [draft-ietf-adslmib-vdsl-ext-mcm-07] (23 pages) - Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines [draft-ietf-adslmib-gshdslbis-12] (76 pages) - Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2) [draft-ietf-adslmib-adsl2-09] (166 pages) - xDSL multi-pair bonding (G.Bond) MIB [draft-ietf-adslmib-gbond-mib-04] (66 pages) - Ethernet-based xDSL multi-pair bonding (G.Bond/Ethernet) MIB [draft-ietf-adslmib-gbond-eth-mib-01] (23 pages) - xDSL multi-pair bonding using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB [draft-ietf-adslmib-gbond-tdim-mib-02] (49 pages) - ATM-Based xDSL Bonded Interfaces MIB [draft-ietf-adslmib-gbond-atm-mib-00] (17 pages) Requests for Comments: RFC2662: Definitions of Managed Objects for the ADSL Lines (115 pages) RFC3276: Definitions of Managed Objects for HDSL2 and SHDSL Lines (66 pages) * OBSOLETED BY RFC4319 RFC3440: Definitions of Extension Managed Objects for Asymmetric Digital Subscriber Lines (36 pages) RFC3705: High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals (10 pages) RFC3728: Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL) (68 pages) RFC4069: Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Single Carrier Modulation (SCM) Line Coding (18 pages) RFC4070: Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding (23 pages) RFC4319: Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines (76 pages) * Obsoletes RFC3276 RFC4706: Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2) (166 pages) RFC5650: Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2) (215 pages) Benchmarking Methodology (bmwg) ------------------------------- Charter Last Modified: 2009-10-19 Current Status: Active Chair: Al Morton Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Ronald Bonica Mailing Lists: General Discussion: bmwg@ietf.org To Subscribe: bmwg-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/bmwg/index.html Description of Working Group: The major goal of the Benchmarking Methodology Working Group is to make a series of recommendations concerning the measurement of the performance characteristics of various internetworking technologies; further, these recommendations may focus on the systems or services that are built from these technologies. Each recommendation will describe the class of equipment, system, or service being addressed; discuss the performance characteristics that are pertinent to that class; clearly identify a set of metrics that aid in the description of those characteristics; specify the methodologies required to collect said metrics; and lastly, present the requirements for the common, unambiguous reporting of benchmarking results. To better distinguish the BMWG from other measurement initiatives in the IETF, the scope of the BMWG is limited to technology characterization using simulated stimuli in a laboratory environment. Said differently, the BMWG does not attempt to produce benchmarks for live, operational networks. Moreover, the benchmarks produced by this WG shall strive to be vendor independent or otherwise have universal applicability to a given technology class. Because the demands of a particular technology may vary from deployment to deployment, a specific non-goal of the Working Group is to define acceptance criteria or performance requirements. An ongoing task is to provide a forum for discussion regarding the advancement of measurements designed to provide insight on the operation inter-networking technologies. In addition to its current work plan, the BMWG is explicitly tasked to develop benchmarks and methodologies for the following technologies: * MPLS Forwarding: Develop specific methods to characterize the latency and forwarding performance of MPLS devices, extending the fundamental recommendations of RFC 1242 and RFC 2544 to this networking technology. * SIP Networking Devices: Develop new terminology and methods to characterize the key performance aspects of network devices using SIP, including the signaling plane scale and service rates while considering load conditions on both the signaling and media planes. This work will be harmonized with related SIP performance metric definitions prepared by the PMOL working group. Goals and Milestones: Done - Expand the current Ethernet switch benchmarking methodology draft to define the metrics and methodologies particular to the general class of connectionless, LAN switches. Done - Edit the LAN switch draft to reflect the input from BMWG. Issue a new version of document for comment. If appropriate, ascertain consensus on whether to recommend the draft for consideration as an RFC. Done - Take controversial components of multicast draft to mailing list for discussion. Incorporate changes to draft and reissue appropriately. Done - Submit workplan for initiating work on Benchmarking Methodology for LAN Switching Devices. Done - Submit workplan for continuing work on the Terminology for Cell/Call Benchmarking draft. Done - Submit initial draft of Benchmarking Methodology for LAN Switches. Done - Submit Terminology for IP Multicast Benchmarking draft for AD Review. Done - Submit Benchmarking Terminology for Firewall Performance for AD review Done - Progress ATM benchmarking terminology draft to AD review. Done - Submit Benchmarking Methodology for LAN Switching Devices draft for AD review. Done - Submit first draft of Firewall Benchmarking Methodology. Done - First Draft of Terminology for FIB related Router Performance Benchmarking. Done - First Draft of Router Benchmarking Framework Done - Progress Frame Relay benchmarking terminology draft to AD review. Done - Methodology for ATM Benchmarking for AD review. Done - Terminology for ATM ABR Benchmarking for AD review. Done - Terminology for FIB related Router Performance Benchmarking to AD review. Done - Firewall Benchmarking Methodology to AD Review Done - First Draft of Methodology for FIB related Router Performance Benchmarking. Done - First draft Net Traffic Control Benchmarking Methodology. Done - Methodology for IP Multicast Benchmarking to AD Review. Done - Resource Reservation Benchmarking Terminology to AD Review Done - First I-D on IPsec Device Benchmarking Terminology Done - EGP Convergence Benchmarking Terminology to AD Review Done - Resource Reservation Benchmarking Methodology to AD Review Done - Net Traffic Control Benchmarking Terminology to AD Review Done - IGP/Data-Plane Terminology I-D to AD Review Done - IGP/Data-Plane Methodology and Considerations I-Ds to AD Review Done - Hash and Stuffing I-D to AD Review Done - IPv6 Benchmarking Methodology to AD Review Done - IPsec Device Benchmarking Terminology to IESG Review Done - IPsec Device Benchmarking Methodology to IESG Review Dec 2008 - Net Traffic Control Benchmarking Methodology to AD Review. Dec 2008 - Router Accelerated Test Terminology to IESG Review Dec 2008 - Router Accelerated Test Methodology to IESG Review Feb 2009 - Terminology For Protection Benchmarking to AD Review Feb 2009 - Methodology For Protection Benchmarking to AD Review Done - Methodology for MPLS Forwarding to AD Review Jun 2009 - Terminology for SIP Device Benchmarking to IESG Review Jun 2009 - Methodology for SIP Device Benchmarking to IESG Review Dec 2009 - Router Accelerated Test Method for EBGP to IESG Review Dec 2009 - Router Accelerated Test Method for Operational Security to IESG Review Jul 2010 - Basic BGP Convergence Benchmarking Methodology to AD Review. Internet-Drafts: - Benchmarking Terminology for Network Interconnection Devices [draft-ietf-bmwg-terms-02] (0 pages) - Benchmarking Methodology for Network Interconnect Devices [draft-ietf-bmwg-methodology-03] (23 pages) - Benchmarking Methodologies for Overall Network Performance [draft-ietf-bmwg-overallperf-00] (6 pages) - Benchmarking Methodology for Ethernet Switches [draft-ietf-bmwg-ethernet-switches-01] (13 pages) - Benchmarking Terminology for LAN Switching Devices [draft-ietf-bmwg-lanswitch-07] (25 pages) - Terminology for Cell/Call Benchmarking [draft-ietf-bmwg-call-04] (29 pages) - Connectivity [draft-ietf-bmwg-ippm-connect-00] (9 pages) - Terminology for IP Multicast Benchmarking [draft-ietf-bmwg-mcast-09] (15 pages) - Benchmarking Terminology for Firewall Performance [draft-ietf-bmwg-secperf-09] (23 pages) - Benchmarking Methodology for LAN Switching Devices [draft-ietf-bmwg-mswitch-05] (34 pages) - Terminology for Frame Relay Benchmarking [draft-ietf-bmwg-fr-term-06] (24 pages) - Methodology for IP Multicast Benchmarking [draft-ietf-bmwg-mcastm-15] (31 pages) - Terminology for ATM Benchmarking [draft-ietf-bmwg-atm-term-01] (29 pages) - Methodology for ATM Benchmarking [draft-ietf-bmwg-atm-method-03] (168 pages) - Terminology for ATM ABR Benchmarking [draft-ietf-bmwg-atm-term-abr-03] (18 pages) - Terminology for Forwarding Information Base (FIB) based Router Performance [draft-ietf-bmwg-fib-term-04] (13 pages) - Framework for Router Benchmarking [draft-ietf-bmwg-rtr-framework-00] (8 pages) - Benchmarking Methodology for Firewall Performance [draft-ietf-bmwg-firewall-08] (30 pages) - Terminology for Benchmarking Network-layer Traffic Control Mechanisms [draft-ietf-bmwg-dsmterm-14] (32 pages) - Benchmarking Terminology for Resource Reservation Capable Routers [draft-ietf-bmwg-benchres-term-09] (22 pages) - Benchmarking Methodology for Routers Supporting Resource Reservation [draft-ietf-bmwg-benchres-method-00] (15 pages) - Terminology for Benchmarking BGP Device Convergence in the Control Plane [draft-ietf-bmwg-conterm-07] (35 pages) - Benchmarking Methodology for Basic BGP Convergence [draft-ietf-bmwg-bgpbas-01] (16 pages) - Methodology for Forwarding Information Base (FIB) based Router Performance [draft-ietf-bmwg-fib-meth-03] (13 pages) - OSPF Benchmarking Terminology and Concepts [draft-ietf-bmwg-ospfconv-term-11] (10 pages) - Benchmarking Basic OSPF Single Router Control Plane Convergence [draft-ietf-bmwg-ospfconv-intraarea-11] (16 pages) - Considerations When Using Basic OSPF Convergence Benchmarks [draft-ietf-bmwg-ospfconv-applicability-08] (12 pages) - Terminology for Benchmarking IPsec Devices [draft-ietf-bmwg-ipsec-term-12] (46 pages) - Benchmarking Methodology for Link-State IGP Data Plane Route Convergence [draft-ietf-bmwg-igp-dataplane-conv-meth-19] (36 pages) - Terminology for Benchmarking Link-State IGP Data Plane Route Convergence [draft-ietf-bmwg-igp-dataplane-conv-term-19] (28 pages) - Considerations for Benchmarking Link-State IGP Data Plane Route Convergence [draft-ietf-bmwg-igp-dataplane-conv-app-18] (6 pages) - Terminology for Accelerated Stress Benchmarking [draft-ietf-bmwg-acc-bench-term-13] (27 pages) - Framework for Accelerated Stress Benchmarking [draft-ietf-bmwg-acc-bench-framework-00] (7 pages) - Methodology Guidelines for Accelerated Stress Benchmarking [draft-ietf-bmwg-acc-bench-meth-09] (13 pages) - Hash and Stuffing: Overlooked Factors in Network Device Benchmarking [draft-ietf-bmwg-hash-stuffing-09] (34 pages) - Methodology for Benchmarking Accelerated Stress with Operational EBGP Instabilities [draft-ietf-bmwg-acc-bench-meth-ebgp-00] (9 pages) - Methodology for Benchmarking Accelerated Stress with Operational Security [draft-ietf-bmwg-acc-bench-meth-opsec-00] (7 pages) - Methodology for Benchmarking IPsec Devices [draft-ietf-bmwg-ipsec-meth-05] (41 pages) - Methodology for Benchmarking Network-layer Traffic Control Mechanisms [draft-ietf-bmwg-dsmmeth-02] (13 pages) - Benchmarking Terminology for Protection Performance [draft-ietf-bmwg-protection-term-08] (28 pages) - Methodology for benchmarking MPLS protection mechanisms [draft-ietf-bmwg-protection-meth-07] (29 pages) - IPv6 Benchmarking Methodology for Network Interconnect Devices [draft-ietf-bmwg-ipv6-meth-06] (19 pages) - MPLS Forwarding Benchmarking Methodology for IP Flows [draft-ietf-bmwg-mpls-forwarding-meth-07] (31 pages) - Terminology for Benchmarking Session Initiation Protocol (SIP) Networking Devices [draft-ietf-bmwg-sip-bench-term-01] (34 pages) - Methodology for Benchmarking SIP Networking Devices [draft-ietf-bmwg-sip-bench-meth-01] (20 pages) Requests for Comments: RFC1242: Benchmarking Terminology for Network Interconnection Devices (12 pages) RFC1944: Benchmarking Methodology for Network Interconnect Devices (30 pages) * OBSOLETED BY RFC2544 RFC2285: Benchmarking Terminology for LAN Switching Devices (25 pages) RFC2432: Terminology for IP Multicast Benchmarking (16 pages) RFC2544: Benchmarking Methodology for Network Interconnect Devices (31 pages) * Obsoletes RFC1944 RFC2647: Benchmarking Terminology for Firewall Performance (26 pages) RFC2761: Terminology for ATM Benchmarking (32 pages) RFC2889: Benchmarking Methodology for LAN Switching Devices (35 pages) RFC3116: Methodology for ATM Benchmarking (128 pages) RFC3133: Terminology for Frame Relay Benchmarking (24 pages) RFC3134: Terminology for ATM ABR Benchmarking (16 pages) RFC3222: Terminology for Forwarding Information Base (FIB) based Router Performance (15 pages) RFC3511: Benchmarking Methodology for Firewall Performance (34 pages) RFC3918: Methodology for IP Multicast Benchmarking (31 pages) RFC4098: Terminology for Benchmarking BGP Device Convergence in the Control Plane (35 pages) RFC4063: Considerations When Using Basic OSPF Convergence Benchmarks (12 pages) RFC4062: OSPF Benchmarking Terminology and Concepts (10 pages) RFC4061: Benchmarking Basic OSPF Single Router Control Plane Convergence (16 pages) RFC4689: Terminology for Benchmarking Network-layer Traffic Control Mechanisms (32 pages) RFC4814: Hash and Stuffing: Overlooked Factors in Network Device Benchmarking (34 pages) RFC4883: Benchmarking Terminology for Resource Reservation Capable Routers (22 pages) RFC5180: IPv6 Benchmarking Methodology for Network Interconnect Devices (19 pages) RFC5695: MPLS Forwarding Benchmarking Methodology for IP Flows (27 pages) Control And Provisioning of Wireless Access Points (capwap) ----------------------------------------------------------- Charter Last Modified: 2008-08-21 Current Status: Active Chairs: Margaret Wasserman Mahalingam Mani Dorothy Gellert Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Tech Advisors: David Borman Scott Kelly Bob O'Hara Charles Clancy Mailing Lists: General Discussion: capwap@frascone.com To Subscribe: http://lists.frascone.com/mailman/listinfo/capwap Archive: http://lists.frascone.com/pipermail/capwap Description of Working Group: The original CAPWAP WG charter included drafting a problem statement and a taxonomy of architectures. The new charter of the CAPWAP WG proposes building upon the original charter and developing a CAPWAP protocol to provide interoperability among WLAN backend architectures. The intent of the CAPWAP protocol is to facilitate control, management and provisioning of WLAN Termination Points (WTPs) specifying the services, functions and resources relating to 802.11 WLAN Termination Points in order to allow for interoperable implementations of WTPs and ACs. The revised CAPWAP WG will reference two classes of the Centralized WLAN Architecture family, namely the Local MAC and the Split MAC, as described in the CAPWAP Architecture Taxonomy draft. The protocol will define the CAPWAP control plane including the primitives to control data access. An effective Centralized CAPWAP Architecture impacts how WLAN data traffic is managed over the backend network. This implies the abilitiy to control how data is forwarded by negotiating existng data encapsulation mechanisms and specifying data payload formats in order to ensure interoperability between CAPWAP vendors. No other specifications of the CAPWAP data plane are within the scope of this charter. The CAPWAP WG will strive for extensibility in the protocol design to favor future applicability to other access technologies, especially IEEE 802.16. While accommodation of any access technology other than IEEE 802.11 is not required for successful completion, there are clear deployment advantages if a wide range of access technologies are accommodated. In summary, the primary goals of the group will be: 1. Defining a set of Objectives based on the architecture taxonomy work that lists the requirements for an interoperable CAPWAP protocol. In addition, the WG will incorporate requirements derived from the inputs provided by Enterprise and (hotspot) Providers based on the WLAN deployment challenges addressed by CAPWAP architecture. This document will: a. include objectives to address problems described in the CAPWAP Problem statement document b. Describe each objective, its benefit to the protocol and how it satisfies the problem statement. c. Prioritize and classify the objectives into 3 categories: i. Mandatory and Accepted ii. Desirable iii. Rejected d. Undergo review in IEEE 802 as needed This should result in the first WG Last Call for Objectives draft. To avoid requirements bloat and stalemate, the WG has a hard deadline on the Objectives phase. The WG MUST reach WG consensus on the objectives draft by Feb 2005. This is for several reasons: * We must send this for review to IEEE at that time. * We must have a reasonably stable set of objectives so that candidate submissions are aware of the objectives to be met. The 2nd WG Last Call (in April) for the objectives draft is to ensure that the WG has consensus on any changes that may result from IEEE and expert review. So it is not the intention that the WG keeps adding new Objectives after Feb 2005. If the WG cannot reach consensus on the Objectives draft by the May 2005 milestone to the IESG, the WG will close. 2. Evaluating a set of candidate proposals that include existing IETF protocols and any proposals leading to the selection of a protocol on which to base the CAPWAP standard. 3. Developing a CAPWAP protocol standard that meets the Mandatory and Accepted objectives from the Evaluation draft and contains the minimal set of feature needed to control and provision WLAN Access Points. Specifically The CAPWAP protocol document will address the following considerations: a. Architecture b. Operations c. Security d. Network Management e. Scalability f. Performance 4. A MIB Document to support the CAPWAP protocol. In addition, the CAPWAP WG will maintain its Liaison with the IEEE to ensure consistency of its work with the IEEE 802.11 Standard. Deliverables: * Objectives/Criteria Document for CAPWAP protocol * Protocol evaluation and base protocol selection document * CAPWAP Protocol standard * MIB support standard Goals and Milestones: Done - Last call for problem statement draft. Done - Discuss last call comments for problem statement at IETF 59. Done - Last Call for architecture description document. Done - Submit problem statement to IESG for publication approval. Done - Architecture document to expert review. Done - Stable Architecture document for review/sync-up with IEEE 802 Done - Discuss results of IEEE 802 review/sync-up Done - Issue first Internet-Draft of CAPWAP Objectives document Done - Submit CAPWAP Objectives to IEEE/IETF experts review Done - First WGLC for CAPWAP Objectives Draft Done - Deadline to submit candidate protocol proposals to the WG Done - Second WGLC for CAPWAP Objectives Draft Done - Issue first Internet-Draft of CAPWAP Evaluation draft Done - Submit CAPWAP Evaluation draft to IESG as Information RFC Done - Submit CAPWAP Objectives draft to IESG as Informational RFC Done - Issue first Internet Draft of CAPWAP protocol Done - Issue first CAPWAP protocol 802.11bindings Jan 2007 - Issue first Internet-Draft of 802.11 Binding MIB Jan 2007 - Issue first Internet-Draft of CAPWAP Base MIB Feb 2007 - First WGLC for CAPWAP Base Protocol Feb 2007 - First WGLC for 802.11 Binding Mar 2007 - CAPWAP Specs to IEEE 802.11 for Review Apr 2007 - WGLC for CAPWAP Base MIB Apr 2007 - WGLC for CAPWAP 802.11 Binding MIB May 2007 - Receive results of IEEE 802.11 Review May 2007 - Final WGLC for CAPWAP Base Protocol May 2007 - Final WGLC for 802.11 Binding Jul 2007 - CAPWAP Base Protocol to IESG Jul 2007 - CAPWAP 802.11 Binding to IESG Sep 2007 - CAPWAP Base MIB to the IESG Sep 2007 - CAPWAP 802.11 Binding MIB to IESG Internet-Drafts: - CAPWAP Problem Statement [draft-ietf-capwap-problem-statement-03] (9 pages) - Architecture Taxonomy for Control and Provisioning of Wireless Access Points(CAPWAP) [draft-ietf-capwap-arch-07] (44 pages) - CAPWAP Tunneling Protocol (CTP) [draft-singh-capwap-ctp-02] (41 pages) - Objectives for Control and Provisioning of Wireless Access Points (CAPWAP) [draft-ietf-capwap-objectives-05] (35 pages) - LWAPP Self Evaluation [draft-calhoun-capwap-lwapp-objectives-comparison-01] (32 pages) - Evaluation of Wireless LAN Control Protocol (WiCoP) [draft-govindan-capwap-wicop-evaluation-00] (19 pages) - Evaluation of CAPWAP Tunneling Protocol (CTP) [draft-francisco-capwap-ctp-evaluation-01] (15 pages) - SLAPP Evaluation [draft-narasimhan-capwap-slapp-evaluation-00] (25 pages) - Evaluation of Candidate CAPWAP Protocols [draft-ietf-capwap-eval-01] (34 pages) - CAPWAP Protocol Specification [draft-ietf-capwap-protocol-specification-16] (165 pages) - CAPWAP Protocol Binding for IEEE 802.11 [draft-ietf-capwap-protocol-binding-ieee80211-13] (83 pages) - CAPWAP Threat Analysis for IEEE 802.11 Deployments [draft-ietf-capwap-threat-analysis-05] (34 pages) - CAPWAP Access Controller DHCP Option [draft-ietf-capwap-dhc-ac-option-03] (12 pages) - CAPWAP Protocol Base MIB [draft-ietf-capwap-base-mib-08] (82 pages) - CAPWAP Protocol Binding MIB for IEEE 802.11 [draft-ietf-capwap-802dot11-mib-06] (25 pages) Requests for Comments: RFC3990: CAPWAP Problem Statement (9 pages) RFC4118: Architecture Taxonomy for Control and Provisioning of Wireless Access Points(CAPWAP) (44 pages) RFC4565: Evaluation of Candidate Control and Provisioning of Wireless Access Points (CAPWAP) Protocols (34 pages) RFC4564: Objectives for Control and Provisioning of Wireless Access Points (CAPWAP) (35 pages) RFC5418: Control And Provisioning of Wireless Access Points (CAPWAP) Threat Analysis for IEEE 802.11 Deployments (34 pages) RFC5417: Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller DHCP Option (12 pages) RFC5416: Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11 (83 pages) RFC5415: Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification (165 pages) Diameter Maintenance and Extensions (dime) ------------------------------------------ Charter Last Modified: 2009-07-07 Current Status: Active Chairs: Hannes Tschofenig Victor Fajardo Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion: dime@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dime Archive: http://www.ietf.org/mail-archive/web/dime/current/maillist.html Description of Working Group: The Diameter Maintenance and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use for authentication, authorization, accounting and provisioning in network access as well as for other applications environments (e.g., IP telephony, mobility). The IETF has completed work on the Diameter Base protocol and is working on revising the base protocol specification. There is on-going work on defining RADIUS extensions and the DIME WG will ensure that work done in RADEXT is also available for Diameter. The DIME working group plains to address the following items: - Maintaining and/or progressing, along the standards track, the Diameter Base protocol and Diameter Applications. This includes extensions to Diameter Base protocol that can be considered as enhanced features or bug fixes, such NAI routing or capability update extensions. - Diameter application design guideline. This document will provide guidelines for design of Diameter extensions. It will detail when to consider reusing an existing application and when to develop a new application. - Diameter QoS extensions. This work focuses on extensions to Diameter to support QoS information to be authorized and provisioned in AAA deployments. - Protocol extensions for the management of Diameter entities. This work focuses on the standardization of Management Information Bases (MIBs) to configure Diameter entities (such as the Diameter Base protocol or Diameter Credit Control nodes). The usage of other management protocols for configuring Diameter entities may be future work within the group. - Diameter extensions for mobility protocols, such as Mobile IPv6 and Proxy Mobile IPv6. Diameter extensions to support handover keying developed in the HOKEY WG are part of this effort. - New Diameter applications, such as the Diameter NAT control application. This group will also conduct work on new Diameter applications with a Diameter application for configuring NATs as the first item. Additionally, AAA systems require interoperability in order to work. The working group, along with the AD, will need to evaluate any potential extensions and require verification that the proposed extension is needed. Coordination with other IETF working groups and other SDOs will used to ensure this. Goals and Milestones: Done - Submit the following two Diameter Mobility documents to the IESG for consideration as a Proposed Standards:* 'Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction' * 'Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction' Done - Submit 'Diameter API' to the IESG for consideration as an Informational RFC Done - Submit 'Quality of Service Parameters for Usage with Diameter' to the IESG for consideration as a Proposed Standard. Done - Submit 'Diameter QoS Application' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Support for EAP Re-authentication Protocol' as DIME working group item Done - Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' as DIME working group item Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working group item Done - Submit 'Quality of Service Attributes for Diameter' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' to the IESG for consideration as a Proposed Standard Jun 2009 - Submit new DIME charter to the IESG Jun 2009 - Submit 'Updated IANA Considerations for Diameter Command Code Allocations' as DIME working group item Jul 2009 - Submit 'Updated IANA Considerations for Diameter Command Code Allocations' to the IESG for consideration as a Proposed Standard Jul 2009 - Submit 'Diameter NAT Control Application' as DIME working group item Jul 2009 - Submit 'Diameter Capabilities Update' as DIME working group item Aug 2009 - Submit 'Diameter Application Design Guidelines' to the IESG for consideration as a BCP document Nov 2009 - Submit Revision of 'Diameter Base Protocol' to the IESG for consideration as a Proposed Standard Nov 2009 - Submit ' Diameter Credit Control Application MIB' to the IESG for consideration as an Informational RFC Nov 2009 - Submit 'Diameter Base Protocol MIB' to the IESG for consideration as an Informational RFC Nov 2009 - Submit 'Diameter Capabilities Update' to the IESG for consideration as a Proposed Standard Jan 2010 - Submit 'Diameter Support for EAP Re-authentication Protocol' to the IESG for consideration as a Proposed Standard Jan 2010 - Submit 'Diameter NAT Control Application' 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-17] (42 pages) - Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction [draft-ietf-dime-mip6-integrated-13] (18 pages) - Diameter Base Protocol [draft-ietf-dime-rfc3588bis-19] (159 pages) - Diameter Quality of Service Application [draft-ietf-dime-diameter-qos-13] (57 pages) - Quality of Service Parameters for Usage with Diameter [draft-ietf-dime-qos-parameters-12] (11 pages) - Diameter Applications Design Guidelines [draft-ietf-dime-app-design-guide-10] (16 pages) - Traffic Classification and Quality of Service Attributes for Diameter [draft-ietf-dime-qos-attributes-15] (44 pages) - Diameter Support for EAP Re-authentication Protocol (ERP) [draft-ietf-dime-erp-02] (18 pages) - Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server [draft-ietf-dime-pmip6-04] (21 pages) - Diameter User-Name and Realm Based Request Routing Clarifications [draft-ietf-dime-nai-routing-04] (12 pages) - Diameter Credit Control Application MIB [draft-ietf-dime-diameter-cc-appl-mib-03] (21 pages) - Diameter Base Protocol MIB [draft-ietf-dime-diameter-base-protocol-mib-04] (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-02] (6 pages) - The Diameter Capabilities Update Application [draft-ietf-dime-capablities-update-01] (7 pages) - Diameter NAT Control Application [draft-ietf-dime-nat-control-01] (40 pages) - Diameter Extended NAPTR [draft-ietf-dime-extended-naptr-00] (8 pages) - Diameter IKEv2: Support for Interaction between IKEv2 Server and Diameter Server [draft-ietf-dime-ikev2-psk-diameter-00] (19 pages) - Diameter Attribute-Value Pairs for Cryptographic Key Transport [draft-ietf-dime-local-keytran-01] (7 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 Domain Name System Operations (dnsop) ------------------------------------- Charter Last Modified: 2008-12-16 Current Status: Active Chairs: Rob Austein Peter Koch Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Ronald Bonica Mailing Lists: General Discussion: dnsop@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/dnsop Archive: http://www.ietf.org/mail-archive/web/dnsop Description of Working Group: The DNS Operations Working Group will develop guidelines for the operation of DNS software servers and the administration of DNS zone files. These guidelines will provide technical information relating to the implementation of the DNS protocol by the operators and administrators of DNS zones. The group will perform the following activities: 1. Define the processes by which Domain Name System (DNS) software may be efficiently and correctly administered, configured, and operated on Internet networks. This will include root zone name servers, gTLD name servers, name servers for other DNS zones, iterative DNS resolvers, and recursive DNS resolvers. As part of this effort, the group will produce documents explaining to the general Internet community what processes and mechanisms should be employed for the effective management and operation of DNS software. 2. Publish documents concerning DNSSEC operational procedures. 3. Publish documents concerning the IPv6 DNS operational procedures and DNS-related IPv6 transition and coexistence issues. 4. Publish documents concerning the operations of the root and TLD services, and DNS resolvers. Goals and Milestones: Done - Submit I-D: revised Root Server Requirements. Done - Submit I-D: revised version of Key Handling. Done - Submit I-D: first version of Servers Sharing IP#. Done - Submit I-D: first version of Performance and Measuring. Done - Submit I-D: revised version of Key Handling. Done - Submit I-D: revised version of Servers Sharing IP#. Done - Submit Root Server Requirements to the IESG for consideration as Informational (BCP?). Done - Submit I-D: 2nd revised version of Servers Sharing IP#. Done - Distributing Authoritative Name Servers via Shared Unicast Addresses to the IESG for Informational Done - Submit Observed DNS Resolution Misbehavior to the IESG for Informational Done - Submit document describing the outstanding problems and issues with DNS discovery for IPv6 to the IESG for Informational. Done - Submit Operational Guidelines for 'local' zones in the DNS to IESG. Category to be determined. Done - Submit Operational Considerations and Issues with IPv6 DNS to the IESG for Informational Done - Submit Common Misbehavior against DNS Queries for IPv6 Addresses to the IESG for Informational Done - Submit DNSSEC Operational Procedures to IESG for BCP Done - Submit Identifying an Authoritative Name Server to IESG for Informational Done - Submit I-D: revised version of Considerations for the use of DNS Reverse Mapping Done - Submit I-D: revised version of Considerations for the use of DNS Reverse Mapping Sep 2007 - Submit I-D: revised version of Considerations for the use of DNS Reverse Mapping Sep 2007 - Submit I'm Being Attacked by PRISONER.IANA.ORG! to IESG for FYI Sep 2007 - Submit Locally-served DNS Zones to IESG for BCP Oct 2007 - Submit DNS Response Size Issues to IESG for Informational Dec 2007 - Submit Considerations for the use of DNS Reverse Mapping to IESG for BCP Dec 2007 - Submit AS112 Nameserver Operations to IESG for Informational Feb 2008 - Submit Initializing a DNS Resolver with Priming Queries to IESG for BCP Internet-Drafts: - Domain Name System (DNS) Security Key Rollover [draft-ietf-dnsind-rollover-00] (11 pages) - Root Name Server Operational Requirements [draft-ietf-dnsop-root-opreq-05] (9 pages) - Handling of DNS Zone Signing Keys [draft-ietf-dnsop-keyhand-04] (9 pages) - Distributing Root Name Servers via Shared Unicast Addresses [draft-ietf-dnsop-shared-root-server-01] (4 pages) - Distributing Authorittative Name Servers via Shared Unicast Addresses [draft-ietf-dnsop-hardie-shared-root-server-07] (0 pages) - DNSSEC Implementation in the CAIRN Testbed [draft-ietf-dnsop-dnsseccairn-00] (22 pages) - Domain Name System (DNS) Security Key Rollover [draft-ietf-dnsop-rollover-01] (11 pages) - Root Name Servers with Inter Domain Anycast Addresses [draft-ietf-dnsop-ohta-shared-root-server-03] (5 pages) - Testing Root Name Servers with Inter Domain Anycast Addresses [draft-ietf-dnsop-ohta-shared-root-server-test-00] (3 pages) - Encouraging the use of DNS IN-ADDR Mapping [draft-ietf-dnsop-inaddr-required-07] (7 pages) - Parent's SIG over child's KEY [draft-ietf-dnsop-parent-sig-00] (0 pages) - DNS IPv6 transport operational guidelines [draft-ietf-dnsop-ipv6-transport-guidelines-03] (6 pages) - Rollover of statically configured resolver keys [draft-ietf-dnsop-resolver-rollover-00] (9 pages) - IP Addresses that should never appear in the public DNS [draft-ietf-dnsop-dontpublish-unreachable-03] (0 pages) - Observed DNS Resolution Misbehavior [draft-ietf-dnsop-bad-dns-res-07] (23 pages) - IPv4-to-IPv6 migration and DNS name space fragmentation [draft-ietf-dnsop-v6-name-space-fragmentation-01] (0 pages) - Requirements for a Mechanism Identifying a Name Server Instance [draft-ietf-dnsop-serverid-09] (13 pages) - Operational Considerations and Issues with IPv6 DNS [draft-ietf-dnsop-ipv6-dns-issues-13] (30 pages) - An Interim Scheme for Signing the Public DNS Root [draft-ietf-dnsop-interim-signed-root-01] (0 pages) - DNS Referral Response Size Issues [draft-ietf-dnsop-respsize-11] (13 pages) - IPv6 Host Configuration of DNS Server Information Approaches [draft-ietf-dnsop-ipv6-dns-configuration-07] (33 pages) - DNSSEC Operational Practices [draft-ietf-dnsop-dnssec-operational-practices-09] (36 pages) - Common Misbehavior against DNS Queries for IPv6 Addresses [draft-ietf-dnsop-misbehavior-against-aaaa-03] (8 pages) - Requirements for Automated Key Rollover in DNSsec [draft-ietf-dnsop-key-rollover-requirements-02] (8 pages) - Preventing Use of Recursive Nameservers in Reflector Attacks [draft-ietf-dnsop-reflectors-are-evil-07] (8 pages) - Locally-served DNS Zones [draft-ietf-dnsop-default-local-zones-09] (13 pages) - DNSSEC Trust Anchor Configuration and Maintenance [draft-ietf-dnsop-dnssec-trust-anchor-04] (14 pages) - Considerations for the use of DNS Reverse Mapping [draft-ietf-dnsop-reverse-mapping-considerations-06] (15 pages) - I'm Being Attacked by PRISONER.IANA.ORG! [draft-ietf-dnsop-as112-under-attack-help-help-03] (17 pages) - AS112 Nameserver Operations [draft-ietf-dnsop-as112-ops-03] (23 pages) - Initializing a DNS Resolver with Priming Queries [draft-ietf-dnsop-resolver-priming-02] (8 pages) - Requirements for Management of Name Servers for the DNS [draft-ietf-dnsop-name-server-management-reqs-04] (18 pages) - DNSSEC Operational Practices, Version 2 [draft-ietf-dnsop-rfc4641bis-02] (38 pages) - DNSSEC Signing Policy & Practice Statement Framework [draft-ietf-dnsop-dnssec-dps-framework-00] (28 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) Global Routing Operations (grow) -------------------------------- Charter Last Modified: 2008-12-16 Current Status: Active Chairs: Christopher Morrow Peter Schoenmaker Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Ronald Bonica Tech Advisors: Bill Fenner Vijay Gill Mailing Lists: General Discussion: grow@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/grow Archive: http://www.ietf.org/mail-archive/web/grow Description of Working Group: The Border Gateway Protocol (BGP) is fundamental to the operation of the Internet. In recent years, occurrences of BGP related operational issues have increased, and while overall understanding of the default-free routing system has improved, there is still a long and growing list of concerns. Among these are routing table growth rates, interaction of interior and exterior routing protocols, dynamic properties of the routing system, and the effects of routing policy on both the size and dynamic nature of the routing table. In addition, new and innovative uses of BGP, such as the use of BGP as a signaling protocol for some types of Virtual Private Networks, have created new and unexpected operational issues. The purpose of the GROW is to consider the operational problems associated with the IPv4 and IPv6 global routing systems, including but not limited to routing table growth, the effects of the interactions between interior and exterior routing protocols, and the effect of address allocation policies and practices on the global routing system. Finally, where appropriate, the GROW documents the operational aspects of measurement, policy, security, and VPN infrastructures. GROW will also advise various working groups, including the IDR and RPSEC working groups, with respect to whether it is addressing the relevant operational needs, and where appropriate, suggest course corrections. Finally, operational requirements developed in GROW can also be used by any new working group charged with standardizing a next generation inter-domain routing protocol. GOALS: ----- (i). Evaluate and develop various methodologies of controlling policy information in order to reduce the effect of prefix sub-aggregates beyond the necessary diameter, so as to reduce the Network Layer Reachability Information (or NLRI; see e.g.,draft-ietf-idr-bgp4-23.txt) load on network infrastructure. (ii). Document and suggest operational solutions to problematic aspects of the currently deployed routing system. Examples include instability caused by oscillation of MULTI_EXIT_DISC (or MED; see RFC 3345) values. (iii). Analyze aspects of supporting new applications, including extending existing routing protocols and creating new ones. This includes risk, interference and application fit. (iv). Determine the effect of IGP extensions on the stability of the Internet routing system. (v). Document the operational aspects of securing the Internet routing system, and provide recommendations to other WGs. Some Relevant References: ------------------------- http://www.routeviews.org http://bgp.potaroo.net http://www.cidr-report.org http://www.pch.net/routing/BGP_table_size.ital http://moat.nlanr.net/AS http://www.apnic.net/stats/bgp http://www.merit.edu/ipma http://www.caida.org/projects/routing/atoms Goals and Milestones: Done - Publish Risk, Interference and Fit (RIFT) document as WG I-D Done - Publish Embedding Globally ...Considered Harmful as WG I-D Done - Publish MED Considerations Draft as WG I-D Done - Publish Collection Communities as WG I-D Done - Submit Collection Communities to IESG for BCP Done - Submit Embedding Globally ...Considered Harmful to IESG for Info Done - Submit MED Considerations to IESG for Info Internet-Drafts: - BGP Communities for Data Collection [draft-ietf-grow-collection-communities-09] (13 pages) - Controlling the redistribution of BGP routes [draft-ietf-grow-bgp-redistribution-00] (16 pages) - Bounding Longest Match Considered [draft-grow-bounded-longest-match-00] (8 pages) - BGP MULTI_EXIT_DISC (MED) Considerations [draft-ietf-grow-bgp-med-considerations-06] (17 pages) - Embedding Globally Routable Internet Addresses Considered Harmful [draft-ietf-grow-embed-addr-06] (11 pages) - Operational Concerns and Considerations for Routing Protocol Design -- Risk, Interference, and Fit (RIFT) [draft-ietf-grow-rift-01] (39 pages) - BGP Wedgies [draft-ietf-grow-bgp-wedgies-04] (10 pages) - Operation of Anycast Services [draft-ietf-grow-anycast-05] (31 pages) - Classless Inter-Domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan [draft-ietf-grow-rfc1519bis-05] (29 pages) - MRT routing information export format [draft-ietf-grow-mrt-11] (28 pages) - BGP Monitoring Protocol [draft-ietf-grow-bmp-03] (14 pages) - Routing System Stability [draft-ietf-grow-rss-01] (13 pages) - MPLS Tunnels for Virtual Aggregation [draft-ietf-grow-va-mpls-01] (5 pages) - FIB Suppression with Virtual Aggregation [draft-ietf-grow-va-01] (27 pages) - Requirements for the graceful shutdown of BGP sessions [draft-ietf-grow-bgp-graceful-shutdown-requirements-01] (14 pages) - Graceful BGP session shutdown [draft-ietf-grow-bgp-gshut-01] (19 pages) - Performance of Virtual Aggregation [draft-ietf-grow-va-perf-01] (16 pages) - GRE and IP-in-IP Tunnels for Virtual Aggregation [draft-ietf-grow-va-gre-01] (7 pages) - Proposal to use an inner MPLS label to identify the remote ASBR VA [draft-ietf-grow-va-mpls-innerlabel-00] (6 pages) - Proposal for Auto-Configuration in Virtual Aggregation [draft-ietf-grow-va-auto-00] (11 pages) Requests for Comments: RFC4085: Embedding Globally Routable Internet Addresses Considered Harmful (11 pages) RFC4264: BGP Wedgies (10 pages) RFC4384: BGP Communities for Data Collection (13 pages) RFC4451: BGP MULTI_EXIT_DISC (MED) Considerations (17 pages) RFC4632: Classless Inter-Domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan (29 pages) RFC4786: Operation of Anycast Services (31 pages) IP Flow Information Export (ipfix) ---------------------------------- Charter Last Modified: 2009-09-29 Current Status: Active Chairs: Nevil Brownlee Juergen Quittek Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion: ipfix@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/ipfix Archive: http://www.ietf.org/mail-archive/web/ipfix Description of Working Group: The IPFIX working group has specified the Information Model (to describe IP flows) and the IPFIX protocol (to transfer IP flow data from IPFIX exporters to collectors). Several implementers have already built applications using the IPFIX protocol. As a result of a series of IPFIX interoperability testing events the WG has produced guidelines for IPFIX implementation and testing as well as recommendations for handling special cases such as bidirectional flow reporting and reducing redundancy in flow records. Practical experiences with IPFIX implementations exposed new requirements for the IPFIX protocol that so far have not been addressed by the WG. The major current goal of the WG is developing solutions that meet the new requirements without modifying the core IPFIX protocol specifications. 1. The IPFIX WG has developed a MIB module for monitoring IPFIX implementations. Means for configuring these devices have not been standardized yet. The WG will develop an XML-based configuration data model that can be used for configuring IPFIX devices and for storing, modifying and managing IPFIX configurations parameter sets. This work will be performed in close collaboration with the NETCONF WG. 2. First applications of IPFIX at large operator networks showed the need for mediation of flow information, for example, for aggregating huge amounts of flow data and for anomymization of flow information. The IPFIX WG will investigate this issue and produce a problem statement and a framework for IPFIX flow mediation. 3. The PSAMP WG has developed a protocol for reporting observed packets. The PSAMP protocol is an extension of the IPFIX protocol. The IPFIX WG will develop a MIB module for monitoring PSAMP implementations. The new MIB module will be an extension of the IPFIX MIB module. 4. Anonymization of flow information has been identified as a requirement for flow information export already in RFC 3917. However, technologies for flow anonymization are still a research issue and have so far not been considered to be mature enough for standardization. As one step in this direction, the IPFIX WG will develop guidelines for the implementation of anonymized data export and storage over IPFIX and define an information model for configuring and reporting anonymization applied at IPFIX devices. 5. The IPFIX and PSAMP WGs have defined standards for selecting observed IP packets and collecting information in flow records. In order to reduce the amount of data to be processed, packet selection methods have been defined. Another method for reducing flow data is flow selection. The IPFIX WG will define methods for flow selection and provide an information model for configuring and reporting flow selection applied at IPFIX devices. 6. Being designed for the export of flow records the IPFIX protocol provides very limited means for structuring information elements within IPFIX records. With the increasing number of IPFIX applications there is a need for exporting more complex information. The IPFIX WG will develop an extension of the IPFIX protocol that supports hierarchically structured data and lists (sequences) of Information Elements in data records. Goals and Milestones: Done - Submit Revised Internet-Draft on IP Flow Export Requirements Done - Submit Internet-Draft on IP Flow Export Architecture Done - Submit Internet-Draft on IP Flow Export Data Model Done - Submit Internet-Draft on IPFIX Protocol Evaluation Report Done - Submit Internet-Draft on IP Flow Export Applicability Statement Done - Select IPFIX protocol, revise Architecture and Data Model drafts Done - Submit IPFX-REQUIREMENTS to IESG for publication as Informational RFC Done - Submit IPFIX Protocol Evaluation Report to IESG for publication as Informational RFC Done - Submit IPFX-ARCHITECTURE to IESG for publication as Proposed Standard RFC Done - Submit IPFX-INFO_MODEL to IESG for publication as Informational RFC Done - Submit IPFX-APPLICABILITY to IESG for publication as Informational RFC Done - Submit IPFX-PROTOCOL to IESG for publication as Proposed Standard RFC Done - Publish Internet Draft on IPFIX Implementation Guidelines Done - Publish Internet Draft on IPFIX Testing Done - Publish Internet Draft on Reducing Redundancy in IPFIX data transfer Done - Publish Internet Draft on IPFIX MIB Done - Publish Internet Draft on Handling IPFIX Bidirectional Flows Done - Submit IPFIX Implementation Guidelines draft to IESG for publication as Informational RFC Done - Submit IPFIX Testing draft to IESG for publication as Informational RFC Done - Submit IPFIX Reducing Redundancy draft to IESG for publication as Informational RFC Done - Submit IPFIX Biflows draft to IESG for publication as Standards Track RFC Done - Publish Internet draft on IPFIX Type Information Export Done - Publish Internet draft on IPFIX Configuration Data Model Done - Publish Internet draft on IPFIX File Format Done - Publish Internet draft on Single SCTP Stream Reporting Done - Publish Internet draft on IPFIX Mediation Problem Statement Done - Submit File Format draft to IESG for publication as Standards track RFC Done - Submit IPFIX MIB draft to IESG for publication as Standards track RFC Done - Submit Type Export draft to IESG for publication as Standards track RFC Done - Submit Single SCTP Stream draft to IESG for publication as Informational RFC Oct 2009 - Submit Mediation Problem Statement I-D to IESG for publication as Informational RFC Oct 2009 - Submit initial draft on anonymization support Oct 2009 - Submit initial draft on flow selection Oct 2009 - Submit initial draft on structuring information elements Jan 2010 - Submit final version of PSAMP MIB module Jan 2010 - Submit Configuration Data Model draft to IESG for publication as Standards track RFC Jan 2010 - Submit Mediation Framework I-D to IESG for publication as Informational RFC Jun 2010 - Submit anonymization support I-D to IESG for publication as Experimental RFC Jun 2010 - Submit flow selection I-D to IESG for publication as Standards Track RFC Jun 2010 - Submit structuring information elements I-D to IESG for publication as Standards Track RFC Internet-Drafts: - Requirements for IP Flow Information Export [draft-ietf-ipfix-reqs-17] (32 pages) - Architecture for IP Flow Information Export [draft-ietf-ipfix-architecture-13] (32 pages) - IPFIX Data Model Data Model for IP Flow Information Export [draft-ietf-ipfix-data-00] (25 pages) - Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX) [draft-leinen-ipfix-eval-contrib-04] (28 pages) - Information Model for IP Flow Information Export [draft-ietf-ipfix-info-16] (170 pages) - Architecture Model for IP Flow Information Export [draft-ietf-ipfix-arch-02] (28 pages) - Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information [draft-ietf-ipfix-protocol-27] (65 pages) - IPFIX Applicability [draft-ietf-ipfix-as-13] (32 pages) - IPFIX Implementation Guidelines [draft-ietf-ipfix-implementation-guidelines-09] (36 pages) - Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports [draft-ietf-ipfix-reducing-redundancy-05] (32 pages) - Bidirectional Flow Export using IPFIX [draft-ietf-ipfix-biflow-06] (23 pages) - Guidelines for IP Flow Information eXport (IPFIX) Testing [draft-ietf-ipfix-testing-06] (38 pages) - Definitions of Managed Objects for IP Flow Information Export [draft-ietf-ipfix-mib-10] (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-07] (29 pages) - IPFIX Mediation: Framework [draft-ietf-ipfix-mediators-framework-04] (33 pages) - IPFIX Export per SCTP Stream [draft-ietf-ipfix-export-per-sctp-stream-06] (23 pages) - Configuration Data Model for IPFIX and PSAMP [draft-ietf-ipfix-configuration-model-04] (94 pages) - IP Flow Anonymisation Support [draft-ietf-ipfix-anon-01] (37 pages) - Export of Structured Data in IPFIX [draft-ietf-ipfix-structured-data-00] (57 pages) - Flow Selection Techniques [draft-ietf-ipfix-flow-selection-tech-00] (25 pages) - Reliability Extension for IPFIX [draft-ietf-ipfix-reliability-template-ext-00] (11 pages) Requests for Comments: RFC3917: Requirements for IP Flow Information Export (32 pages) RFC3955: Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX) (28 pages) RFC5103: Bidirectional Flow Export using IP Flow Information Export (IPFIX) (23 pages) RFC5102: Information Model for IP Flow Information Export (170 pages) RFC5101: Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information (65 pages) RFC5153: IPFIX Implementation Guidelines (36 pages) RFC5470: Architecture for IP Flow Information Export (32 pages) RFC5471: Guidelines for IP Flow Information Export (IPFIX) Testing (32 pages) RFC5472: IP Flow Information Export (IPFIX) Applicability (31 pages) RFC5473: Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports (27 pages) RFC5610: Exporting Type Information for IPFIX Information Elements (20 pages) RFC5655: Specification of the IP Flow Information Export (IPFIX) File Format (66 pages) IPv6 Operations (v6ops) ----------------------- Charter Last Modified: 2008-08-21 Current Status: Active Chairs: Fred Baker Kurt Lindqvist Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Ronald Bonica Mailing Lists: General Discussion: v6ops@ops.ietf.org To Subscribe: majordomo@ops.ietf.org Archive: http://ops.ietf.org/lists/v6ops/ Description of Working Group: The global deployment of IPv6 is underway, creating an IPv4/IPv6 Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and nodes. This deployment must be properly handled to avoid the division of the Internet into separate IPv4 and IPv6 networks while ensuring addressing and connectivity for all IPv4 and IPv6 nodes. The IPv6 Operations Working Group (v6ops) develops guidelines for the operation of a shared IPv4/IPv6 Internet and provides operational guidance on how to deploy IPv6 into existing IPv4-only networks, as well as into new network installations. The main focus of the v6ops WG is to look at the immediate deployment issues; more advanced stages of deployment and transition are a lower priority. The goals of the v6ops working group are: 1. Solicit input from network operators and users to identify operational issues with the IPv4/IPv6 Internet, and determine solutions or workarounds to those issues. These issues will be documented in Informational or BCP RFCs, or in Internet-Drafts. This work should primarily be conducted by those areas and WGs which are responsible and best fit to analyze these problems, but v6ops may also cooperate in focusing such work. 2. Publish Informational or BCP RFCs that identify potential security risks in the operation of shared IPv4/IPv6 networks, and document operational practices to eliminate or mitigate those risks. This work will be done in cooperation with the Security area and other relevant areas or working groups. 3. As a particular instance of (1) and (2), provide feedback to the IPv6 WG regarding portions of the IPv6 specifications that cause, or are likely to cause, operational or security concerns, and work with the IPv6 WG to resolve those concerns. This feedback will be published in Internet-Drafts or RFCs. 4. Publish Informational or BCP RFCs that identify and analyze solutions for deploying IPv6 within common network environments, such as ISP Networks, Enterprise Networks, Unmanaged Networks (Home/Small Office), and Cellular Networks. These documents should serve as useful guides to network operators and users on possible ways how to deploy IPv6 within their existing IPv4 networks, as well as in new network installations. These documents should not be normative guides for IPv6 deployment, and the primary intent is not capture the needs for new solutions, but rather describe which approaches work and which do not. IPv6 operational and deployment issues with specific protocols or technologies (such as Applications, Transport Protocols, Routing Protocols, DNS or Sub-IP Protocols) are the primary responsibility of the groups or areas responsible for those protocols or technologies. However, the v6ops WG may provide input to those areas/groups, as needed, and cooperate with those areas/groups in reviewing solutions to IPv6 operational and deployment problems. Future work items within this scope will be adopted by the WG only if there is a substantial expression of interest from the community and if the work clearly does not fit elsewhere in the IETF. There must be a continuous expression of interest for the WG to work on a particular work item. If there is no longer sufficient interest in the WG in a work item, the item may be removed from the list of WG items. Specifying any protocols or transition mechanisms is out of scope of the WG. Goals and Milestones: Done - Publish Cellular Deployment Scenarios as a WG I-D Done - Publish Unmanaged Network Deployment Scenarios as a WG I-D Done - Publish Survey of IPv4 Addresses in IETF Standards as WG I-D Done - Publish Cellular Deployment Solutions as a WG I-D Done - Publish Unmanaged Network Deployment Solutions as a WG I-D Done - Submit Cellular Deployment Scenarios to IESG for Info Done - Submit Unmanaged Network Deployment Scenarios to IESG for Info Done - Publish Enterprise Deployment Scenarios as a WG I-D Done - Submit Survey of IPv4 Addresses in IETF Standards to IESG for Info Done - Publish ISP Deployment & Solutions as a WG I-D Done - Submit Cellular Deployment Solutions to IESG for Info Done - Submit Transition Mechanisms to IESG for PS Done - Submit IPv6 Neighbor Discovery On-Link Assumption to IESG for Info Done - Submit Unmanaged Network Deployment Solutions to IESG for BCP Done - Submit Dual Stack IPv6 on by Default to IESG for Informational Done - Submit ISP Deployment Scenarios & Solutions to IESG for Info Done - Submit Application Aspects of IPv6 Transition to IESG for Informational Done - Submit 6to4 Security Analysis to IESG for Informational Done - Submit Enterprise Deployment Scenarios to IESG for Info Done - Submit Renumbering Procedures to IESG for Info Done - Adopt IPv6 Network Architecture Protection as WG item Done - Adopt document describing how to use IPsec with draft-ietf-v6ops-mech-v2 as WG item Done - Adopt IPv6 Security Overview as WG item Done - Ensure draft-ietf-v6ops-v6onbydefault keeps going forward for RFC publication Done - Submit IPv6 deployment using VLANs to IESG for Info Done - Submit document describing issues with NAT-PT to IESG for Info Done - Submit document on IPsec w/ draft-ietf-v6ops-mech-v2 to IESG for Info Done - Adopt IPv6 deployment using VLANs to IESG for Info Done - Adopt ISP IPv6 Deployment Scenarios in Broadband Access Networks as WG item Done - Submit IPv6 Network Architecture Protection to IESG for Info Done - Submit Enterprise Deployment Analysis to IESG for Info Done - Submit IPv6 Security Overview to IESG for Info Done - Submit ISP IPv6 Deployment Scenarios in Broadband Access Networks to IESG for Info Internet-Drafts: - IPv4/IPv6 Coexistence and Transition: Requirements for solutions [draft-ietf-v6ops-nat64-pb-statement-req-00] (17 pages) - Transition Scenarios for 3GPP Networks [draft-ietf-v6ops-3gpp-cases-03] (11 pages) - Analysis on IPv6 Transition in 3GPP Networks [draft-ietf-v6ops-3gpp-analysis-12] (22 pages) - Unmanaged Networks IPv6 Transition Scenarios [draft-ietf-v6ops-unman-scenarios-04] (19 pages) - Survey of IPv4 Addresses in Currently Deployed IETF Standards [draft-ietf-v6ops-ipv4survey-00] (0 pages) - Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards [draft-ietf-v6ops-ipv4survey-apps-05] (55 pages) - Survey of IPv4 Addresses in Currently Deployed IETF General Area Standards [draft-ietf-v6ops-ipv4survey-gen-00] (0 pages) - Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards [draft-ietf-v6ops-ipv4survey-ops-06] (0 pages) - Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards [draft-ietf-v6ops-ipv4survey-int-04] (56 pages) - Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards [draft-ietf-v6ops-ipv4survey-intro-07] (0 pages) - Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards [draft-ietf-v6ops-ipv4survey-routing-04] (17 pages) - Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards [draft-ietf-v6ops-ipv4survey-sec-05] (0 pages) - Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards [draft-ietf-v6ops-ipv4survey-subip-05] (0 pages) - Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards [draft-ietf-v6ops-ipv4survey-trans-06] (0 pages) - IPv6 Enterprise Networks Scenarios [draft-ietf-v6ops-entnet-scenarios-00] (17 pages) - Basic Transition Mechanisms for IPv6 Hosts and Routers [draft-ietf-v6ops-mech-v2-08] (29 pages) - Evaluation of Transition Mechanisms for Unmanaged Networks [draft-ietf-v6ops-unmaneval-04] (18 pages) - Security Considerations for 6to4 [draft-ietf-v6ops-6to4-security-05] (41 pages) - IPv6 Enterprise Network Scenarios [draft-ietf-v6ops-ent-scenarios-06] (18 pages) - Issues with Dual Stack IPv6 on by Default [draft-ietf-v6ops-v6onbydefault-03] (14 pages) - IPv6 Neighbor Discovery On-Link Assumption Considered Harmful [draft-ietf-v6ops-onlinkassumption-05] (11 pages) - Recommendations for Filtering ICMPv6 Messages in Firewalls [draft-ietf-v6ops-icmpv6-filtering-recs-04] (36 pages) - Scenarios and Analysis for Introducing IPv6 into ISP Networks [draft-ietf-v6ops-isp-scenarios-analysis-04] (27 pages) - Application Aspects of IPv6 Transition [draft-ietf-v6ops-application-transition-04] (30 pages) - IPv6 Enterprise Network Analysis - IP Layer 3 Focus [draft-ietf-v6ops-ent-analysis-08] (42 pages) - Procedures for Renumbering an IPv6 Network without a Flag Day [draft-ietf-v6ops-renumbering-procedure-06] (25 pages) - Goals for Registered Assisted Tunneling [draft-ietf-v6ops-assisted-tunneling-requirements-01] (14 pages) - Reasons to Move NAT-PT to Experimental [draft-ietf-v6ops-natpt-to-exprmntl-03] (25 pages) - ISP IPv6 Deployment Scenarios in Broadband Access Networks [draft-ietf-v6ops-bb-deployment-scenarios-06] (79 pages) - Local Network Protection for IPv6 [draft-ietf-v6ops-nap-07] (46 pages) - IPv6 Transition/Co-existence Security Considerations [draft-ietf-v6ops-security-overview-07] (40 pages) - Using IPsec to Secure IPv6-in-IPv4 Tunnels [draft-ietf-v6ops-ipsec-tunnels-06] (22 pages) - Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks [draft-ietf-v6ops-vlan-usage-02] (13 pages) - Best Current Practice for Filtering ICMPv6 Messages in Firewalls [draft-ietf-v6ops-icmpv6-filtering-bcp-01] (34 pages) - Requirements for Address Selection Mechanisms [draft-ietf-v6ops-addr-select-req-08] (9 pages) - IPv6 Deployment Scenarios in 802.16 Networks [draft-ietf-v6ops-802-16-deployment-scenarios-08] (17 pages) - IPv6 Unicast Address Assignment Considerations [draft-ietf-v6ops-addcon-11] (35 pages) - IPv6 Routing Policies Guidelines [draft-ietf-v6ops-routing-guidelines-01] (8 pages) - IPv6 Implications for Network Scanning [draft-ietf-v6ops-scanning-implications-05] (13 pages) - IPv6 Campus Transition Scenario Description and Analysis [draft-ietf-v6ops-campus-transition-01] (28 pages) - Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues [draft-ietf-v6ops-addr-select-ps-10] (17 pages) - Special-Use IPv6 Addresses [draft-ietf-v6ops-rfc3330-for-ipv6-05] (8 pages) - Reasons to Move NAT-PT to Historic Status [draft-ietf-v6ops-natpt-to-historic-01] (25 pages) - Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service [draft-ietf-v6ops-cpe-simple-security-08] (36 pages) - Teredo Security Concerns [draft-ietf-v6ops-teredo-security-concerns-03] (20 pages) - IPv6 RA-Guard [draft-ietf-v6ops-ra-guard-04] (10 pages) - Security Concerns With IP Tunneling [draft-ietf-v6ops-tunnel-security-concerns-01] (20 pages) - Basic Requirements for IPv6 Customer Edge Routers [draft-ietf-v6ops-ipv6-cpe-router-04] (15 pages) - Rogue IPv6 Router Advertisement Problem Statement [draft-ietf-v6ops-rogue-ra-01] (16 pages) - IPv6 Deployment in Internet Exchange Points (IXPs) [draft-ietf-v6ops-v6inixp-05] (12 pages) - An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition [draft-ietf-v6ops-incremental-cgn-00] (11 pages) Requests for Comments: RFC3574: Transition Scenarios for 3GPP Networks (12 pages) RFC3750: Unmanaged Networks IPv6 Transition Scenarios (19 pages) RFC3793: Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards (0 pages) RFC3796: Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards (0 pages) RFC3795: Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards (55 pages) RFC3794: Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards (0 pages) RFC3792: Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards (0 pages) RFC3791: Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards (17 pages) RFC3790: Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards (56 pages) RFC3789: Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards (0 pages) RFC3904: Evaluation of Transition Mechanisms for Unmanaged Networks (18 pages) RFC3964: Security Considerations for 6to4 (41 pages) RFC4038: Application Aspects of IPv6 Transition (30 pages) RFC4029: Scenarios and Analysis for Introducing IPv6 into ISP Networks (27 pages) RFC4057: IPv6 Enterprise Network Scenarios (18 pages) RFC4192: Procedures for Renumbering an IPv6 Network without a Flag Day (25 pages) * Updates RFC2072 RFC4215: Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks (22 pages) RFC4213: Basic Transition Mechanisms for IPv6 Hosts and Routers (29 pages) * Obsoletes RFC2893 RFC4554: Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks (13 pages) RFC4779: ISP IPv6 Deployment Scenarios in Broadband Access Networks (79 pages) RFC4852: IPv6 Enterprise Network Analysis - IP Layer 3 Focus (42 pages) RFC4890: Recommendations for Filtering ICMPv6 Messages in Firewalls (36 pages) RFC4891: Using IPsec to Secure IPv6-in-IPv4 Tunnels (22 pages) RFC4864: Local Network Protection for IPv6 (46 pages) RFC4966: Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status (25 pages) * Obsoletes RFC2766 RFC4943: IPv6 Neighbor Discovery On-Link Assumption Considered Harmful (11 pages) RFC4942: IPv6 Transition/Co-existence Security Considerations (40 pages) RFC5156: Special-Use IPv6 Addresses (8 pages) RFC5157: IPv6 Implications for Network Scanning (13 pages) RFC5181: IPv6 Deployment Scenarios in 802.16 Networks (16 pages) RFC5220: Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues (17 pages) RFC5221: Requirements for Address Selection Mechanisms (7 pages) RFC5375: IPv6 Unicast Address Assignment Considerations (35 pages) MBONE Deployment (mboned) ------------------------- Charter Last Modified: 2009-01-28 Current Status: Active Chairs: Leonard Giuliano Greg Shepherd Marshall Eubanks Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Ronald Bonica Tech Advisor: Scott Bradner Mailing Lists: General Discussion: mboned@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mboned Archive: http://www.ietf.org/mail-archive/web/mboned Description of Working Group: The MBONE Deployment Working Group is a forum for coordinating the deployment, engineering, and operation of multicast routing protocols and procedures in the global Internet. This activity will include, but not be limited to: - Documenting deployment of multicast routing in the global Internet. - Receive regular reports on the current state of the deployment of multicast technology. Create "practice and experience" documents that capture the experience of those who have deployed and are deploying various multicast technologies. - Based on reports and other information, provide feedback to other relevant working groups. - Develop mechanisms and procedures for sharing operational information to aid in operation of the multicast backbones and interconnects. - Update RFC 3171/BCP 51 based on experience. - Develop a roadmap informational RFC that describes the current IPv4 and IPv6 IETF multicast architectures, including references to the relevant IETF documents and guidance for implementers and network operators. - Complete the MSDP MIB This is not meant to be a protocol development Working Group. Goals and Milestones: Done - Submit I-D on inter-provider coordination of the deployment of pruning mrouteds. Done - Establish initial charter, goals, and long-term group agenda. Done - Submit I-D outlining requirements for the existing MBONE infrastructure. Done - Submit I-D specifying the use of administratively scoped multicast addresses (RFC 2365) Done - Submit I-D specifying the use of native multicast where appropriate (e.g. exchange points). Done - Submit I-D on IP Multicast and Firewalls (RFC 2588) Done - Submit I-D specifying static allocations in 233/87 (RFC 3180) Done - Submit I-D on debugging multicast problems. Done - Submit final version of scope zone announcement protocol (MZAP RFC 2776) Done - Submit final version of scoped address discovery protocol (SADP) Done - Submit I-D describing ISP multicast deployment practices Done - Submit I-D, with RPS WG, on extensions to RPSL to describe multicast routing policy Done - Submit I-D describing extended allocations in 233/8 (RFC 3138) Done - Submit I-D describing IANA Guidelines for IPv4 Multicast Address Assignments (RFC 3171) Done - Submit I-D describing IP Multicast Applications issues (RFC 3170) Done - Submit I-D describing Anycast (RP) mechanism (RFC 3446) Done - Submit I-D describing Source-Specific Protocol Independent Multicast in 232/8 Done - Submit I-D describing MSDP Deployment Scenarios Done - Submit I-D describing IPv4 Multicast Unusable Group And Source Addresses Done - Submit I-D describing Embedded RP for IPv6 Multicast Address Apr 2004 - Submit I-D on PIM-SM Multicast Routing Security Issues May 2004 - Submit I-D on IPv4/IPv6 multicast co-existence issues and strategies for IPv4 multicast and IPv6 multicast Jun 2004 - Update IANA Guidelines for IPv4 Multicast Address Assignments (RFC 3171/BCP 51) Jun 2004 - Submit PIM-SM Multicast Routing Security Issues to IESG for Informational Jun 2004 - Submit MSDP MIB to IESG for Experimental Aug 2004 - Submit IPv4 multicast address allocation procedures IESG for BCP Aug 2004 - Submit IPv4/v6 co-existence strategies to IESG for Informational Aug 2004 - Submit multicast roadmap/reference architecture document to IESG for Informational Internet-Drafts: - Multicast pruning a necessity [draft-ietf-mboned-pruning-02] (3 pages) - The Use of SNTP as a Multicast Heartbeat [draft-ietf-mboned-sntp-heart-00] (8 pages) - Administratively Scoped IP Multicast [draft-ietf-mboned-admin-ip-space-06] (8 pages) - Introduction to IP Multicast Routing [draft-ietf-mboned-intro-multicast-03] (60 pages) - Some Issues for an Inter-domain Multicast Routing Protocol [draft-ietf-mboned-imrp-some-issues-03] (12 pages) - Guidelines for Rate Limits on the MBONE [draft-ietf-mboned-limit-rate-guide-00] (3 pages) - PIM Multicast Border Router (PMBR) specification for connecting PIM-SM domains to a DVMRP Backbone [draft-ietf-mboned-pmbr-spec-00] (8 pages) - Multicast Debugging Handbook [draft-ietf-mboned-mdh-05] (34 pages) - Administratively Scoped IP Multicast [draft-ietf-mboned-oops-disregard-00] (6 pages) - Multicast-Scope Zone Announcement Protocol (MZAP) [draft-ietf-mboned-mzap-07] (29 pages) - IP Multicast and Firewalls [draft-ietf-mboned-mcast-firewall-03] (7 pages) - Scoped Address Discovery Protocol (SADP) [draft-ietf-mboned-sadp-02] (14 pages) - Multicast-Friendly Internet Exchange (MIX) [draft-ietf-mboned-mix-01] (10 pages) - IP Multicast Applications: Challenges and Solutions [draft-ietf-mboned-mcast-apps-02] (28 pages) - Justification for and use of the Multicast Routing Monitor (MRM) Protocol [draft-ietf-mboned-mrm-use-00] (9 pages) - Using MSDP to create Logical RPs [draft-ietf-mboned-logical-rp-00] (7 pages) - Static Allocations in 233/8 [draft-ietf-mboned-static-allocation-00] (5 pages) - GLOP Addressing in 233/8 [draft-ietf-mboned-glop-addressing-03] (5 pages) - Anycast RP mechanism using PIM and MSDP [draft-ietf-mboned-anycast-rp-08] (9 pages) - Multicast Reachability Monitor (MRM) [draft-ietf-mboned-mrm-01] (22 pages) - Connecting Multicast Domains [draft-ietf-mboned-mcast-connect-00] (14 pages) - Source-Specific Protocol Independent Multicast in 232/8 [draft-ietf-mboned-ssm232-10] (9 pages) - Automatic IP Multicast Without Explicit Tunnels (AMT) [draft-ietf-mboned-auto-multicast-09] (38 pages) - IANA Guidelines for IPv4 Multicast Address Assignments [draft-ietf-mboned-iana-ipv4-mcast-guidelines-04] (9 pages) - Extended Allocations in 233/8 [draft-ietf-mboned-glop-extensions-02] (5 pages) - GLOP Addressing in 233/8 [draft-ietf-mboned-glop-update-01] (6 pages) - Multicast Source Discovery Protocol (MSDP) Deployment Scenarios [draft-ietf-mboned-msdp-deploy-07] (20 pages) - IPv4 Multicast Best Current Practice [draft-ietf-mboned-ipv4-mcast-bcp-01] (12 pages) - IANA Guidelines for IPv4 Multicast Address Assignments [draft-ietf-mboned-rfc3171-update-00] (9 pages) - Unicast-Prefix-based IPv4 Multicast Addresses [draft-ietf-mboned-ipv4-uni-based-mcast-07] (6 pages) - Internet Multicast Gap Analysis from the MBONED Working Group for the IESG [draft-ietf-mboned-iesg-gap-analysis-00] (14 pages) - IPv4 Multicast Unusable Group And Source Addresses [draft-ietf-mboned-ipv4-mcast-unusable-01] (7 pages) - Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address [draft-ietf-mboned-embeddedrp-08] (18 pages) - IANA Guidelines for IPv4 Multicast Address Assignments [draft-ietf-mboned-rfc3171bis-08] (11 pages) - PIM-SM Multicast Routing Security Issues and Enhancements [draft-ietf-mboned-mroutesec-05] (21 pages) - Multicast Source Discovery protocol MIB [draft-ietf-mboned-msdp-mib-02] (34 pages) - IPv6 Multicast Deployment Issues [draft-ietf-mboned-ipv6-multicast-issues-02] (12 pages) - Overview of the Internet Multicast Addressing Architecture [draft-ietf-mboned-addrarch-07] (16 pages) - Lightweight Multicast Address Discovery Problem Space [draft-ietf-mboned-addrdisc-problems-02] (11 pages) - Overview of the Internet Multicast Routing Architecture [draft-ietf-mboned-routingarch-13] (24 pages) - Requirements for Multicast AAA coordinated between Content Provider(s) and Network Service Provider(s) [draft-ietf-mboned-maccnt-req-09] (16 pages) - Issues Related to Receiver Access Control in the Current Multicast Protocols [draft-ietf-mboned-rac-issues-03] (24 pages) - IP Multicast MIB [draft-ietf-mboned-ip-mcast-mib-08] (61 pages) - AAA and Admission Control Framework for Multicasting [draft-ietf-mboned-multiaaa-framework-11] (22 pages) - Lightweight IGMPv3 and MLDv2 Protocols [draft-ietf-mboned-lightweight-igmpv3-mldv2-06] (23 pages) - Moving MCAST.NET into the ARPA infrastructure top level domain [draft-ietf-mboned-mcast-arpa-01] (8 pages) - Multicast Ping Protocol [draft-ietf-mboned-ssmping-07] (21 pages) - Mtrace Version 2: Traceroute Facility for IP Multicast [draft-ietf-mboned-mtrace-v2-06] (38 pages) - Requirements for IP Multicast Session Announcement [draft-ietf-mboned-session-announcement-req-02] (14 pages) Requests for Comments: RFC2365: Administratively Scoped IP Multicast (8 pages) RFC2588: IP Multicast and Firewalls (12 pages) RFC2770: GLOP Addressing in 233/8 (5 pages) * OBSOLETED BY RFC3180 RFC2776: Multicast-Scope Zone Announcement Protocol (MZAP) (27 pages) RFC3138: Extended Allocations in 233/8 (4 pages) RFC3171: IANA Guidelines for IPv4 Multicast Address Assignments (8 pages) RFC3170: IP Multicast Applications: Challenges and Solutions (29 pages) RFC3180: GLOP Addressing in 233/8 (5 pages) * Obsoletes RFC2770 RFC3446: Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP) (7 pages) RFC3956: Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address (18 pages) * Updates RFC3306 RFC4611: Multicast Source Discovery Protocol (MSDP) Deployment Scenarios (20 pages) RFC4608: Source-Specific Protocol Independent Multicast in 232/8 (9 pages) RFC4609: Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements (21 pages) RFC4624: Multicast Source Discovery Protocol (MSDP) MIB (34 pages) RFC5132: IP Multicast MIB (61 pages) * Obsoletes RFC2932 RFC5110: Overview of the Internet Multicast Routing Architecture (24 pages) NETCONF Data Modeling Language (netmod) --------------------------------------- Charter Last Modified: 2009-05-06 Current Status: Active Chairs: David Partain David Kessens Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion: netmod@ietf.org To Subscribe: netmod-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/netmod/ Description of Working Group: The NETCONF Working Group has completed a base protocol to be used for configuration management. However, the NETCONF protocol does not include a standard content layer. The specifications do not include a modeling language or accompanying rules that can be used to model the management information that is to be configured using NETCONF. This has resulted in inconsistent syntax and interoperability problems. The purpose of NETMOD is to support the ongoing development of IETF and vendor-defined data models for NETCONF. NETMOD's requirements are drawn from the RCDML requirements draft (draft-presuhn-rcdml) and documents referenced therein. The WG will define a "human-friendly" modeling language defining the semantics of operational data, configuration data, notifications, and operations. This language will focus on readability and ease of use. This language must be able to serve as the normative description of NETCONF data models. The WG will use YANG (draft-bjorklund-yang) as its starting point for this language. Language abstractions that facilitate model extensibility and reuse have been identified as a work area and will be considered as a work item or may be integrated into the YANG document based on WG consensus. The WG will define a canonical mapping of this language to NETCONF XML instance documents, the on-the-wire format of YANG-defined XML content. Only data models defined in YANG will have to adhere to this on-the-wire format. In order to leverage existing XML tools for validating NETCONF data in various contexts and also facilitate exchange of data models and schemas with other IETF working groups, the WG will define standard mapping rules from YANG to the DSDL data modeling framework (ISO/IEC 19757) with additional annotations to preserve semantics. The initial YANG mapping rules specifications are expressly defined for NETCONF modeling. However, there may be future areas of applicability beyond NETCONF, and the WG must provide suitable language extensibility mechanisms to allow for such future work. The NETMOD WG will only address modeling NETCONF devices and the language extensibility mechanisms. Any application of YANG to other protocols is future work. The WG will consult with the NETCONF WG to ensure that NETMOD's decision do not conflict with planned work in NETCONF (e.g., locking, notifications). While it is desirable to provide a migration path from existing MIB modules to YANG data models (modules), it is not a requirement to provide full compatibility between SMIv2 and YANG. The Working Group will determine which constructs (e.g., conformance statements) are not relevant for translation from SMIv2 to YANG. YANG is also permitted to introduce constructs that cannot be expressed in SMIv2. However, all basic types that can be represented in SMIv2 must be expressible in YANG. Initial deliverables are below. The working group may choose to combine multiple deliverables into a single document where deemed appropriate. 1. An architecture document explaining the relationship between YANG and its inputs and outputs. (informational) 2. The YANG data modeling language and semantics (proposed standard) 3. Mapping rules of YANG to XML instance data in NETCONF (proposed standard) 4. YIN, a semantically equivalent fully reversible mapping to an XML-based syntax for YANG. YIN is simply the data model in an XML syntax that can be manipulated using existing XML tools (e.g., XSLT) (proposed standard) 5. Mapping rules of YANG to DSDL data modeling framework (ISO/IEC 19757), including annotations for DSDL to preserve top-level semantics during translation (proposed standard). 6. A standard type library for use by YANG (proposed standard) Goals and Milestones: Jun 2008 - All _individual_ drafts available that will be used as input into the WG documents (draft-bjorklund-yang, architecture draft, YIN draft, YANG standard library draft, DSDL mapping rules draft) Aug 2008 - Initial set of WG drafts: architecture, YANG, YIN, YANG standard library, DSDL mapping rules (if there is one/more individual draft), based on WG decisions in Dublin Sep 2008 - Initial DSDL mapping rules document Oct 2008 - 01 of YANG, DSDL, architecture, YIN, and standard library draft. If split out, -00 of on-the-wire XML draft. May 2009 - WGLC for Netmod architecture document May 2009 - Initial YANG Usage guidelines document available as a working group document Jun 2009 - Submit the architecture document to the IESG for publication as an Informational RFC Aug 2009 - WGLC for YANG, YIN, XML on-the-wire (if split out), YANG standard library, DSDL mapping rules Sep 2009 - Submit YANG, YIN, XML on-the-wire (if split out), YANG standard library, DSDL mapping rules to the IESG for publication as a Proposed Standard Sep 2009 - Submit YANG Usage Guidelines to the IESG for publication as an Informational RFC Internet-Drafts: - YANG - A data modeling language for NETCONF [draft-ietf-netmod-yang-10] (181 pages) - Common YANG Data Types [draft-ietf-netmod-yang-types-06] (31 pages) - Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content [draft-ietf-netmod-dsdl-map-04] (120 pages) - An NETCONF- and NETMOD-based Architecture for Network Management [draft-ietf-netmod-arch-03] (20 pages) - Guidelines for Authors and Reviewers of YANG Data Model Documents [draft-ietf-netmod-yang-usage-03] (29 pages) No Requests for Comments Network Configuration (netconf) ------------------------------- Charter Last Modified: 2010-01-12 Current Status: Active Chairs: Bert Wijnen Mehmet Ersue Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Tech Advisor: Charlie Kaufman Mailing Lists: General Discussion: netconf@ietf.org To Subscribe: netconf-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/netconf/ Description of Working Group: Charlie Kaufman is Technical Advisor for Security Matters Configuration of networks of devices has become a critical requirement for operators in today's highly interoperable networks. Operators from large to small have developed their own mechanisms or used vendor specific mechanisms to transfer configuration data to and from a device, and for examining device state information which may impact the configuration. Each of these mechanisms may be different in various aspects, such as session establishment, user authentication, configuration data exchange, and error responses. The NETCONF Working Group is chartered to produce a protocol suitable for network configuration, with the following characteristics: - Provides retrieval mechanisms which can differentiate between configuration data and non-configuration data - Is extensible enough so that vendors will provide access to all configuration data on the device using a single protocol - Has a programmatic interface (avoids screen scraping and formatting-related changes between releases) - Uses a textual data representation, that can be easily manipulated using non-specialized text manipulation tools. - Supports integration with existing user authentication methods - Supports integration with existing configuration database systems - Supports network wide configuration transactions (with features such as locking and rollback capability) - Is as transport-independent as possible - Provides support for asynchronous notifications. The NETCONF protocol is using XML for data encoding purposes, because XML is a widely deployed standard which is supported by a large number of applications. The NETCONF protocol should be independent of the data definition language and data models used to describe configuration and state data. However, the authorization model used in the protocol is dependent on the data model. Although these issues must be fully addressed to develop standard data models, only a small part of this work will be initially addressed. This group will specify requirements for standard data models in order to fully support the NETCONF protocol, such as: - identification of principals, such as user names or distinguished names - mechanism to distinguish configuration from non-configuration data - XML namespace conventions - XML usage guidelines The initial work started in 2003 and has already been completed and was restricted to following items: a) NETCONF Protocol Specification, which defines the operational model, protocol operations, transaction model, data model requirements, security requirements, and transport layer requirements. b) NETCONF over SSH Specification: Implementation Mandatory, c) NETCONF over BEEP Specification: Implementation Optional, d) NETCONF over SOAP Specification: Implementation Optional. These documents define how the NETCONF protocol is used with each transport protocol selected by the working group, and how it meets the security and transport layer requirements of the NETCONF Protocol Specification. e) NETCONF Notification Specification, which defines mechanisms that provide an asynchronous message notification delivery service for the NETCONF protocol. NETCONF Notification is an optional capability built on top of the base NETCONF definition and provides the capabilities and operations necessary to support this service. The NETCONF notification specification has been finished now as well. In the current phase of the incremental development of NETCONF the workgroup will focus on following items: 1. Fine-grain locking: The base NETCONF protocol only provides a lock for the entire configuration datastore, which is not deemed to meet important operational and security requirements. The NETCONF working group will produce a standards-track RFC specifying a mechanism for fine-grain locking of the NETCONF configuration datastore. 2. NETCONF monitoring: It is considered best practice for IETF working groups to include management of their protocols within the scope of the solution they are providing. The NETCONF working group will produce a standards-track RFC with mechanisms allowing NETCONF itself to be used to monitor some aspects of NETCONF operation. 3. Schema advertisement: Currently the NETCONF protocol is able to advertise which protocol features are supported on a particular netconf-capable device. However, there is currently no way to discover which XML Schema are supported on the device. The NETCONF working group will produce a standards-track RFC with mechanisms making this discovery possible (this item may be merged with "NETCONF monitoring" into a single document). Note: The schema-advertisement material has been merged into the NETCONF monitoring document based on WG consensus. 4. NETCONF over TLS: Based on implementation experience there is a need for a standards track document to define NETCONF over TLS as an optional transport for the NETCONF protocol. 5. NETCONF default handling: NETCONF today does not define whether default values should be returned by the server in replies to requests for reading configuration and state data. Different clients have different needs to receive or not to receive default data. The NETCONF working group will produce a standards-track RFC defining a mechanism that allows NETCONF clients to control whether default data is returned by the netconf server. 6. NETCONF implementations have shown that the specification in RFC4741 is not 100% clear and has lead to different interpretations and implementations. Also some errors have been uncovered. So the WG will do an rfc4741bis with following constraints: - bug fixes are to be done - clarifications can be done - extensions can be done only when needed to fix bugs or inconsistencies (i.e. we are not doing a NETCONF V2) - The work can be started based on the discussion in IETF #73 (see http://www.ietf.org/proceedings/08nov/slides/netconf-3.pdf). Note: A technical errata has been posted on rfc4742. If the work on rfc4741bis uncovers any additional fixes/clarifications that need to be made to rfc4742, the WG may consider to also do a rfc4742bis as part of this work-item. The following items have been identified as important but are currently not considered in scope for re-chartering and may be candidates for work when there is community consensus to take them on: - NETCONF Notification content - Access Control requirements - NETCONF access to SMI-based MIB data Goals and Milestones: Done - Working Group formed Done - Submit initial Netconf Protocol draft Done - Submit initial Netconf over (transport-TBD) draft Done - Begin Working Group Last Call for the Netconf Protocol draft Done - Begin Working Group Last Call for the Netconf over (transport-TBD) draft Done - Submit final version of the Netconf Protocol draft to the IESG Done - Submit final version of the Netconf over SOAP draft to the IESG Done - Submit final version of the Netconf over BEEP draft to the IESG Done - Submit final version of the Netconf over SSH draft to the IESG Done - Update charter Done - Submit first version of NETCONF Notifications document Done - Begin WGLC of NETCONF Notifications document Done - Submit final version of NETCONF Notifications document to IESG for consideration as Proposed Standard Done - -00 draft for NETCONF Monitoring Done - -00 draft for Schema Advertisement Done - -00 draft for Fine Grain Locking Done - -00 draft for NETCONF over TLS Done - Early Review of client authentication approach (for NETCONF over TLS) with the security community at IETF 71 Done - WG Last Call on NETCONF Monitoring after IETF72 Done - WG Last Call on NETCONF over TLS after IETF72 Done - WG Last Call on Fine Grain Locking after IETF72 Done - Send Partial Locking to IESG for consideration as Proposed Standards Done - Initial WG draft for with-defaults capability Done - Initial WG draft for rfc4741bis Done - WG Last Call on NETCONF Monitoring after IETF73 Done - Submit first WG draft for rfc4742bis Mar 2010 - WG Last Call on rfc4741bis Mar 2010 - WG Last Call on with-defaults Mar 2010 - Send NETCONF monitoring to IESG for approval as Proposed Standard Mar 2010 - WG Last Call for rfc4742bis Jun 2010 - rfc4741bis to IESG for considerations as Proposed Standard Jun 2010 - with-defaults capability to IESG for considerations as Proposed Standard Jun 2010 - Send rfc4742bis to IESG for consideration as proposed standard. Internet-Drafts: - NETCONF Configuration Protocol [draft-ietf-netconf-prot-13] (105 pages) - Using the NETCONF Protocol over Blocks Extensible Exchange Protocol (BEEP) [draft-ietf-netconf-beep-11] (15 pages) - Using the Network Configuration Protocol (NETCONF) Over the Simple Object Access Protocol (SOAP) [draft-ietf-netconf-soap-09] (22 pages) - Using the NETCONF Configuration Protocol over Secure Shell (SSH) [draft-ietf-netconf-ssh-07] (11 pages) - NETCONF Event Notifications [draft-ietf-netconf-notification-15] (49 pages) - NETCONF Over Transport Layer Security (TLS) [draft-ietf-netconf-tls-08] (9 pages) - Partial Lock RPC for NETCONF [draft-ietf-netconf-partial-lock-12] (29 pages) - YANG Module for NETCONF Monitoring [draft-ietf-netconf-monitoring-11] (38 pages) - With-defaults capability for NETCONF [draft-ietf-netconf-with-defaults-04] (15 pages) - Network Configuration Protocol (NETCONF) [draft-ietf-netconf-4741bis-02] (111 pages) - Using the NETCONF Configuration Protocol over Secure Shell (SSH) [draft-ietf-netconf-rfc4742bis-00] (10 pages) Requests for Comments: RFC4741: NETCONF Configuration Protocol (105 pages) RFC4742: Using the NETCONF Configuration Protocol over Secure Shell (SSH) (11 pages) RFC4744: Using the NETCONF Protocol over Blocks Extensible Exchange Protocol (BEEP) (15 pages) RFC4743: Using the Network Configuration Protocol (NETCONF) Over the Simple Object Access Protocol (SOAP) (22 pages) RFC5277: NETCONF Event Notifications (35 pages) RFC5539: NETCONF Over Transport Layer Security (TLS) (9 pages) RFC5717: Partial Lock Remote Procedure Call (RPC) for NETCONF (23 pages) Operational Security Capabilities for IP Network Infrastructure (opsec) ----------------------------------------------------------------------- Charter Last Modified: 2009-04-20 Current Status: Active Chairs: Joel Jaeggli Joe Abley Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Ronald Bonica Mailing Lists: General Discussion: opsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/opsec Archive: http://www.ietf.org/mail-archive/web/opsec/current/maillist.html Description of Working Group: Goals: The OPSEC WG will document best current practices with regard to network security. In particular an effort will be made to clarify the rationale supporting current operational practice, address gaps in currently understood best practices for forwarding, control plane, and management plane security and make clear the liabilities inherent in security practices where they exist. Scope: The scope of the OPSEC WG is intended to include the protection and secure operation of the forwarding, control and management planes. Documentation of best common practices, revision of existing operational security practices documents and proposals for new approaches to operational challenges are in scope. Method: It is expected that the work product of the working group will fall into the category of best current practices documents. Taxonomy or problem statement documents may provide a basis for best current practices documents. Best Current Practices Document For each topic addressed, a document will be produced that attempts to capture current practices related to secure operation. This will be primarily based on operational experience. Each entry will list: * threats addressed, * current practices for addressing the threat, * protocols, tools and technologies extant at the time of writing that are used to address the threat, * the possibility that a solution does not exist within existing tools or technologies. Taxonomy and Problem Statement Documents A document which attempts to describe the scope of particular operational security challenge or problem space without necessarily coming to a conclusion or proposing a solution. Such a document might be a precursor to a best common practices document. While the principal input of the Working Group are operational experience and needs, the output should be directed both to provide guidance to the operators community as well as to Working Groups that develop protocols or the community of protocol developers at large, as well as to the implementers of these protocols. Non-Goals: The Operations security working group is not the place to do new protocols. New protocol work should be addressed in a working group chartered in the appropriate area or as individual submissions. The OPSEC WG may take on documents related to the practices of using such work. Goals and Milestones: Done - Complete Charter Done - First draft of Framework Document as Internet Draft Done - First draft of Standards Survey Document as Internet Draft Done - First draft of Packet Filtering Capabilities Done - First draft of Event Logging Capabilities Done - First draft of Network Operator Current Security Practices Done - First draft of In-Band management capabilities Done - First draft of Out-of-Band management capabilities Done - First draft of Configuration and Management Interface Capabilities Feb 2005 - First draft of Authentication, Authorization, and Accounting (AAA) Capabilities Feb 2005 - First draft of Documentation and Assurance capabilities Done - First draft of Miscellaneous capabilities Mar 2005 - First draft of Deliberations Summary document Mar 2005 - Submit Framework to IESG Mar 2005 - Submit Standards Survey to IESG Done - Submit Network Operator Current Security Practices to IESG May 2005 - First draft of ISP Operational Security Capabilities Profile May 2005 - First draft of Enterprise Operational Security Capabilities Profile Jun 2005 - Submit Packet Filtering capabilities to IESG Jun 2005 - Submit Event Logging Capabilities document to IESG Jul 2005 - Submit In-Band management capabilities to IESG Jul 2005 - Submit Out-of-Band management capabilities to IESG Aug 2005 - Submit Configuration and Management Interface Capabilities to IESG Aug 2005 - Submit Authentication, Authorization and Accounting (AAA) capabilities document to IESG Sep 2005 - Submit Documentation and Assurance capabilities to IESG Sep 2005 - Submit Miscellaneous capabilities document to IESG Dec 2005 - Submit ISP Operational Security Capabilities Profile to IESG Dec 2005 - Submit Large Enterprise Operational Security Capabilities Profile to IESG Dec 2005 - Submit OPSEC Deliberation Summary document to IESG Nov 2008 - Submit a draft to the IESG regarding filtering of ICMP messages in the backbone Mar 2009 - Submit a draft to the IESG regarding backbone threats and mitigations Mar 2009 - Submit a draft to the IESG regarding BGP Session Security Internet-Drafts: - Framework for Operational Security Capabilities for IP Network Infrastructure [draft-ietf-opsec-framework-05] (29 pages) - Security Best Practices Efforts and Documents [draft-ietf-opsec-efforts-11] (35 pages) - Operational Security Current Practices [draft-ietf-opsec-current-practices-08] (43 pages) - Filtering and Rate Limiting Capabilities for IP Network Infrastructure [draft-ietf-opsec-filter-caps-09] (30 pages) - Miscellaneous Capabilities for IP Network Infrastructure [draft-ietf-opsec-misc-cap-00] (21 pages) - Network Management Access Security Capabilities [draft-ietf-opsec-nmasc-00] (13 pages) - Service Provider Infrastructure Security [draft-ietf-opsec-infrastructure-security-01] (17 pages) - Routing Control Plane Security Capabilities [draft-ietf-opsec-routing-capabilities-03] (20 pages) - Logging Capabilities for IP Network Infrastructure [draft-ietf-opsec-logging-caps-04] (35 pages) - Recommendations for filtering ICMP messages [draft-ietf-opsec-icmp-filtering-01] (44 pages) - Remote Triggered Black Hole filtering with uRPF [draft-ietf-opsec-blackhole-urpf-05] (18 pages) - Issues with existing Cryptographic Protection Methods for Routing Protocols [draft-ietf-opsec-routing-protocols-crypto-issues-03] (17 pages) - Security Assessment of the Internet Protocol version 4 [draft-ietf-opsec-ip-security-01] (73 pages) - Cryptographic Authentication Algorithm Implementation Best Practices for Routing Protocols [draft-ietf-opsec-igp-crypto-requirements-00] (10 pages) Requests for Comments: RFC4778: Operational Security Current Practices in Internet Service Provider Environments (43 pages) RFC5635: Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF) (18 pages) Operations and Management Area Working Group (opsawg) ----------------------------------------------------- Charter Last Modified: 2009-11-17 Current Status: Active Chairs: Scott Bradner Chris Liljenstolpe Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion: opsawg@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/opsawg Archive: http://www.ietf.org/mail-archive/web/opsawg Description of Working Group: The Operations and Management Area receives occasional proposals for the development and publication of RFCs dealing with operational and management topics that are not in scope of an existing working group and do not justify the formation of a new working group. The OPSAWG will serve as the forum for developing such work items in the IETF. The OPSAWG mailing list is an open discussion forum for such work items, when they arise. The working group meets if there are active proposals that require discussion. The working group milestones are updated as needed to reflect the current work items and their associated milestones. All new work items and rechartering proposals will be brought for approval with the IESG. The focus of the work will be on topics that govern the behavior or WGs in the O&M area (e.g., manageability requirements) and on small, highly focused projects that don't merit a WG of their own or belong to WGs that have already concluded (e.g. advancement of documents on the standards track, application statements, extensions of MIB modules). The OPSAWG will undertake only work items that are proved to have at least a reasonable level of interest from the operators and users community and have a committed number of editors and reviewers. It is not within the scope of the OPSAWG to pick up failed WG work or parts of a WG charter items that could not come to convergence on what they were chartered to do. The currently active OPSAWG work items mostly fall under the following topics: (A) Development of a BCP document that will provide guidelines for authors and a reference for reviewers of IETF documents that specify new protocols or protocol extensions about the information about operational and manageability requirements that needs to be covered in these documents (B) Templates and tools for Operations and Management Area Documents (C) Maintenance and small scale extensions of documents that were developed in working groups that have concluded (e.g. MIB modules). Goals and Milestones: Done - Initial submission for the 'SNMP Engine ID Discovery' Internet-Draft Done - Initial submission for the 'Guidelines for Considering Operations and Management of New Protocols' Internet-Draft Done - Initial submission for the 'Template for Generic Management Data Models' Internet-Draft Done - Initial submission for the 'Structured Data Elements (SDEs) for syslog' Internet-Draft Done - WGLC for the 'SNMP Engine ID Discovery' Internet-Draft Done - Submit the 'SNMP Engine ID Discovery' Internet-Draft to the IESG for consideration as Proposed Standard Done - WGLC for the 'Guidelines for Considering Operations and Management of New Protocols' Internet-Draft Done - Submit the 'Guidelines for Considering Operations and Management of New Protocols' Internet-Draft to the IESG for consideration as BCP Apr 2008 - WGLC for the 'Template for Generic Management Data Models' Done - WGLC for the 'Structured Data Elements (SDEs) for syslog' Jun 2008 - Submit the 'Template for Generic Management Data Models' to the IESG for consideration as BCP Done - Submit the 'Structured Data Elements (SDEs) for syslog' to the IESG for consideration as Proposed Standard Internet-Drafts: - Simple Network Management Protocol (SNMP) Context EngineID Discovery [draft-ietf-opsawg-snmp-engineid-discovery-04] (10 pages) - Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions [draft-ietf-opsawg-operations-and-management-10] (36 pages) - Expressing SNMP SMI Datatypes in XML Schema Definition Language [draft-ietf-opsawg-smi-datatypes-in-xsd-05] (17 pages) - A Template for Internet Drafts Containing Data Models [draft-ietf-opsawg-data-model-doc-template-00] (24 pages) - Alarms in SYSLOG [draft-ietf-opsawg-syslog-alarm-03] (13 pages) - Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications [draft-ietf-opsawg-syslog-msg-mib-07] (23 pages) - Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages [draft-ietf-opsawg-syslog-snmp-06] (15 pages) - Survey of IETF Network Management Standards [draft-ietf-opsawg-survey-management-01] (21 pages) - "The OAM Acronym Soup" [draft-ietf-opsawg-mpls-tp-oam-def-02] (15 pages) - An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms [draft-ietf-opsawg-oam-overview-00] (22 pages) Requests for Comments: RFC5343: Simple Network Management Protocol (SNMP) Context EngineID Discovery (9 pages) * Updates RFC3411 RFC5676: Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications (23 pages) RFC5675: Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages (15 pages) RFC5674: Alarms in SYSLOG (7 pages) RFC5706: Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions (35 pages) Performance Metrics for Other Layers (pmol) ------------------------------------------- Charter Last Modified: 2008-08-21 Current Status: Active Chairs: Alan Clark Al Morton Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion: pmol@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/pmol Archive: http://www.ietf.org/mail-archive/web/pmol/index.html Description of Working Group: The successful implementation and operation of IP based applications often depends on some underlying performance measurement infrastructure that helps service operators or network managers to recognize when performance is unsatisfactory and identify problems affecting service quality. Standardized performance metrics add the desirable features of consistent implementation, interpretation, no comparison. The IETF has two Working Groups dedicated to the development of performance metrics however each has strict limitations in their charters: - The Benchmarking Methodology WG has addressed a range of networking technologies and protocols in their long history (such as IEEE 802.3, ATM, Frame Relay, and Routing Protocols), but the charter strictly limits their Performance characterizations to the laboratory environment. - The IP Performance Metrics WG has the mandate to develop metrics applicable to the performance of Internet data delivery, but it is specifically prohibited from developing metrics that characterize traffic (such as a VoIP stream). The IETF also has current and completed activities related to the reporting of application performance metrics (e.g. RAQMON and RTCP XR) and is also actively involved in the development of reliable transport protocols which would affect the relationship between IP performance and application performance. Thus there is a gap in the currently chartered coverage of IETF WGs: development of performance metrics for IP-based protocols and applications that operate over UDP, TCP, SCTP, DCCP, Forward Error Correction (FEC) and other robust transport protocols, and that can be used to characterize traffic on live networks. The working group will focus on the completion of two RFCs: 1. A PMOL framework and guidelines memo that will describe the necessary elements of performance metrics of protocols and applications transported over IETF-specified protocols (such as the formal definition, purpose, and units of measure) and the various types of metrics that characterize traffic on live networks (such as metrics derived from other metrics, possibly on lower layers). The framework will also address the need to specify the intended audience and the motivation for the performance metrics. There will also be guidelines for a performance metric development process that includes entry criteria for new proposals (how a proposal might be evaluated for possible endorsement by a protocol development working group), and how an successful proposal will be developed. Also, it is recognized that there are applications and protocols that do not need to use this framework and can make use of simpler specific methods for determining performance. 2. A proof-of-concept RFC defining performance metrics for SIP, based on draft-malas-performance-metrics. This memo would serve as an example of the framework and the PMOL development process in the IETF. Discussion of new work proposals is strongly discouraged under the initial charter of the PMOL WG, except to advise a protocol development WG when they are evaluating a new work proposal for related performance metrics. The Working Group will work closely with the RAI and APPS areas, performing early review of the documents with the two areas and inviting their particpation in the WGLC. The PMOL WG will also be guided by a document describing how memos defining performance metrics are intended to advance along the IETF Standards track (draft-bradner-metricstest). PMOL WG will take advantage of expertise and seek to avoid overlap with other standards development organizations, such as ETSI STQ, ITU- T SG 12, ATIS IIF, ATIS PRQC, and others. Goals and Milestones: Jun 2008 - Performance Metrics Draft to IESG Review for consideration as Proposed Standard Sep 2008 - PMOL Framework and Guidelines Draft to IESG Review for consideration as BCP Nov 2008 - Discuss rechartering of the WG for new PMOL metrics work or shut down Internet-Drafts: - SIP End-to-End Performance Metrics [draft-ietf-pmol-sip-perf-metrics-04] (32 pages) - Framework for Performance Metric Development [draft-ietf-pmol-metrics-framework-03] (22 pages) No Requests for Comments RADIUS EXTensions (radext) -------------------------- Charter Last Modified: 2009-06-03 Current Status: Active Chairs: David Nelson Bernard Aboba Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Tech Advisor: Paul Congdon Mailing Lists: General Discussion: radiusext@ops.ietf.org To Subscribe: radiusext-request@ops.ietf.org Archive: https://ops.ietf.org/lists/radiusext Description of Working Group: The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to define extensions to the standard attribute space as well as to address cryptographic algorithm agility and use over new transports. In addition, RADEXT will work on RADIUS Design Guidelines and define new attributes for particular applications of authentication, authorization and accounting such as NAS management and local area network (LAN) usage. In order to enable interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained. Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: - All documents produced MUST specify means of interoperation with legacy RADIUS and, if possible, be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090 and 5176. Transport profiles should, if possible, be compatible with RFC 3539. - All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible, new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. Work Items The immediate goals of the RADEXT working group are to address the following issues: - RADIUS design guidelines. This document will provide guidelines for design of RADIUS attributes. It will specifically consider how complex data types may be introduced in a robust manner, maintaining backwards compatibility with existing RADIUS RFCs, across all the classes of attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it will review RADIUS data types and associated backwards compatibility issues. - RADIUS Management authorization. This document will define the use of RADIUS for NAS management over IP. -RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes. -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally relied on MD5 for both per-packet integrity and authentication as well as attribute confidentiality. Given the increasingly successful attacks being mounted against MD5, the ability to support alternative algorithms is required. This work item will include documentation of RADIUS crypto-agility requirements, as well as development of one or more Experimental RFCs providing support for negotiation of alternative cryptographic algorithms to protect RADIUS. - IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. - New RADIUS transports. A reliable transport profile for RADIUS will be developed, as well as specifications for Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS. - Documentation of Status-Server usage. A document describing usage of the Status-Server facility will be developed. Goals and Milestones: Done - Updates to RFC 2618-2621 RADIUS MIBs submitted for publication Done - SIP RADIUS authentication draft submitted as a Proposed Standard RFC Done - RFC 2486bis submitted as a Proposed Standard RFC Done - RFC 3576 MIBs submitted as an Informational RFC Done - RADIUS VLAN and Priority Attributes draft submitted as a Proposed Standard RFC (reduced in scope) Done - RADIUS Implementation Issues and Fixes draft submitted as an Informational RFC Done - RADIUS Filtering Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft) Done - RFC 3576bis submitted as an Informational RFC (split out from Issues & Fixes draft) Done - RADIUS Redirection Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft) Done - RADIUS Design Guidelines submitted as a Best Current Practice RFC Done - RADIUS Management Authorization I-D submitted as a Proposed Standard RFC Sep 2008 - Extended Attributes I-D submitted as a Proposed Standard RFC Sep 2008 - RADIUS Crypto-agility Requirements submitted as an Informational RFC Dec 2008 - IEEE 802 Attributes I-D submitted as a Proposed Standard RFC Jan 2009 - Reliable Transport Profile for RADIUS I-D submitted as a Proposed Standard RFC Mar 2009 - Status-Server I-D submitted as a Proposed Standard RFC Mar 2009 - RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC Jun 2009 - RADIUS Cryptographic Algorithm Agility I-D submitted as an Experimental RFC Jun 2009 - RADIUS over DTLS I-D submitted as an Experimental RFC Internet-Drafts: - RADIUS Accounting Client MIB for IPv6 [draft-ietf-radext-rfc2620bis-05] (23 pages) - The Network Access Identifier [draft-ietf-radext-rfc2486bis-07] (17 pages) - RADIUS Delegated-IPv6-Prefix Attribute [draft-ietf-radext-delegated-prefix-06] (9 pages) - RADIUS Extension for Digest Authentication [draft-ietf-radext-digest-auth-10] (37 pages) - Chargeable User Identity [draft-ietf-radext-chargeable-user-id-07] (11 pages) - RADIUS Authentication Client MIB for IPV6 [draft-ietf-radext-rfc2618bis-05] (24 pages) - Dynamic Authorization Server MIB [draft-ietf-radext-dynauth-server-mib-07] (28 pages) - Dynamic Authorization Client MIB [draft-ietf-radext-dynauth-client-mib-07] (30 pages) - VLAN, Priority, and Filtering Attributes [draft-ietf-radext-ieee802-01] (32 pages) - RADIUS Authentication Server MIB for IPv6 [draft-ietf-radext-rfc2619bis-05] (26 pages) - RADIUS Accounting Server MIB for IPv6 [draft-ietf-radext-rfc2621bis-05] (25 pages) - RADIUS Attributes for Virtual LAN and Priority Support [draft-ietf-radext-vlan-07] (15 pages) - RADIUS Attributes for Filtering and Redirection [draft-ietf-radext-filter-rules-03] (30 pages) - RADIUS Filter Rule Attribute [draft-ietf-radext-filter-09] (10 pages) - Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes [draft-ietf-radext-fixes-09] (28 pages) - Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) [draft-ietf-radext-rfc3576bis-14] (29 pages) - RADIUS Extension for Digest Authentication [draft-ietf-radext-rfc4590bis-03] (34 pages) - Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management [draft-ietf-radext-management-authorization-08] (25 pages) - RADIUS Design Guidelines [draft-ietf-radext-design-10] (38 pages) - Extended Remote Authentication Dial In User Service (RADIUS) Attributes [draft-ietf-radext-extended-attributes-09] (13 pages) - Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS) [draft-ietf-radext-crypto-agility-requirements-01] (9 pages) - TLS encryption for RADIUS over TCP (RadSec) [draft-ietf-radext-radsec-06] (16 pages) - Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol [draft-ietf-radext-status-server-05] (23 pages) - New Tunnel-Type Values [draft-ietf-radext-tunnel-type-00] (6 pages) - RADIUS Over TCP [draft-ietf-radext-tcp-transport-04] (18 pages) - NAI-based Dynamic Peer Discovery for RADIUS over TLS and DTLS [draft-ietf-radext-dynamic-discovery-02] (8 pages) Requests for Comments: RFC4282: The Network Access Identifier (17 pages) * Obsoletes RFC2486 RFC4372: Chargeable User Identity (11 pages) RFC4590: RADIUS Extension for Digest Authentication (37 pages) * OBSOLETED BY RFC5090 RFC4668: RADIUS Authentication Client MIB for IPV6 (24 pages) * Obsoletes RFC2618 RFC4669: RADIUS Authentication Server MIB for IPv6 (26 pages) * Obsoletes RFC2619 RFC4671: RADIUS Accounting Server MIB for IPv6 (25 pages) * Obsoletes RFC2621 RFC4670: RADIUS Accounting Client MIB for IPv6 (23 pages) * Obsoletes RFC2620 RFC4675: RADIUS Attributes for Virtual LAN and Priority Support (15 pages) RFC4673: RADIUS Dynamic Authorization Server MIB (28 pages) RFC4672: RADIUS Dynamic Authorization Client MIB (30 pages) RFC4818: RADIUS Delegated-IPv6-Prefix Attribute (9 pages) RFC4849: RADIUS Filter Rule Attribute (10 pages) RFC5080: Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes (28 pages) * Updates RFC2865 * Updates RFC2866 * Updates RFC2869 * Updates RFC3579 RFC5176: Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) (29 pages) * Obsoletes RFC3576 RFC5090: RADIUS Extension for Digest Authentication (34 pages) * Obsoletes RFC4590 RFC5607: Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management (25 pages) Audio/Video Transport (avt) --------------------------- Charter Last Modified: 2010-02-09 Current Status: Active Chairs: Tom Taylor Roni Even Real-time Applications and Infrastructure Area Directors: Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: General Discussion: avt@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/avt Archive: http://www.ietf.org/mail-archive/web/avt/index.html Description of Working Group: The Audio/Video Transport Working Group was formed to specify a protocol for real-time transmission of audio and video over unicast and multicast UDP/IP. This is the Real-time Transport Protocol, RTP, along with its associated profiles and payload formats. RTP itself has been shepherded to Full Standard. Its associated profiles, extensions, and payload formats are currently at various levels of stardards maturity. This working group's current work centers in four areas: 1) Maintenance of the core RTP/RTCP protocols and the AVP, SAVP, AVPF, and SAVPF profiles 2) Specification and maintenance of payload formats for use with RTP 3) Specification of metric blocks for use with the RTCP Extended Report (XR) framework 4) Extensions to the core protocols to facilitate joining, synchronizing, control, and monitoring of RTP multimedia sessions In these areas, the group is chartered to focus on the following tasks. Work supporting those areas, but not reflected in these tasks must not be accepted by the working group without an explicit re-chartering. In particular, new items supporting the fourth area are expected to be reviewed in DISPATCH before being considered new charter items for this group. 1) Maintenance of the core RTP/SRTP/RTCP protocols and the AVP, SAVP, AVPF, and SAVPF profiles - maintain and enhance the SRTP Profile, with review and input from the Security Area - specify how to use Explicit Congestion Notification (ECN) with RTP/RTCP - continue to investigate the export of summarized RTP/RTCP information for operations and monitoring purposes 2) Specification and maintenance of payload formats for use with RTP - provide guidelines for payload format design - develop payload formats for new media codecs - review and revise existing payload formats to advance those which are useful to Draft Standard or Standard, and to declare others as Historic. 3) Specification of metric blocks for use with the RTCP Extended Report (XR) framework - provide a mechanism allowing identification data for a set of related metric reports to be carried separately and identified in those reports by reference - provide report blocks for delay, delay variation, and discard - provide report blocks for burst/gap discard and loss - provide report blocks supporting rapid synchronization of multiple RTP streams - provide report blocks for jitter buffer metrics - provide report blocks for loss concealment metrics 4) Extensions to the core protocols to facilitate joining, synchronizing, control, and monitoring of RTP multimedia sessions - develop tools to support rapid acquisition of multimedia streams - specify necessary extensions to support rapid synchronization of multiple RTP streams Goals and Milestones: Done - Review DCCP including prototypes and API; feedback to DCCP WG Done - Initial draft requirements for ECRTP over MPLS; discuss with MPLS WG Done - Submit iLBC payload format for Proposed Standard Done - Submit iLBC codec specification for Experimental Done - Advance RTP specification and A/V profile to Full Standard Done - Submit RTP/SAVPF profile for Proposed Standard Done - Submit ULP Payload Format for Proposed Standard Done - Finished investigation of advanced FEC codes for RTP, update plan Done - Submit SMTPE Timestamping of Media for Proposed Standard Done - Submit Codec Control Messages for Proposed Standard Done - Submit Multiplexing of RTCP and RTP on the same port for Proposed Standard Done - Submit RTCP/SSM draft for Proposed Standard Done - Submit draft on Enhancing RTP header extensions for proposed standard Done - Submit RTP Payload Format for ITU-T Recommendation G.711.1 for Proposed Standard Done - Submit RTP payload format for mU-law EMbedded Codec for Low-delay IP communication (UEMCLIP) speech codec for Proposed Standard Done - Submit Transmission Time offsets in RTP streams for Proposed Standard Done - Submit RTP Payload Format for Adaptive TRansform Acoustic Coding (ATRAC) Family for Proposed Standard Done - Submit RTP Payload Format for JPEG 2000 Video Streams for Proposed Standard Done - Submit Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Header Recovery for Proposed Standard Done - Submit RTP Payload Format for the Speex Codec for Proposed Standard Done - Submit G.729.1 RTP Payload Format update: DTX support for Proposed Standard Done - Submit RTP Payload Format for ITU-T Recommendation G.722.1 for Proposed Standard Done - Submit draft on Mechanisms to keep NAT bindings for RTP flows alive for BCP Done - Submit The SEED Cipher Algorithm and Its Use with the Secure Real-time Transport Protocol (SRTP) for Proposed Standard Done - Submit RTP Payload Format for Elementary Streams with MPEG Surround multi-channel audio for Proposed Standard Done - Submit Support for reduced size RTCP, opportunities and consequences Done - Submit RTP Payload Format for SPIRIT IP-MR Speech Codec Software for Proposed Standard Done - Submit Post-Repair Loss RLE Report Block Type for RTCP XR for Proposed Standard Done - Submit RTP Payload Format for H.264 Video for Proposed Standard Done - Submit RTP Payload Format for G.719 audio for Proposed Standard Jan 2010 - Submit draft explaining why SRTP need not be mandatory for media transport, for Informational Jan 2010 - Policy for Registering SRTP Transforms for Proposed Standard Jan 2010 - RTP Payload Format for GSM-HR for Proposed Standard Jan 2010 - RTP Payload Format for DRA Audio for Informational Jan 2010 - Submit RTP Payload Format for H.264 RCDO Video for Proposed Standard Jan 2010 - Submit Unicast-Based Rapid Acquisition of Multicast RTP Sessions for Proposed Standard Jan 2010 - Submit Rapid Synchronization of RTP Flows for Proposed Standard Jan 2010 - Submit Forward-shifted RTP Redundancy Payload Support for Proposed Standard Feb 2010 - Submit Multicast Acquisition Report Block Type for RTCP XR Feb 2010 - Submit Port Mapping Between Unicast and Multicast RTP Sessions for Proposed Standard Feb 2010 - Submit RTP Payload Format for SVC Video for Proposed Standard Feb 2010 - Submit How to Write an RTP Payload Format for Informational Mar 2010 - Submit Monitoring Architecture for RTP for Informational Mar 2010 - Submit Guidelines for Extending the RTP Control Protocol (RTCP) for Informational Mar 2010 - RTP Payload Format for MPEG-4 Audio/Visual Streams for Proposed Standard Mar 2010 - RTP Payload Format for MPEG2-TS preamble for Proposed Standard Mar 2010 - Submit EVBR/G.718 payload draft for Proposed Standard Mar 2010 - Submit RTP Payload Format for DV (IEC 61834) Video for Proposed Standard Mar 2010 - Submit RTCP XR Report Block for Measurement Identity Apr 2010 - RTP Payload Format for the iSAC codec for Proposed Standard Apr 2010 - Submit in band keying mechanism for SRTP draft for Proposed Standard Apr 2010 - RTP Payload Format for Bluetooth's SBC audio codec for Proposed Standard Apr 2010 - RTP Payload Format for Enhanced Variable Rate Narrowband- Wideband Codec (EVRC-NW) for Proposed Standard Apr 2010 - Submit RTCP XR Report Block for Burst/Gap Discard metric Reporting Apr 2010 - Submit RTCP XR Report Block for Burst/Gap Loss metric Reporting Apr 2010 - Submit RTCP XR Report Block for Concealed Seconds metric Reporting Apr 2010 - Submit RTCP XR Report Block for Delay metric Reporting Apr 2010 - Submit RTCP XR Report Block for Discard metric Reporting Apr 2010 - Submit RTCP XR Report Block for Jitter Buffer Metric Reporting Apr 2010 - Submit RTCP XR Report Block for Loss Concealment metric Reporting Apr 2010 - Submit RTCP XR Report Block for Packet Delay Variation Metric Reporting Apr 2010 - Submit Real-time Transport Control Protocol Extension Report for Run Length Encoding of Discarded Packets Apr 2010 - Submit RTCP XR Report Block for QoE Metrics Reporting Apr 2010 - Submit Considerations for RAMS Scenarios for Informational May 2010 - Submit Explicit Congestion Notification (ECN) for RTP over UDP for Proposed Standard May 2010 - Submit Real-Time Transport Control Protocol (RTCP) in Overlay Multicast for Proposed Standard Sep 2010 - RTP profile for the carriage of SMPTE 336M data for Proposed Standard Sep 2010 - RTP Payload Format for the APTX codec for Proposed Standard Sep 2010 - RTP Payload Format for the CELT codec for Proposed Standard Oct 2010 - RTP Payload Format for MVC Video for Proposed Standard Nov 2010 - Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP) for Proposed Standard Dec 2010 - Submit RTP Payload Format for MIDI for Proposed Standard Internet-Drafts: - Issues in Designing a Transport Protocol for Audio and Video Conferences and other Multiparticipant Real-Time Applications [draft-ietf-avt-issues-01] (64 pages) - RTP: A Transport Protocol for Real-Time Applications [draft-ietf-avt-rtp-09] (77 pages) - Media Encodings [draft-ietf-avt-encodings-02] (7 pages) - RTP Profile for Audio and Video Conferences with Minimal Control [draft-ietf-avt-profile-08] (18 pages) - RTP payload format for H.261 video streams [draft-ietf-avt-h261-04] (14 pages) - RTP Payload Format of Sun's CellB Video Encoding [draft-ietf-avt-cellb-09] (8 pages) - RTP Payload Format for JPEG-compressed Video [draft-ietf-avt-jpeg-04] (15 pages) - RTP Payload Format for MPEG1/MPEG2 Video [draft-ietf-avt-mpeg-03] (10 pages) - RTP usage with Layered Multimedia Streams [draft-speer-avt-layered-video-05] (5 pages) - RTP Payload Format for H.263 Video Streams [draft-ietf-avt-rtp-payload-04] (11 pages) - RTP Payload for Redundant Audio Data [draft-ietf-avt-rtp-redundancy-01] (10 pages) - RTP Payload Format for Bundled MPEG [draft-civanlar-bmpeg-03] (7 pages) - Compressing IP/UDP/RTP Headers for Low-Speed Serial Links [draft-ietf-avt-crtp-06] (22 pages) - Alternatives for Enhancing RTCP Scalability [draft-aboba-rtpscale-02] (10 pages) - Real-Time Transport Protocol Management Information Base [draft-ietf-avt-rtp-mib-14] (35 pages) - RTP Profile for Audio and Video Conferences with Minimal Control [draft-ietf-avt-profile-new-13] (45 pages) - RTP Payload Format for MPEG1/MPEG2 Video [draft-ietf-avt-mpeg-new-02] (15 pages) - RTP Payload Format for QuickTime Media Streams [draft-ietf-avt-qt-rtp-00] (15 pages) - RTP Payload Format for BT.656 Video Encoding [draft-tynan-rtp-bt656-03] (9 pages) - RTP Payload for DTMF Digits [draft-ietf-avt-dtmf-01] (6 pages) - An RTP Payload Format for Generic Forward Error Correction [draft-ietf-avt-fec-09] (24 pages) - Options for Repair of Streaming Media [draft-ietf-avt-info-repair-03] (11 pages) - RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+) [draft-ietf-avt-rtp-h263-video-02] (10 pages) - RTP Payload Format for JPEG-compressed Video [draft-ietf-avt-jpeg-new-02] (25 pages) - New Results in RTP Scalability [draft-ietf-avt-byerecon-00] (10 pages) - Guidelines for Writers of RTP Payload Format Specifications [draft-ietf-avt-rtp-format-guidelines-05] (9 pages) - RTP: A Transport Protocol for Real-Time Applications [draft-ietf-avt-rtp-new-12] (107 pages) - RTP Payload Format for X Protocol Media Streams [draft-ietf-avt-X11-new-00] (16 pages) - The Role of DMIF in Support of RTP MPEG-4 Payloads [draft-ietf-avt-rtp-mpeg4-dmif-01] (11 pages) - RTP Payload Format for MPEG-4 Streams [draft-ietf-avt-rtp-mpeg4-03] (11 pages) - An RTP Payload Format for User Multiplexing [draft-ietf-avt-aggregation-00] (10 pages) - RTP Payload for Redundant Audio Data [draft-ietf-avt-redundancy-revised-00] (11 pages) - Sampling of the Group Membership in RTP [draft-ietf-avt-rtpsample-07] (11 pages) - User Multiplexing in RTP payload between IP Telephony Gateways [draft-ietf-avt-mux-rtp-00] (17 pages) - Issues and Options for RTP Multiplexing [draft-ietf-avt-muxissues-00] (27 pages) - An RTP Payload Format for Reed Solomon Codes [draft-ietf-avt-reedsolomon-00] (12 pages) - GeRM: Generic RTP Multiplexing [draft-ietf-avt-germ-00] (8 pages) - RTP Payload format for Interleaved Media [draft-ietf-avt-interleaving-01] (6 pages) - RTP Payloads for Telephone Signal Events [draft-ietf-avt-telephone-tones-00] (11 pages) - RTP Payload Format for DV Format Video [draft-ietf-avt-dv-video-04] (12 pages) - RTP Interoperability Statement [draft-ietf-avt-rtp-interop-08] (8 pages) - RTP Testing Strategies [draft-ietf-avt-rtptest-06] (22 pages) - RTP Payload Format for MPEG-2 and MPEG-4 AAC Streams [draft-ietf-avt-rtp-mpeg2aac-02] (10 pages) - RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals [draft-ietf-avt-tones-07] (29 pages) - Multiplexing Scheme for RTP Flows between Access Routers [draft-ietf-avt-multiplexing-rtp-01] (13 pages) - MIME Type Registration of RTP Payload Formats [draft-ietf-avt-rtp-mime-06] (36 pages) - SDP Bandwidth Modifiers for RTCP Bandwidth [draft-ietf-avt-rtcp-bw-05] (7 pages) - RTP Payload for Text Conversation [draft-ietf-avt-rtp-text-05] (9 pages) - RTP Payload Format for Real-Time Pointers [draft-ietf-avt-pointer-02] (5 pages) - RTP Payload Format for 12-bit DAT, 20- and 24-bit Linear Sampled Audio [draft-ietf-avt-dv-audio-04] (16 pages) - A More Loss-Tolerant RTP Payload Format for MP3 Audio [draft-ietf-avt-rtp-mp3-06] (0 pages) - RTP Audio/Video Profile Interoperability Statement [draft-ietf-avt-profile-interop-06] (7 pages) - Registration of parityfec MIME types [draft-ietf-avt-fecmime-02] (9 pages) - RTP payload format for MPEG-4 Audio/Visual streams [draft-ietf-avt-rtp-mpeg4-es-06] (18 pages) - RTP Payload for Comfort Noise [draft-ietf-avt-rtp-cn-06] (8 pages) - Extension of RTP payload Type for Multiple Program MPEG Transport Stream [draft-ietf-avt-rtp-mp2t-04] (0 pages) - RTP Payload Format for MPEG-4 with Flexible Error Resiliency [draft-ietf-avt-mpeg4streams-04] (18 pages) - Tunneling Multiplexed Compressed RTP ('TCRTP') [draft-ietf-avt-tcrtp-09] (22 pages) - RTP Payload Format for ITU-T Recommendation G.722.1 [draft-ietf-avt-rtp-g7221-01] (7 pages) - RTP Payload Format for SMPTE 292M Video [draft-ietf-avt-smpte292-video-08] (12 pages) - Enhanced Compressed RTP (CRTP) for links with high delay,packet loss and reordering [draft-ietf-avt-crtp-enhance-07] (0 pages) - RTP Profile for RTCP-based Retransmission Request for Unicast session. [draft-ietf-avt-rtprx-00] (10 pages) - RTP payload format and file storage format for the Adoptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) audio codecs [draft-ietf-avt-rtp-amr-13] (41 pages) - RTP Payload Format for Generic Forward Error Correction [draft-ietf-avt-ulp-24] (43 pages) - RTP Payload Formats to Enable Multiple Selective Retransmission [draft-ietf-avt-rtp-selret-05] (29 pages) - An RTP Payload Format for EVRC Speech [draft-ietf-avt-evrc-08] (17 pages) - An RTP Payload Format for Erasure-Resilient Transmission of Progressive Multimedia Streams [draft-ietf-avt-uxp-07] (29 pages) - The Secure Real-