appsawg hybi core eai ftpext2 httpbis iri marf precis paws repute spfbis sieve urnbis websec vcarddav ancp autoconf csi dnsext dmm dhc homenet hip 6man 6lowpan intarea l2tpext lwig lisp mip4 multimob mif ntp netext pppext pcp softwire savi tictoc trill adslmib armd bmwg dime dnsop eman grow ipfix v6ops 6renum mboned netmod netconf opsec opsawg radext avtcore avtext payload atoca bliss bfcpbis cuss clue drinks dispatch ecrit xmpp geopriv codec mediactrl xrblock mmusic p2psip rtcweb sipclf soc siprec simple sipcore salud speechsc vipr bfd ccamp forces isis idr karp l2vpn l3vpn manet mpls ospf pce pim pwe3 rtgwg roll sidr abfab kitten dane emu hokey ipsecme jose krb-wg mile nea pkix tls oauth alto behave conex pcn cdni dccp decade fecframe ippm ledbat mptcp nfsv4 ppsp rmt storm tcpm tsvwg Applications Area Working Group (appsawg) ----------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Barry Leiba Alexey Melnikov Jiankang Yao Applications Area Directors: Pete Resnick Barry Leiba Peter Saint-Andre Applications Area Advisor: Pete Resnick Mailing Lists: General Discussion: apps-discuss@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/apps-discuss Archive: http://www.ietf.org/mail-archive/web/apps-discuss/ Description of Working Group: The Applications Area sometimes receives proposals for the development of specifications dealing with application-related topics that are not in scope for an existing working group and do not justify the formation of a new working group. The Applications Area Working Group (APPSAWG) can serve as a forum for such work in the IETF. The APPSAWG accepts work items in accordance with the consensus of the Working Group and the best judgment of the Applications Area Directors, who are responsible for updating the working group milestones as needed. The working group meets if there are active proposals that require intensive discussion. Work items that are appropriate for the APPSAWG mostly fall under the following topics: (A) Well-defined security issues that are relevant to multiple application technologies (e.g., draft-saintandre-tls-server-id-check). (B) Small-scale additions to the protocol stack for HTTP and other application technologies, mostly related to service discovery and meta-data (e.g., RFC 5785, draft-nottingham-http-link-header, and draft-hammer-hostmeta). (C) Selected other work items addressing topics that historically fall within the Applications Area, such as calendaring, date and time formats, HTTP, internationalization, language tags, MIME, URIs and XML. When considering whether to accept a proposed work item, the APPSAWG and the Applications Area Directors shall take into account the following factors, among others: * There is no existing related Working Group that is willing to recharter to take on this work, and the document doesn't justify the formation of a new working group. * Whether the WG has consensus on the suitability, importance, and projected quality of the proposed work item. * Whether there is a core team of WG participants with sufficient energy and expertise to advance the proposed work item according to the proposed schedule. * Whether there are enough WG participants who are willing to review the work produced by the document authors or editors. * Whether the Area Directors judge that wider input is needed before accepting the proposed work item (e.g., from the IESG, IAB, or another standards development organization). Goals and Milestones: Sep 2011 - Submit draft-ietf-appsawg-rfc3462bis to the IESG Internet-Drafts: - The Unicode code points and IDNA - Unicode 6.0 [draft-faltstrom-5892bis-06] (5 pages) - Email Greylisting: An Applicability Statement for SMTP [draft-ietf-appsawg-greylisting-02] (12 pages) - Terminology Used in Internationalization in the IETF [draft-ietf-appsawg-rfc3536bis-07] (46 pages) - Best Current Practices for Handling of Malformed Messages [draft-ietf-appsawg-malformed-mail-01] (9 pages) - The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages [draft-ietf-appsawg-rfc3462bis-05] (18 pages) - Deprecating Use of the "X-" Prefix in Application Protocols [draft-ietf-appsawg-xdash-02] (12 pages) - The "about" URI Scheme [draft-ietf-appsawg-about-uri-scheme-01] (7 pages) - JSON Pointer [draft-ietf-appsawg-json-pointer-00] (7 pages) - JSON Patch [draft-ietf-appsawg-json-patch-00] (12 pages) - Update to MIME regarding Charset Parameter Handling in Textual Media Types [draft-ietf-appsawg-mime-default-charset-00] (6 pages) - Forwarded HTTP Extension [draft-ietf-appsawg-http-forwarded-00] (12 pages) - Media Type Specifications and Registration Procedures [draft-ietf-appsawg-media-type-regs-01] (29 pages) Requests for Comments: RFC6365: Terminology Used in Internationalization in the IETF (47 pages) * Obsoletes RFC3536 RFC6452: The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) - Unicode 6.0 (4 pages) RFC6522: The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages (9 pages) * Obsoletes RFC3462 BiDirectional or Server-Initiated HTTP (hybi) --------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Salvatore Loreto Gabriel Montenegro Applications Area Directors: Pete Resnick Barry Leiba Peter Saint-Andre Applications Area Advisor: Peter Saint-Andre Secretary: S Moonesamy Mailing Lists: General Discussion: hybi@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/hybi Archive: http://www.ietf.org/mail-archive/web/hybi/current/maillist.html Description of Working Group: HTTP has most often been used as a request/response protocol, leading to clients polling for new data, or users hitting the refresh button in their browsers. Recent web applications are finding ways to communicate with web servers in realtime, pushing data from the server-side to the client as soon as it is available. However, these applications at present can only use a variety of HTTP mechanisms (e.g. long polling requests) to communicate with web servers bidirectionally. The Hypertext-Bidirectional (HyBi) working group will seek standardization of one approach to maintain bidirectional communications between the HTTP client, server and intermediate entities, which will provide more efficiency compared to the current use of hanging requests. A general approach is preferred, with abstract semantics that can apply to a large number of applications. The Web is the design space into which the solution will be deployed. Since the existing Web is much more complicated that it seems, the working group will document how it works first, with special attention to deployed infrastructure (e.g. web clients, intermediaries, firewalls, NATs, web servers) and programming environments. New features will be required of clients, servers, or intermediaries allowing a more scalable and robust end-to-end experience. Although multiple protocols exist as starting points, backward compatibility with these protocols is not a requirement. In particular, the working group has liaised with the W3C WebApps working group around the WebSockets protocol and the need to support the WebSocket API; as agreed by both parties, the HyBi working group will take on prime responsibility for the specification of the WebSockets protocol, taking into consideration all the requirements, needs and eventual concerns raised by the W3C WebApps working group. The draft-hixie-thewebsocketprotocol "The Web Socket protocol" is considered as the input document for the working group. Wide browser support is a goal for the bidirectional communication mechanism, however the solution should also be suitable for clients other than Web Browsers. The Working Group will work to standardize a generic solution that can work efficiently in as many of the deployed environments as possible and in particular in all the elements of the web infrastructure (e.g. web browser, generic HTTP client, HTTP server and HTTP-aware intermediaries like proxies, load balancers, caches, etc.) and it is not specific for just one. The Working Group should consider: * Implementer experience * Impact on existing implementations and deployments * Ability to achieve broad implementation * Ability to address broader use cases than those covered in the input document The Working Group will produce one or more documents suitable for consideration as Proposed Standard that will: * Define a characterization of the design space * Define a solution for the bidirectional web communication Goals and Milestones: Apr 2010 - Submit a document as a working group item describing the Web Socket requirements (draft-hixie-thewebsocketprotocol will be used as a starting point for further work.) Apr 2010 - Submit 'The Web Socket protocol' as working group item (draft-hixie-thewebsocketprotocol will be used as a starting point for further work.) Jul 2010 - Start Working Group Last Call on the WebSocket requirements Jul 2010 - Submit a document as a working group item describing the Design Space characterization Sep 2010 - Submit the 'Web Socket requirements' to the IESG for consideration as an Informational document Nov 2010 - Start Working Group Last Call on the Design Space characterization Nov 2010 - Start of discussion about Web Socket extensions the group should work on Dec 2010 - Submit the 'Design Space characterization' to the IESG for consideration as an Informational document Mar 2011 - Start Working Group Last Call on 'The Web Socket protocol' Mar 2011 - Prepare milestone update to start new work within the scope of the charter Apr 2011 - Submit the 'The Web Socket protocol' to the IESG for consideration as a Proposed Standard May 2011 - Close or recharter Internet-Drafts: - HyBi WebSocket Requirements and Features [draft-ietf-hybi-websocket-requirements-03] (9 pages) - Design Space for Bidirectional Protocols [draft-ietf-hybi-design-space-00] (9 pages) - The WebSocket protocol [draft-ietf-hybi-thewebsocketprotocol-18] (77 pages) Requests for Comments: RFC6455: The WebSocket Protocol (71 pages) Constrained RESTful Environments (core) --------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Carsten Bormann Cullen Jennings Applications Area Directors: Pete Resnick Barry Leiba Peter Saint-Andre Applications Area Advisor: Peter Saint-Andre Mailing Lists: General Discussion: core@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/core Archive: http://www.ietf.org/mail-archive/web/core/current/maillist.html Description of Working Group: CoRE is providing a framework for resource-oriented applications intended to run on constrained IP networks. A constrained IP network has limited packet sizes, may exhibit a high degree of packet loss, and may have a substantial number of devices that may be powered off at any point in time but periodically "wake up" for brief periods of time. These networks and the nodes within them are characterized by severe limits on throughput, available power, and particularly on the complexity that can be supported with limited code size and limited RAM per node. More generally, we speak of constrained networks whenever at least some of the nodes and networks involved exhibit these characteristics. Low-Power Wireless Personal Area Networks (LoWPANs) are an example of this type of network. Constrained networks can occur as part of home and building automation, energy management, and the Internet of Things. The CoRE working group will define a framework for a limited class of applications: those that deal with the manipulation of simple resources on constrained networks. This includes applications to monitor simple sensors (e.g. temperature sensors, light switches, and power meters), to control actuators (e.g. light switches, heating controllers, and door locks), and to manage devices. The general architecture consists of nodes on the constrained network, called Devices, that are responsible for one or more Resources that may represent sensors, actuators, combinations of values or other information. Devices send messages to change and query resources on other Devices. Devices can send notifications about changed resource values to Devices that have subscribed to receive notification about changes. A Device can also publish or be queried about its resources. (Typically a single physical host on the network would have just one Device but a host might represent multiple logical Devices. The specific terminology to be used here is to be decided by the WG.) As part of the framework for building these applications, the WG will define a Constrained Application Protocol (CoAP) for the manipulation of Resources on a Device. CoAP will be designed for use between Devices on the same constrained network, between Devices and general nodes on the Internet, and between Devices on different constrained networks both joined by an internet. CoAP targets the type of operating environments defined in the ROLL and 6LOWPAN working groups which have additional constraints compared to normal IP networks, but the CoAP protocol will also operate over traditional IP networks. There also may be proxies that interconnect between other Internet protocols and the Devices using the CoAP protocol. The WG will define a mapping from CoAP to an HTTP REST API; this mapping will not depend on a specific application. It is worth noting that proxy does not have to occur at the boundary between the constrained network and the more general network, but can be deployed at various locations in the unconstrained network. CoAP will support various forms of "caching". For example, if a temperature sensor is normally asleep but wakes up every five minutes and sends the current temperature to a proxy that has subscribed, when the proxy receives a request over HTTP for that temperature resource, it can respond with the last seen value instead of trying to query the Device which is currently asleep. The initial work item of the WG is to define a protocol specification for CoAP that includes: 1) The ability to create, read, update and delete a Resource on a Device. 2) The ability to allow a Device to publish a value or event to another Device that has subscribed to be notified of changes, as well as the way for a Device to subscribe to receive publishes from another Device. 3) The ability to support a non-reliable multicast message to be sent to a group of Devices to manipulate a resource on all the Devices in the group. 4) The core CoAP functionality MUST operate well over UDP and UDP MUST be implemented on CoAP Devices. There may be OPTIONAL functions in CoAP (e.g. delivery of larger chunks of data) which if implemented are implemented over TCP. Applications which require the optional TCP features will limit themselves to a narrower subset of deployment cases. 5) A definition of how to use CoAP to advertise about or query for a Device's description. This description may include the device name and a list of its Resources, each with a URL, an interface description URI (pointing e.g. to a Web Application Description Language (WADL) document) and an optional name or identifier. The name taxonomy used for this description will be consistent with other IETF work, e.g. draft-cheshire-dnsext-dns-sd. 6) Specification for the HTTP REST based API and translation to communicate with Devices. Translation should make use of Device description information and should not need code updates to deal with new Devices. 7) Consider operational and manageability aspects of the protocol and at a minimum provide a way to tell if a Device is powered on or not. The working group will not develop a reliable multicast solution, and will not develop a general service discovery solution. There is a desire for discovery and configuration features, but the working group has not yet closed in on an specific approach. Thus, the WG may explore these topics and adopt drafts that define requirements or set problem statements, but will not adopt implementable specifications without a recharter. Security, particularly keying of new Devices, is very challenging for these applications. The WG will work to select approaches to security bootstrapping which are realistic given the constraints and requirements of the network. To ensure that any two nodes can join together, all nodes must implement at least one universal bootstrapping method. Security can be achieved using either session security or object security. For both object and session security, the WG will work with the security area to select appropriate security framework and protocol as well as selecting a minimal required to implement cipher suite. CoAP will initially look at CMS (RFC 5652), TLS/DTLS, and EAP. The WG will coordinate on requirements from many organizations including OpenSG/NIST, ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI, ASHRAE/BACnet; other SDOs and organizations. The WG will closely coordinate with other IETF WGs including ROLL, 6LoWPAN, and appropriate groups in the IETF OPS and Security areas. Goals and Milestones: Apr 2010 - Select WG document for basis of the CoAP protocol Dec 2010 - CoAP protocol specification with mapping to HTTP Rest API submitted to IESG as PS Dec 2010 - Constrained security bootstrapping specification submitted to IESG as PS Jan 2011 - Recharter to add things reduced out of initial scope Nov 2012 - Using CoAP for group communications to IESG as Informational Internet-Drafts: - Group Communication for CoAP [draft-ietf-core-groupcomm-00] (32 pages) - Constrained Application Protocol (CoAP) [draft-ietf-core-coap-08] (88 pages) - Blockwise transfers in CoAP [draft-ietf-core-block-07] (28 pages) - Observing Resources in CoAP [draft-ietf-core-observe-03] (27 pages) - CoRE Link Format [draft-ietf-core-link-format-11] (20 pages) No Requests for Comments Email Address Internationalization (eai) ---------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: John Klensin Joseph Yee Applications Area Directors: Pete Resnick Barry Leiba Peter Saint-Andre Applications Area Advisor: Pete Resnick Secretary: Jiankang Yao Mailing Lists: General Discussion: ima@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ima Archive: http://www.ietf.org/mail-archive/web/ima Description of Working Group: The email address has two parts, local part and domain part. Email address internationalization must deal with both. This working group's previous experimental efforts investigated the use of UTF-8 as a general approach to email internationalization. That approach is based on the use of an SMTP extension to enable the use of UTF-8 in envelope address local-parts, optionally in address domain-parts, and in mail headers. The mail header contexts can include both addresses and wherever existing protocols (e.g., RFC 2231) permit the use of encoded-words. All WG deliverables specified under the original charter, particularly the experimental protocol specifications, have been completed. The core specifications have been implemented and interoperability tests performed. The WG is now being rechartered to permit advancing revised versions of those specifications and supporting documents into the standards track. As a result of implementation and testing experience, the WG has concluded to drop the model of in-transit downgrading that was a key part of the original effort. In-transit downgrading approaches simply do not work well enough and predictably enough to be worth the considerable additional complexity that accompanies them. In particular, dropping in-transit downgrading eliminates the need for the first significant change to the syntax of an email address since RFC 821 and 822 were published in 1982. Work will therefore reflect a "no fallback" approach. That approach provides a very minimal transition mechanism, but is consistent with the long-term view that email with invalid addresses or syntax should be rejected, rather than fixed up in transit between submission servers and delivery servers. Discoverable fallback addresses that could be applied before or during message submission or after SMTP "final delivery" may be investigated. The WG may also develop other materials to give advice to implementers or operators. Those efforts may lead to informational documents or best practices recommendations, but are considered independent of the core documents. Work on them will progress only under the condition that it not delay the primary standards track specifications. The WG believes that the lessons learned from implementation and testing and removal of in-transit downgrading as a goal eliminates all major areas of controversy about the core specifications and should permit very rapid progress. Such rapid progress is an explicit goal for the WG; issues resolved in the past will not be revisited unless those who wish to do so can demonstrate data, reasoning, or consequences that were not considered earlier. At the same time, any attempt to significantly extend an established and widely deployed set of protocols may uncover new consequences or side effects that need consideration and evaluation. If faced with a choice between spending time on such new considerations, the WG will favor getting things right over accelerating the schedule. Deliverables The following deliverables are foreseen in this charter. The WG chairs may (re)structure the deliverables into specific documents or document sets as needed. Adding or removing documents other than those listed below as "Required" or "Additional" will require a charter update. Required Documents (these are the "core specifications" referred to elsewhere) * Overview and Framework for Internationalized Email, replacing RFC 4952 (Informational or Proposed Standard at IESG discretion once complete) * UTF-8 SMTP extension specification, replacing RFC 5336 (Proposed Standard) * Header format specification, replacing RFC 5335 (Proposed Standard) * Internationalized DSN specification, replacing RFC 5337 (Proposed Standard) * UTF-8 POP specification, replacing RFC 5721 (Proposed Standard) * UTF-8 IMAP specification, replacing RFC 5738 (Proposed Standard) Additional possible documents suggested. While milestones are listed for most of these documents, they may be dropped by the WG with the consent of the Responsible AD. * Advice for MUA implementors (Informational or BCP) * Advice for EAI deployment (Informational or BCP) * Advice for non-ASCII and ASCII addresses for the same mailbox (Informational or BCP) * Mailinglist (Informational or Standards Track, replacing draft-eai-mailinglist) * Mailto (Proposed Standard, updating draft-duerst-mailto-bis to reflect internationalized addresses) * Protocol extensions for RFC 4409 Submission Servers or configuration advice for the MUA->Submission server interface. Goals and Milestones: Done - Overview/architecture draft first Done - Interworking scenarios first draft Done - SMTP Extensions first draft Done - Header format first draft Done - Downgrading in SMTP first draft Done - Downgrading in IMAP first draft Done - Downgrading in POP first draft Done - Overview/architecture draft to IESG Done - SMTP Extensions to IESG Done - Header format to IESG Done - Downgrading in SMTP to IESG Done - Downgrading in POP to IESG Done - Downgrading in IMAP to IESG Done - Discussion of Recharter for standards track at IETF 77 May 2010 - New charter approval from IESG Jul 2010 - EAI Framework to IESG Sep 2010 - Headers to IESG Sep 2010 - SMTP to IESG Sep 2010 - DSN to IESG Nov 2010 - IMAP & POP3 to IESG Dec 2010 - Decision about possible changes or comments about Submission Servers. If the decision is to generate a document, the decision will include a schedule. Jan 2011 - Advice for non-ASCII & ASCII addresses to IESG Jan 2011 - Advice for MUA implementors to IESG Jan 2011 - Advice for EAI deployment to IESG Apr 2011 - Mailinglist to IESG Apr 2011 - Mailto (Proposed Standard) to IESG Internet-Drafts: - POP3 Support for UTF-8 [draft-ietf-eai-pop-10] (17 pages) - SMTP extension for internationalized email address [draft-ietf-eai-smtpext-14] (24 pages) - Downgrading mechanism for Email Address Internationalization [draft-ietf-eai-downgrade-13] (28 pages) - IMAP Support for UTF-8 [draft-ietf-eai-imap-utf8-10] (15 pages) - UTF-8 Mail: Scenarios [draft-ietf-eai-scenarios-03] (9 pages) - Overview and Framework for Internationalized Email [draft-ietf-eai-framework-06] (23 pages) - Internationalized Email Headers [draft-ietf-eai-utf8headers-13] (17 pages) - Mailing Lists and Internationalized Email Addresses [draft-ietf-eai-mailinglist-08] (12 pages) - Internationalized Delivery Status and Disposition Notifications [draft-ietf-eai-dsn-07] (19 pages) - An update to the mailto URI scheme for Email Address Internationalization [draft-ietf-eai-mailto-01] (6 pages) - Displaying Downgraded Messages for Email Address Internationalization [draft-ietf-eai-downgraded-display-04] (15 pages) - Internationalized Delivery Status and Disposition Notifications [draft-ietf-eai-dsnbis-01] (17 pages) - Overview and Framework for Internationalized Email [draft-ietf-eai-frmwrk-4952bis-12] (30 pages) - Guidelines for Internationalized Email Clients [draft-ietf-eai-email-clients-00] (16 pages) - POP3 Support for UTF-8 [draft-ietf-eai-rfc5721bis-03] (14 pages) - SMTP Extension for Internationalized Email [draft-ietf-eai-rfc5336bis-16] (21 pages) - Internationalized Email Headers [draft-ietf-eai-rfc5335bis-13] (14 pages) - Post-delivery Message Downgrading for Internationalized Email Messages [draft-ietf-eai-popimap-downgrade-03] (19 pages) - Internationalized Delivery Status and Disposition Notifications [draft-ietf-eai-rfc5337bis-dsn-06] (19 pages) - IMAP Support for UTF-8 [draft-ietf-eai-5378bis-01] (15 pages) - IMAP Support for UTF-8 [draft-ietf-eai-5738bis-03] (14 pages) - Mailing Lists and UTF-8 Addresses [draft-ietf-eai-mailinglistbis-01] (8 pages) Requests for Comments: RFC4952: Overview and Framework for Internationalized Email (23 pages) * Updated by RFC5336 RFC5335: Internationalized Email Headers (14 pages) * Updates RFC2045 * Updates RFC2822 RFC5336: SMTP Extension for Internationalized Email Addresses (22 pages) * Updates RFC2821 * Updates RFC2822 * Updates RFC4952 RFC5337: Internationalized Delivery Status and Disposition Notifications (18 pages) * Updates RFC3461 * Updates RFC3464 * Updates RFC3798 RFC5504: Downgrading Mechanism for Email Address Internationalization (24 pages) RFC5721: POP3 Support for UTF-8 (13 pages) RFC5738: IMAP Support for UTF-8 (15 pages) * Updates RFC3501 RFC5825: Displaying Downgraded Messages for Email Address Internationalization (14 pages) RFC5983: Mailing Lists and Internationalized Email Addresses (10 pages) FTP Extensions, 2nd edition (ftpext2) ------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Tony Hansen Anthony Bryan Applications Area Directors: Pete Resnick Barry Leiba Peter Saint-Andre Applications Area Advisor: Pete Resnick Mailing Lists: General Discussion: ftpext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ftpext Archive: http://www.ietf.org/mail-archive/web/ftpext/ Description of Working Group: The Standard File Transfer Protocol specification in RFC 959 has been updated several times with command extensions of one sort or another, including those based on the extension mechanism of RFC 2389 (a complete list appears in RFC 5797 and the corresponding IANA registry at http://www.iana.org/assignments/ftp-commands-extensions). The following are active FTP related drafts: draft-bryan-ftp-hash draft-hethmon-mcmurray-ftp-hosts FTP extensions to support IPv4/IPv6 translation scenario draft-klensin-ftp-typeu-00 - FTP Extension for Internationalized Text The Working Group will: * Review and finalize drafts listed above. * Review and confirm or reject errata of current FTP RFCs. * Investigate the differences between FTP in theory (current RFCs) and practice, and recommend future work to align them. Any future work would require rechartering of the WG. The Working Group's specification deliverables are: * A document that specifies the HOST command (Proposed Standard). * A document that specifies the HASH command (Proposed Standard). * A document that specifies FTP extensions to support IPv4/IPv6 translation scenario. * A document that specifies FTP extensions for Internationalized Text. The Working Group must not introduce a new version of FTP, e.g. an incompatible FTP 2.0. Goals and Milestones: Nov 2010 - Submit 'File Transfer Protocol HOST Command for Virtual Hosts' as working group item (draft-hethmon-mcmurray-ftp-hosts will be used as a starting point) Nov 2010 - Submit 'File Transfer Protocol HASH Command for Cryptographic Hashes' as working group item (draft-bryan-ftp-hash will be used as a starting point) Nov 2010 - Submit 'FTP extensions to support IPv4/IPv6 translation' as working group item (draft-liu-ftp64-extension will be used as a starting point) Dec 2010 - Working group Last Call of HOST document Jan 2011 - Submit 'File Transfer Protocol HOST Command for Virtual Hosts' to the IESG for consideration as a Proposed Standard Jan 2011 - Working group Last Call of HASH document Feb 2011 - Submit 'File Transfer Protocol HASH Command for Cryptographic Hashes' to the IESG for consideration as a Proposed Standard Mar 2011 - Working group Last Call of 'FTP extensions to support IPv4/IPv6 translation' document Apr 2011 - Submit 'FTP Extension for Internationalized Text' as working group item May 2011 - Submit 'FTP extensions to support IPv4/IPv6 translation' to the IESG for consideration as Proposed Standard Jul 2011 - Working group Last Call of 'FTP Extension for Internationalized Text' Aug 2011 - Submit 'FTP Extension for Internationalized Text' to the IESG for consideration as Proposed Standard Sep 2011 - Close or recharter Internet-Drafts: - File Transfer Protocol HASH Command for Cryptographic Hashes [draft-ietf-ftpext2-hash-03] (16 pages) - File Transfer Protocol HOST Command for Virtual Hosts [draft-ietf-ftpext2-hosts-05] (22 pages) - FTP TYPE Extension for Internationalized Text [draft-ietf-ftpext2-typeu-03] (11 pages) - FTP consideration for IPv4/IPv6 transition [draft-ietf-ftpext2-ftp64-02] (7 pages) No Requests for Comments Hypertext Transfer Protocol Bis (httpbis) ----------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chair: Mark Nottingham Applications Area Directors: Pete Resnick Barry Leiba Peter Saint-Andre Applications Area Advisor: Peter Saint-Andre Mailing Lists: General Discussion: ietf-http-wg@w3.org To Subscribe: ietf-http-wg-request@w3.org Archive: http://lists.w3.org/Archives/Public/ietf-http-wg/ Description of Working Group: HTTP is one of the most successful and widely-used protocols on the Internet today. However, its specification has several editorial issues. Additionally, after years of implementation and extension, several ambiguities have become evident, impairing interoperability and the ability to easily implement and use HTTP. The working group will refine RFC2616 to: * Incorporate errata and updates (e.g., references, IANA registries, ABNF) * Fix editorial problems which have led to misunderstandings of the specification * Clarify conformance requirements * Remove known ambiguities where they affect interoperability * Clarify existing methods of extensibility * Remove or deprecate those features that are not widely implemented and also unduly affect interoperability * Where necessary, add implementation advice * Document the security properties of HTTP and its associated mechanisms (e.g., Basic and Digest authentication, cookies, TLS) for common applications It will also incorporate the generic authentication framework from RFC 2617, without obsoleting or updating that specification's definition of the Basic and Digest schemes. Finally, it will incorporate relevant portions of RFC 2817 (in particular, the CONNECT method and advice on the use of Upgrade), so that that specification can be moved to Historic status. In doing so, it should consider: * Implementer experience * Demonstrated use of HTTP * Impact on existing implementations and deployments The Working Group must not introduce a new version of HTTP and should not add new functionality to HTTP. The WG is not tasked with producing new methods, headers, or extension mechanisms, but may introduce new protocol elements if necessary as part of revising existing functionality which has proven to be problematic. The Working Group's specification deliverables are: * A document (or set of documents) that is suitable to supersede RFC 2616 and move RFC 2817 to Historic status * A document cataloguing the security properties of HTTP Goals and Milestones: Done - First HTTP Revision Internet Draft Done - First HTTP Security Properties Internet Draft Nov 2010 - Request Last Call for HTTP Revision Nov 2010 - Request Last Call for HTTP Security Properties Apr 2011 - Submit HTTP Revision to IESG for consideration as a Draft Standard Apr 2011 - Submit HTTP Security Properties to IESG for consideration as Informational Internet-Drafts: - HTTP/1.1, part 1: URIs, Connections, and Message Parsing [draft-ietf-httpbis-p1-messaging-18] (92 pages) - HTTP/1.1, part 2: Message Semantics [draft-ietf-httpbis-p2-semantics-18] (74 pages) - HTTP/1.1, part 3: Message Payload and Content Negotiation [draft-ietf-httpbis-p3-payload-18] (44 pages) - HTTP/1.1, part 4: Conditional Requests [draft-ietf-httpbis-p4-conditional-18] (30 pages) - HTTP/1.1, part 5: Range Requests and Partial Responses [draft-ietf-httpbis-p5-range-18] (30 pages) - HTTP/1.1, part 6: Caching [draft-ietf-httpbis-p6-cache-18] (48 pages) - HTTP/1.1, part 7: Authentication [draft-ietf-httpbis-p7-auth-18] (23 pages) - Security Requirements for HTTP [draft-ietf-httpbis-security-properties-05] (14 pages) - Initial Hypertext Transfer Protocol (HTTP) Method Registrations [draft-ietf-httpbis-method-registrations-07] (6 pages) - Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) [draft-ietf-httpbis-content-disp-10] (17 pages) - Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations [draft-ietf-httpbis-authscheme-registrations-02] (4 pages) Requests for Comments: RFC6266: Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) (14 pages) * Updates RFC2616 Internationalized Resource Identifiers (iri) -------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chair: Chris Weber Applications Area Directors: Pete Resnick Barry Leiba Peter Saint-Andre Applications Area Advisor: Peter Saint-Andre Mailing Lists: General Discussion: public-iri@w3.org To Subscribe: public-iri-request@w3.org Archive: http://lists.w3.org/Archives/Public/public-iri/ Description of Working Group: This working group will produce * A new version of RFC 3987: "Internationalized Resource Identifiers (IRIs)" using draft-duerst-iri-bis as the base * A new version of RFC 4395: "Guidelines and Registration Procedures for New URI Schemes" The new version of RFC 3987 may be split into separate documents, if, in the opinion of the chair(s), it would facilitate distribution of the workload and allow more focused reviews. For example, the following breakdown has been suggested: * Handling of Internationalized domain names in IRIs (BCP) * Internationalization Considerations in IRIs (guidelines for BIDI, character ranges to avoid, special considerations) (BCP) * Syntax, parsing, comparison of IRIs (Standards track) The working group starts with a relatively mature update to RFC 3987 in preparation; the primary focus of the group is to resolve conflicting uses, requirements and best practices for internationalized URLs/URIs/IRIs and various other forms, among many specifications and committees, while moving toward consistent use of IRIs among the wide range of Internet applications that use them. In particular: * The IRI specification(s) must (continue to) be suitable for normative reference with Web and XML standards from W3C specifications. The group should coordinate with the W3C working groups on HTML5, XML Core, and Internationalization, as well as with IETF HTTPBIS WG to ensure acceptability. * The IRI specification(s) should be follow best practices for domain names. The group should coordinate with the IETF IDNABIS working group and Unicode Consortium to assure acceptability. * Explicit review by experts on (and native speakers) of RTL languages, of the recommendations for BIDI languages, is required. The Working Group will examine at least one and possibly more URI/IRI schemes to check that the new specification(s) are appropriate for existing schemes. The exact schemes to be reviewed will be decided by the WG. Changes to RFC 3986 ("Uniform Resource Identifier (URI): Generic Syntax") are explicitly out of scope of this charter, and may only be considered with a charter update. Goals and Milestones: Feb 2010 - Publish initial version of the WG documents May 2010 - Working group Last Call of all documents Jun 2010 - Publish IRI documents as RFCs (BCP, standards track, as appropriate) Internet-Drafts: - Internationalized Resource Identifiers (IRIs) [draft-ietf-iri-3987bis-09] (40 pages) - Guidelines and Registration Procedures for New URI/IRI Schemes [draft-ietf-iri-4395bis-irireg-04] (16 pages) - Equivalence and Canonicalization of Internationalized Resource Identifiers (IRIs) [draft-ietf-iri-comparison-00] (14 pages) - Guidelines for Internationalized Resource Identifiers with Bi- directional Characters (Bidi IRIs) [draft-ietf-iri-bidi-guidelines-00] (10 pages) No Requests for Comments Messaging Abuse Reporting Format (marf) --------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Barry Leiba Murray Kucherawy Applications Area Directors: Pete Resnick Barry Leiba Peter Saint-Andre Applications Area Advisor: Pete Resnick 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 Mar 2011 - Submit DKIM reporting specification for IETF approval Sep 2011 - Submit ARF guidelines document for IETF approval Sep 2011 - Submit ARF address advertising specification for IETF approval Internet-Drafts: - Redaction of Potentially Sensitive Data from Mail Abuse Reports [draft-ietf-marf-redaction-08] (8 pages) - Extensions to DKIM for Failure Reporting [draft-ietf-marf-dkim-reporting-09] (22 pages) - An Extensible Format for Email Feedback Reports [draft-ietf-marf-base-07] (38 pages) - Authentication Failure Reporting using the Abuse Report Format [draft-ietf-marf-authfailure-report-10] (21 pages) - A DNS TXT Record for Advertising and Discovering Willingness to Provide or Receive ARF Reports [draft-ietf-marf-reporting-discovery-02] (14 pages) - SPF Authentication Failure Reporting using the Abuse Report Format [draft-ietf-marf-spf-reporting-05] (15 pages) - Email Feedback Report Type Value : not-spam [draft-ietf-marf-not-spam-feedback-04] (7 pages) - Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF) [draft-ietf-marf-as-07] (13 pages) Requests for Comments: RFC5965: An Extensible Format for Email Feedback Reports (25 pages) RFC6430: Email Feedback Report Type Value: not-spam (7 pages) Preparation and Comparison of Internationalized Strings (precis) ---------------------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Marc Blanchet Yoshiro Yoneya Applications Area Directors: Pete Resnick Barry Leiba Peter Saint-Andre Applications Area Advisor: Pete Resnick Mailing Lists: General Discussion: precis@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/precis Archive: http://www.ietf.org/mail-archive/web/precis/ Description of Working Group: Problem Statement The use of non-ASCII strings in Internet protocols requires additional processing to be handled properly. As part of the Internationalized Domain Names (idn) work in 2003, a method for preparation and comparison of internationalized strings was defined and generalized to be re-used by other protocols. This "stringprep" method [RFC 3454] defines the overall framework whereas specific protocols define their own profiles. Known existing IETF profiles are: - The Nameprep profile [RFC 3490] for use in Internationalized Domain Names in Applications (IDNA) - The iSCSI profile [RFC 3722] for use in Internet Small Computer Systems Interface (iSCSI) Names - The Nodeprep and Resourceprep profiles [RFC 3920] for use in the Extensible Messaging and Presence Protocol (XMPP) - The Policy MIB profile [RFC 4011] for use in the Simple Network Management Protocol (SNMP) - The SASLprep profile [RFC 4013] for use in the Simple Authentication and Security Layer (SASL) - The trace profile [RFC 4505] for use with the SASL ANONYMOUS mechanism - The LDAP profile (RFC 4518] for use with LDAP The IAB completed a review of IDN and made recommendations for change [RFC 4690], which triggered a new version of the IDNA protocol called IDNA2008. Whereas IDNA2003 was tied to Unicode 3.2 via stringprep, IDNA2008 does not use the stringprep method, but instead uses an algorithm based on the properties of Unicode characters, which makes it agile to the Unicode database version. The protocols using stringprep need Unicode version agility and therefore need to investigate whether and how to move away from the current stringprep approach, with the associated challenges of backward compatibility and migration. Objectives The goal of this group is to assess whether a new method based on the new IDNA2008 algorithmic approach is the appropriate path forward for existing stringprep protocols as well as for other application protocols requiring internationalized strings. The group will evaluate if a new generalized framework based on the algorithmic approach is appropriate and, if so, define it. The group will analyze existing stringprep profiles and will do one of the following with regard to each profile: 1. Develop a replacement for the profile in close collaboration with the related protocol working group (if any). 2. Collaborate with another active working group which will be developing the new profile as part of its charter. 3. Advise the authors of profiles for which there is no active working group how to proceed. The group will also define a set of best current practices for preparation and comparison of internationalized strings. Because the framework, profile replacements, and guidelines are very much interrelated, work on them will proceed in parallel as much as possible. Based on normal working group processes for achieving consensus, the group will attempt to gather input from, and may provide advice to, "customers" working on IETF technologies other than those listed above, including but not limited to Network Address Identifiers (RFC 4282) and Kerberos (RFC 4120). However, the group will prioritize work on the listed stringprep profiles higher than work on other technologies, and will formally accept additional tasks as official milestones only after rechartering. In completing its tasks, the working group should collaborate with other teams involved in internationalized identifiers, such as the IETF's IRI and EAI working groups as well as other relevant standards development organizations (e.g., the Unicode Consortium). Deliverables 1. Problem statement / analysis of existing stringprep profiles (Informational). 2. Possible new framework to replace stringprep (Standards Track). 3. Possible replacements for the existing IETF stringprep profiles as listed earlier in this charter (Standards Track). 4. String preparation and comparison guidelines (BCP). Goals and Milestones: Aug 2010 - Accept problem statement document as a WG item Nov 2010 - Accept framework document as a WG item Nov 2010 - Accept new profile documents as WG items Dec 2010 - Start Working Group Last Call on problem statement document Jan 2011 - Submit problem statement document to the IESG Jan 2011 - Accept guidelines document as a WG item May 2011 - Start Working Group Last Call on framework document May 2011 - Start Working Group Last Call on new profile documents Jun 2011 - Submit framework document to the IESG Jun 2011 - Submit new profile documents to the IESG Jun 2011 - Start Working Group Last Call on guidelines document Aug 2011 - Submit guidelines document to the IESG Internet-Drafts: - Stringprep Revision Problem Statement [draft-ietf-precis-problem-statement-04] (18 pages) - PRECIS Framework: Handling Internationalized Strings in Protocols [draft-ietf-precis-framework-01] (27 pages) No Requests for Comments Protocol to Access WS database (paws) ------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Brian Rosen Gabor Bajko Applications Area Directors: Pete Resnick Barry Leiba Peter Saint-Andre Applications Area Advisor: Peter Saint-Andre Mailing Lists: General Discussion: paws@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/paws Archive: http://www.ietf.org/mail-archive/web/paws/ Description of Working Group: Background Radio spectrum is a limited resource. National and international bodies assign different frequencies for specific uses, and in most cases license the rights to use these frequencies. Locally unused spectrum is commonly called "white space" and may be made available to other services on a basis of non-interference with the primary user of the frequencies concerned (if any). This technique can help "unlock" existing spectrum, for example to enable the wireless communications industry to provide more services over frequencies associated with unused television channels. An obvious requirement is that white space uses must not interfere with the primary use of the spectrum. This is achieved through spatial and/or temporal separation of the primary user and whitespace user with due consideration made to the radio characteristics of the two uses. Problem Statement The fundamental problem is enabling a radio device to determine, in a specific location and at specific time, if any white space is available for secondary use. There are two parties to such an interaction: 1. A database containing records about the protected contours (in space and time) of primary spectrum users. Typically, such databases will be populated by information provided by the appropriate spectrum regulation bodies and by spectrum licensees. 2. A radio device that wishes to query such a database. Typically, the nature of the query will depend on the needs of the device. The contents of white space databases, and the needs of radio devices, are being defined elsewhere. However, these parties need a protocol for communication that will enable radio devices to find out what white space is available at a given time in a given location. It is expected that white space databases will be reachable via the Internet, and that radio devices too will have some form of Internet connectivity, directly or indirectly. Therefore, it is appropriate to define an Internet-based protocol for querying white space databases and receiving responses from such databases. In rough outline, such a protocol would enable a radio device that knows its location and the current time to complete the following tasks: 1. Determine the relevant white space database to query. 2. Connect to the database using a well-defined access method. 3. Provide its geolocation and perhaps other data to the database using a well-defined format for querying the database. 4. Receive in return a list of currently available white space using a well-defined format for returning information. Once the device learns of the available white space (e.g., in a TV white space implementation, the list of available channels at that location), it can then select one of the bands from the list and begin to transmit and receive on the selected band. If the device's parameters have changed (e.g., if some amount of time has passed or if the device has changed location beyond a specified threshold), it might need to query the database again to determine what white space is still available. Objectives The overall goals of this working group are to: 1. Standardize a mechanism for discovering a white space database. 2. Standardize a method for accessing a white space database. 3. Standardize query and response formats to be carried over the database access method. 4. Ensure that the discovery mechanism, database access method, and query/response formats have appropriate security levels in place. By "standardize" is not meant that the working group will necessarily develop new technologies. In completing its work, the group will: - Evaluate existing discovery mechanisms to determine if one of them provides the necessary application features and security properties (or can be extended to do so) for discovering a white space database. Examples might include DNS. - Evaluate existing application-layer transport protocols to determine if one of them provides the necessary application features and security properties (or can be extended to do so) for use as a building block for communication between location- aware devices and white space databases. If such a method exists, the group will reuse it; if not, the group will develop one. Examples might include HTTP. - Develop a method for querying a white space database. Such a method will utilize, so far as possible, the features of the application-layer transport protocol and not re-implement them in the new protocol. It will include mechanisms to verify that the requests and responses come from authorized sources, and that they have not been modified in transit. Examples might include LDAP. - Define extensible formats for both location-specific queries and location-specific responses for interaction with radio white space databases. The group will consider whether existing data formats can be reused. The protocol must protect both the channel enablement process and the privacy of users. Robust privacy and security mechanisms are needed to prevent: device identity spoofing, modification of device requests, modification of channel enablement information, impersonation of registered database services, and unauthorized disclosure of a device's location. The group will consider whether existing privacy and security mechanisms can be reused. The task of defining the structure and contents of the databases themselves is out of scope. The group will standardize formats for communication between devices and databases, but not the information models for the databases, since those models are likely to be country-specific or application-specific. In addition, the particular data exchanged between a device and a database might depend on the ranges of radio spectrum that are to be used, the requirements of the database operators and their governing regulations, and other factors. Therefore, the database access method and the query/response data formats that are exchanged using that method need to be designed for extensibility rather than being tied to any specific spectrum, country, or phy/mac/air interface. For example, the working group should define extension points for the database access method and the query/response formats, so that use cases other than those currently envisioned can be addressed in the future if a community of interest wishes to do so. However, the access method and query/response formats will incorporate relevant aspects of the parameters needed for the currently envisioned use cases to ensure proper operation. In accordance with existing IETF processes, the group will communicate and invite participation with other relevant standards bodies and groups, and if necessary reuse existing liaison relationships or request the establishment of new liaison relationships, including but not limited to IEEE 802.11af and IEEE 802.22. In order to ensure that it takes into account a broad range of possible use cases and requirements, the group should also reach out to other potential "customers" for a white space database access method and consider input from regulatory entities that are involved in the specification of the rules for secondary use of spectrum in specific radio bands. Deliverables 1. A description of the relevant use cases and requirements. This document shall be Informational. Subject to working group consensus, draft-probasco-paws-overview-usecases and draft-patil-paws-problem-stmt might be used as a starting point. 2. A specification of the mechanism for discovering a white space database, the method for accessing a white space database, and the query/response formats for interacting with a white space database. This document shall be Standards Track. Goals and Milestones: Oct 2011 - Submit 'Use Cases and Requirements for Accessing a Radio White Space Database' to the IESG for publication as Informational Apr 2012 - Submit 'Accessing a Radio White Space Database' to the IESG for publication as Proposed Standard Internet-Drafts: - Protocol to Access White Space database: PS, use cases and rqmts [draft-ietf-paws-problem-stmt-usecases-rqmts-02] (34 pages) No Requests for Comments Reputation Services (repute) ---------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Dave Crocker Chris Lewis Applications Area Directors: Pete Resnick Barry Leiba Peter Saint-Andre Applications Area Advisor: Pete Resnick Mailing Lists: General Discussion: domainrep@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/domainrep/ Archive: http://www.ietf.org/mail-archive/web/domainrep/ Description of Working Group: In the open Internet, making a meaningful choice about the handling of content requires an assessment of its safety or "trustworthiness". This can be based on a trust metric for the owner (identity) of an identifier associated with the content, to distinguish (likely) good actors from bad actors. The generic term for such information is "reputation". This working group will develop mechanisms for reputation reporting by independent services. One mechanism will be for a basic assessment of trustworthiness. Another will provide a range of attribute/value data that is used as input to such an assessment. Each service determines the attributes it reports. Various mechanisms have been developed for associating a verified identifier with email content, such as with SPF (RFC4408) and DKIM (RFC4871). An existing reputation query mechanism is Vouch-by-Reference (RFC5518). It provides a simple Boolean response concerning a domain name used for email. The current working group effort will expand upon this, to support additional applications -- such as Web pages and hosts -- and a wider range of reporting information. Given the recent adoption of domain name verification for email, by SPF and DKIM, the most obvious initial use case for reputation is for email. Inbound email filters that perform message authentication can obtain a verified domain name and then consult a reputation service provider to make a determination (perhaps also based on other factors) of whether or not the content is desirable and take appropriate action with respect to delivery, routing or rejection. Another possible use case is identity-based evaluation of web content using technologies such as the DKIM-derived DOSETA (work in progress). This working group will produce specifications (targeting the standards track, though the working group will determine the appropriate status) for: * the detailed requirements for reporting * an end-to-end system architecture in which reporting occurs * the mechanisms and formats for reporting Two mechanisms are under consideration: * simple -- a reputation is expressed in a simple manner, via records in the DNS (see draft-kucherawy-reputation-query-dns) * extended -- a response can contain more complex information useful to an assessor, reported over HTTP using an encoding such as XML or JSON (see draft-kucherawy-reputation-query-http) The syntactic and semantic aspects of mechanisms and formats will be designed to be application-independent and portable (i.e., reputation provider-independent). By distinguishing reporting information (format) from reporting mechanism (channel), the specifications will permit adaptation to support reporting through additional channels. Limited application-specific tailoring will be provided for email, to demonstrate the approach, which can be applied for supporting additional applications. The design and specification will also permit adaptation to support reporting through additional transport channels. Items that are specifically out of scope for this work: * Specific actions to be taken in response to a reputation reply. It is up to assessors (i.e., the consumers of reputation data) to determine this. Non-normative illustrations, however, can be included to demonstrate possible uses of reputation data in a particular context. * Selection of what data might be valid as the subject of a reputation query. It is up to reputation service providers and assessors to select which qualities of a body of data might be useful input to reputation evaluation. * Concerns about methods of verifying domain names that are used for email reputation. A verified domain name is a starting point for this work; the means by which it was obtained and the "meaning" of the name or its verification are matters for discussion elsewhere. * Algorithms to be applied to aggregated feedback in order to compute reputations. These are part of a back-end system, usually proprietary, and not appropriate for specification as part of a query/reply framework and protocol. The initial draft set: draft-kucherawy-reputation-model draft-kucherawy-reputation-media-type draft-kucherawy-reputation-query-http draft-kucherawy-reputation-query-dns draft-kucherawy-reputation-query-udp draft-kucherawy-reputation-vocab-identity Goals and Milestones: Mar 2012 - Informational document, defining the problem space and solution architecture, to the IESG for publication. Mar 2012 - Specification for the multi-attribute reporting data structure, to the IESG for publication. May 2012 - Informational document, defining the vocabulary for providing reputation in the email sphere, to the IESG for publication. Jul 2012 - Specification defining the simple query mechanism, to the IESG for publication. Jul 2012 - Specification for the extended query mechanism, to the IESG for publication. Oct 2012 - Informational document, discussing issues of data transparency, redress, meta-reputation and other important operational considerations, to the IESG for publication. Internet-Drafts: - A Media Type for Reputation Interchange [draft-ietf-repute-media-type-01] (12 pages) - Reputation Data Interchange using HTTP and XML [draft-ietf-repute-query-http-01] (7 pages) - A Reputation Vocabulary for Email Identifiers [draft-ietf-repute-email-identifiers-02] (7 pages) - A Model for Reputation Interchange [draft-ietf-repute-model-00] (8 pages) No Requests for Comments SPF Update (spfbis) ------------------- Charter Last Modified: 2012-02-07 Current Status: Active Chairs: Andrew Sullivan S Moonesamy Applications Area Directors: Pete Resnick Barry Leiba Peter Saint-Andre Applications Area Advisor: Pete Resnick Mailing Lists: General Discussion: spfbis@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/spfbis Archive: http://www.ietf.org/mail-archive/web/spfbis/ Description of Working Group: The Sender Policy Framework (SPF, RFC4408) specifies the publication of a DNS record which states that a listed IP address is authorized to send mail on behalf of the listing domain name's owner. SMTP servers extract the domain name in the SMTP "MAIL FROM" or "HELO" command for confirming this authorization. The protocol has had Experimental status for some years and has become widely deployed. This working group will summarize the result of the experiment and revise the specification, based on deployment experience and listed errata, and will seek Standards Track status for the protocol. The MARID working group considered two specifications for publication of email-sending authorization: Sender-ID, which eventually became RFC4405, RFC4406 and RFC4407, and SPF, which eventually became RFC4408, all in the end published under Experimental status. By using IP addresses, both protocols specify authorization in terms of path, though unlike SPF, Sender-ID uses domain names found in the header of the message rather than the envelope. The two protocols rely on the same policy publication mechanism, namely a specific TXT resource record in the DNS. This creates a basic ambiguity about the interpretation of any specific instance of the TXT record. Because of this, there were concerns about conflicts between the two in concurrent operation. The IESG note prepended to RFC 4405 through RFC 4408 defined an experiment with SPF and Sender-ID, and invited an expression of community consensus in the period following the publication of those specifications. Both technologies initially enjoyed widespread deployment. Since that time, broad SPF use has continued, whereas use of Sender-ID has slackened. Furthermore, SPF's linkage to the envelope (as opposed to Sender-ID's linkage to identifiers in the message content) has proven sufficient among operators. Formation of the SPF Update Working Group is predicated on three assumptions: 1. The SPF/Sender-ID experiment has concluded. 2. SPF has been a qualified success, warranting further development. 3. Sender-ID has had less success, and no further development is justified. The working group will produce a document describing the course of the SPF/Sender-ID experiment, thus bringing that experiment to a formal conclusion. The group will complete additional work on SPF (described below), but will not complete additional work on the Sender-ID specification. Changes to the SPF specification will be limited to the correction of errors, removal of unused features, addition of any enhancements that have already gained widespread support, and addition of clarifying language. Specifically out-of-scope for this working group: * Revisiting past technical arguments where consensus was reached in the MARID working group, except where review is reasonably warranted based on operational experience. * Discussion of the merits of SPF. * Discussion of the merits of Sender-ID in preference to SPF. * Extensions to the SPF protocols. * Removal of existing features that are in current use. Discussion of extensions to the SPF protocols or removal of existing features shall only be discussed after completion of current charter items in anticipation of rechartering the working group. An initial draft of an updated SPF specification document is draft-kitterman-4408bis. The working group may choose to use this document as a basis for their specification. Goals and Milestones: Aug 2012 - A document describing the SPF/Sender-ID experiment and its conclusions to the IESG for publication. Dec 2012 - A standards track document defining SPF, based on RFC4408 and as amended above, to the IESG for publication. Internet-Drafts: No Requests for Comments Sieve Mail Filtering Language (sieve) ------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Cyrus Daboo Aaron Stone Applications Area Directors: Pete Resnick Barry Leiba Peter Saint-Andre Applications Area Advisor: Pete Resnick Secretary: Barry Leiba 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) External lists (draft-ietf-sieve-external-lists) (b) Notify SIP (draft-ietf-sieve-notify-sip-message) (c) RegEx (draft-ietf-sieve-regex) (d) Include/multi-script (draft-ietf-sieve-include) (e) Sieve in IMAP (draft-ietf-sieve-imap-sieve) (2) Finalize and publish the following SIEVE extensions as proposed standards: (a) General Auto-reply (draft-george-sieve-autoreply) (b) Notify presence (draft-george-sieve-notify-presence) (c) Vacation time (draft-george-sieve-vacation-time) (d) Convert messages (draft-melnikov-sieve-convert) 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 for iCalendar and vCard extraction, and cooperate with the VCARDDAV WG for address book tests in Sieve. (4) Work on a specification to describe how EAI/IDN issues should be handled in SIEVE. (5) 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. (6) 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 Done - WGLC Metadata Done - Submit Metadata to IESG Done - Publish refuse/reject - RFC 5429 Done - Publish notify base spec - RFC 5435 Done - Publish notify mailto extension - RFC 5436 Done - Publish notify xmpp extension - RFC 5437 Done - Publish ihave - RFC 5463 Done - Publish meta-data - RFC 5490 Done - Publish mime loops - RFC 5703 Done - Publish Sieve in XML - RFC 5784 Done - Revised RegEx draft Apr 2010 - Revised Include/multi-script draft Apr 2010 - WGLC external-lists May 2010 - WGLC Include/multi-script May 2010 - Submit external-lists to IESG Jun 2010 - Submit Include/multi-script to IESG Jun 2010 - WGLC Notify-SIP Jul 2010 - Initial eai-issues draft Jul 2010 - Submit Notify-sip to IESG Aug 2010 - WGLC RegEx Aug 2010 - Initial test-scripts draft Aug 2010 - Initial benefits draft Sep 2010 - Submit RegEx to IESG Oct 2010 - WGLC eai-issues Nov 2010 - Submit eai-issues to IESG Nov 2010 - WGLC benefits Jan 2011 - Submit benefits to IESG Mar 2011 - WGLC test-scripts Apr 2011 - 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-11] (18 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-01] (9 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-10] (16 pages) - Sieve Email Filtering: Sieves and display directives in XML [draft-freed-sieve-in-xml-08] (33 pages) - A Protocol for Remotely Managing Sieve Scripts [draft-ietf-sieve-managesieve-10] (52 pages) - Sieve Notification Mechanism: SIP MESSAGE [draft-ietf-sieve-notify-sip-message-08] (11 pages) - Sieve Email Filtering: Include Extension [draft-ietf-sieve-include-15] (17 pages) - Support for Sieve in Internet Message Access Protocol (IMAP4) [draft-ietf-sieve-imap-sieve-03] (24 pages) - Sieve Vacation Extension: "Seconds" parameter [draft-ietf-sieve-vacation-seconds-04] (6 pages) - Sieve Notification Using Presence Information [draft-ietf-sieve-notify-presence-05] (9 pages) - Sieve Email Filtering: Use of Presence Information with Auto Responder functionality [draft-ietf-sieve-autoreply-05] (10 pages) - Sieve Extension for Converting Messages Before Delivery [draft-ietf-sieve-convert-06] (9 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) RFC5784: Sieve Email Filtering: Sieves and Display Directives in XML (32 pages) RFC5804: A Protocol for Remotely Managing Sieve Scripts (49 pages) RFC6009: Sieve Email Filtering: Delivery Status Notifications and Deliver-By Extensions (15 pages) Uniform Resource Names, Revised (urnbis) ---------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Andrew Newton Alfred Hoenes Applications Area Directors: Pete Resnick Barry Leiba Peter Saint-Andre Applications Area Advisor: Peter Saint-Andre Mailing Lists: General Discussion: urn@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/urn Archive: http://www.ietf.org/mail-archive/web/urn/current/maillist.html Description of Working Group: * * * Problem Statement * * * Uniform Resource Names (URNs) are location-independent, persistent identifiers for information resources. The RFCs defining URNs were published in 1997-2001. They rely on old (or even provisional) basic documents on the concepts of URI and URL. At that time there was almost no URN implementation experience. Since then, the URN system has gained significant popularity, and roughly 40 formal URN Namespaces have been defined and registered with IANA. Hundreds of millions of resources have been assigned URNs; this enables searching of and persistent linking to these documents, artifacts, and other objects. However, the URN system lacks a foundation that is consistent in terminology and formal description with present (Full) Internet Standards. The core URN RFCs -- RFC 2141 (URN Syntax), RFC 3406 (Namespace Definition Mechanisms) -- are based on outdated framework documents and understanding of digital archiving. All references in RFC 2141 point to "work in progress" or documents that have been superseded at least once. The lack of a standard definition of the 'urn' URI scheme fosters recurring discussions on what URNs are and IETF commitment to them. There is a need to clarify that URNs are specific URIs (namely those using the 'urn' URI scheme) and hence all general URI rules apply to URNs. There also is a need to update some namespace registrations for at least two reasons: the standards specifying the relevant underlying namespaces (such as International Standard Book Number (ISBN)) have been amended/expanded since the original specification of the related URN namespace and the WG's update of the basic URN-related RFCs might introduce or identify inconsistencies. * * * Objectives for the Working Group * * * This working group is chartered to update the key RFCs describing the URN system, including RFC 2141 (URN Syntax), RFC 3406 (Namespace Definition Mechanisms), and review and update selected URN namespace specifications including those for ISBN, National Bibliography Numbers (NBN) and International Serial Standard Number (ISSN). For all document revisions, backward compatibility with previous URN-related RFCs will be retained. The WG will produce an updated set of URN-related RFCs. All documents will be on the Standards-Track or BCP. These updates will provide a normative foundation for URNs and assure uniformity of the URN assignment and resolution concepts and procedures at the abstract level. Details and tasks (the WG will approach these tasks in roughly this order): a) Core URN specifications For RFC 2141, this revision will include in particular: - an update of the formal syntax specification in the light of the URI Standard (STD 66, RFC 3986) using the ABNF from STD 68 (RFC 5234); - a formal IANA registration for the 'urn' URI scheme using the current template from BCP 35 (RFC 4395); - a revised set of URN examples and - an update of the sections describing how URNs are resolved in the Internet, based on the current practices. RFC 3406 (BCP 33) will be aligned with the current IANA procedures and terminology as defined in BCP 26 (RFC 5226). b) URN Namespace specifications The WG will focus on updating the RFCs related to the key bibliographic identifier systems: - RFC 3187 (URN Namespace for International Standard Book Numbers), - RFC 3188 (URN Namespace for National Bibliography Numbers), and - RFC 3044 (URN Namespace for International Serial Standard Number). All these identifier systems have been updated since these RFCs were written in a way that makes revision of the namespace registration necessary. c) Further work The WG will support the current registrants of URN namespaces. It will review the legacy URN namespace definition documents and if needed, provide advice to their registrants on how to bring these registrations in line with the upcoming URN-related RFCs. However any work on updating such specifications beyond giving an advice would require rechartering of the WG. WG Output: +++++++++++++++++ Revision of RFC 2141 based on draft-ah-rfc2141bis-urn Revision of RFC 3406 Revision of RFC 3187 based on draft-hakala-rfc3187bis-isbn-urn Revision of RFC 3188 based on draft-hakala-rfc3188bis-nbn-urn Revision of RFC 3044 Goals and Milestones: Feb 2011 - WGLC on rfc2141bis, rfc3406bis, rfc3187bis-isbn-urn and rfc3188bis-nbn-urn Apr 2011 - Deliver rfc2141bis, rfc3406bis, rfc3187bis-isbn-urn and rfc3188bis-nbn-urn to IESG for consideration as Proposed Standards May 2011 - WGLC on rfc3044bis Jul 2011 - Deliver rfc3044bis to IESG for consideration as Proposed Standards Apr 2012 - Implementation report for promoting 2141bis to Draft Standard Internet-Drafts: - Uniform Resource Name (URN) Syntax [draft-ietf-urnbis-rfc2141bis-urn-01] (28 pages) - Uniform Resource Name (URN) Namespace Definition Mechanisms [draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01] (29 pages) - Using International Standard Book Numbers as Uniform Resource Names [draft-ietf-urnbis-rfc3187bis-isbn-urn-01] (20 pages) - Using National Bibliography Numbers as Uniform Resource Names [draft-ietf-urnbis-rfc3188bis-nbn-urn-02] (20 pages) No Requests for Comments Web Security (websec) --------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Alexey Melnikov Tobias Gondrom Applications Area Directors: Pete Resnick Barry Leiba Peter Saint-Andre Applications Area Advisor: Peter Saint-Andre Tech Advisor: Sean Turner Secretary: Yoav Nir Mailing Lists: General Discussion: websec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/websec Archive: http://www.ietf.org/mail-archive/web/websec/current/maillist.html Description of Working Group: Problem Statement Although modern Web applications are built on top of HTTP, they provide rich functionality and have requirements beyond the original vision of static web pages. HTTP, and the applications built on it, have evolved organically. Over the past few years, we have seen a proliferation of AJAX-based web applications (AJAX being shorthand for asynchronous JavaScript and XML), as well as Rich Internet Applications (RIAs), based on so-called Web 2.0 technologies. These applications bring both luscious eye-candy and convenient functionality, e.g. social networking, to their users, making them quite compelling. At the same time, we are seeing an increase in attacks against these applications and their underlying technologies. The list of attacks is long and includes Cross-Site-Request Forgery (CSRF)-based attacks, content-sniffing, cross-site-scripting (XSS) attacks, attacks against browsers supporting anti-XSS policies, clickjacking attacks, malvertising attacks, as well as man-in-the-middle (MITM) attacks against "secure" (e.g. Transport Layer Security (TLS/SSL)-based) web sites along with distribution of the tools to carry out such attacks (e.g. sslstrip). Objectives and Scope With the arrival of new attacks the introduction of new web security indicators, security techniques, and policy communication mechanisms have sprinkled throughout the various layers of the Web and HTTP. The goal of this working group is to compose an overall "problem statement and requirements" document derived from surveying the issues outlined in the above section ([1] provides a starting point). The requirements guiding the work will be taken from the Web application and Web security communities. The scope of this document is HTTP applications security, but does not include HTTP authentication, nor internals of transport security which are addressed by other working groups (although it may make reference to transport security as an available security "primitive"). See the "Out of Scope" section, below. Additionally, the WG will standardize a small number of selected specifications that have proven to improve security of Internet Web applications. Initial work will be the following topics: - Same origin policy, as discussed in draft-abarth-origin (see also Appendices A and B, below) - HTTP Strict transport security, as discussed in draft-hodges-strict-transport-sec - Media type sniffing, as discussed in draft-abarth-mime-sniff This working group will work closely with IETF Apps Area WGs (such as HYBI, HTTPstate, and HTTPbis), as well as appropriate W3C working group(s) (e.g. HTML, WebApps). Out of Scope As noted in the objectives and scope (above), this working group's scope does not include working on HTTP Authentication nor underlying transport (secure or not) topics. So, for example, these items are out-of-scope for this WG: - Replacements for BASIC and DIGEST authentication - New transports (e.g. SCTP and the like) Deliverables 1. A document illustrating the security problems Web applications are facing and listing design requirements. This document shall be Informational. 2. A selected set of technical specifications documenting deployed HTTP-based Web security solutions. These documents shall be Standards Track. References [1] Hodges and Steingruebl, "The Need for a Coherent Web Security Policy Framework", W2SP position paper, 2010. http://w2spconf.com/2010/papers/p11.pdf Appendices A. Relationship between origin work in IETF WebSec and W3C HTML WG draft-abarth-origin defines the nuts-and-bolts of working with origins (computing them from URIs, comparing them to each other, etc). HTML5 defines HTML-specific usage of origins. For example, when making an HTTP request, HTML5 defines how to compute which origin among all the origins rendering HTML is the one responsible for making the request. draft-abarth-origin then takes that origin, serializes it to a string, and shoves it in a header. B. Origin work may yield two specifications There also seems to be demand for a document that describes the same-origin security model overall. However, it seems like that document ought to be more informative rather than normative. The working group may split draft-abarth-origin into separate informative and standards track specifications, the former describing same-origin security model, and the latter specifying the nuts-and-bolts of working with origins (computing them from URLs, comparing them to each other, etc). Goals and Milestones: Oct 2010 - Submit 'HTTP Application Security Problem Statement and Requirements' as initial WG item. Done - Submit 'Media Type Sniffing' as initial WG item. Done - Submit 'Web Origin Concept' as initial WG item. Done - Submit 'Strict Transport Security' as initial WG item. Feb 2011 - Submit 'HTTP Application Security Problem Statement and Requirements' to the IESG for consideration as an Informational RFC. Mar 2011 - Submit 'Media Type Sniffing' to the IESG for consideration as a Standards Track RFC. Done - Submit 'Web Origin Concept' to the IESG for consideration as a Standards Track RFC. Mar 2011 - Submit 'Strict Transport Security' to the IESG for consideration as a Standards Track RFC. Apr 2011 - Possible re-chartering Internet-Drafts: - The Web Origin Concept [draft-ietf-websec-origin-07] (26 pages) - Media Type Sniffing [draft-ietf-websec-mime-sniff-04] (24 pages) - HTTP Strict Transport Security (HSTS) [draft-ietf-websec-strict-transport-sec-04] (43 pages) - Public Key Pinning Extension for HTTP [draft-ietf-websec-key-pinning-01] (16 pages) Requests for Comments: RFC6454: The Web Origin Concept (20 pages) vCard and CardDAV (vcarddav) ---------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chair: Simon Perreault Applications Area Directors: Pete Resnick Barry Leiba Peter Saint-Andre Applications Area Advisor: Peter Saint-Andre 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 4.0) and an access protocol (CardDAV) for the interchange of both PABs and user directory entry data objects. Having completed its work on the base vCard and CardDAV specifications, the VCARDDAV working group currently focuses on extensions to those two technologies. In particular, the WG will complete the following work: (1) A limited set of extensions to vCard (and its XML representation) as well as to CardDAV. Extensions are accepted for group consideration based on normal IETF consensus rules and in consultation with the responsible Area Director. (2) A lossless mapping between LDAP and vCard 4.0. Goals and Milestones: Done - Address book access protocol draft Done - vCard new revision draft Done - submit to IESG both drafts Done - XML schema Sep 2011 - Submit simple extensions to IESG as Proposed Standard (draft-ietf-vcarddav-kind-app; draft-ietf-vcarddav-birth-death-extensions) Nov 2011 - Adopt draft for LDAP mapping as working group item (draft-cal-resource-schema or its equivalent will be taken as the starting point) Dec 2011 - Submit social networking extensions to IESG as Proposed Standard (draft-george-vcarddav-vcard-extension will be taken) as the starting point Dec 2011 - Submit OMA extensions to IESG as Proposed Standard (draft-cauchie-vcarddav-oma-cab-extensions will be taken as the starting point) Dec 2011 - Submit CardDAV extensions to IESG as Proposed Standard (draft-daboo-carddav-directory-gateway will be taken as the starting point) Apr 2012 - Submit LDAP mapping to IESG as Proposed Standard Internet-Drafts: - vCard Extensions to WebDAV (CardDAV) [draft-ietf-vcarddav-carddav-11] (56 pages) - vCard Format Specification [draft-ietf-vcarddav-vcardrev-23] (89 pages) - Extended MKCOL for WebDAV [draft-ietf-vcarddav-webdav-mkcol-07] (13 pages) - xCard: vCard XML Representation [draft-ietf-vcarddav-vcardxml-12] (25 pages) - vCard KIND:application [draft-ietf-vcarddav-kind-app-01] (6 pages) - vCard Format Extensions : place of birth, place and date of death [draft-ietf-vcarddav-birth-death-extensions-03] (6 pages) - vCard Format extension : represent vCard extensions defined by the Open Mobile Alliance (OMA) Converged Address Book (CAB) group [draft-ietf-vcarddav-oma-cab-extensions-00] (16 pages) - vCard Format Extension : To Represent the Social Network Information of an Individual [draft-ietf-vcarddav-social-networks-00] (12 pages) Requests for Comments: RFC5689: Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV) (13 pages) * Updates RFC4791 * Updates RFC4918 RFC6352: CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV) (48 pages) RFC6351: xCard: vCard XML Representation (22 pages) RFC6350: vCard Format Specification (74 pages) * Obsoletes RFC2425 * Obsoletes RFC2426 * Obsoletes RFC4770 * Updates RFC2739 RFC6473: vCard KIND:application (5 pages) RFC6474: vCard Format Extensions: Place of Birth, Place and Date of Death (6 pages) Access Node Control Protocol (ancp) ----------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Matthew Bocci Wojciech Dec Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman Internet Area Advisor: Ralph Droms Tech Advisor: Dan Romascanu Mailing Lists: General Discussion: ancp@ietf.org To Subscribe: ancp-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/ancp/current/maillist.html Description of Working Group: Purpose: The purpose of the ANCP WG is to standardize an IP-based Access Node Control Protocol (ANCP) for use in service provider Digital Subscriber Line (DSL) and Passive Optical Network (PON) access and aggregation networks. ANCP operates between an Access Node (AN) and Network Access Server (NAS). Necessary Terminology: Access Node (AN) - Network device, usually located at a service provider central office or street cabinet, that terminates access loop connections from Subscribers. In DSL, this is often referred to as a Digital Subscriber Line Access Multiplexer (DSLAM). In PON, this is usually comprised of an Optical Network Termination (ONT) / Optical Network Unit (ONU) and an Optical Line Termination (OLT). Network Access Server (NAS) - Network device which aggregates multiplexed Subscriber traffic from a number of Access Nodes. The NAS plays a central role in per-subscriber policy enforcement and QoS. This is often referred to as a Broadband Network Gateway (BNG) or Broadband Remote Access Server (BRAS). A detailed definition of the NAS is given in RFC2881. Goals: ANCP is intended to address the requirement for a bidirectional, IP- based, control protocol that operates across multiple types (i.e., Ethernet, ATM) of DSL and PON access and aggregation networks. The goal of an ANCP message exchange is to convey status and control information between one or more ANs and one or more NASs without going through intermediate element managers. The ANCP WG will address the following four use-cases: 1. Dynamic Access Loop Attributes Various queuing and scheduling mechanisms are used in access networks to avoid congestion while dealing with multiple flows and distinct QoS profiles. Communicating the access-loop status, attributes and current DSL synchronization rate between the AN and Subscriber up to the NAS is desirable, particularly when the NAS is providing QoS for individual flows and subscribers. ANCP will provide a mechanism to communicate dynamic access-loop attributes from the AN to the NAS. 2. Access Loop Configuration In additional to reporting Access Loop characteristics from the AN to the NAS, ANCP will allow a NAS to send loop-specific configuration information to an AN based on the results of subscriber authentication and authorization (e.g., after AAA responses have been received at the NAS). 3. Remote Connectivity Test Traditional DSL access and aggregation networks employ point-to-point ATM circuits between the AN and NAS for each subscriber, allowing troubleshooting of the local loop from the NAS via ATM OAM tools. With the increasing deployment of Ethernet in the access and aggregation network, operators require consistent methods to test and troubleshoot connectivity for mixed Ethernet and ATM access networks (including the local loop). ANCP will allow a remote procedure for a local loop connectivity test to be triggered from the NAS with results communicated back to the NAS. 4. Multicast When multicast replication for subscriber-bound traffic is performed at the AN, it offloads the network between the AN and NAS. However, a subscriber's policy and configuration for multicast traffic may only be known at the NAS. ANCP will provide a mechanism to communicate the necessary information exchange between the AN and NAS so as to allow the AN to perform subscriber bound multicast group replication in line with the subscriber's policy and configuration, and also allow the NAS to follow each subscriber's multicast group membership. Non-Goals: ANCP is an IP-based protocol that operates between the AN and NAS. It will not address setup or configuration of circuits or connections in the access and aggregation network itself. The focus of this WG is on one very specific application space. While the design of the protocol must be general as to not preclude other uses in the future should a need arise, it is not a goal of this WG to address specific requirements outside of service provider broadband (such as xDSL, xPON) access and aggregation networks. Security: The ANCP working group will provide a threat analysis and address the associated security aspects of the control protocol. Resiliency and Scalability: A graceful restart mechanism will be defined to enable the protocol to be resilient to network failures between the AN and NAS. Scalability at the NAS is of primary concern, as it may be aggregating traffic from a large number of ANs, which in turn may be serving a large number of Subscribers. ANCP traffic should not become a denial of service attack on the NAS control plane. Format of messages, pacing, transport over UDP or TCP, etc. will be considered with this in mind. For reasons of aggregation network scalability, some use cases require that aspects of NAS or AN functionality may be distributed in nodes in the aggregation network. In these cases, ANCP can run between these nodes. Deliverables: The working group will define a basic framework and requirements document intended for Informational publication, focusing on the four use-cases outlined in this charter. This document will include a security threat analysis and associated requirements. The WG will then investigate and define a solution for an IP based control protocol meeting these requirements. There are early interoperable implementations of an ANCP-like protocol which are based on an extended subset of the GSMPv3 protocol. This running code will be the the starting point for the working group solution, and will be abandoned only if the WG determines it is not adequate to meet requirements going forward. Coordination with other Working Groups or Organizations: The working group will coordinate with the ADSL MIB working group so the management framework and MIB modules are consistent for DSL access environments. The working group will re-use, as far as possible, standard MIB modules that have already been defined. The remote connectivity test use case may require coordination with ITU-T Ethernet OAM and PON work and with IEEE 802.1ag. Goals and Milestones: Done - Accept WG I-D for ANCP Framework and Requirements Done - Accept WG I-D for Access Node Control Protocol (ANCP) Done - Accept WG ID for Security Threats analysis Done - Accept WG I-D for ANCP MIB Done - Security Threats Analysis last call Done - Framework and Requirements last call Done - Accept WG I-D for ANCP Multicast Extensions Done - Accept WG I-D for ANCP applicability to PON Sep 2010 - Access Node Control Protocol (ANCP) Last Call Dec 2010 - ANCP MIB Last Call Dec 2010 - ANCP Multicast Extensions last call Jan 2011 - ANCP applicability to PON last call Mar 2011 - Re-charter or conclude Working Group Internet-Drafts: - Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks [draft-ietf-ancp-framework-14] (53 pages) - Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) [draft-ietf-ancp-security-threats-09] (18 pages) - Protocol for Access Node Control Mechanism in Broadband Networks [draft-ietf-ancp-protocol-18] (82 pages) - Access Node Control Protocol (ANCP) MIB module for Access Nodes [draft-ietf-ancp-mib-an-08] (36 pages) - Multicast Control Extensions for ANCP [draft-ietf-ancp-mc-extensions-06] (95 pages) - Applicability of Access Node Control Mechanism to PON based Broadband Networks [draft-ietf-ancp-pon-02] (35 pages) Requests for Comments: RFC5713: Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) (18 pages) RFC5851: Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks (53 pages) RFC6320: Protocol for Access Node Control Mechanism in Broadband Networks (82 pages) Ad-Hoc Network Autoconfiguration (autoconf) ------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Ryuji Wakikawa Thomas Clausen Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: autoconf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf Archive: http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html Description of Working Group: RFC 5889 presents one possible IPv6 addressing model for ad hoc nodes. In this model the ad hoc routers need to configure their network interface(s) with addresses valid in the ad hoc network, and may configure additional prefixes for use by attached nodes. After completing the work on RFC 5889, the main purpose of the AUTOCONF WG is to standardize how existing IPv6 address configuration tools can be used for address configuration. 1. DHCPv6 operation over MANET, including: - A DHCPv6-based mechanism for configuring required interface addresses for the routers in the ad hoc network. This mechanism is expected to produce addresses with properties outlined in RFC 5889. This mechanism uses the existing DHCPv6 protocol unchanged, and assumes a central node that can allocate addresses on a first-come-first-served basis. Nodes in the ad hoc network will relay messages to the central node in order to help a new node get an address for itself. This mechanism is only suitable for deployments were a central node can be set up. It should be noted that many existing deployments employ Internet gateways that can act as such a central node as well. Future extensions such as central node election may make this mechanism suitable for also for stand-alone ad hoc networks. - A DHCPv6-based mechanism for delegating a prefix(es) to each router for use by applications running on the routers themselves, or for configuration of attached hosts/networks. This mechanism works in a similar manner to the one above, but allocates prefixes instead of addresses. Both mechanisms should be independent from operation of any specific MANET routing protocol, although may exploit information maintained by such a routing protocol, if available. The working group will adapt and/or reuse existing protocols whenever reasonable and possible. No new duplicate address detection mechanisms will be specified. 2. Analysis of Problem Space for distributed address configuration and service discovery. This analysis is necessary in order to understand what type of distributed solution(s) can be standardized. There is already quite a lot of material about possible solutions in the literature. The working group plans to establish design teams for rapidly advancing towards initial submissions for these two work items. The group shall also work with the 6LOWPAN and ROLL working group to ensure that the results from AUTOCONF working group are useful for the larger community and do not overlap with work already in progress in these other working groups. Goals and Milestones: Done - Submit an initial 'MANET architecture' WG document Done - Submit an initial 'terminology and problem statement' WG document Done - Submit 'MANET architecture' document to IESG for publication as an informational RFC Jan 2011 - First working group draft of the 'Analysis of Problem Space' Jan 2011 - First working group draft of the 'DHCPv6 operation over MANET' Sep 2011 - Submission of the 'DHCPv6 operation over MANET' to the IESG for publication as BCP Sep 2011 - Submission of the 'Analysis of Problem Space' the IESG for publication as Informational RFC Oct 2011 - First working group draft of the 'Distributed Solution' Jun 2012 - Submission of the 'Distributed Solution' to the IESG for publication as an Proposed Standard RFC Jun 2012 - Rechartering or Closing WG Internet-Drafts: - Mobile Ad hoc Network Architecture [draft-ietf-autoconf-manetarch-07] (20 pages) - Address Autoconfiguration for MANET: Terminology and Problem Statement [draft-ietf-autoconf-statement-04] (22 pages) - IP Addressing Model in Ad Hoc Networks [draft-ietf-autoconf-adhoc-addr-model-04] (8 pages) Requests for Comments: RFC5889: IP Addressing Model in Ad Hoc Networks (8 pages) Cga & Send maIntenance (csi) ---------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Marcelo Bagnulo Gabriel Montenegro Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion: cga-ext@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/cga-ext Archive: http://www.ietf.org/mail-archive/web/cga-ext/current/maillist.html Description of Working Group: The Secure Neighbor Discovery (SEND) protocol defined by RFC 3971 provides security mechanisms protecting different functions of the Neighbor Discovery (ND) protocol defined by RFC 2461. This includes address resolution (discovering link layer address of another node attached to the link), router discovery (discovering routers attached to the link), and neighbor unreachability detection (detecting that a node attached to the link is no longer reachable). SEND protection of address resolution and neighbor unreachability detection functions relies on IPv6 address proof-of-ownership and message integrity protection provided respectively via Cryptographically Generated Addresses (CGAs) and RSA Digital Signatures. CGAs are defined in RFC 3972, and are extended with a CGA extension format defined in RFC 4581, and a support for multiple hash functions defined in RFC 4982. While CGAs were originally defined for the SEND protocol, they have proved to be a useful security tool in other environments too, and its usage has been proposed to secure other protocols such as the Shim6 multihoming protocol and the Mobile IPv6 protocol. While there is very little deployment of SEND to date, there are a number of implementations, recommendations in the NIST and DOD profiles call for use of SEND, and operating system vendors are considering adding SEND to their next releases. As a result, it is desirable to review the current state of the SEND and CGA specifications, maintain and complement them where necessary. Up to date cryptographic algorithms are needed, and the protocols need to be able to deal with certain common situations currently not supported. Specifically, the WG will look at the following issues: - Develop an informational document analyzing the implications of recent attacks on hash functions used by SeND protocol. Current SeND specification uses the SHA-1 hash algorithm and does not provides support for hash algorithm agility, hence the critical need for understanding the impact of the attacks on the SeND protocol. In addition, if as a result of the aforementioned analysis it is deemed necessary, standard-track extensions to the SeND protocol to support multiple hash algorithms will be defined. - Specify a standards-track CGA and SeND extensions to support multiple public key algorithms. As currently defined CGA and SeND can only use RSA keys, and they lack support for other public key algorithms (e.g. Elliptic Curve Cryptography -- ECC). - Develop X.509 certificate management tools for SeND. SeND utilizes X.509v3 certificates for performing router authorization. It uses the X.509 extension for IP addresses to verify whether the router is authorized to advertise the mentioned IP addresses. Since the IP addresses extension does not explicitly mention what functions the node can perform for the IP addresses it becomes impossible to know the reason for which the certificate was allowed. In order to facilitate issuance of certificates for specific functions, we need to encode the functions permitted for the certificate into the certificate itself. The WG will develop a certificate profile, including a definition of X.509 Extended Key Usage for SeND . In addition, the WG will recommend best practices for (1) enrollment, (2) revocation checking, and (3) publishing of certificates. This WG will ensure that the profile and recommended practices will cover usage by hosts in addition to routers. The working group will coordinate this activity with the PKIX and SIDR WGs. Prior to IESG submission of the certificate profile, the working group will seek input from and coordinate with other groups enabling cryptographic identification of device-related properties (e.g., IEEE 802.1ar, IEEE 802.16, WiMAX Forum, IETF CAPWAP WG). - Develop a standard track document defining a mechanism to perform SeND certificate provisioning for routers. SeND protocol as defined in RFC3971 specifies how IPv6 nodes can trust the prefixes advertised by a router. The solution is based on the use of the IP Address Delegation extension (RFC3779) in X.509 v3 certificates (RFC3280). This work will provide the tools require to provision with the certificates to the routers in an automatic manner. The working will coordinate this activity with the PKIX WG. - Produce a problem statement document for Neighbor Discovery Proxies and then specify standards-track SEND Extensions to support Neighbor Discovery Proxies: SEND protocol as currently defined in RFC 3971 lacks of support for ND Proxies defined in RFC 3775 and RFC 4389. Extensions to the SEND protocol will be defined in order to provide equivalent SEND security capabilities to ND Proxies. - Develop an informational document analysing different approaches to allow SeND and CGAs to be used in conjunction with DHCP, and making recommendations on which are the best suited. Recharter based on the result of the analysis. - Update base specifications (RFC 3971 and 3972). Goals and Milestones: Jun 2008 - WG last-call on analysis of hash related threats in SeND Jul 2008 - Submit draft on analysis of hash related threats in SeND to IESG Aug 2008 - WG last-call on Proxy-SeND problem statement Sep 2008 - Submit draft on Proxy-SeND problem statement to IESG Dec 2008 - WG last-call on multiple hash function support in SeND, if required Dec 2008 - WG last-call on multiple public key algorithm support for CGA Dec 2008 - WG last-call on multiple public key algorithm support for SeND Dec 2008 - WG last-call on certificate profile definition for SeND Jan 2009 - WG last-call on Proxy SeND Jan 2009 - Submit draft on multiple hash function support in SeND to IESG, if required Jan 2009 - Submit draft on multiple public key algorithm support for CGA to IESG Jan 2009 - Submit draft on multiple public key algorithm support for SeND to IESG Jan 2009 - Submit draft on certificate profile definition for SeND to IESG Feb 2009 - Submit draft on Proxy SeND to IESG Jun 2009 - WG last-call on certificate provision mechanism for SeND routers Jun 2009 - WG last-call on certificate management best practices for SeND routers Jul 2009 - WG last-call on CGA-DHCP interaction Jul 2009 - Submit draft on certificate provision mechanism for SeND routers to IESG Jul 2009 - Submit draft on certificate management best practices for SeND routers to IESG Aug 2009 - Submit draft on CGA-DHCP interaction to IESG Nov 2009 - WG last-call on updated SeND specification Dec 2009 - Submit draft on updated SeND specification to IESG Dec 2009 - Submit draft on updated CGA specification to IESG Internet-Drafts: - SEND Hash Threat Analysis [draft-ietf-csi-hash-threat-13] (7 pages) - Securing Neighbor Discovery Proxy: Problem Statement [draft-ietf-csi-sndp-prob-05] (22 pages) - Secure Proxy ND Support for SEND [draft-ietf-csi-proxy-send-06] (29 pages) - Certificate profile and certificate management for SEND [draft-ietf-csi-send-cert-11] (21 pages) - DHCPv6 and CGA Interaction: Problem Statement [draft-ietf-csi-dhcpv6-cga-ps-07] (10 pages) - Subject Key Identifier (SKI) SEND Name Type fields. [draft-ietf-csi-send-name-type-registry-07] (6 pages) Requests for Comments: RFC5909: Securing Neighbor Discovery Proxy: Problem Statement (22 pages) RFC6273: The Secure Neighbor Discovery (SEND) Hash Threat Analysis (7 pages) RFC6495: Subject Key Identifier (SKI) SEcure Neighbor Discovery (SEND) Name Type Fields (5 pages) * Updates RFC3971 RFC6496: Secure Proxy ND Support for SEcure Neighbor Discovery (SEND) (24 pages) RFC6494: Certificate Profile and Certificate Management for SEcure Neighbor Discovery (SEND) (12 pages) * Updates RFC3971 DNS Extensions (dnsext) ----------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Olafur Gudmundsson Andrew Sullivan Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion: dnsext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dnsext Archive: http://www.ietf.org/mail-archive/web/dnsext/ Description of Working Group: The DNS has a large installed base and repertoire of protocol specifications. The DNSEXT working group will actively advance DNS protocol-related RFCs on the standards track while thoroughly reviewing further proposed extensions. The scope of the DNSEXT WG is confined to the DNS protocol, particularly changes that affect DNS protocols "on the wire" or the internal processing of DNS data. DNS operations are out of scope for the WG. The WG will consider work in the following areas: * DNSSEC and TSIG/TKEY algorithm maintenance * Mechanisms that complement, or are alternatives to, TSIG and SIG(0) * Hardening DNS protocol and providing guidance to implementers * Advancing existing DNS-related Proposed Standard RFCs to Draft/Full Standard * Obsoleting DNS-related RFCs * Improving DNS zone synchronization mechanisms * Examining transport protocols, possibly adding new ones * Mechanisms to alias DNS trees or parts thereof Before formal adoption of any work item at least 5 working group participants must publicly state that the item is within charter and is a worthwhile item for further study. The DNSEXT WG will conduct the specified RFC5395 review of RR templates as they are posted, and EDNS0 Option templates if EDNS0-bis updates registration requirements. The WG will review DNS protocol related work which may originate elsewhere in the IETF, including AD-sponsored submissions or drafts in other working group. Goals and Milestones: Done - Forward NSEC rdata to IESG for Proposed Standard Done - Forward RFC2535-bis to IESG for proposed standard Done - Forward Case Insensitive to IESG for Proposed Standard Done - Forward LLMNR to IESG for Proposed Standard Done - Update boilerplate text on OPT-IN Done - Forward Wildcard clarification to IESG for proposed standard Done - Finalize Zone Enumeration Requirements Done - RFC2538 (CERT RR) to Draft Standard Done - Forgery Resilience advanced to IESG Done - GOST DNSKEY and DS support advanced to IESG Done - AXFR Clarify to IESG Done - DNS existing transport protocol recommendations/clarifications to IESG Apr 2011 - RFC3597-bis Unknown RR advanced to IESG for PS Done - DNSKEY Registry fixes and allocation procedure advanced to IESG Jun 2011 - EDNS0-bis update advanced to IESG Done - DNAME-bis to IESG Aug 2011 - Algorithm signaling document to IESG Oct 2011 - DNSSEC Errata document to IESG Nov 2011 - Decision about new protocol elements, if any Nov 2011 - Requirements and current state survey document to IESG for publication Dec 2011 - IXFR-only to IESG Dec 2011 - If new protocol elements, recharter Internet-Drafts: - Secret Key Transaction Authentication for DNS (TSIG) [draft-ietf-dnsind-tsig-13] (14 pages) - Extensions to DNS (EDNS1) [draft-ietf-dnsext-edns1-03] (4 pages) - A DNS RR for specifying the location of services (DNS SRV) [draft-ietf-dnsind-rfc2052bis-06] (10 pages) - A DNS RR Type for Lists of IP Address Prefixes (APL RR) [draft-ietf-dnsind-apl-rr-03] (6 pages) - Simple Secure Domain Name System (DNS) Dynamic Update [draft-ietf-dnsind-simple-secure-update-02] (8 pages) - Secret Key Establishment for DNS (TKEY RR) [draft-ietf-dnsind-tkey-03] (18 pages) - Domain Name System (DNS) IANA Considerations [draft-ietf-dnsind-iana-dns-04] (13 pages) - DNS Request and Transaction Signatures ( SIG(0)s ) [draft-ietf-dnsind-sig-zero-01] (10 pages) - DNS SIGALGOPT [draft-ietf-dnsind-sigalgopt-00] (3 pages) - A DNS RR for encoding DHCP information [draft-ietf-dnsind-dhcp-rr-00] (4 pages) - DNS Security Extension Clarification on Zone Status [draft-ietf-dnsind-zone-status-00] (9 pages) - Domain Name System Security (DNSSEC) Signing Authority [draft-ietf-dnsext-signing-auth-03] (7 pages) - Secure Domain Name System (DNS) Dynamic Update [draft-ietf-dnsext-simple-secure-update-03] (9 pages) - DNS Security Extension Clarification on Zone Status [draft-ietf-dnsext-zone-status-05] (9 pages) - Secret Key Establishment for DNS (TKEY RR) [draft-ietf-dnsext-tkey-05] (17 pages) - Domain Name System (DNS) IANA Considerations [draft-ietf-dnsext-iana-dns-02] (12 pages) - A Proposed Enhancement to the EDNS0 Version Mechanism [draft-ietf-dnsext-edns0dot5-02] (6 pages) - DNS Request and Transaction Signatures ( SIG(0)s ) [draft-ietf-dnsext-sig-zero-03] (9 pages) - A DNS RR Type for Lists of Address Prefixes (APL RR) [draft-ietf-dnsext-apl-rr-02] (7 pages) - Secret Key Transaction Authentication for DNS (TSIG) [draft-ietf-dnsext-tsig-01] (15 pages) - DNS Zone Transfer Protocol (AXFR) [draft-ietf-dnsext-axfr-clarify-15] (28 pages) - Incremental Zone Transfer in DNS [draft-ietf-dnsext-ixfr-01] (10 pages) - DNSSEC and IPv6 A6 aware server/resolver message size requirements [draft-ietf-dnsext-message-size-04] (6 pages) - GSS Algorithm for TSIG (GSS-TSIG) [draft-ietf-dnsext-gss-tsig-07] (22 pages) - A DNS RR for Encoding DHCP Information (DHCID RR) [draft-ietf-dnsext-dhcid-rr-14] (12 pages) - DNS Security Document Roadmap [draft-ietf-dnsext-dnssec-roadmap-07] (16 pages) - RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) [draft-ietf-dnsext-rsa-03] (8 pages) - Authenticating denial of existence in DNS with minimum disclosure (or; An alternative to DNSSEC NXT records) [draft-ietf-dnsext-not-existing-rr-01] (17 pages) - Indicating Resolver Support of DNSSEC [draft-ietf-dnsext-dnssec-okbit-03] (5 pages) - Applicability Statement for DNS MIB Extensions [draft-ietf-dnsext-dnsmib-historical-00] (4 pages) - Handling of Unknown DNS Resource Record Types [draft-ietf-dnsext-unknown-rrs-07] (8 pages) - Link-local Multicast Name Resolution (LLMNR) [draft-ietf-dnsext-mdns-48] (29 pages) - Redefinition of DNS AD bit [draft-ietf-dnsext-ad-is-secure-07] (7 pages) - A DNS RR for specifying the location of services (DNS SRV) [draft-ietf-dnsext-rfc2782bis-01] (12 pages) - ZONE option in DNS messages [draft-ietf-dnsext-edns-zone-option-00] (4 pages) - Bind VIEW option in DNS messages [draft-ietf-dnsext-edns-bind-view-option-00] (4 pages) - Handling of unknown EDNS0 attributes [draft-ietf-dnsext-ends-unknown-00] (6 pages) - Obsoleting IQUERY [draft-ietf-dnsext-obsolete-iquery-04] (4 pages) - Parent's SIG over child's KEY [draft-ietf-dnsext-parent-sig-00] (7 pages) - Parent stores the child's zone KEYs [draft-ietf-dnsext-parent-stores-zone-keys-01] (10 pages) - Comparison of AAAA and A6 (do we really need A6?) [draft-ietf-dnsext-aaaa-a6-01] (13 pages) - Delegation Signer Resource Record [draft-ietf-dnsext-delegation-signer-16] (16 pages) - DNSSEC Opt-In [draft-ietf-dnsext-dnssec-opt-in-10] (16 pages) - DSA Keying and Signature Information in the DNS [draft-ietf-dnsext-rfc2536bis-dsa-08] (11 pages) - Storage of Diffie-Hellman Keying Information in the DNS [draft-ietf-dnsext-rfc2539bis-dhk-08] (12 pages) - Tradeoffs in DNS support for IPv6 [draft-ietf-dnsext-ipv6-dns-tradeoffs-02] (10 pages) - DNS Security Introduction and Requirements [draft-ietf-dnsext-dnssec-intro-14] (26 pages) - Elliptic Curve Keys and Signatures in the Domain Name System (DNS) [draft-ietf-dnsext-ecc-key-10] (16 pages) - Representing IPv6 addresses in DNS [draft-ietf-dnsext-ipv6-addresses-02] (6 pages) - TKEY Secret Key Renewal Mode [draft-ietf-dnsext-tkey-renewal-mode-05] (23 pages) - Limiting the Scope of the KEY Resource Record out [draft-ietf-dnsext-restrict-key-for-dnssec-04] (15 pages) - Threat Analysis Of The Domain Name System [draft-ietf-dnsext-dns-threats-08] (16 pages) - DNSSEC NSEC RDATA Format [draft-ietf-dnsext-nsec-rdata-07] (9 pages) - Resource Records for the DNS Security Extensions [draft-ietf-dnsext-dnssec-records-12] (33 pages) - The DISCOVER opcode [draft-dnsext-opcode-discover-02] (0 pages) - KEY RR Secure Entry Point Flag [draft-ietf-dnsext-keyrr-key-signing-flag-13] (10 pages) - DNS Extensions to support IP version 6 [draft-ietf-dnsext-rfc1886bis-04] (7 pages) - Protocol Modifications for the DNS Security Extensions [draft-ietf-dnsext-dnssec-protocol-10] (58 pages) - Domain Name System (DNS) Case Insensitivity Clarification [draft-ietf-dnsext-insensitive-07] (13 pages) - Domain Name Auto-Registration for Plugged-in IPv6 Nodes [draft-ietf-dnsext-ipv6-name-auto-reg-01] (21 pages) - Legacy Resolver Compatibility for Delegation Signer [draft-ietf-dnsext-dnssec-2535typecode-change-07] (5 pages) - The Role of Wildcards in the Domain Name System [draft-ietf-dnsext-wcard-clarify-12] (30 pages) - Minimally Covering NSEC Records and DNSSEC On-line Signing [draft-ietf-dnsext-dnssec-online-signing-03] (11 pages) - DNS Name Server Identifier Option (NSID) [draft-ietf-dnsext-nsid-03] (16 pages) - Evaluating DNSSEC Transition Mechanisms [draft-ietf-dnsext-dnssec-trans-06] (16 pages) - HMAC SHA TSIG Algorithm Identifiers [draft-ietf-dnsext-tsig-sha-07] (9 pages) - RFC 3597 Interoperability Report [draft-ietf-dnsext-interop3597-02] (6 pages) - Automated Updates of DNSSEC Trust Anchors [draft-ietf-dnsext-trustupdate-timers-07] (13 pages) - Requirements related to DNSSEC Signed Proof of Non-Existence [draft-ietf-dnsext-signed-nonexistence-requirements-03] (14 pages) - An In-Band Rollover Mechanism and an Out-Of-Band Priming Method for DNSSEC Trust Anchors [draft-ietf-dnsext-trustupdate-threshold-01] (24 pages) - Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC [draft-ietf-dnsext-dnssec-rsasha256-15] (10 pages) - DNSSEC Hashed Authenticated Denial of Existence [draft-ietf-dnsext-nsec3-14] (52 pages) - Storing Certificates in the Domain Name System (DNS) [draft-ietf-dnsext-rfc2538bis-10] (17 pages) - DNSSEC Experiments [draft-ietf-dnsext-dnssec-experiments-05] (15 pages) - Clarifications and Implementation Notes for DNSSECbis [draft-ietf-dnsext-dnssec-bis-updates-16] (20 pages) - Domain Name System (DNS) IANA Considerations [draft-ietf-dnsext-2929bis-08] (21 pages) - Derivation of DNS Name Predecessor and Successor [draft-ietf-dnsext-dns-name-p-s-02] (26 pages) - Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) [draft-ietf-dnsext-ds-sha256-06] (9 pages) - Requirements related to DNSSEC Trust Anchor Rollover [draft-ietf-dnsext-rollover-requirements-05] (11 pages) - DNAME Redirection in the DNS [draft-ietf-dnsext-rfc2672bis-dname-25] (22 pages) - Measures for making DNS more resilient against forged answers [draft-ietf-dnsext-forgery-resilience-11] (26 pages) - The Modern DNS Implementation Guide [draft-ietf-dnsext-dns-protocol-profile-01] (26 pages) - Extension Mechanisms for DNS (EDNS0) [draft-ietf-dnsext-rfc2671bis-edns0-08] (15 pages) - Deprecation of HMAC-MD5 in DNS TSIG and TKEY Resource Records [draft-ietf-dnsext-tsig-md5-deprecated-03] (6 pages) - DNS Proxy Implementation Guidelines [draft-ietf-dnsext-dnsproxy-07] (14 pages) - Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry [draft-ietf-dnsext-dnssec-registry-fixes-08] (8 pages) - Cryptographic Algorithm Identifier Allocation for DNSSEC [draft-ietf-dnsext-dnssec-alg-allocation-04] (6 pages) - Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records for DNSSEC [draft-ietf-dnsext-dnssec-gost-08] (9 pages) - Handling of Unknown DNS Resource Record (RR) Types [draft-ietf-dnsext-rfc3597-bis-03] (8 pages) - DNS Transport over TCP - Implementation Requirements [draft-ietf-dnsext-dns-tcp-requirements-04] (9 pages) - A mechanism for synchronization across name servers on zone creation [draft-ietf-dnsext-newzone-notify-02] (9 pages) - Signaling Cryptographic Algorithm Understanding in DNSSEC [draft-ietf-dnsext-dnssec-algo-signal-03] (8 pages) - Domain Name System (DNS) IANA Considerations [draft-ietf-dnsext-5395bis-04] (19 pages) - Elliptic Curve DSA for DNSSEC [draft-ietf-dnsext-ecdsa-04] (8 pages) - Problem Statement: DNS Resolution of Aliased Names [draft-ietf-dnsext-aliasing-requirements-02] (22 pages) - xNAME RCODE and Status Bits Clarification [draft-ietf-dnsext-xnamercode-00] (9 pages) - DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates [draft-ietf-dnsext-dnssec-registry-update-00] (6 pages) - Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status [draft-ietf-dnsext-dnssec-algo-imp-status-00] (6 pages) Requests for Comments: RFC2782: A DNS RR for specifying the location of services (DNS SRV) (2 pages) * Obsoletes RFC2052 * Updated by RFC6335 RFC2845: Secret Key Transaction Authentication for DNS (TSIG) (15 pages) * Updates RFC1035 * Updated by RFC3645 RFC2929: Domain Name System (DNS) IANA Considerations (12 pages) * OBSOLETED BY RFC5395 RFC2930: Secret Key Establishment for DNS (TKEY RR) (16 pages) RFC2931: DNS Request and Transaction Signatures ( SIG(0)s ) (10 pages) * Updates RFC2535 RFC3007: Secure Domain Name System (DNS) Dynamic Update (9 pages) * Updates RFC2137 * Obsoletes RFC2535 * Obsoletes RFC2136 * Updated by RFC4033 * Updated by RFC4034 * Updated by RFC4035 RFC3008: Domain Name System Security (DNSSEC) Signing Authority (7 pages) * Updates RFC2535 * Updated by RFC3658 * OBSOLETED BY RFC4033 * OBSOLETED BY RFC4034 * OBSOLETED BY RFC4035 RFC3090: DNS Security Extension Clarification on Zone Status (11 pages) * Updated by RFC3658 * OBSOLETED BY RFC4033 * OBSOLETED BY RFC4034 * OBSOLETED BY RFC4035 RFC3110: RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) (7 pages) RFC3123: A DNS RR Type for Lists of Address Prefixes (APL RR) (8 pages) RFC3225: Indicating Resolver Support of DNSSEC (6 pages) * Updated by RFC4033 * Updated by RFC4034 * Updated by RFC4035 RFC3226: DNSSEC and IPv6 A6 aware server/resolver message size requirements (6 pages) * Updates RFC2874 * Updates RFC2535 * Updated by RFC4033 * Updated by RFC4034 * Updated by RFC4035 RFC3363: Representing IPv6 addresses in DNS (6 pages) * Updates RFC2673 * Updates RFC2874 RFC3364: Tradeoffs in DNS support for IPv6 (11 pages) * Updates RFC2874 RFC3197: Applicability Statement for DNS MIB Extensions (5 pages) RFC3425: Obsoleting IQUERY (5 pages) * Updates RFC1035 RFC3445: Limiting the Scope of the KEY Resource Record out (10 pages) * Updates RFC2535 * OBSOLETED BY RFC4033 * OBSOLETED BY RFC4034 * OBSOLETED BY RFC4035 RFC3597: Handling of Unknown DNS Resource Record (RR) Types (8 pages) * Updated by RFC4033 * Updated by RFC4034 * Updated by RFC4035 * Updated by RFC5395 * Updated by RFC6195 RFC3596: DNS Extensions to support IP version 6 (7 pages) RFC3645: GSS Algorithm for TSIG (GSS-TSIG) (22 pages) * Updates RFC2845 RFC3655: Redefinition of DNS AD bit (7 pages) * Obsoletes RFC2535 * OBSOLETED BY RFC4033 * OBSOLETED BY RFC4034 * OBSOLETED BY RFC4035 RFC3658: Delegation Signer Resource Record (19 pages) * Updates RFC3090 * Updates RFC3008 * Updates RFC2535 * Updates RFC1035 * Updated by RFC3755 * OBSOLETED BY RFC4033 * OBSOLETED BY RFC4034 * OBSOLETED BY RFC4035 RFC3755: Legacy Resolver Compatibility for Delegation Signer (5 pages) * Updates RFC3658 * Updates RFC2535 * Updated by RFC3757 * OBSOLETED BY RFC4033 * OBSOLETED BY RFC4034 * Updated by RFC3845 * OBSOLETED BY RFC4035 RFC3757: KEY RR Secure Entry Point Flag (10 pages) * Updates RFC3755 * Updates RFC2535 * OBSOLETED BY RFC4033 * OBSOLETED BY RFC4034 * OBSOLETED BY RFC4035 RFC3845: DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format (9 pages) * Updates RFC3755 * Updates RFC2535 * OBSOLETED BY RFC4035 * OBSOLETED BY RFC4034 * OBSOLETED BY RFC4033 RFC3833: Threat Analysis Of The Domain Name System (16 pages) RFC4033: DNS Security Introduction and Requirements (26 pages) * Updates RFC1034 * Updates RFC1035 * Updates RFC2136 * Updates RFC2181 * Updates RFC2308 * Updates RFC3225 * Updates RFC3007 * Updates RFC3597 * Updates RFC3226 * Obsoletes RFC2535 * Obsoletes RFC3008 * Obsoletes RFC3090 * Obsoletes RFC3445 * Obsoletes RFC3655 * Obsoletes RFC3658 * Obsoletes RFC3755 * Obsoletes RFC3757 * Obsoletes RFC3845 * Updated by RFC6014 RFC4034: Resource Records for the DNS Security Extensions (33 pages) * Obsoletes RFC3845 * Obsoletes RFC2535 * Obsoletes RFC3008 * Obsoletes RFC3090 * Obsoletes RFC3445 * Obsoletes RFC3655 * Obsoletes RFC3658 * Obsoletes RFC3755 * Obsoletes RFC3757 * Updates RFC1034 * Updates RFC1035 * Updates RFC2136 * Updates RFC2181 * Updates RFC2308 * Updates RFC3225 * Updates RFC3007 * Updates RFC3597 * Updates RFC3226 * Updated by RFC4470 * Updated by RFC6014 RFC4035: Protocol Modifications for the DNS Security Extensions (58 pages) * Obsoletes RFC3845 * Updates RFC1034 * Updates RFC1035 * Updates RFC2136 * Updates RFC2181 * Updates RFC2308 * Updates RFC3225 * Updates RFC3007 * Updates RFC3597 * Updates RFC3226 * Obsoletes RFC2535 * Obsoletes RFC3008 * Obsoletes RFC3090 * Obsoletes RFC3445 * Obsoletes RFC3655 * Obsoletes RFC3658 * Obsoletes RFC3755 * Obsoletes RFC3757 * Updated by RFC4470 * Updated by RFC6014 RFC4343: Domain Name System (DNS) Case Insensitivity Clarification (13 pages) * Updates RFC1034 * Updates RFC1035 * Updates RFC2181 RFC4398: Storing Certificates in the Domain Name System (DNS) (17 pages) * Obsoletes RFC2538 RFC4470: Minimally Covering NSEC Records and DNSSEC On-line Signing (11 pages) * Updates RFC4035 * Updates RFC4034 RFC4509: Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) (9 pages) RFC4592: The Role of Wildcards in the Domain Name System (30 pages) * Updates RFC1034 * Updates RFC2672 RFC4471: Derivation of DNS Name Predecessor and Successor (26 pages) RFC4635: HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers (9 pages) RFC4701: A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR) (12 pages) * Updated by RFC5494 RFC4795: Link-local Multicast Name Resolution (LLMNR) (29 pages) RFC4955: DNS Security (DNSSEC) Experiments (15 pages) RFC4956: DNS Security (DNSSEC) Opt-In (16 pages) RFC5001: DNS Name Server Identifier Option (NSID) (16 pages) RFC4986: Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover (11 pages) RFC5011: Automated Updates of DNS Security (DNSSEC) Trust Anchors (13 pages) RFC5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence (52 pages) RFC5395: Domain Name System (DNS) IANA Considerations (17 pages) * Obsoletes RFC2929 * Updates RFC1183 * Updates RFC3597 RFC5452: Measures for Making DNS More Resilient against Forged Answers (18 pages) * Updates RFC2181 RFC5625: DNS Proxy Implementation Guidelines (12 pages) RFC5702: Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC (10 pages) RFC5936: DNS Zone Transfer Protocol (AXFR) (29 pages) * Updates RFC1034 * Updates RFC1035 RFC5933: Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC (9 pages) RFC5966: DNS Transport over TCP - Implementation Requirements (7 pages) * Updates RFC1035 * Updates RFC1123 RFC6014: Cryptographic Algorithm Identifier Allocation for DNSSEC (6 pages) * Updates RFC4033 * Updates RFC4034 * Updates RFC4035 RFC6195: Domain Name System (DNS) IANA Considerations (17 pages) * Updates RFC1183 * Updates RFC3597 Distributed Mobility Management (dmm) ------------------------------------- Charter Last Modified: 2012-01-10 Current Status: Active Chairs: Julien Laganier Jouni Korhonen Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: mext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mext Archive: http://www.ietf.org/mail-archive/web/mext Description of Working Group: The Distributed Mobility Management (DMM) working group specifies IP mobility, access network and routing solutions, which allow for setting up IP networks so that traffic is distributed in an optimal way and does not rely on centrally deployed anchors to manage IP mobility sessions. The distributed mobility management solutions aim for transparency above the IP layer, including maintenance of active transport level sessions as mobile hosts or entire mobile networks change their point of attachment to the Internet. The protocol solutions should be based on existing IP mobility protocols, either host- or network-based, such as Mobile IPv6 [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and NEMO [RFC3963]. Solutions may also focus specifically on managing the use of care-of versus home addresses in an efficient manner for different types of communications. Although the maintenance of stable home address(es) and/or prefix(es) and upper level sessions is a desirable goal when mobile hosts/routers change their point of attachment to the Internet, it is not a strict requirement. Mobile hosts/routers should not assume that IP addressing including home address(es) and/or home network prefix(es) remain the same throughout the entire upper level session lifetime, or that support for mobility functions is provided on the network side in all conditions. The distributed mobility management solutions primarily target IPv6 Deployment and should not be tailored specifically to support IPv4, in particular in situations where private IPv4 addresses and/or NATs are used. At least IPv6 is assumed to be present in both the mobile host/router and the access networks. Independent of the distributed mobility management solution, backward compatibility must be maintained. If the network or the mobile host/router do not support the distributed mobility management enabling protocol, nothing should break. Work items related to the distributed mobility management include: o Solution Requirements: Define precisely the problem of distributed mobility management and identity the requirements for a distributed mobility management solution. o Practices: Document practices for the deployment of existing mobility protocols in a distributed mobility management environment. o Gap Analysis and extensions: identify the limitations in the current practices with respect to providing the expected functionality. o If limitations are identified as part of the above deliverable, specify extensions to existing protocols that removes these limitations within a distributed mobility management environment. Goals and Milestones: Done - Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for publication as a Proposed Standard Done - Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG for publication as a Proposed Standard Done - Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for publication as a Proposed Standard. Done - Submit I-D 'Motivation for Authentication I-D' to IESG for publication as Informational. Done - Submit Multiple CoA Registration to IESG Done - Submit I-D 'Goals for AAA HA Interface' to IESG for publication as Informational. Done - Submit -00 draft on Route Optimization Needs for Automobile and Highway Deployments Done - Submit -00 draft on Route Optimization Needs for Aircraft and Spacecraft Deployments Done - Submit I-D 'Mobility Header Home Agent Switch Message' to IESG for publication as a Proposed Standard Done - Submit final doc on Route Optimization Needs for Aircraft and Spacecraft Deployments, for Informational Done - Submit 00 draft on Binding Revocation Done - Submit the final doc on MIB for NEMO Basic Support to the IESG, for Proposed Standard Done - Submit draft on Binding Revocation to IESG Done - Submit I-D(s) related to specific updates and corrections of RFC 3775 to IESG for publication as Proposed Standard. Done - Submit the final doc on Prefix Delegation for NEMO to the IESG, for Proposed Standard Aug 2012 - Submit I-D 'Solution Requirements' as a working group document. To be Informational RFC. Aug 2012 - Submit I-D 'Practices and Gap Analysis' as a working group document. To be Informational RFC. Nov 2012 - Evaluate the need for additional working group document(s) for extensions to fill the identified gaps. Jan 2013 - Submit I-D 'Solution Requirements' to the IESG for consideration as an Informational RFC. Jan 2013 - Submit I-D 'Practices ' to the IESG for consideration as an Informational RFC. Mar 2013 - Submit I-D 'Gap Analysis' to the IESG for consideration as an Informational RFC. Mar 2013 - Evaluate the need for further work based on the identified gaps and revise the milestones and/or the charter of the group Internet-Drafts: - NEMO Management Information Base [draft-ietf-nemo-mib-03] (42 pages) - Motivations and Scenarios for Using Multiple Interfaces and Global Addresses [draft-ietf-monami6-multihoming-motivation-scenario-03] (20 pages) - Mobile Network Prefix Delegation [draft-ietf-nemo-prefix-delegation-02] (22 pages) - Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6) [draft-ietf-mip6-nemo-v4traversal-06] (28 pages) - Analysis of Multihoming in Mobile IPv6 [draft-ietf-monami6-mipv6-analysis-05] (31 pages) - Multiple Care-of Addresses Registration [draft-ietf-monami6-multiplecoa-15] (44 pages) - Home Agent Reliability Protocol (HARP) [draft-ietf-mip6-hareliability-10] (44 pages) - Generic Notification Message for Mobile IPv6 [draft-ietf-mip6-generic-notification-message-00] (10 pages) - RADIUS Mobile IPv6 Support [draft-ietf-mip6-radius-06] (48 pages) - Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks [draft-ietf-mext-aero-reqs-05] (31 pages) - AAA Goals for Mobile IPv6 [draft-ietf-mext-aaa-ha-goals-02] (12 pages) - NEMO Management Information Base [draft-ietf-mext-nemo-mib-07] (44 pages) - Mobile IPv6 Support for Dual Stack Hosts and Routers [draft-ietf-mext-nemo-v4traversal-11] (48 pages) - Automotive Industry Requirements for NEMO Route Optimization [draft-ietf-mext-nemo-ro-automotive-req-02] (25 pages) - Flow Bindings in Mobile IPv6 and NEMO Basic Support [draft-ietf-mext-flow-binding-12] (38 pages) - Mobility Support in IPv6 [draft-ietf-mext-rfc3775bis-14] (177 pages) - DHCPv6 Prefix Delegation for NEMO [draft-ietf-mext-nemo-pd-08] (16 pages) - Binding Revocation for IPv6 Mobility [draft-ietf-mext-binding-revocation-15] (40 pages) - Mobile IPv6 Generic Signaling Message [draft-ietf-mext-generic-signaling-message-00] (14 pages) - Guidelines for firewall administrators regarding MIPv6 traffic [draft-ietf-mext-firewall-admin-05] (12 pages) - Guidelines for firewall vendors regarding MIPv6 traffic [draft-ietf-mext-firewall-vendor-05] (8 pages) - Traffic Selectors for Flow Bindings [draft-ietf-mext-binary-ts-06] (19 pages) - Transport Layer Security-based Mobile IPv6 Security Framework for Mobile Node to Home Agent Communication [draft-ietf-mext-mip6-tls-02] (38 pages) No Requests for Comments Dynamic Host Configuration (dhc) -------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Ted Lemon John Jason Brzozowski Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion: dhcwg@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/dhcwg Archive: http://www.ietf.org/mail-archive/web/dhcwg/current/maillist.html Description of Working Group: The dhc working group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCPv4 is currently a "Draft Standard" and is documented in RFC 2131 and RFC 2132. DHCPv6 is currently a "Proposed Standard" and is documented in RFC 3315. Subsequent RFCs document additional options and other enhancements to the specifications. The DHC WG is responsible for reviewing DHCP options or other extensions (for both IPv4 and IPv6). The DHC WG is expected to review all proposed extensions to DHCP to ensure that they are consistent with the DHCP specification and other option formats, that they do not duplicate existing mechanisms, etc. Generally speaking, the DHC WG will not be responsible for evaluating the semantic content of proposed options. Similarly, the ownership of specifications typically belongs the relevant working group that needs more functionality from DHCP, not the DHC WG. The DHC WG coordinates reviews of the proposed options together with those working groups. It is required that those working groups have consensus to take on the work and that the work is within their charter. Exceptionally, with AD agreement, this same process can also be used for Individual Submissions originating outside WGs. However, the DHC WG can in some cases develop its own options that relate to either maintenance of existing specifications or improvements in the operation of the DHCP infrastructure itself. The DHC WG has the following main objectives: * Develop extensions to the DHCP infrastructure as required to meet new applications and deployments of DHCP. The topics currently in development are: - Subnet allocation mechanisms - Virtual subnet identification option - Option for passing DNS domain information in DHCPv6 - DHCP relay agent assignment notification in DHCPv6 - Option for DHCPv6 server reply sequence numbers - Rebinding capability for DHCPv6 Reconfigure messages - Behavior of layer 2 relay agents The adoption of new items requires explicit agreement from the AD or rechartering. * Write analyses of the DHCPv4 and DHCPv6 specifications, including RFC 2131, RFC 2132, RFC 3315 and other RFCs defining additional options, which identifies ambiguities, contradictory specifications and other obstacles to development of interoperable implementations. Recommend a process for resolving identified problems and incorporating the resolutions into the DHCP specification. Secondly, advance DHCPv4 (RFC 2131 and RFC 2132) and DHCPv6 (RFC 3315) in IETF Standards Track. Thirdly, specify guidelines for creating new DHCP options, and report on the status of DHCPv4 option reclassification. * Assess the requirements for a dual-stack host to use DHCP to obtain configuration settings for both IPv4 and IPv6. Hosts that include implementations of both IPv4 and IPv6 ("dual-stack hosts") may use DHCP to obtain configuration settings (including assigned addresses) for both IPv4 and IPv6. The DHCPv4 and DHCPv6 specifications (RFC 2131, RFC 2132, RFC 3315 and subsequent RFCs) do not explicitly explain how a dual-stack host uses DHCP to obtain configuration settings for both IP stacks. The DHC WG will evaluate solutions for configuration of dual-stack hosts through DHCP and select a solution that will be developed and published by the WG. * Hold a discussion whether on-link prefix information and default router information is needed in DHCP in addition to router advertisements. Actual solutions are out of scope for the WG, however. Goals and Milestones: Done - WG Last Call on DHCP Options for Internet Storage Name Service (draft-ietf-dhc-isnsoption-03.txt) Done - WG Last Call on Load Balancing for DHCPv6 (draft-ietf-dhc-dhcpv6-loadb-02.txt) Done - WG Last Call on Time Configuration Options for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt) Done - WG Last Call on IPv6 Prefix Options for DHCPv6 (draft-troan-dhcpv6-opt-prefix-delegation-02.txt) Done - WG Last Call on DNS Configuration options for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-dnsconfig-01.txt) Done - WG Last Call on NIS Configuration Options for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt) Done - Resubmit draft-ietf-dhc-dhcpv6-28.txt to IESG Done - Identify DHCPv4 authentication design team Done - Identify DHCPv4 specification review design team Done - Identify DHCPv4 relay agent message authentication design team Done - Submit DHCP Options for Internet Storage Name Service to IESG (draft-ietf-dhc-isnsoption) Done - Submit DNS Configuration options for DHCPv6 to IESG (draft-ietf-dhc-dhcpv6-opt-dnsconfig) Done - Submit NIS Configuratio Options for DHCPv6 to IESG (draft-ietf-dhc-dhcpv6-opt-nisconfig) Done - Submit IPv6 Prefix Options for DHCPv6 to IESG (draft-troan-dhcpv6-opt-prefix-delegation) Done - Submit 'Detection of Network Attachment (DNA) in IPv4' to IESG (draft-ietf-dhc-dna-ipv4) Done - Resolve IPR issues around 'Rapid Commit Option for DHCPv4' Done - Publish report on dual-stack issues in DHCP (draft-ietf-dhc-dual-stack) Done - Publish report on requirements for renumbering using stateless DHCPv6 (draft-ietf-dhc-stateless-dhcpv6-renumbering) Done - Submit 'Lifetime Option for DHCPv6' to IESG (draft-ietf-dhc-lifetime) Done - Submit 'Rapid Commit Option for DHCPv4' to IESG (draft-ietf-dhc-rapid-commit-opt) Done - Submit DDNS/DHCP documents to IESG Done - Submit 'Node-Specific Client Identifiers for DHCPv4' to IESG (draft-ietf-dhc-3315id-for-v4) Done - WG last call for 'Subnet Allocation Option' Done - WG last call on 'Virtual Subnet Selection Option' Oct 2007 - Submit 'Subnet Allocation Option' (draft-ietf-dhc-subnet-alloc-04) to IESG for Proposed Standard Nov 2007 - WG last call on 'Guidelines for Creating New DHCP Options' (draft-ietf-dhc-option-guidelines) Nov 2007 - Submit 'Virtual Subnet Selection Option', (draft-ietf-dhc-vpn-option) and (draft-ietf-dhc-agent-vpn-id) to IESG for Proposed Standard Dec 2007 - WG last call for 'Domain Suffix Option for DHCPv6' (draft-ietf-dhc-dhcpv6-opt-dnsdomain) Jan 2008 - Submit 'Domain Suffix Option for DHCPv6' (draft-ietf-dhc-dhcpv6-opt-dnsdomain) to IESG for Proposed Standard Jan 2008 - Submit 'Guidelines for Creating New DHCP Options' (draft-ietf-dhc-option-guidelines) to IESG for Best Current Practice Jan 2008 - Develop plan for advancing DHCPv4 and DHCPv6 plan to include completion of DHCPv4 specification review report, 'Implementation Issues with RFC 2131' (draft-ietf-dhc-implementation) for Informational Feb 2008 - WG last call for 'Status of Reclassifying DHCPv4 Options' (draft-ietf-dhc-status-3942) Feb 2008 - WG last call for 'Dual-stack clients and merging of data from DHCPv4 and DHCPv6' (draft-ietf-dhc-dual-stack-merge); waiting for more experience with IPv6 deployment Feb 2008 - WG last call for 'Rebind Capability in DHCPv6 Reconfigure Messages' (draft-ietf-dhc-dhcpv6-reconfigure-rebind) Mar 2008 - Submit 'Status of Reclassifying DHCPv4 Options' (draft-ietf-dhc-status-3942) to IESG for Informational Apr 2008 - 2nd WG last call for 'DHCP Relay Agent Assignment Notification Option (draft-ietf-dhc-dhcpv6-agentopt-delegate) and 'DHCPv6 Server Reply Sequence Number Option' (draft-ietf-dhc-dhcpv6-srsn-option) May 2008 - Submit 'Rebind Capability in DHCPv6 Reconfigure Messages' (draft-ietf-dhc-dhcpv6-reconfigure-rebind) to IESG for Proposed Standard Jun 2008 - WG last call on 'Layer 2 Relay Agent Behaviour' (draft-ietf-dhc-layer2-relay-agent) Jul 2008 - Submit 'Layer 2 Relay Agent Behaviour' to IESG (draft-ietf-dhc-layer2-relay-agent) for Informational Jul 2008 - Submit 'DHCP Relay Agent Assignment Notification Option' (draft-ietf-dhc-dhcpv6-agentopt-delegate) and 'DHCPv6 Server Reply Sequence Number Option' (draft-ietf-dhc-dhcpv6-srsn-option) to IESG for Proposed Standard Jul 2008 - Recharter, if needed Internet-Drafts: - Dynamic Configuration of Internet Hosts [draft-ietf-dhc-problem-stmt-00] (0 pages) - Clarifications and Extensions for the Bootstrap Protocol [draft-ietf-dhc-bootp-02] (27 pages) - Dynamic Host Configuration Protocol [draft-ietf-dhc-protocol-07] (38 pages) - DHCP Options and BOOTP Vendor Extensions [draft-ietf-dhc-options-04] (27 pages) - Interoperation Between DHCP and BOOTP [draft-ietf-dhc-between-bootp-03] (4 pages) - Dynamic Host Configuration Protocol [draft-ietf-dhc-dhcp-09] (45 pages) - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-ietf-dhc-dhcpv6-28] (89 pages) - DHCP Options and BOOTP Vendor Extensions [draft-ietf-dhc-options-1533update-06] (38 pages) - Options for DHCPv6 [draft-ietf-dhc-v6opts-00] (15 pages) - Procedure for Defining New DHCP Options [draft-ietf-dhc-new-options-06] (6 pages) - Interaction between DHCP and DNS [draft-ietf-dhc-dhcp-dns-12] (19 pages) - Authentication for DHCP Messages [draft-ietf-dhc-authentication-16] (17 pages) - An Extension to the DHCP Option Codes [draft-ietf-dhc-options-opt127-03] (3 pages) - An option for FQDNs in DHCP options [draft-ietf-dhc-fqdn-opt-03] (4 pages) - Extensions for the Dynamic Host Configuration Protocol for IPv6 [draft-ietf-dhc-dhcpv6exts-12] (39 pages) - Graceful renumbering of networks with DHCP [draft-ietf-dhc-renumbering-00] (8 pages) - DHCP Options for Service Location Protocol [draft-ietf-dhc-slp-08] (5 pages) - The User Class Option for DHCP [draft-ietf-dhc-userclass-11] (5 pages) - DHCP Options for Novell Directory Services [draft-provan-dhcp-options-dir-serv-02] (3 pages) - DHCP Option for IEEE 1003.1 POSIX Timezone Specifications [draft-ietf-dhc-timezone-03] (3 pages) - An Inter-server Protocol for DHCP [draft-ietf-dhc-interserver-02] (89 pages) - DHCP Relay Agent Information Option [draft-ietf-dhc-agent-options-12] (15 pages) - Multicast Address Allocation Configuration Options [draft-ietf-dhc-multopt-03] (5 pages) - Multicast address allocation extensions to the Dynamic Host Configuration Protocol [draft-ietf-dhc-mdhcp-03] (14 pages) - Subnet Configuration Option Set for DHCP [draft-ietf-dhc-dyn-subnet-conf-02] (14 pages) - The Server Identification Option for DHCP [draft-ietf-dhc-sio-00] (6 pages) - The Server Selection Option for DHCP [draft-ietf-dhc-sso-03] (14 pages) - Security Architecture for DHCP [draft-ietf-dhc-security-arch-01] (14 pages) - An Inter-server Protocol for DHCP [draft-ietf-dhc-interserver-alt-00] (53 pages) - The Named Pool Request Option for DHCP [draft-ietf-dhc-namedpool-00] (4 pages) - Netware/IP Domain Name and Information [draft-ietf-dhc-netware-options-01] (6 pages) - Securing DHCP [draft-ietf-dhc-securing-dhc-00] (5 pages) - The Domain Search Option for DHCP [draft-ietf-dhc-domsrch-02] (4 pages) - Subnet Selection Option for DHCP [draft-ietf-dhc-subsel-00] (5 pages) - DHCP Failover Protocol [draft-ietf-dhc-failover-12] (133 pages) - DHCP Continuation Option Code [draft-ietf-dhc-options-cont-01] (3 pages) - The Autonomous System Option for DHCP [draft-ietf-dhc-asnum-00] (5 pages) - The Server Range Option for DHCP [draft-ietf-dhc-range-00] (2 pages) - DHCP Safe Failover Protocol [draft-ietf-dhc-safe-failover-proto-00] (29 pages) - Security Requirements for the DHCP protocol [draft-ietf-dhc-security-requirements-00] (12 pages) - Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Server MIB [draft-ietf-dhc-server-mib-10] (37 pages) - DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients [draft-ietf-dhc-autoconfig-05] (9 pages) - DHCP Option for User Authentication Protocol [draft-ietf-dhc-options-uap-03] (3 pages) - Automatically Choosing an IP Address in an Ad-Hoc IPv4 Network [draft-ietf-dhc-ipv4-autoconfig-05] (8 pages) - DHCP Use of the User Class Option for Address Assignment [draft-ietf-dhc-useraddr-00] (5 pages) - The Subnet Selection Option for DHCP [draft-ietf-dhc-subnet-option-08] (6 pages) - DHCP Options for Call Control Servers [draft-ietf-dhc-callcontrolserv-00] (4 pages) - The Name Service Search Option for DHCP [draft-ietf-dhc-nsso-06] (4 pages) - New Option Review Guidelines and Additional Option Namespace [draft-ietf-dhc-option-review-and-namespace-02] (14 pages) - DHCP Schema for LDAP [draft-ietf-dhc-schema-02] (23 pages) - Interpreting Client Options for the Dynamic Host Configuration Protocol [draft-ietf-dhc-client-options-00] (24 pages) - DHC load balancing algorithm [draft-ietf-dhc-loadb-03] (9 pages) - The Migration Agent List Option for DHCP [draft-ietf-dhc-migagntlist-00] (4 pages) - DHCP Next Server Option [draft-ietf-dhc-nextserver-02] (0 pages) - The Classless Static Route Option for DHCP [draft-ietf-dhc-csr-08] (0 pages) - DHCP reconfigure extension [draft-ietf-dhc-pv4-reconfigure-06] (6 pages) - Authentication, Authorization, and Accounting Requirements for Roaming Nodes using DHCP [draft-ietf-dhc-aaa-requirements-00] (8 pages) - Requirements for Extending DHCP into New Environments [draft-ietf-dhc-enhance-requirements-00] (15 pages) - DHCP Option for CableLabs Client Configuration [draft-ietf-dhc-packetcable-06] (12 pages) - Procedure for Defining New DHCP Options and Message Types [draft-ietf-dhc-new-opt-msg-03] (7 pages) - The DHCP Client FQDN Option [draft-ietf-dhc-fqdn-option-14] (17 pages) - Resolution of FQDN Conflicts among DHCP Clients [draft-ietf-dhc-ddns-resolution-13] (14 pages) - New Option Review Guidelines for DHCP [draft-ietf-dhc-new-opt-review-00] (8 pages) - The DOCSIS Device Class DHCP Relay Agent Information Sub-option [draft-ietf-dhc-agentoptions-device-class-04] (5 pages) - DHCP Lease Query [draft-ietf-dhc-leasequery-10] (27 pages) - Triggering AAA from DHCP Relay Agents [draft-ietf-dhc-aaa-ra-00] (7 pages) - Encoding Long Options in DHCPv4 [draft-ietf-dhc-concat-05] (0 pages) - Extensions to DHCP for Roaming Users [draft-ietf-dhc-dhcproam-00] (15 pages) - LDAP Schema for DHCP [draft-ietf-dhc-ldap-schema-00] (18 pages) - Link Selection sub-option for the Relay Agent Information Option for DHCPv4 [draft-ietf-dhc-agent-subnet-selection-04] (8 pages) - Virtual Subnet Selection Sub-Option for the Relay Agent Information Option for DHCPv4 [draft-ietf-dhc-agent-vpn-id-06] (11 pages) - Virtual Subnet Selection Options for DHCPv4 and DHCPv6 [draft-ietf-dhc-vpn-option-15] (26 pages) - Wireless Key Management using DHCP [draft-ietf-dhc-key-management-00] (0 pages) - DSTM Options for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-dstm-01] (7 pages) - DNS Configuration Options for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-dnsconfig-05] (8 pages) - RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option [draft-ietf-dhc-agentopt-radius-09] (9 pages) - Load Balancing for DHCPv6 [draft-ietf-dhc-dhcpv6-loadb-02] (6 pages) - DSTM Ports Option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-dstm-ports-01] (4 pages) - NIS Configuration Options for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-nisconfig-06] (6 pages) - Time Configuration Options for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-timeconfig-03] (8 pages) - Considerations for the use of the Host Name option [draft-ietf-dhc-host-option-considerations-02] (8 pages) - The IPv4 DHCP Options for the Internet Storage Name Service [draft-ietf-dhc-isnsoption-14] (14 pages) - Unused DHCP Option Codes [draft-ietf-dhc-unused-optioncodes-08] (11 pages) - Extending DHCP Options Codes [draft-ietf-dhc-extended-optioncodes-00] (9 pages) - Client Preferred Prefix option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-cliprefprefix-01] (6 pages) - The Authentication Suboption for the DHCP Relay Agent Option [draft-ietf-dhc-auth-suboption-06] (15 pages) - KDC Server Address Sub-option [draft-ietf-dhc-suboptions-kdc-serveraddress-05] (5 pages) - IPv6 Prefix Options for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-prefix-delegation-06] (20 pages) - DHCP Option for Mobile IP Mobility Agents [draft-ietf-dhc-mipadvert-opt-02] (15 pages) - DHCP Subscriber ID Suboption for the DHCP Relay Agent Option [draft-ietf-dhc-subscriber-id-08] (10 pages) - PacketCable Security Ticket Control Sub-option for the the DHCP CableLabs Client Configuration Option [draft-ietf-dhc-pktc-kerb-tckt-03] (7 pages) - DHCP Server Identifier Override Suboption [draft-ietf-dhc-server-override-06] (12 pages) - Results from Interoperability Tests of DHCPv6 Implementations [draft-ietf-dhc-dhcpv6-interop-01] (12 pages) - Subnet Allocation Option [draft-ietf-dhc-subnet-alloc-12] (30 pages) - Implementation Issues with RFC 2131, "Dynamic Host Configuration Protocol (DHCPv4)" [draft-ietf-dhc-implementation-02] (41 pages) - Stateless DHCP Service for IPv6 [draft-ietf-dhc-dhcpv6-stateless-05] (10 pages) - The Authentication Suboption for the DHCP Relay Agent Option [draft-ietf-dhc-relay-agent-auth-01] (16 pages) - Node-Specific Client Identifiers for DHCPv4 [draft-ietf-dhc-3315id-for-v4-06] (11 pages) - Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis [draft-ietf-dhc-v4-threat-analysis-03] (20 pages) - DHCP RSA/DSA Authentication using DNS KEY records [draft-ietf-dhc-auth-sigzero-00] (0 pages) - Detecting Network Attachment in IPv4 (DNAv4) [draft-ietf-dhc-dna-ipv4-19] (16 pages) - Authentication of DHCP Relay Agent Options Using IPsec [draft-ietf-dhc-relay-agent-ipsec-02] (10 pages) - DHCP Options for the Intel Preboot eXecution Environment (PXE) [draft-ietf-dhc-pxe-options-04] (8 pages) - Vendor-Identifying Vendor Options for DHCPv4 [draft-ietf-dhc-vendor-04] (10 pages) - Rapid Commit Option for DHCPv4 [draft-ietf-dhc-rapid-commit-opt-06] (12 pages) - The Name Service Search Option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-nss-00] (6 pages) - Timezone Specifier Option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-tz-00] (6 pages) - Simple Network Time Protocol Configuration Option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-sntp-02] (5 pages) - Reclassifying DHCPv4 Options [draft-ietf-dhc-reclassify-options-02] (8 pages) - Client Identifier Option in DHCP Server Replies [draft-ietf-dhc-client-id-01] (5 pages) - DHCP Option for Proxy Server Configuration [draft-ietf-dhc-proxyserver-opt-05] (8 pages) - Configured Tunnel End Point Option for DHCPv6 [draft-ietf-dhc-dhcpv6-ctep-opt-02] (6 pages) - DHCPv6 Support for Remote Boot [draft-ietf-dhc-dhcpv6-opt-rboot-00] (6 pages) - The Extended Remote Boot Option for DHCPv4 [draft-ietf-dhc-opt-extrboot-00] (7 pages) - DHCP: IPv4 and IPv6 Dual-Stack Issues [draft-ietf-dhc-dual-stack-05] (14 pages) - Information Refresh Time Option for DHCPv6 [draft-ietf-dhc-lifetime-04] (8 pages) - Renumbering Requirements for Stateless DHCPv6 [draft-ietf-dhc-stateless-dhcpv6-renumbering-03] (8 pages) - Vendor-Specific Information Suboption for the DHCP Relay Agent Option [draft-ietf-dhc-vendor-suboption-01] (9 pages) - The DHCPv6 Client FQDN Option [draft-ietf-dhc-dhcpv6-fqdn-06] (15 pages) - Clarifications on DHCPv6 Authentication [draft-ietf-dhc-dhcpv6-clarify-auth-01] (14 pages) - DHCPv4 Options for Broadcast and Multicast Control Servers [draft-ietf-dhc-bcmcv4-option-00] (12 pages) - DHCPv6 Options for Broadcast and Multicast Control Servers [draft-ietf-dhc-bcmcv6-option-00] (14 pages) - Service-Oriented Address Assignment using DHCPv6 [draft-ietf-dhc-soa-option-00] (9 pages) - DHCPv6 Relay agent RADIUS Attribute Option [draft-ietf-dhc-v6-relay-radius-02] (12 pages) - DHCP Options for Broadcast and Multicast Control Servers [draft-ietf-dhc-bcmc-options-06] (15 pages) - DHCPv6 Relay Agent Subscriber-ID Option [draft-ietf-dhc-dhcpv6-subid-02] (8 pages) - DHCPv6 Relay Agent Remote ID Option [draft-ietf-dhc-dhcpv6-remoteid-02] (8 pages) - Dual-stack clients and merging of data from DHCPv4 and DHCPv6 [draft-ietf-dhc-dual-stack-merge-01] (8 pages) - DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents [draft-ietf-dhc-paa-option-06] (9 pages) - Domain Suffix Option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-dnsdomain-04] (7 pages) - DHCPv6 Relay Agent Assignment Notification (RAAN) Option [draft-ietf-dhc-dhcpv6-agentopt-delegate-04] (8 pages) - Time Protocol Servers and Time Offset Options for IPv6 DHCP [draft-ietf-dhc-dhcpv6-rfc868-servers-00] (6 pages) - A Timezone Option for DHCP [draft-ietf-dhc-timezone-option-06] (11 pages) - DHCPv4 Relay Agent Flags Suboption [draft-ietf-dhc-relay-agent-flags-04] (8 pages) - Dynamic Host Configuration Protocol Options Used by PXELINUX [draft-ietf-dhc-pxelinux-04] (14 pages) - Rebind Capability in DHCPv6 Reconfigure Messages [draft-ietf-dhc-dhcpv6-reconfigure-rebind-09] (8 pages) - DHCPv6 Leasequery [draft-ietf-dhc-dhcvp6-leasequery-01] (21 pages) - DHCPv6 Leasequery [draft-ietf-dhc-dhcpv6-leasequery-02] (23 pages) - DHCPv6 Relay Agent Echo Request Option [draft-ietf-dhc-dhcpv6-ero-02] (7 pages) - DHCPv6 Server Reply Sequence Number Option [draft-ietf-dhc-dhcpv6-srsn-option-02] (7 pages) - Guidelines for Creating New DHCP Options [draft-ietf-dhc-option-guidelines-07] (18 pages) - Container Option for Server Configuration [draft-ietf-dhc-container-opt-05] (10 pages) - DHCPv6 Bulk Leasequery [draft-ietf-dhc-dhcpv6-bulk-leasequery-07] (18 pages) - Layer 2 Relay Agent Information [draft-ietf-dhc-l2ra-06] (13 pages) - Extensions to Layer 2 Relay Agent [draft-ietf-dhc-l2ra-extensions-01] (22 pages) - The DHCPv4 Relay Agent Identifier Suboption [draft-ietf-dhc-relay-id-suboption-10] (7 pages) - DHCPv6 options for network boot [draft-ietf-dhc-dhcpv6-opt-netboot-11] (11 pages) - Dynamic Host Configuration Protocol DHCPINFORM Message Clarifications [draft-ietf-dhc-dhcpinform-clarify-06] (9 pages) - DHCPv4 lease query by Relay Agent Remote ID [draft-ietf-dhc-leasequery-by-remote-id-10] (18 pages) - DHCPv6 Vendor-specific Message [draft-ietf-dhc-dhcpv6-vendor-message-01] (6 pages) - DHCPv4 Vendor-specific Message [draft-ietf-dhc-dhcpv4-vendor-message-01] (7 pages) - Bulk DHCPv4 Lease Query [draft-ietf-dhc-dhcpv4-bulk-leasequery-05] (39 pages) - Forcerenew Nonce Authentication [draft-ietf-dhc-forcerenew-nonce-03] (11 pages) - Lightweight DHCPv6 Relay Agent [draft-ietf-dhc-dhcpv6-ldra-04] (14 pages) - Secure DHCPv6 Using CGAs [draft-ietf-dhc-secure-dhcpv6-04] (16 pages) - IEEE 802.11 parameters DHCP Option [draft-ietf-dhc-80211-option-01] (5 pages) - Relay-Supplied DHCP Options [draft-ietf-dhc-dhcpv6-relay-supplied-options-10] (8 pages) - Definition of the UUID-based DHCPv6 Unique Identifier (DUID-UUID) [draft-ietf-dhc-duid-uuid-04] (6 pages) - Prefix Exclude Option for DHCPv6-based Prefix Delegation [draft-ietf-dhc-pd-exclude-04] (10 pages) - Relay Agent Encapsulation for DHCPv4 [draft-ietf-dhc-dhcpv4-relay-encapsulation-02] (22 pages) - DHCPv6 Redundancy Deployment Considerations [draft-ietf-dhc-dhcpv6-redundancy-consider-02] (16 pages) - Configuring Cryptographically Generated Addresses (CGA) using DHCPv6 [draft-ietf-dhc-cga-config-dhcpv6-01] (10 pages) - Prefix Assignment in DHCPv6 [draft-ietf-dhc-host-gen-id-01] (10 pages) - DHCPv6 Failover Requirements [draft-ietf-dhc-dhcpv6-failover-requirements-00] (19 pages) - DHCPv4 over IPv6 Transport [draft-ietf-dhc-dhcpv4-over-ipv6-00] (9 pages) - DHCPv6 through Tunnels [draft-ietf-dhc-dhcpv6-tunnel-00] (5 pages) Requests for Comments: RFC2131: Dynamic Host Configuration Protocol (34 pages) * Obsoletes RFC1541 * Obsoletes RFC1533 * Updated by RFC3396 * Updated by RFC4361 * Updated by RFC5494 RFC2132: DHCP Options and BOOTP Vendor Extensions (34 pages) * Obsoletes RFC1533 * Updated by RFC3442 * Updated by RFC3942 * Updated by RFC4361 * Updated by RFC4833 * Updated by RFC5494 RFC1542: Clarifications and Extensions for the Bootstrap Protocol (23 pages) * Obsoletes RFC1532 RFC1541: Dynamic Host Configuration Protocol (39 pages) * Obsoletes RFC1531 * OBSOLETED BY RFC2131 RFC1532: Clarifications and Extensions for the Bootstrap Protocol (22 pages) * Obsoletes RFC951 * OBSOLETED BY RFC1542 RFC1534: Interoperation Between DHCP and BOOTP (4 pages) RFC1533: DHCP Options and BOOTP Vendor Extensions (30 pages) * Obsoletes RFC1497 * OBSOLETED BY RFC2132 * OBSOLETED BY RFC2131 RFC1531: Dynamic Host Configuration Protocol (39 pages) * OBSOLETED BY RFC1541 RFC2241: DHCP Options for Novell Directory Services (5 pages) RFC2242: Netware/IP Domain Name and Information (6 pages) RFC2485: DHCP Option for The Open Group's User Authentication Protocol (4 pages) RFC2489: Procedure for Defining New DHCP Options (5 pages) * OBSOLETED BY RFC2939 RFC2610: DHCP Options for Service Location Protocol (6 pages) RFC2939: Procedure for Defining New DHCP Options and Message Types (7 pages) * Obsoletes RFC2489 RFC2937: The Name Service Search Option for DHCP (5 pages) RFC3004: The User Class Option for DHCP (6 pages) RFC3011: The Subnet Selection Option for DHCP (6 pages) RFC3046: DHCP Relay Agent Information Option (14 pages) RFC2563: DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients (9 pages) RFC3074: DHC load balancing algorithm (10 pages) RFC3118: Authentication for DHCP Messages (17 pages) RFC3203: DHCP reconfigure extension (6 pages) RFC3256: The DOCSIS Device Class DHCP Relay Agent Information Sub-option (5 pages) RFC3396: Encoding Long Options in DHCPv4 (9 pages) * Updates RFC2131 RFC3442: The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4 (9 pages) * Updates RFC2132 RFC3495: Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration (13 pages) RFC3527: Link Selection sub-option for the Relay Agent Information Option for DHCPv4 (9 pages) RFC3315: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (101 pages) * Updated by RFC4361 * Updated by RFC5494 * Updated by RFC6221 * Updated by RFC6422 RFC3594: PacketCable Security Ticket Control Sub-option for the the DHCP CableLabs Client Configuration (CCC)Option (7 pages) RFC3646: DNS Configuration Options for DHCPv6 (8 pages) RFC3633: IPv6 Prefix Options for DHCPv6 (20 pages) RFC3634: KDC Server Address Sub-option (5 pages) RFC3679: Unused DHCP Option Codes (8 pages) RFC3736: Stateless DHCP Service for IPv6 (10 pages) RFC3898: NIS Configuration Options for DHCPv6 (6 pages) RFC3925: Vendor-Identifying Vendor Options for DHCPv4 (10 pages) RFC3942: Reclassifying DHCPv4 Options (8 pages) * Updates RFC2132 RFC4014: RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option (9 pages) RFC3993: DHCP Subscriber ID Suboption for the DHCP Relay Agent Option (10 pages) RFC4030: The Authentication Suboption for the DHCP Relay Agent Option (15 pages) RFC4039: Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4) (12 pages) RFC4075: Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6 (5 pages) RFC4076: Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (8 pages) RFC4174: The IPv4 Dynamic Host Configuration Protocol (DHCP) Options for the Internet Storage Name Service (14 pages) RFC4242: Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (8 pages) RFC4280: Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers (15 pages) RFC4243: Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option (9 pages) RFC4361: Node-Specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4) (11 pages) * Updates RFC2131 * Updates RFC2132 * Updates RFC3315 * Updated by RFC5494 RFC4388: Dynamic Host Configuration Protocol (DHCP) Leasequery (27 pages) * Updated by RFC6148 RFC4436: Detecting Network Attachment in IPv4 (DNAv4) (16 pages) RFC4477: Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues (14 pages) RFC4580: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option (8 pages) RFC4649: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option (8 pages) RFC4704: The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option (15 pages) RFC4703: Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients (14 pages) RFC4702: The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option (17 pages) RFC4578: Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE) (8 pages) RFC4833: A Timezone Option for DHCP (11 pages) * Updates RFC2132 RFC5010: The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption (8 pages) RFC5007: DHCPv6 Leasequery (23 pages) RFC4994: DHCPv6 Relay Agent Echo Request Option (7 pages) RFC5071: Dynamic Host Configuration Protocol Options Used by PXELINUX (14 pages) RFC5107: DHCP Server Identifier Override Suboption (12 pages) RFC5192: DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents (8 pages) RFC5460: DHCPv6 Bulk Leasequery (18 pages) RFC5970: DHCPv6 Options for Network Boot (11 pages) RFC6148: DHCPv4 Lease Query by Relay Agent Remote ID (13 pages) * Updates RFC4388 RFC6221: Lightweight DHCPv6 Relay Agent (17 pages) * Updates RFC3315 RFC6355: Definition of the UUID-based DHCPv6 Unique Identifier (DUID-UUID) (6 pages) RFC6422: Relay-Supplied DHCP Options (8 pages) * Updates RFC3315 Home Networking (homenet) ------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Mark Townsley Ray Bellis Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman Internet Area Advisor: Ralph Droms Tech Advisor: Acee Lindem Mailing Lists: General Discussion: homenet@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/homenet Archive: http://www.ietf.org/mail-archive/web/homenet/ Description of Working Group: This working group focuses on the evolving networking technology within and among relatively small "residential home" networks. For example, an obvious trend in home networking is the proliferation of networking technology in an increasingly broad range and number of devices. This evolution in scale and diversity sets some requirements on IETF protocols. Some of the relevant trends include: o Multiple segments: While less complex L3-toplogies involving as few subnets as possible are preferred in home networks for a variety of reasons including simpler management and service discovery, the introduction of more than one subnet into a home network is enough to add complexity that needs to be addressed, and multiple dedicated segments are necessary for some cases. For instance, a common feature in modern home routers in the ability to support both guest and private network segments. Also, link layer networking technology is poised to become more heterogeneous, as networks begin to employ both traditional Ethernet technology and link layers designed for low-powered sensor networks. Finally, similar needs for segmentation may occur in other cases, such as separating building control or corporate extensions from the Internet access network for the home. Different segments may be associated with subnets that have different routing and security policies. o Service providers are deploying IPv6, and support for IPv6 is increasingly available in home gateway devices. While IPv6 resembles IPv4 in many ways, it changes address allocation principles and allows direct IP addressability and routing to devices in the home from the Internet. This is a promising area in IPv6 that has proved challenging in IPv4 with the proliferation of NAT. o End-to-end communication is both an opportunity and a concern as it enables new applications but also exposes nodes in the internal networks to receipt of unwanted traffic from the Internet. Firewalls that restrict incoming connections may be used to prevent exposure, however, this reduces the efficacy of end-to-end connectivity that IPv6 has the potential to restore. Home networks need to provide the tools to handle these situations in a manner accessible to all users of home networks. Manual configuration is rarely, if at all, possible, as the necessary skills and in some cases even suitable management interfaces are missing. The purpose of this working group is to focus on this evolution, in particular as it addresses the introduction of IPv6, by developing an architecture addressing this full scope of requirements: o prefix configuration for routers o managing routing o name resolution o service discovery o network security The task of the group is to produce an architecture document that outlines how to construct home networks involving multiple routers and subnets. This document is expected to apply the IPv6 addressing architecture, prefix delegation, global and ULA addresses, source address selection rules and other existing components of the IPv6 architecture, as appropriate. The architecture document should drive what protocols changes, if any, are necessary. Specific protocol work described below is expected to be within the scope of the working group once the architecture work is complete. However, the group is required to review its charter and milestones with the IESG and IETF community before submitting documents that make protocol changes. It is expected that the group has to discuss some of the below solutions, however, in order to complete the architecture work. The group will apply existing protocols to handle the five requirements above. For prefix configuration, existing protocols are likely sufficient, and at worst may need some small enhancements, such as new options. For automatic routing, it is expected that existing routing protocols can be used as is, however, a new mechanism may be needed in order to turn a selected protocol on by default. For name resolution and service discovery, extensions to existing multicast-based name resolution protocols are needed to enable them to work across subnets. For network security, the group shall document the concept of "advanced security" as a further development of "simple security" from RFC 6092. The main goal of this work is to enable a security policy that adapts to IPv6 threats as they emerge, taking into account not only traffic from the Internet at large, but within and leaving the home network itself. It is expected that the working group will define a set of protocol specifications to accomplish the five requirements from above. However, it is not in the scope of the working group to define entirely new routing protocols or address allocation protocols. As noted, additional options or other small extensions may be necessary to use the existing protocols in these new configuration tasks. The working group shall also not make any changes to IPv6 protocols or addressing architecture. Prefix configuration, routing, and security related work shall not cause any changes that are not backwards compatible to existing IPv6 hosts. There may be host visible changes in the work on naming and discovery protocols, however. In its design, the working group shall also consider security aspects and the impact on manageability. The main focus of the working group is home networks, but the group's results may also find applications in other small networks. The group should assume that an IPv4 network may have to co-exist alongside the IPv6 network and should take this into account insofar as alignment with IPv6 is desirable. But the group should also ensure that even IPv6-only are possible, and while IP-version agnostic work is of course desirable, IPv4-specific work is outside the scope of the group. The working group will liaise with the relevant IETF working groups. In particular, the group should work closely with the V6OPS working group, review any use or extension of DHCP with the DHC working group, and work with additional DNS requirements with the DNSEXT and DNSOP working groups. If it turns out that additional options are needed for a routing protocol, they will be developed in the appropriate Routing Area working group, with the HOMENET working group providing the architecture and requirements for such enhancements. The working group will also liason with external standards bodies where it is expected that there are normative dependencies between the specifications of the two bodies. It is expected that in the architecture definition stage liaising with the Broadband Forum, DLNA, UPnP Forum, OASIS, ZigBee Alliance and other SDOs is necessary, as is understanding existing technology from these groups. Goals and Milestones: Jul 2011 - Formation of the working group Sep 2011 - First WG draft on the architecture Dec 2011 - Submission of the architecture draft to the IESG as Informational RFC Dec 2011 - Charter re-evaluation based on the architecture work Dec 2011 - First WG draft on prefix configuration Dec 2011 - First WG draft on routing Jan 2012 - First WG draft on name resolution Feb 2012 - First WG draft on service discovery Feb 2012 - First WG draft on perimeter security Feb 2012 - Start of routing related work in the relevant routing area working group, if needed Mar 2012 - Submission of the prefix configuration draft to the IESG as Standards Track RFC Apr 2012 - Submission of the routing draft to the IESG as Informational RFC Sep 2012 - Submission of the name resolution draft to the IESG as Standards Track RFC Nov 2012 - Submission of the service discovery draft to the IESG as Standards Track RFC Dec 2012 - Submission of the perimeter security draft to the IESG as Informational RFC Internet-Drafts: - Home Networking Architecture for IPv6 [draft-ietf-homenet-arch-01] (34 pages) No Requests for Comments Host Identity Protocol (hip) ---------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: David Ward Gonzalo Camarillo Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion: hipsec@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/hipsec Archive: http://www.ietf.org/mail-archive/web/hipsec/current/maillist.html Description of Working Group: The Host Identity Protocol (HIP) provides a method of separating the end-point identifier and locator roles of IP addresses. It introduces a new Host Identity (HI) name space, based on public keys, from which end-point identifiers are taken. The public keys are typically, but not necessarily, self generated. HIP uses existing IP addressing and forwarding for locators and packet delivery. The architecture and protocol details for these mechanisms are currently specified in the following Experimental RFCs: o HIP Architecture (RFC 4423) o Host Identity Protocol (RFC 5201) There are several publicly known interoperating implementations, some of which are open source. The HIP WG was chartered to publish protocol specifications in documents whose quality and security properties would meet the requirements for publication as standards track documents. These specifications have been published as Experimental RFCs, because the effects of the protocol on applications and on the Internet as a whole were unknown. The Experimental RFCs produced by the HIP WG allowed the community to experiment with HIP technologies and learn from these experiments. The HIP WG will now produce standards track versions of the main HIP RFCs taking as a base the existing Experimental RFCs. The WG will also specify certificate handling in HIP in a standards track RFC. Additionally, the WG will finish the WG items it was working on before starting the standards track work. These WG items relate to how to build HIP-based overlays and will result in Experimental RFCs. The following are charter items for the working group: o Revise RFCs 4423, 4843, 5201, 5202, 5203, 5204, 5205, 5206, and 5770 as standards track RFCs. o Specify in a standards track RFC how to carry certificates in the base exchange. This was removed from the base HIP spec so that the mechanism is specified in a stand-alone spec. o Specify in an Experimental RFC how to build a HIP-based overlay using RELOAD. o Specify in an Experimental RFC how to transport HIP messages over encrypted connections that were established using HIP. Goals and Milestones: Done - Submit Native API specification to the IESG Done - Submit Framework for HIP overlays specification to the IESG Done - Submit Multi-hop routing mechanism for HIP Done - Submit Upper-layer data transport in HIP to the IESG Done - WGLC Certs in HIP base exchange specification Done - WGLC the HIP over HIP specification Done - Submit Certs in HIP base exchange to the IESG as Experimental Done - Submit the HIP over HIP specification to the IESG Mar 2011 - WGLC the specification on how to build HIP-based overlays using RELOAD Apr 2011 - Submit the specification on how to build HIP-based overlays using RELOAD to the IESG May 2011 - WGLC RFC4423bis May 2011 - WGLC RFC4843bis May 2011 - WGLC RFC5201bis May 2011 - WGLC RFC5202bis Jun 2011 - Submit RFC5201bis to the IESG Jun 2011 - Submit RFC4843bis to the IESG Jun 2011 - Submit RFC4423bis to the IESG Jun 2011 - Submit RFC5202bis to the IESG Jul 2011 - WGLC RFC5203bis Jul 2011 - WGLC RFC5204bis Jul 2011 - WGLC RFC5205bis Jul 2011 - WGLC the mobility portion of RFC5206bis Aug 2011 - Submit RFC5203bis to the IESG Aug 2011 - Submit RFC5204bis to the IESG Aug 2011 - Submit RFC5205bis to the IESG Aug 2011 - Submit the mobility portion of RFC5206bis to the IESG Sep 2011 - WGLC RFC5770bis Sep 2011 - WGLC the multihoming portion of RFC5206bis Oct 2011 - Submit RFC5770bis to the IESG Oct 2011 - Submit the multihoming portion of RFC5206bis to the IESG Nov 2011 - WGLC Certs in HIP base exchange specification (referencing RFC5201bis) Dec 2011 - Submit Certs in HIP base exchange (referencing RFC5201bis) to the IESG as PS Jan 2012 - Recharter or close the WG Internet-Drafts: - Host Identity Protocol [draft-ietf-hip-base-11] (108 pages) - Host Identity Protocol Architecture [draft-ietf-hip-arch-04] (24 pages) - End-Host Mobility and Multihoming with the Host Identity Protocol [draft-ietf-hip-mm-06] (48 pages) - Host Identity Protocol (HIP) Domain Name System (DNS) Extensions [draft-ietf-hip-dns-10] (21 pages) - Host Identity Protocol (HIP) Rendezvous Extension [draft-ietf-hip-rvs-06] (15 pages) - Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) [draft-ietf-hip-esp-07] (37 pages) - Host Identity Protocol (HIP) Registration Extension [draft-ietf-hip-registration-03] (14 pages) - Using the Host Identity Protocol with Legacy Applications [draft-ietf-hip-applications-05] (22 pages) - Basic HIP Extensions for Traversal of Network Address Translators [draft-ietf-hip-nat-traversal-10] (33 pages) - Basic Socket Interface Extensions for Host Identity Protocol (HIP) [draft-ietf-hip-native-api-13] (19 pages) - Host Identity Protocol Certificates [draft-ietf-hip-cert-13] (14 pages) - HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment [draft-ietf-hip-bone-08] (22 pages) - HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper- layer Protocol Signaling (HICCUPS) [draft-ietf-hip-hiccups-06] (17 pages) - Host Identity Protocol (HIP) Multi-hop Routing Extension [draft-ietf-hip-via-04] (10 pages) - Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD) [draft-ietf-hip-reload-instance-04] (10 pages) - Encrypted Signaling Transport Modes for the Host Identity Protocol [draft-ietf-hip-over-hip-07] (13 pages) - Host Identity Protocol Architecture [draft-ietf-hip-rfc4423-bis-03] (27 pages) - An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID) [draft-ietf-hip-rfc4843-bis-02] (13 pages) - Host Identity Protocol (HIP) Registration Extension [draft-ietf-hip-rfc5203-bis-02] (13 pages) - Host Identity Protocol (HIP) Rendezvous Extension [draft-ietf-hip-rfc5204-bis-02] (15 pages) - Host Identity Protocol (HIP) Domain Name System (DNS) Extension [draft-ietf-hip-rfc5205-bis-02] (17 pages) - Host Identity Protocol Version 2 (HIPv2) [draft-ietf-hip-rfc5201-bis-07] (124 pages) - Host Mobility with the Host Identity Protocol [draft-ietf-hip-rfc5206-bis-03] (33 pages) - Host Multihoming with the Host Identity Protocol [draft-ietf-hip-multihoming-00] (22 pages) - Native NAT Traversal Mode for the Host Identity Protocol [draft-ietf-hip-native-nat-traversal-02] (15 pages) - Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) [draft-ietf-hip-rfc5202-bis-00] (37 pages) Requests for Comments: RFC4423: Host Identity Protocol (HIP) Architecture (24 pages) RFC5201: Host Identity Protocol (108 pages) * Updated by RFC6253 RFC5205: Host Identity Protocol (HIP) Domain Name System (DNS) Extensions (21 pages) RFC5203: Host Identity Protocol (HIP) Registration Extension (14 pages) RFC5202: Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) (37 pages) RFC5204: Host Identity Protocol (HIP) Rendezvous Extension (15 pages) RFC5206: End-Host Mobility and Multihoming with the Host Identity Protocol (48 pages) RFC5338: Using the Host Identity Protocol with Legacy Applications (14 pages) RFC5770: Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators (34 pages) RFC6028: Host Identity Protocol (HIP) Multi-hop Routing Extension (10 pages) RFC6078: Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS) (17 pages) RFC6079: HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE) (21 pages) RFC6253: Host Identity Protocol Certificates (12 pages) * Updates RFC5201 RFC6261: Encrypted Signaling Transport Modes for the Host Identity Protocol (13 pages) RFC6317: Basic Socket Interface Extensions for the Host Identity Protocol (HIP) (18 pages) IPv6 Maintenance (6man) ----------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Robert Hinden Brian Haberman Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: ipv6@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipv6 Archive: http://www.ietf.org/mail-archive/web/ipv6 Description of Working Group: The 6man working group is responsible for the maintenance, upkeep, and advancement of the IPv6 protocol specifications and addressing architecture. It is not chartered to develop major changes or additions to the IPv6 specifications. The working group will address protocol limitations/issues discovered during deployment and operation. It will also serve as a venue for discussing the proper location for working on IPv6-related issues within the IETF. The working group's work items are as follows: o Complete work on RA Flags Option o Complete work on RH0 Deprecation o Complete work on IPv6 over PPP Compression Negotiation o Complete work on Centrally Allocated Unique Local Addresses (ULA-C) All new work items not listed above require the approval of the working group and the sponsoring Area Director before they will be taken on by the working group. Goals and Milestones: Done - Submit RH0 Deprecation specification to IESG as a Proposed Standard Jan 2008 - Submit PPP Compression Negotiation specification to IESG as a Proposed Standard Mar 2008 - Determine way forward for ULA-C specification Internet-Drafts: - Centrally Assigned Unique Local IPv6 Unicast Addresses [draft-ietf-ipv6-ula-central-02] (11 pages) - Negotiation for IPv6 datagram compression using IPv6 Control Protocol [draft-ietf-ipv6-compression-nego-v2-03] (8 pages) - IPv6 Node Requirements [draft-ietf-6man-node-req-bis-12] (31 pages) - Reserved IPv6 Interface Identifiers [draft-ietf-6man-reserved-iids-04] (12 pages) - Solution approaches for address-selection problems [draft-ietf-6man-addr-select-sol-03] (17 pages) - IPv6 Subnet Model: the Relationship between Links and Subnet Prefixes [draft-ietf-6man-ipv6-subnet-model-13] (13 pages) - Handling of overlapping IPv6 fragments [draft-ietf-6man-overlap-fragment-04] (7 pages) - IPv6 Flow Label Specification [draft-ietf-6man-flow-3697bis-08] (17 pages) - A Recommendation for IPv6 Address Text Representation [draft-ietf-6man-text-addr-representation-08] (14 pages) - IANA Allocation Guidelines for the IPv6 Routing Header [draft-ietf-6man-iana-routing-header-01] (3 pages) - Considerations for IPv6 Address Selection Policy Changes [draft-ietf-6man-addr-select-considerations-04] (19 pages) - IPv6 Router Advertisement Options for DNS Configuration [draft-ietf-6man-dns-options-bis-09] (18 pages) - An IPv6 Routing Header for Source Routes with RPL [draft-ietf-6man-rpl-routing-header-07] (20 pages) - Interface Identifier Assignment in IPv6 SLAAC [draft-ietf-6man-neighbor-inform-00] (17 pages) - An uniform format for IPv6 extension headers [draft-ietf-6man-exthdr-06] (8 pages) - IPv6 UDP Checksum Considerations [draft-ietf-6man-udpzero-05] (34 pages) - RPL Option for Carrying RPL Information in Data-Plane Datagrams [draft-ietf-6man-rpl-option-06] (14 pages) - Update to RFC 3484 Default Address Selection for IPv6 [draft-ietf-6man-rfc3484-revise-05] (12 pages) - Using 127-bit IPv6 Prefixes on Inter-Router Links [draft-ietf-6man-prefixlen-p2p-02] (9 pages) - Using the IPv6 flow label for equal cost multipath routing and link aggregation in tunnels [draft-ietf-6man-flow-ecmp-06] (10 pages) - Rationale for update to the IPv6 flow label specification [draft-ietf-6man-flow-update-08] (13 pages) - Distributing Address Selection Policy using DHCPv6 [draft-ietf-6man-addr-select-opt-02] (10 pages) - The Line Identification Destination Option [draft-ietf-6man-lineid-02] (14 pages) - Duplicate Address Detection Proxy [draft-ietf-6man-dad-proxy-02] (13 pages) - UDP Checksums for Tunneled Packets [draft-ietf-6man-udpchecksums-01] (12 pages) - Neighbor Unreachability Detection is too impatient [draft-ietf-6man-impatient-nud-00] (7 pages) - RFC3627 to Historic status [draft-ietf-6man-3627-historic-01] (4 pages) - Processing of IPv6 "atomic" fragments [draft-ietf-6man-ipv6-atomic-fragments-00] (14 pages) Requests for Comments: RFC5172: Negotiation for IPv6 datagram compression using IPv6 Control Protocol (8 pages) * Obsoletes RFC2472 RFC5453: Reserved IPv6 Interface Identifiers (12 pages) RFC5722: Handling of Overlapping IPv6 Fragments (6 pages) * Updates RFC2460 RFC5871: IANA Allocation Guidelines for the IPv6 Routing Header (3 pages) * Updates RFC2460 RFC5942: IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes (11 pages) * Updates RFC4861 RFC5952: A Recommendation for IPv6 Address Text Representation (14 pages) * Updates RFC4291 RFC6106: IPv6 Router Advertisement Options for DNS Configuration (19 pages) * Obsoletes RFC5006 RFC6164: Using 127-bit IPv6 Prefixes on Inter-Router Links (8 pages) RFC6436: Rationale for Update to the IPv6 Flow Label Specification (13 pages) RFC6437: IPv6 Flow Label Specification (15 pages) * Updates RFC2205 * Updates RFC2460 RFC6438: Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels (9 pages) RFC6434: IPv6 Node Requirements (30 pages) * Obsoletes RFC4294 IPv6 over Low power WPAN (6lowpan) ---------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Carsten Bormann Geoffrey Mulligan Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion: 6lowpan@lists.ietf.org To Subscribe: 6lowpan-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/6lowpan/current/maillist.html Description of Working Group: Background/Introduction: Well-established fields such as control networks, and burgeoning ones such as "sensor" (or transducer) networks, are increasingly being based on wireless technologies. Most (but certainly not all) of these nodes are amongst the most constrained that have ever been networked wirelessly. Extreme low power (such that they will run potentially for years on batteries) and extreme low cost (total device cost in single digit dollars, and riding Moore's law to continuously reduce that price point) are seen as essential enablers towards their deployment in networks with the following characteristics: * Significantly more devices than current local area networks * Severely limited code and ram space (e.g., highly desirable to fit the required code--MAC, IP and anything else needed to execute the embedded application--in, for example, 32K of flash memory, using 8-bit microprocessors) * Unobtrusive but very different user interface for configuration (e.g., using gestures or interactions involving the physical world) A chief component of these devices is wireless communication technology. In particular, the IEEE 802.15.4 standard is very promising for the lower (physical and link) layers. As for higher layer functions, there is considerable interest from non-IETF groups in using IP technology. The IEEE 1451.5 standard for wireless transducers has a chapter for 6LoWPAN and the ISA SP100 standard for wireless industrial networks has adopted 6LoWPAN for their network layer. This working group is expected to coordinate and interact with such groups. Description of Working Group: ----------------------------- The Working Group has completed two RFCs: "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" (RFC4919) that documents and discusses the problem space and "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" (RFC4944) which defines the format for the adaptation between IPv6 and 802.15.4. The Working Group will generate the necessary documents to ensure interoperable implementations of 6LoWPAN networks and will define the necessary security and management protocols and constructs for building 6LoWPAN networks, paying particular attention to protocols already available. 6lowpan will work closely with the Routing Over Low power and Lossy networks (roll) working group which is developing IPv6 routing solutions for low power and lossy networks (LLNs). Work Items: ----------- 1. Produce "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations" to define limited extensions to IPv6 Neighbor Discovery [RFC4861] for use specifically in low-power networks. This document (or documents) will define how to bootstrap a 6LoWPAN network and explore ND optimizations such as reusing the structure of the 802.15.4 network (e.g., by using the coordinators), and reduce the need for multicast by having devices talk to coordinators (without creating a single point-of-failure, or changing the semantics of the IPv6 ND multicasts). This document or documents will be a proposed standard. 2. Produce "6LoWPAN Improved Header Compression" to describe mechanisms to allow enhancements to the 6LoWPAN headers. Specifically this document will describe compression of addresses that are not link-local. Additionally this document may include other enhancements or optimizations of the HC1 or HC2 6LoWPAN headers. This document will be a proposed standard. 3. Produce "6LoWPAN Architecture" to describe the design and implementation of 6LoWPAN networks. This document will cover the concepts of "Mesh Under" and "Route Over", 802.15.4 design issues such as operation with sleeping nodes, network components (both battery- and line-powered), addressing, and IPv4/IPv6 network connections. This document will be informational. 4. As a separate Internet Draft, "6LoWPAN Routing Requirements" will describe 6LoWPAN-specific requirements on routing protocols used in 6LoWPANs, addressing both the "route-over" and "mesh-under" approach. This document will be created and owned by this working group but is expected to be reviewed by the ROLL WG. This document will be informational. 5. Produce "Use Cases for 6LoWPAN" to define, for a small set of applications with sufficiently unique requirements, how 6LoWPANs can solve those requirements, and which protocols and configuration variants can be used for these scenarios. The use cases will cover protocols for transport, application layer, discovery, configuration and commissioning. This document will be informational. 6. Produce "6LoWPAN Security Analysis" to define the threat model of 6LoWPANs, to document suitability of existing key management schemes and to discuss bootstrapping/installation/commissioning/setup issues. This document will be referenced from the "security considerations" of the other 6LoWPAN documents. This document will be informational. The working group will continue to reuse existing protocols and mechanisms whenever reasonable and possible. Non-milestone work items: ------------------------- The Working Group will keep two running, often-respun documents: -- implementers guide, collecting clarifying information based on input from implementers, in particular as it becomes available from interoperability events. -- interoperability guide, providing information for interoperability events, such as temporary interoperability testing strategies or information about test harnesses used for interoperability testing. Both documents will be WG documents, but their disposition is not decided at this point (one example for such a document became RFC 4815 after five years of maintenance and 22 revisions). Goals and Milestones: Done - Working group last call on draft-ietf-lowpan-goals-assumptions-xx.txt Done - Submit draft-ietf-lowpan-goals-assumptions-xx.txt to IESG for consideration of publication as Informational Done - Working Group Last Call on draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt Done - Submit draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt to IESG for consideration of publication as Proposed Standard Aug 2008 - Submit Improved Header Compression document to IESG for consideration as a proposed standard Aug 2008 - Submit Security Analysis document to IESG for consideration as an Informational RFC Sep 2008 - Submit Architecture document to IESG for consideration as an Informational RFC Sep 2008 - Submit Routing Requirements document to IESG for consideration as an Informational RFC Nov 2008 - Submit Bootstrapping and ND Optimizations document to IESG to be considered as a Proposed Standard Dec 2008 - Submit Use Case document to IESG as an Informational RFC Internet-Drafts: - Transmission of IPv6 Packets over IEEE 802.15.4 Networks [draft-ietf-6lowpan-format-14] (31 pages) - 6LoWPAN: Overview, Assumptions, Problem Statement and Goals [draft-ietf-6lowpan-problem-09] (13 pages) - Compression Format for IPv6 Datagrams in Low Power and Lossy Networks (6LoWPAN) [draft-ietf-6lowpan-hc-16] (25 pages) - Design and Application Spaces for 6LoWPANs [draft-ietf-6lowpan-usecases-10] (33 pages) - Design Considerations for Session Initiation Protocol (SIP) Overload Control [draft-ietf-sipping-overload-design-04] (21 pages) - Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN) [draft-ietf-6lowpan-nd-18] (59 pages) - Problem Statement and Requirements for 6LoWPAN Routing [draft-ietf-6lowpan-routing-requirements-10] (35 pages) - Transmission of IPv6 Packets over Bluetooth Low Energy [draft-ietf-6lowpan-btle-05] (13 pages) Requests for Comments: RFC4919: IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals (13 pages) RFC4944: Transmission of IPv6 Packets over IEEE 802.15.4 Networks (31 pages) * Updated by RFC6282 RFC6282: Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks (24 pages) * Updates RFC4944 Internet Area Working Group (intarea) ------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Julien Laganier Suresh Krishnan Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: int-area@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/int-area Archive: http://www.ietf.org/mail-archive/web/int-area/current/maillist.html Description of Working Group: The Internet Area Working Group (INTAREA WG) acts primarily as a forum for discussing far-ranging topics that affect the entire area. Such topics include, for instance, address space issues, basic IP layer functionality, and architectural questions. The group also serves as a forum to distribute information about ongoing activities in the area, create a shared understanding of the challenges and goals for the area, and to enable coordination. The Internet Area receives occasional proposals for the development and publication of RFCs that are not in scope of an existing working group and do not justify the formation of a new working group. The INTAREA WG has a secondary role to serve as the forum for developing such work items in the IETF. The working group milestones are updated as needed to reflect the current work items and their associated milestones. New work must satisfy the following conditions: (1) WG consensus on the relevance for the Internet at large. (2) WG consensus on the suitability and projected quality of the proposed work item. (3) A core group of WG participants with sufficient energy and expertise to advance the work item according to the proposed schedule. (4) Commitment from the WG as a whole to provide sufficient and timely review of the proposed work item. (5) Agreement by the ADs, who, depending on the scope of the proposed work item, may decide that an IESG review is needed first. Goals and Milestones: May 2010 - Submission of IPID document to the IESG as PS Aug 2010 - Submission of tunneling issues document to the IESG as Info Aug 2010 - Submission of tunneling security issues document to the IESG as Info Internet-Drafts: - Tunnels in the Internet Architecture [draft-ietf-intarea-tunnels-00] (22 pages) - IP Router Alert Considerations and Usage [draft-ietf-intarea-router-alert-considerations-11] (24 pages) - Updated Specification of the IPv4 ID Field [draft-ietf-intarea-ipv4-id-update-04] (16 pages) - Issues with IP Address Sharing [draft-ietf-intarea-shared-addressing-issues-06] (29 pages) - Logging recommendations for Internet facing servers [draft-ietf-intarea-server-logging-recommendations-05] (6 pages) - IPv6 Support Required for all IP-capable Nodes [draft-ietf-intarea-ipv6-required-02] (7 pages) Requests for Comments: RFC6269: Issues with IP Address Sharing (29 pages) RFC6302: Logging Recommendations for Internet-Facing Servers (5 pages) RFC6398: IP Router Alert Considerations and Usage (19 pages) * Updates RFC2113 * Updates RFC2711 Layer Two Tunneling Protocol Extensions (l2tpext) ------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Ignacio Goyret Carlos Pignataro Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman 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 Mar 2008 - Submit Internet-Draft of PPP over L2TPv3 to IESG 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 Light-Weight Implementation Guidance (lwig) ------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Zhen Cao Robert Cragie Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman Internet Area Advisor: Jari Arkko Tech Advisor: Lars Eggert Mailing Lists: General Discussion: lwip@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lwip Archive: http://www.ietf.org/mail-archive/web/lwip Description of Working Group: Communications technology is being embedded into our environment. Different types of devices in our buildings, vehicles, equipment and other objects have a need to communicate. It is expected that most of these devices will employ the Internet Protocol suite. However, there is a lot of variation in the capabilities between different types of devices, and it is not always easy to embed all the necessary features. The Light-Weight Implementation Guidance (LWIG) Working Group focuses on helping the implementors of the smallest devices. The goal is to be able to build minimal yet interoperable IP-capable devices for the most constrained environments. Building a small implementation does not have to be hard. Many small devices use stripped down versions of general purpose operating systems and their TCP/IP stacks. However, there are implementations that go even further in minimization and can exist in as few as a couple of kilobytes of code, as on some devices this level of optimization is necessary. Technical and cost considerations may limit the computing power, battery capacity, available memory, or communications bandwidth that can be provided. To overcome these limitations the implementors have to employ the right hardware and software mechanisms. For instance, certain types of memory management or even fixed memory allocation may be required. It is also useful to understand what is necessary from the point of view of the communications protocols and the application employing them. For instance, a device that only acts as a client or only requires one connection can simplify its TCP implementation. The purpose of the LWIG working group is to collect experiences from implementors of IP stacks in constrained devices. The group shall focus only on techniques that have been used in actual implementations and do not impact interoperability with other devices. The techniques shall also not affect conformance to the relevant specifications. The output of this work is a document that describes implementation techniques for reducing complexity, memory footprint, or power usage. The topics for this working group will be chosen from these protocols: IPv4, IPv6, UDP, TCP, ICMPv4/v6, MLD/IGMP, ND, DNS, DHCPv4/v6, IPsec, 6LOWPAN, COAP, RPL, SNMP and NETCONF protocols. This document will be helpful for the implementors of new devices or for the implementors of new general-purpose small IP stacks. It is also expected that the document increases our knowledge of what existing small implementations do, and helps in the further optimization of the existing implementations. On areas where the considerations for small implementations have already been documented the group shall make an effort to refer to those documents instead of developing its own. Generic hardware design advice and software implementation techniques are outside the scope of this work, as such expertise is not within the IETF domain. Protocol implementation experience, however, is within the IETF domain. The group shall also not develop any new protocols or protocol behavior modifications beyond what is already allowed by existing RFCs, because it is important to ensure that different types of devices can work together. The group shall not develop assumptions or profiles about the operating environment of the devices, because, in general, it is not possible to guarantee any special configuration. Finally, while implementation techniques relating to security mechanisms are within scope, mere removal of security functionality from a protocol is not an acceptable recommendation. Given that the group works on both IP and transport layer protocols it is necessary to ensure that expertise in both aspects is present in the group. Participation from the implementors of existing small IP stacks is also required. Goals and Milestones: Feb 2011 - Design team of experts and a document editor recruited Aug 2011 - First version of the implementation guidance document submitted Mar 2012 - Submit the implementation guidance document to the IESG for publication as an Informational RFC Internet-Drafts: No Requests for Comments Locator/ID Separation Protocol (lisp) ------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Joel Halpern Terry Manderson Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman Internet Area Advisor: Jari Arkko Secretaries: Wassim Haddad Luigi Iannone 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 Network Element Deployment Considerations [draft-ietf-lisp-deployment-02] (22 pages) - LISP for Multicast Environments [draft-ietf-lisp-multicast-13] (40 pages) - Locator/ID Separation Protocol (LISP) [draft-ietf-lisp-21] (97 pages) - Interworking LISP with IPv4 and IPv6 [draft-ietf-lisp-interworking-02] (24 pages) - LISP Alternative Topology (LISP+ALT) [draft-ietf-lisp-alt-10] (30 pages) - LISP Map Server Interface [draft-ietf-lisp-ms-15] (16 pages) - LISP Internet Groper (LIG) [draft-ietf-lisp-lig-06] (19 pages) - LISP Map-Versioning [draft-ietf-lisp-map-versioning-07] (23 pages) - LISP MIB [draft-ietf-lisp-mib-03] (54 pages) - LISP-Security (LISP-SEC) [draft-ietf-lisp-sec-01] (20 pages) - LISP EID Block [draft-ietf-lisp-eid-block-01] (10 pages) - LISP Threats Analysis [draft-ietf-lisp-threats-01] (29 pages) No Requests for Comments Mobility for IPv4 (mip4) ------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Henrik Levkowetz Pete McCann Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman 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-11] (105 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-06] (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-16] (37 pages) - Dynamic Prefix Allocation for NEMOv4 [draft-ietf-mip4-nemov4-dynamic-05] (11 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-02] (14 pages) - Flow Binding Support for Mobile IPv4 [draft-ietf-mip4-multiple-tunnel-support-02] (26 pages) - GRE Key Extension for Mobile IPv4 [draft-ietf-mip4-gre-key-extension-06] (10 pages) - Home Agent assisted Route Optimization between Mobile IPv4 Networks [draft-ietf-mip4-nemo-haaro-07] (52 pages) - IPv4 Mobility Extension for Multicast and Broadcast Packets [draft-ietf-mip4-mcbc-01] (12 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) RFC5944: IP Mobility Support for IPv4, revised (100 pages) * Obsoletes RFC3344 RFC6245: Generic Routing Encapsulation (GRE) Key Extension for Mobile IPv4 (8 pages) Multicast Mobility (multimob) ----------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Behcet Sarikaya Stig Venaas Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman 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. The group will work on extensions of Proxy Mobile IPv6 to improve its capability to handle multicast efficiently. Work requiring modifications to IGMPv3/MLDv2 is out of scope in this stage of this working group, however, as are modifications to multicast routing protocols. Specific goals for the group are: - A solution to the tunnel convergence problem by separating multicast routing from a mobility anchor. Possible techniques are using native infrastructure, using a dedicated mobility anchor etc. - Mechanisms to optimize multicast traffic during a handover. Such mechanisms may include context transfer functionality. - Mechanisms needed to support multicast source mobility. Both any source multicast and source specific multicast source mobility will be covered. - Document the configuration of IGMPv3/MLDv2 in mobile environments The group shall primarily focus on Proxy Mobile IPv6 (PMIPv6) based networks when looking at the first three items. It is possible but not required that the solutions are applicable also for Mobile IPv6 (MIPv6) based networks. For background, the 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 working group has already documented how existing mechanisms can be used to support multicast, without requiring any additions or changes to message types and parameters specified in RFC 5213, and assuming an unmodified mobile host. The current goals of the working group relate to improving the efficiency of this base solution. 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). In performing its work, the working group will work closely with both the mobility community (NETEXT WG) 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 IGMPv3/MLDv2 to support better operation in mobile environments. Goals and Milestones: Nov 2010 - Initial version of a document on how to tune IGMPv3/MLDv2 for mobility Apr 2011 - Submit a document on how to tune IGMPv3/MLDv2 for mobility, for publication as either Informational or Best Current Practice Jun 2011 - Initial version of document on PMIPv6 routing optimizations to avoid tunnel convergence problem Nov 2011 - Initial version of document on PMIPv6 multicast source mobility solution Nov 2011 - Initial version of document on PMIPv6 handover optimizations Jun 2012 - Submit PMIPv6 routing optimizations document to IESG for publication as Internet Standard Nov 2012 - Submit PMIPv6 handover optimizations document to IESG for publication as Internet Standard Nov 2012 - Submit PMIPv6 multicast source mobility solution to IESG for publication as Internet Standard Dec 2012 - Decision to include additional optimization work involving extensions to IGMPv3 or MLDv2 Dec 2012 - Recharter based on the above decisions (or close the group if no new work is needed) Internet-Drafts: - Base Deployment for Multicast Listener Support in PMIPv6 Domains [draft-ietf-multimob-pmipv6-base-solution-08] (21 pages) - Tuning the Behavior of IGMP and MLD for Routers in Mobile and Wireless Networks [draft-ietf-multimob-igmp-mld-tuning-03] (13 pages) - Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains [draft-ietf-multimob-pmipv6-source-00] (17 pages) Requests for Comments: RFC6224: Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains (19 pages) Multiple Interfaces (mif) ------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Margaret Wasserman Hui Deng Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman 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. After completing some of its initial goals in 2010 the group is also developing three specific extensions: 1) DNS server selection solution: a specification for describing a way for a network to communicate to nodes information required to perform advanced DNS server selection at name resolution request granularity in scenarios involving multiple namespaces. The specification shall describe the information to be delivered for nodes and the protocol to be used for delivery. 2) DHCPv6 routing configuration: DHCPv6 routing configuration: a specification of DHCPv6 options allowing to provision client nodes with small amount of static routing information (e.g. regarding first-hop selection). This is an additional mechanism to the one already defined in RFC 4191 to enable per-host configuration in a managed network environment. The development of dynamic routing capabilities or ability to send more than a few specific routes are explicitly outside the scope of work in this working group, and require the use of either existing or new routing protocols. 3) MIF API: While no changes are needed for applications to run on multiple interface hosts, a new API could provide additional services to applications running on hosts attached to multiple provisioning domains. For instance, these services could assist advanced applications in having greater control over first-hop, source address and/or DNS selection issues. This API will be defined as an abstract interface specification, i.e., specific details about mapping to operating system primitives or programming language will be left out. Network discovery and selection on lower layers as defined by RFC 5113 is out of scope. With the exception of support for additional DHCP options in DHCP servers, 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. Future work in this area requires rechartering the working group 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 Done - Initial draft on analysis of existing practices adopted by the WG Done - Problem statement draft submitted to the IESG for publication as an Informational RFC Done - Existing practices draft submitted to the IESG for publication as an Informational RFC Dec 2010 - Initial WG draft on DHCPv6 option for routing configuration Jan 2011 - Analysis draft submitted to the IESG for publication as an Informational RFC Jan 2011 - Initial WG draft on advanced DNS server selection solution Jan 2011 - Initial WG draft on MIF API extension Mar 2011 - Submit MIF API extension solution to IESG for publication as an Informational RFC Jun 2011 - Submit DHCPv6 routing configuration option to IESG for publication as a Proposed Standard RFC Nov 2011 - Submit advanced DNS server selection solution to IESG for publication as a Proposed Standard RFC Internet-Drafts: - Multiple Interfaces and Provisioning Domains Problem Statement [draft-ietf-mif-problem-statement-16] (20 pages) - Current Practices for Multiple Interface Hosts [draft-ietf-mif-current-practices-13] (22 pages) - DHCPv6 Route Options [draft-ietf-mif-dhcpv6-route-option-03] (14 pages) - Improved DNS Server Selection for Multi-Interfaced Nodes [draft-ietf-mif-dns-server-selection-07] (26 pages) Requests for Comments: RFC6418: Multiple Interfaces and Provisioning Domains Problem Statement (22 pages) RFC6419: Current Practices for Multiple-Interface Hosts (21 pages) Network Time Protocol (ntp) --------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Karen O'Donoghue Brian Haberman Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion: ntpwg@lists.ntp.org To Subscribe: https://lists.ntp.org/listinfo/ntpwg Archive: http://lists.ntp.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-14] (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-08] (27 pages) - Network Time Protocol Version 4 Autokey Specification [draft-ietf-ntp-autokey-09] (54 pages) - Network Time Protocol (NTP) Server Option for DHCPv6 [draft-ietf-ntp-dhcpv6-ntp-opt-07] (10 pages) Requests for Comments: RFC5905: Network Time Protocol Version 4: Protocol and Algorithms Specification (110 pages) * Obsoletes RFC1305 * Obsoletes RFC4330 RFC5906: Network Time Protocol Version 4: Autokey Specification (58 pages) RFC5907: Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4) (26 pages) RFC5908: Network Time Protocol (NTP) Server Option for DHCPv6 (9 pages) Network-Based Mobility Extensions (netext) ------------------------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Basavaraj Patil Rajeev Koodli Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman 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: - Localized Routing for Proxy Mobile IPv6 [draft-ietf-netext-pmip-lr-08] (26 pages) - PMIPv6 Localized Routing Problem Statement [draft-ietf-netext-pmip6-lr-ps-07] (19 pages) - Bulk Binding Update Support for Proxy Mobile IPv6 [draft-ietf-netext-bulk-re-registration-10] (23 pages) - Runtime LMA Assignment Support for Proxy Mobile IPv6 [draft-ietf-netext-redirect-12] (22 pages) - Logical Interface Support for multi-mode IP Hosts [draft-ietf-netext-logical-interface-support-04] (25 pages) - A central policy controlling based PMIPv6 Solutions [draft-ietf-netext-pmip6-cpc-01] (19 pages) - RADIUS Support for Proxy Mobile IPv6 [draft-ietf-netext-radius-pmip6-08] (37 pages) - Prefix Delegation for Proxy Mobile IPv6 [draft-ietf-netext-pd-pmip-01] (13 pages) - IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6 [draft-ietf-netext-pmipv6-sipto-option-03] (12 pages) - Access Network Identifier (ANI) Option for Proxy Mobile IPv6 [draft-ietf-netext-access-network-option-05] (16 pages) - Proxy Mobile IPv6 Extensions to Support Flow Mobility [draft-ietf-netext-pmipv6-flowmob-02] (20 pages) Requests for Comments: RFC6279: Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement (14 pages) Point-to-Point Protocol Extensions (pppext) ------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chair: Donald Eastlake 3rd Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman Internet Area Advisor: Jari Arkko Tech Advisor: James Carlson 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-04] (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) 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) RFC3079: Derivating Keys for use with Microsoft Point-to-Point Encryption (MPPE) (20 pages) Port Control Protocol (pcp) --------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Dave Thaler Alain Durand Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: pcp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/pcp Archive: http://www.ietf.org/mail-archive/web/pcp/current/maillist.html Description of Working Group: Middleboxes such as NATs and firewalls have seen significant deployment in residential and enterprise networks for years. Applications have adapted to such environments. A first family of solutions involves some form of static configuration on the middlebox to perform port opening and/or port forwarding. Another family of solutions works indirectly, using external services to help the establishment of connections and work around the NAT. STUN (RFC 5389) and TURN (RFC 5766) are examples of such solutions. A third family of solutions include protocols that work directly with the middlebox to dynamically open up ports. Universal Plug and Play Internet Gateway Device (UPnP-IGD) and NAT Port Mapping Protocol (NAT-PMP) are examples of such solutions. IPv4 address exhaustion is now forcing ISPs to deploy carrier-grade NAT devices in their network. Those devices could operate either in addition to or instead of an existing NAT device. An example of the former case is a double NAT configuration and an example of the latter case is the application of Dual Stack Lite (DS-Lite) in a network. These deployments will break a fundamental assumption made by protocols, such UPnP or NAT-PMP, that the NAT is located on the same link as the host running the client application. As a result, such applications may break in the presence of a carrier grade NAT. The PCP working group is chartered to standardize a client/server Port Control Protocol (PCP) to enable an explicit dialog with a middlebox such as a NAT or a firewall to open up and/or forward TCP or UDP port, regardless of the location of that middlebox. A PCP client can be used by applications to directly dialog with the middlebox running a PCP server. It can also be used by a home gateways on behalf of applications. This eases the deployment of PCP in situations where applications have already changed to support the APIs necessary for communicating with UPnP-IGD or NAT-PMP. Those applications only work today when the home gateway gets a public address, but may no longer work in situations where the gateway is behind another NAT. Home gateways could use PCP to translate and relay those UPnP and NAP-PMP messages to the PCP server, thus allowing such applications to continue working as they do today. The functionality that enables the control of IPv4 middleboxes such as NAT devices or firewalls can also be useful in IPv6 context, to control IPv6 functionality in firewalls. As such, PCP will be defined for both IPv4 and IPv6. The discovery PCP servers, using classic methods such as DHCP options, is in scope for the PCP working group. The working group will also ensure that the protocol has the necessary security mechanisms. The IETF will make no changes to either NAT-PMP or UPnP-IGP protocols, and they will be used only as is. Deliverables: - PCP protocol description and terminology document - PCP service discovery document - PCP relay of UPnP document - PCP relay of NAT-PMP document Goals and Milestones: Oct 2010 - First WG draft on PCP protocol description Dec 2010 - First WG draft on PCP service discovery Feb 2011 - First WG draft on UPnP relay Feb 2011 - First WG draft on NAT-PMP relay May 2011 - Send PCP protocol description to IESG for publication as Proposed Standard May 2011 - Send PCP service discovery to IESG for publication as Proposed Standard Oct 2011 - Send UPnP relay to IESG for publication as Proposed Standard Oct 2011 - Send NAT-PMP relay to IESG for publication as Proposed Standard Internet-Drafts: - Port Control Protocol (PCP) [draft-ietf-pcp-base-22] (92 pages) - DHCP Options for the Port Control Protocol (PCP) [draft-ietf-pcp-dhcp-02] (11 pages) - Universal Plug and Play (UPnP) Internet Gateway Device (IGD)-Port Control Protocol (PCP) Interworking Function [draft-ietf-pcp-upnp-igd-interworking-00] (25 pages) No Requests for Comments Softwires (softwire) -------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Alain Durand Yong Cui Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman 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 Softwires Problem Statement, RFC 4925, identifies two distinct topological scenarios that the Working Group will provide solutions for: "Hubs and Spokes" and "Mesh." In the former case (Hubs and Spokes), 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 Softwires Working Group will reuse existing technologies as much as possible and only when necessary, create additional protocol building blocks. For generality, all base softwires 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/IPv6 translation mechanisms, new addressing schemes, and block address assignments are out of scope. DHCP options developed in this working group will be reviewed jointly with the DHC Working Group. RADIUS attributes developed in the Softwires Working Group will be reviewed jointly with the RADEXT Working Group. The MIB Doctors directorate will be asked to review any MIB modules developed in the Softwires Working Group. 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). The specific work areas for this working group are: 1. Developments for Mesh softwires topology; the Mesh topology work will be reviewed in the L3VPN and IDR Working Groups - multicast - MIB module 2. Developments for 6rd: - multicast - operational specification - RADIUS attribute for 6rd server - MIB module - Gateway-initiated 6rd (GI-6rd) 3. Developments for Dual-Stack Lite (DS-Lite): - multicast - operational specification - RADIUS attribute for AFTR - proxy extensions; GI-DS-Lite; No NAT on AFTR - MIB module 4. Developments for stateless legacy IPv4 carried over IPv6 - develop a solution motivation document to be published as an RFC - develop a protocol specification response to the solution motivation document; this work item will not be taken through Working Group last call until the solution motivation document has been published or approved for publication 5. Finalize discovery and configuration mechanisms for a gateway to use DS-Lite or 6rd; these discovery and configuration mechanisms must take into a account other operating environments such as dual-stack and tunneling mechanisms not defined by the Softwires Working Group. Development of new mechanisms will involve the DHC and/or V6OPS Working Groups as appropriate Other work items would require Working Group approval and rechartering. Goals and Milestones: Done - Submit a problem statement to the IESG to be considered as an Informational RFC Jun 2011 - Submit DS-lite RADIUS attribute document for Proposed Standard Jun 2011 - Adopt DS-lite operational document as a Working Group document Jul 2011 - Submit 6rd RADIUS attribute document for Proposed Standard Jul 2011 - Submit GI DS-lite document for Proposed Standard Jul 2011 - Adopt DS-Lite without NAT document as a Working Group document Jul 2011 - Adopt DHCPv4 over tunnel document as a Working Group document Aug 2011 - Adopt 6rd operational document as a Working Group document Aug 2011 - Adopt Multicast extensions document as a Working Group document Aug 2011 - Submit DS-lite operational document for Informational Aug 2011 - Adopt stateless legacy IPv4 solution motivation document as a Working Group document Sep 2011 - Submit DS-Lite without NAT document for Informational Sep 2011 - Submit DHCPv4 over tunnel document for Proposed Standard Nov 2011 - Submit Multicast extensions document for Informational Nov 2011 - Submit 6rd operational document for Informational Nov 2011 - Adopt 6rd MIB module document as a Working Group document Nov 2011 - Adopt DS-lite MIB module document as a Working Group document Nov 2011 - Adopt Mesh topology MIB module document as a Working Group document Dec 2011 - Submit stateless legacy IPv4 solution motivation document for Informational Dec 2011 - Adopt stateless legacy IPv4 specification document as a Working Group document Apr 2012 - Submit stateless legacy IPv4 specification document for Proposed Standard Nov 2012 - Submit 6rd MIB module document for Proposed Standard Nov 2012 - Submit DS-lite MIB module document for Proposed Standard Nov 2012 - Submit Mesh topology MIB module document for 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 Following IPv4 Exhaustion [draft-ietf-softwire-dual-stack-lite-12] (33 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 Rapid Deployment on IPv4 Infrastructures (6rd) [draft-ietf-softwire-ipv6-6rd-11] (19 pages) - Gateway Initiated Dual-Stack Lite Deployment [draft-ietf-softwire-gateway-init-ds-lite-06] (15 pages) - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite [draft-ietf-softwire-ds-lite-tunnel-option-11] (8 pages) - RADIUS Extensions for Dual-Stack Lite [draft-ietf-softwire-dslite-radius-ext-07] (12 pages) - RADIUS Attribute for 6rd [draft-ietf-softwire-6rd-radius-attrib-04] (10 pages) - Softwire Mesh Multicast [draft-ietf-softwire-mesh-multicast-01] (23 pages) - Public IPv4 over Access IPv6 Network [draft-ietf-softwire-public-4over6-00] (13 pages) - Motivations for Stateless IPv4 over IPv6 Migration Solutions [draft-ietf-softwire-stateless-4v6-motivation-00] (16 pages) - Multicast Extensions to DS-Lite Technique in Broadband Deployments [draft-ietf-softwire-dslite-multicast-01] (18 pages) - Deployment Considerations for Dual-Stack Lite [draft-ietf-softwire-dslite-deployment-01] (14 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) RFC5969: IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification (18 pages) RFC6333: Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion (32 pages) RFC6334: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite (7 pages) Source Address Validation Improvements (savi) --------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Christian Vogt Jean-Michel Combes Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman 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 Apr 2011 - First WG draft on mix scenario solution Jul 2011 - Submit mix scenario solution to IESG for Proposed Standard Internet-Drafts: - SAVI Threat Scope [draft-ietf-savi-threat-scope-05] (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 IPv6 Addresses [draft-ietf-savi-fcfs-12] (32 pages) - SEND-based Source-Address Validation Implementation [draft-ietf-savi-send-06] (29 pages) - SAVI Solution for DHCP [draft-ietf-savi-dhcp-11] (26 pages) - Source Address Validation Improvement Framework [draft-ietf-savi-framework-06] (15 pages) - SAVI for Mixed Address Assignment Methods Scenario [draft-ietf-savi-mix-01] (8 pages) No Requests for Comments Timing over IP Connection and Transfer of Clock (tictoc) -------------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Karen O'Donoghue Yaakov Stein Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman 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-02] (32 pages) - Transporting PTP messages (1588) over MPLS Networks [draft-ietf-tictoc-1588overmpls-02] (34 pages) - Precision Time Protocol Version 2 (PTPv2) Management Information Base [draft-ietf-tictoc-ptp-mib-01] (66 pages) - TICTOC Security Requirements [draft-ietf-tictoc-security-requirements-00] (15 pages) No Requests for Comments Transparent Interconnection of Lots of Links (trill) ---------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Erik Nordmark Donald Eastlake 3rd Internet Area Directors: Ralph Droms Jari Arkko Brian Haberman 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 has specified 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 and encapsulation with a hop count. The current work of the working group is around operational and deployment support for the protocol. This includes a MIB module and other pieces needed for operations, but also additional ways to extend and optimize TRILL for the properties of the networks on which it is deployed. The WG will work on the following items: (1) A MIB module for TRILL which specifies the unique pieces needed for the protocol while reusing what is in the IS-IS MIB module and the IEEE 802.1 MIB modules for pieces that are not unique to TRILL (draft-ietf-trill-rbridge-mib). (2) Development, within the TRILL protocol context, of requirements and specifications for broadcast/multicast (multi-destination) frame reduction; e.g., ARP/ND (Neighbor Discovery) reduction through use of the TRILL ESADI protocol. (3) Refinement of TRILL Header Options, as initially defined in draft-ietf-trill-rbridge-protocol and specification of an initial base set of options (draft-ietf-trill-rbridge-options). (4) Provide documentation for the handling of Operations, Administration, and Maintenance (OAM) in networks using TRILL. Any documentation will take into consideration any existing OAM mechanisms that might apply to TRILL. (5) Publish an implementation report for TRILL. (6) Analyze use of IS-IS security in TRILL and determine if any work is needed to accommodate the specific application of IS-IS security in TRILL forwarding. (7) Publish a description of the adjacency state machine in TRILL (draft-ietf-trill-adj). The trill WG will continue to work with other IETF working groups such as the isis WG, and SDO groups such as IEEE 802.1 through established inter-WG relationships and SDO liaison processes, including early and WG last call review by the isis WG of documents modifying the IS-IS protocol. The trill WG will have a Routing Area Advisor for advice on the IS-IS protocol and liaison with the isis WG. 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 Done - Submit base protocol specification to IEEE/IETF expert review Done - Base protocol specification submitted to the IESG for publication as a Proposed Standard RFC Done - First draft showing what is needed for MIB Done - Initial WG draft on VLAN Mapping (draft-ietf-trill-rbridge-vlan-mapping) Done - Initial WG draft TRILL Header Options (draft-ietf-trill-rbridge-options) Done - Initial WG draft on RBridge MIB module (draft-ietf-trill-rbridge-mib) Done - Initial WG draft on trill adjacency state machine (draft-ietf-trill-adj) Done - Submit trill adjacency state machine to IESG for publication as Proposed Standard (draft-ietf-trill-adj) Done - Submit RBridge MIB module to IESG for publication as Proposed Standard (draft-ietf-trill-rbridge-mib) Mar 2011 - Submit TRILL Header Options to IESG for publication as Proposed Standard (draft-ietf-trill-rbridge-options) Mar 2011 - Initial WG draft on ARP/ND optimizations Mar 2011 - Initial WG draft on RBridge OAM (draft-bond-trill-rbridge-oam) May 2011 - Submit TRILL ARP/ND optimizations to IESG for publication as Proposed Standard Jun 2011 - Submit RBridge support of Data Center Bridging to IESG for publication as Proposed Standard (draft-eastlake-trill-rbridge-dcb) Jul 2011 - Submit RBridge OAM to IESG for publication as Proposed Standard Jul 2012 - 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-17] (117 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) - RBridges: Campus VLAN and Priority Regions [draft-ietf-trill-rbridge-vlan-mapping-06] (18 pages) - RBridges: Further TRILL Header Extensions [draft-ietf-trill-rbridge-options-06] (19 pages) - Definitions of Managed Objects for RBridges (Routing Bridges) [draft-ietf-trill-rbridge-mib-06] (56 pages) - RBridges: Adjacency [draft-ietf-trill-adj-08] (32 pages) - RBridges: Appointed Forwarders [draft-ietf-trill-rbridge-af-06] (23 pages) - TRILL: RBridge Channel Support [draft-ietf-trill-rbridge-channel-04] (25 pages) - Rbridges: Bidirectional Forwarding Detection (BFD) support for TRILL [draft-ietf-trill-rbridge-bfd-02] (10 pages) - Routing Bridges (RBridges): Operations, Administration, and Maintenance (OAM) Support [draft-ietf-trill-rbridge-oam-01] (31 pages) - TRILL: Header Extension [draft-ietf-trill-rbridge-extension-02] (16 pages) - TRILL: Fine-Grained Labeling [draft-ietf-trill-fine-labeling-00] (20 pages) - TRILL: Clarifications, Corrections, and Updates [draft-ietf-trill-clear-correct-00] (28 pages) Requests for Comments: RFC5556: Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement (17 pages) RFC6325: Routing Bridges (RBridges): Base Protocol Specification (99 pages) * Updated by RFC6327 * Updated by RFC6439 RFC6327: Routing Bridges (RBridges): Adjacency (26 pages) * Updates RFC6325 RFC6439: Routing Bridges (RBridges): Appointed Forwarders (15 pages) * Updates RFC6325 ADSL MIB (adslmib) ------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chair: Menachem Dodge Operations and Management Area Directors: Dan Romascanu Ronald Bonica Benoit Claise Operations and Management Area Advisor: Dan Romascanu Editors: Scott Baillie Edward Beili Moti Morgenstern Umberto Bonollo Mailing Lists: General Discussion: adslmib@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/adslmib Archive: http://www.ietf.org/mail-archive/web/adslmib/current/maillist.html Description of Working Group: The working group will define: 1. A set of managed objects to handle the bonding of xDSL lines according to the ITU-T Recommendations G.998.1 (ATM), G.998.2 (Ethernet) and G.998.3 (TDIM). A common MIB module will be developed to handle the common objects and three specific MIB modules will be developed to handle the three separate layer-2 technologies. Use will be made of the ifStack and ifInvStack Tables defined in RFC 2863 and RFC 2864 respectively. Use will also be made of the ifCapStack and ifInvCapStack tables as defined in RFC 5066. The Broadband forum TR-159 will be used in the definition of these MIBs. 2. The working group will develop a set of managed objects as an optional extension to RFC 5650 that shall provide an alternative approach, known as the "Vector of Profiles", for the configuration of DSL lines. The Vector of Profiles MIB will be based on the Broadband Forum TR-165 document. The ITU-T G.997.1 will also be considered in the definition of this extension. The MIB modules defined by this group will be generated using SMIv2, will be consistent with the SNMP management framework, and will describe the relationship of the objects defined to existing MIBs such as those described in other work products of this Working Group, the interfaces MIB, the Ethernet MIB modules and the AToM MIB. Goals and Milestones: Done - Submit Internet-Draft to cover subscriber equipment Done - Meet at Chicago IETF to review Internet-Drafts Done - Submit Internet-Draft to IESG for consideration as Proposed Standard. Done - Meet at Oslo IETF to review new Internet-Drafts and discuss implementation experience on initial MIB Done - Submit supplementary Internet-Draft to IESG for consideration as Proposed Standard. Done - Produce Internet-Draft covering HDSL2 management objects. Done - Submit updated HDSL2/SHDSL Internet-Draft Done - Complete WG last call for HDSL2/SHDSL management objects Done - Collect implementation reports for ADSL MIB Done - Submit HDSL2/SHDSL MIB to IESG for consideration as Proposed Standard Done - Submit initial Internet-Draft VDSL MIB Done - Complete WG last call on VDSL MIB Done - Submit updated VDSL MIB Internet-Draft Done - Submit final VDSL MIB Internet-Draft Done - Submit VDSL MIB to IESG for consideration as Proposed Standard Done - New WG I-Ds for the LCS MCM and SCM MIB modules Done - Initial WG Internet-Draft covering ADSL2 management objects Done - Integrate working group changes and produce revised draft Done - Complete WG last call on ADSL2 MIB Done - Submit ADSL2 MIB to IESG for consideration as Proposed Standard Done - Re-charter or close down Done - Initial WG Internet-Draft covering VDSL2 management objects Done - Inform the ITU-T and DSL Forum that work on the VDSL2 MIB has begun Done - Integrate working group changes and produce revised VDSL2 MIB draft Done - Post Initial Drafts of all the xDsl Bonding MIB drafts Done - Post Vdsl2 draft version 03 Done - Post Vdsl2 draft version 04. Done - Complete Thorough Working Group Reviews of the Vdsl2 draft and produce version 05. Done - Working Group Last Call for the Vdsl2 document. Done - Early MIB Doctor Reviews of the Vdsl2 draft. Done - Make Correction to the draft following the review. Done - Working Group Last Call for the Vdsl2 document following corrections. Done - Present the Vdsl2 document to the IESG. Feb 2010 - Submit updated ATM and Ethernet G.Bond MIB drafts. Mar 2010 - Initial Vector of Profiles draft to be accepted by the Working Group. Apr 2010 - Submit G.Bond MIB and TDIM MIB Drafts Apr 2010 - Submit Vector of Profiles Draft version 01 May 2010 - Working Group Last Call on all the G. Bond documents. Jun 2010 - Submit G.Bond documents to IESG as Proposed Standard Jun 2010 - Revise the draft and post vector of Profiles draft version 02. Jul 2010 - Working Group Last Call for the Vector of Profiles draft. Aug 2010 - Post Vector of Profiles Draft version 03. Sep 2010 - Submit the Vector Of Profile document to the IESG as Proposed Standard. Oct 2010 - Re-charter or close down. Internet-Drafts: - Definitions of Managed Objects for the ADSL Lines [draft-ietf-adslmib-adsllinemib-10] (113 pages) - Definitions of Extension Managed Objects for Asymmetric Digital Subscriber Lines [draft-ietf-adslmib-adslext-12] (36 pages) - Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2) [draft-ietf-adslmib-vdsl2-08] (215 pages) - Definitions of Managed Objects for HDSL2 and SHDSL Lines [draft-ietf-adslmib-hdsl2-12] (61 pages) - Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL) [draft-ietf-adslmib-vdsl-13] (68 pages) - High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals [draft-ietf-adslmib-hc-tc-08] (10 pages) - Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Single Carrier Modulation (SCM) Line Coding [draft-ietf-adslmib-vdsl-ext-scm-09] (18 pages) - Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding [draft-ietf-adslmib-vdsl-ext-mcm-07] (23 pages) - Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines [draft-ietf-adslmib-gshdslbis-12] (76 pages) - Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2) [draft-ietf-adslmib-adsl2-09] (166 pages) - xDSL multi-pair bonding (G.Bond) MIB [draft-ietf-adslmib-gbond-mib-08] (67 pages) - Ethernet-based xDSL multi-pair bonding (G.Bond/Ethernet) MIB [draft-ietf-adslmib-gbond-eth-mib-04] (51 pages) - xDSL multi-pair bonding using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB [draft-ietf-adslmib-gbond-tdim-mib-06] (52 pages) - ATM-Based xDSL Bonded Interfaces MIB [draft-ietf-adslmib-gbond-atm-mib-05] (33 pages) Requests for Comments: RFC2662: Definitions of Managed Objects for the ADSL Lines (115 pages) RFC3276: Definitions of Managed Objects for HDSL2 and SHDSL Lines (66 pages) * OBSOLETED BY RFC4319 RFC3440: Definitions of Extension Managed Objects for Asymmetric Digital Subscriber Lines (36 pages) RFC3705: High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals (10 pages) RFC3728: Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL) (68 pages) RFC4069: Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Single Carrier Modulation (SCM) Line Coding (18 pages) RFC4070: Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding (23 pages) RFC4319: Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines (76 pages) * Obsoletes RFC3276 RFC4706: Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2) (166 pages) RFC5650: Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2) (215 pages) Address Resolution for Massive numbers of hosts in the Data center (armd) ------------------------------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Linda Dunbar Benson Schliesser Operations and Management Area Directors: Dan Romascanu Ronald Bonica Benoit Claise Operations and Management Area Advisor: Ronald Bonica Mailing Lists: General Discussion: armd@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/armd Archive: http://www.ietf.org/mail-archive/web/armd/ Description of Working Group: Changing workloads in datacenters are having an impact on the performance of current datacenter network designs. For example, the use of virtual machines (VMs) as a means for deployment and management of new services often results in a significant increase in the number of hosts attached to the network. Various requirements for the deployment of VMs in data center networks, such as support for VM mobility, has led to architectures in which broadcast domains are scaling up to span more switching devices and VM servers, and to interconnect more hosts (as represented by VMs). In these deployment architectures, heavily used protocols that are based on broadcast or multicast, such as ARP and ND, may contribute to poor network performance. The armd Working Group will investigate the impact of changing workloads and existing protocols on datacenter network performance. In its work, the armd Working Group will take into consideration work done in data center networking standardization by other SDOs, such as the IEEE 802.1 Data Center Bridging Task Group, and will communicate and exchange information with these organizations. Working Group objectives: (1) Document the current practices in data center network architectures and the scaling characteristics of ARP and ND with respect to large sized layer-2 domains in data centers. (2) Provide operational recommendations intended to minimize issues associated with these architectures and characteristics. Area affiliation of the Working Group: The armd Working Group is assigned to the Operations and Management area, and will maintain close collaboration with the Internet area. Because of its affiliation with Operations and Management, the armd Working Group will focus on documenting current practices and scaling characteristics, and will not do any protocol development or extension work. If the Working Group identifies opportunities for protocol development or extensions, it will first develop requirements for that work. Any protocol development work will be conducted in the appropriate existing Working Groups if such work groups exist. If no such working groups exist, armd may recharter to address the work and may be moved to a different area. Deliverables (Informational RFCs; list to be removed prior to posting): o Problem statement and review of current L2/L3 architectures o Report on ARP/ND statistics collection and behavior analysis in various Data Center environments o Recommendations on data center L2/L3 architectures and identification of opportunities for protocol development work Goals and Milestones: May 2011 - Problem statement Nov 2011 - ARP/ND statistics collection and behavior analysis in various Data Center environments (many subnets with various sizes; subnets with hosts with VMs and VMs migrate over time; subnets with some hosts on local VMs and others on VMs in the cloud (like Amazon's ECS); Large subnet). Nov 2011 - Survey of Existing Implementations Nov 2011 - Survey of Security Mar 2012 - Recommendations to avoid or minimize issues caused by ARP/ND Mar 2012 - Gap Analysis Internet-Drafts: - ARMD Call for Investigation [draft-ietf-armd-call-for-investigation-01] (5 pages) - Problem Statement for ARMD [draft-ietf-armd-problem-statement-00] (11 pages) No Requests for Comments Benchmarking Methodology (bmwg) ------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chair: Al Morton Operations and Management Area Directors: Dan Romascanu Ronald Bonica Benoit Claise Operations and Management Area Advisor: Ronald Bonica Mailing Lists: General Discussion: bmwg@ietf.org To Subscribe: bmwg-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/bmwg/index.html Description of Working Group: The Benchmarking Methodology Working Group (BMWG) will continue to produce a series of recommendations concerning the key performance characteristics of internetworking technologies, or benchmarks for network devices, systems, and services. Taking a view of networking divided into planes, the scope of work includes benchmarks for the management, control, and forwarding planes. Each recommendation will describe the class of equipment, system, or service being addressed; discuss the performance characteristics that are pertinent to that class; clearly identify a set of metrics that aid in the description of those characteristics; specify the methodologies required to collect said metrics; and lastly, present the requirements for the common, unambiguous reporting of benchmarking results. The set of relevant benchmarks will be developed with input from the community of users (e.g, network operators and testing organizations) and from those affected by the benchmarks when they are published (networking and test equipment manufacturers). When possible, the benchmarks and other terminology will be developed jointly with organizations that are willing to share their expertise. Joint review requirements for a specific work area will be included in the detailed description of the task, as listed below. To better distinguish the BMWG from other measurement initiatives in the IETF, the scope of the BMWG is limited to the characterization of implementations of various internetworking technologies using controlled stimuli in a laboratory environment. Said differently, the BMWG does not attempt to produce benchmarks for live, operational networks. Moreover, the benchmarks produced by this WG shall strive to be vendor independent or otherwise have universal applicability to a given technology class. Because the demands of a particular technology may vary from deployment to deployment, a specific non-goal of the Working Group is to define acceptance criteria or performance requirements. An ongoing task is to provide a forum for discussion regarding the advancement of measurements designed to provide insight on the capabilities and operation of inter-networking technology implementations. The BMWG will communicate with the operations community through organizations such as NANOG, RIPE, and APRICOT. In addition to its current work plan, the BMWG is explicitly tasked to develop benchmarks and methodologies for the following technologies: * BGP Control-plane Convergence Methodology (Terminology is complete): With relevant performance characteristics identified, BMWG will prepare a Benchmarking Methodology Document with review from the Routing Area (e.g., the IDR working group and/or the RTG-DIR). The Benchmarking Methodology will be Last-Called in all the groups that previously provided input, including another round of network operator input during the last call. * SIP Networking Devices: Develop new terminology and methods to characterize the key performance aspects of network devices using SIP, including the signaling plane scale and service rates while considering load conditions on both the signaling and media planes. This work will be harmonized with related SIP performance metric definitions prepared by the PMOL working group. * Flow Export and Collection: Develop terminology and methods to characterize network devices flow monitoring, export, and collection. The goal is a methodology to assess the maximum IP flow rate that a network device can sustain without losing any IP flow information or compromising the accuracy of information exported on the IP flows, and to asses the forwarding plane performance (if the forwarding function is present) in the presence of Flow Monitoring. * Data Center Bridging Devices: Some key concepts from BMWG's past work are not meaningful when testing switches that implement new IEEE specifications in the area of data center bridging. For example, throughput as defined in RFC 1242 cannot be measured when testing devices that implement three new IEEE specifications: priority-based flow control (802.1Qbb); priority groups (802.1Qaz); and congestion notification (802.1Qau). Since devices that implement these new congestion-management specifications should never drop frames, and since the metric of throughput distinguishes between non-zero and zero drop rates, no throughput measurement is possible using the existing methodology. The current emphasis is on the Priority Flow Control aspects of Data Center Bridging, and the work will include an investigation into whether TRILL RBridges require any specific treatment in the methodology. This work will update RFC 2544 and exchange periodic Liaisons with IEEE 802.1 DCB Task Group, especially at WG Last Call. * Content Aware Devices: New classes of network devices that operate above the IP layer of the network stack require a new methodology to perform adequate benchmarking. Existing BMWG RFCs (RFC2647 and RFC3511) provides useful measurement and performance statistics, though they may not reflect the actual performance of the device when deployed in production networks. Operating within the limitations of the charter, namely blackbox characterization in laboratory environments, the BMWG will develop a methodology that more closely relates the performance of these devices to performance in an operational setting. In order to confirm or identify key performance characteristics, BMWG will solicit input from operations groups such as NANOG, RIP and APRICOT. * LDP Dataplane Convergence: In order to identify key LDP convergence performance characteristics, BMWG will solicit input from operations groups such as NANOG, RIP and APRICOT. When relevant performance characteristics have been identified, BMWG will jointly prepare a Benchmarking Terminology Document with the Routing Area (e.g., the MPLS working group and or the RTG-DIR), which would define metrics relevant to LDP convergence. The Benchmark definition document would be Last-Called in all the working groups that produced it, and solicit operator input during the last call. The work will then continue in BMWG to define the test methodology, with input and review from the aforementioned parties. Goals and Milestones: Done - Expand the current Ethernet switch benchmarking methodology draft to define the metrics and methodologies particular to the general class of connectionless, LAN switches. Done - Edit the LAN switch draft to reflect the input from BMWG. Issue a new version of document for comment. If appropriate, ascertain consensus on whether to recommend the draft for consideration as an RFC. Done - Take controversial components of multicast draft to mailing list for discussion. Incorporate changes to draft and reissue appropriately. Done - Submit workplan for initiating work on Benchmarking Methodology for LAN Switching Devices. Done - Submit workplan for continuing work on the Terminology for Cell/Call Benchmarking draft. Done - Submit initial draft of Benchmarking Methodology for LAN Switches. Done - Submit Terminology for IP Multicast Benchmarking draft for AD Review. Done - Submit Benchmarking Terminology for Firewall Performance for AD review Done - Progress ATM benchmarking terminology draft to AD review. Done - Submit Benchmarking Methodology for LAN Switching Devices draft for AD review. Done - Submit first draft of Firewall Benchmarking Methodology. Done - First Draft of Terminology for FIB related Router Performance Benchmarking. Done - First Draft of Router Benchmarking Framework Done - Progress Frame Relay benchmarking terminology draft to AD review. Done - Methodology for ATM Benchmarking for AD review. Done - Terminology for ATM ABR Benchmarking for AD review. Done - Terminology for FIB related Router Performance Benchmarking to AD review. Done - Firewall Benchmarking Methodology to AD Review Done - First Draft of Methodology for FIB related Router Performance Benchmarking. Done - First draft Net Traffic Control Benchmarking Methodology. Done - Methodology for IP Multicast Benchmarking to AD Review. Done - Resource Reservation Benchmarking Terminology to AD Review Done - First I-D on IPsec Device Benchmarking Terminology Done - EGP Convergence Benchmarking Terminology to AD Review Done - Resource Reservation Benchmarking Methodology to AD Review Done - Net Traffic Control Benchmarking Terminology to AD Review Done - IGP/Data-Plane Terminology I-D to AD Review Done - IGP/Data-Plane Methodology and Considerations I-Ds to AD Review Done - Hash and Stuffing I-D to AD Review Done - IPv6 Benchmarking Methodology to AD Review Done - IPsec Device Benchmarking Terminology to IESG Review Done - IPsec Device Benchmarking Methodology to IESG Review Done - Terminology For Protection Benchmarking to AD Review Done - Methodology for MPLS Forwarding to AD Review Done - Networking Device Reset Benchmark (Updates RFC 2544) to IESG Review Dec 2010 - Methodology For Protection Benchmarking to IESG Review Feb 2011 - Methodology for Flow Export and Collection Benchmarking to IESG Review Jun 2011 - Methodology for Data Center Bridging Benchmarking to IESG Review Jun 2011 - Terminology for SIP Device Benchmarking to IESG Review Jun 2011 - Methodology for SIP Device Benchmarking to IESG Review Jul 2011 - Basic BGP Convergence Benchmarking Methodology to IESG Review Dec 2011 - Terminology for Content Aware Device Benchmarking to IESG Review Dec 2011 - Methodology for Content Aware Device Benchmarking to IESG Dec 2011 - Terminology for LDP Convergence Benchmarking to IESG Review Dec 2011 - Methodology for LDP Convergence Benchmarking to IESG Review Internet-Drafts: - Benchmarking Terminology for Network Interconnection Devices [draft-ietf-bmwg-terms-02] (0 pages) - Benchmarking Methodology for Network Interconnect Devices [draft-ietf-bmwg-methodology-03] (23 pages) - Benchmarking Methodologies for Overall Network Performance [draft-ietf-bmwg-overallperf-00] (6 pages) - Benchmarking Methodology for Ethernet Switches [draft-ietf-bmwg-ethernet-switches-01] (13 pages) - Benchmarking Terminology for LAN Switching Devices [draft-ietf-bmwg-lanswitch-07] (25 pages) - Terminology for Cell/Call Benchmarking [draft-ietf-bmwg-call-04] (29 pages) - Connectivity [draft-ietf-bmwg-ippm-connect-00] (9 pages) - Terminology for IP Multicast Benchmarking [draft-ietf-bmwg-mcast-09] (15 pages) - Benchmarking Terminology for Firewall Performance [draft-ietf-bmwg-secperf-09] (23 pages) - Benchmarking Methodology for LAN Switching Devices [draft-ietf-bmwg-mswitch-05] (34 pages) - Terminology for Frame Relay Benchmarking [draft-ietf-bmwg-fr-term-06] (24 pages) - Methodology for IP Multicast Benchmarking [draft-ietf-bmwg-mcastm-15] (31 pages) - Terminology for ATM Benchmarking [draft-ietf-bmwg-atm-term-01] (29 pages) - Methodology for ATM Benchmarking [draft-ietf-bmwg-atm-method-03] (168 pages) - Terminology for ATM ABR Benchmarking [draft-ietf-bmwg-atm-term-abr-03] (18 pages) - Terminology for Forwarding Information Base (FIB) based Router Performance [draft-ietf-bmwg-fib-term-04] (13 pages) - Framework for Router Benchmarking [draft-ietf-bmwg-rtr-framework-00] (8 pages) - Benchmarking Methodology for Firewall Performance [draft-ietf-bmwg-firewall-08] (30 pages) - Terminology for Benchmarking Network-layer Traffic Control Mechanisms [draft-ietf-bmwg-dsmterm-14] (32 pages) - Benchmarking Terminology for Resource Reservation Capable Routers [draft-ietf-bmwg-benchres-term-09] (22 pages) - Benchmarking Methodology for Routers Supporting Resource Reservation [draft-ietf-bmwg-benchres-method-00] (15 pages) - Terminology for Benchmarking BGP Device Convergence in the Control Plane [draft-ietf-bmwg-conterm-07] (35 pages) - Benchmarking Methodology for Basic BGP Convergence [draft-ietf-bmwg-bgpbas-01] (16 pages) - Methodology for Forwarding Information Base (FIB) based Router Performance [draft-ietf-bmwg-fib-meth-03] (13 pages) - OSPF Benchmarking Terminology and Concepts [draft-ietf-bmwg-ospfconv-term-11] (10 pages) - Benchmarking Basic OSPF Single Router Control Plane Convergence [draft-ietf-bmwg-ospfconv-intraarea-11] (16 pages) - Considerations When Using Basic OSPF Convergence Benchmarks [draft-ietf-bmwg-ospfconv-applicability-08] (12 pages) - Terminology for Benchmarking IPsec Devices [draft-ietf-bmwg-ipsec-term-12] (46 pages) - Benchmarking Methodology for Link-State IGP Data Plane Route Convergence [draft-ietf-bmwg-igp-dataplane-conv-meth-24] (43 pages) - Terminology for Benchmarking Link-State IGP Data Plane Route Convergence [draft-ietf-bmwg-igp-dataplane-conv-term-24] (27 pages) - Considerations for Benchmarking Link-State IGP Data Plane Route Convergence [draft-ietf-bmwg-igp-dataplane-conv-app-17] (6 pages) - Terminology for Accelerated Stress Benchmarking [draft-ietf-bmwg-acc-bench-term-13] (27 pages) - Framework for Accelerated Stress Benchmarking [draft-ietf-bmwg-acc-bench-framework-00] (7 pages) - Methodology Guidelines for Accelerated Stress Benchmarking [draft-ietf-bmwg-acc-bench-meth-09] (13 pages) - Hash and Stuffing: Overlooked Factors in Network Device Benchmarking [draft-ietf-bmwg-hash-stuffing-09] (34 pages) - Methodology for Benchmarking Accelerated Stress with Operational EBGP Instabilities [draft-ietf-bmwg-acc-bench-meth-ebgp-00] (9 pages) - Methodology for Benchmarking Accelerated Stress with Operational Security [draft-ietf-bmwg-acc-bench-meth-opsec-00] (7 pages) - Methodology for Benchmarking IPsec Devices [draft-ietf-bmwg-ipsec-meth-05] (41 pages) - Methodology for Benchmarking Network-layer Traffic Control Mechanisms [draft-ietf-bmwg-dsmmeth-02] (13 pages) - Benchmarking Terminology for Protection Performance [draft-ietf-bmwg-protection-term-10] (29 pages) - Methodology for benchmarking MPLS protection mechanisms [draft-ietf-bmwg-protection-meth-09] (35 pages) - IPv6 Benchmarking Methodology for Network Interconnect Devices [draft-ietf-bmwg-ipv6-meth-06] (19 pages) - MPLS Forwarding Benchmarking Methodology for IP Flows [draft-ietf-bmwg-mpls-forwarding-meth-07] (31 pages) - Terminology for Benchmarking Session Initiation Protocol (SIP) Networking Devices [draft-ietf-bmwg-sip-bench-term-04] (36 pages) - Methodology for Benchmarking SIP Networking Devices [draft-ietf-bmwg-sip-bench-meth-04] (19 pages) - Device Reset Characterization [draft-ietf-bmwg-reset-07] (20 pages) - IP Flow Information Accounting and Export Benchmarking Methodology [draft-ietf-bmwg-ipflow-meth-07] (32 pages) - RFC 2544 Applicability Statement: Use on Production Networks Considered Harmful [draft-ietf-bmwg-2544-as-01] (9 pages) - Benchmarking Methodology for Content-Aware Network Devices [draft-ietf-bmwg-ca-bench-meth-00] (17 pages) - IMIX Genome: Specification of variable packet sizes for additional testing [draft-ietf-bmwg-imix-genome-01] (9 pages) Requests for Comments: RFC1242: Benchmarking Terminology for Network Interconnection Devices (12 pages) * Updated by RFC6201 RFC1944: Benchmarking Methodology for Network Interconnect Devices (30 pages) * OBSOLETED BY RFC2544 RFC2285: Benchmarking Terminology for LAN Switching Devices (25 pages) RFC2432: Terminology for IP Multicast Benchmarking (16 pages) RFC2544: Benchmarking Methodology for Network Interconnect Devices (31 pages) * Obsoletes RFC1944 * Updated by RFC6201 RFC2647: Benchmarking Terminology for Firewall Performance (26 pages) RFC2761: Terminology for ATM Benchmarking (32 pages) RFC2889: Benchmarking Methodology for LAN Switching Devices (35 pages) RFC3116: Methodology for ATM Benchmarking (128 pages) RFC3133: Terminology for Frame Relay Benchmarking (24 pages) RFC3134: Terminology for ATM ABR Benchmarking (16 pages) RFC3222: Terminology for Forwarding Information Base (FIB) based Router Performance (15 pages) RFC3511: Benchmarking Methodology for Firewall Performance (34 pages) RFC3918: Methodology for IP Multicast Benchmarking (31 pages) RFC4098: Terminology for Benchmarking BGP Device Convergence in the Control Plane (35 pages) RFC4063: Considerations When Using Basic OSPF Convergence Benchmarks (12 pages) RFC4062: OSPF Benchmarking Terminology and Concepts (10 pages) RFC4061: Benchmarking Basic OSPF Single Router Control Plane Convergence (16 pages) RFC4689: Terminology for Benchmarking Network-layer Traffic Control Mechanisms (32 pages) RFC4814: Hash and Stuffing: Overlooked Factors in Network Device Benchmarking (34 pages) RFC4883: Benchmarking Terminology for Resource Reservation Capable Routers (22 pages) RFC5180: IPv6 Benchmarking Methodology for Network Interconnect Devices (19 pages) RFC5695: MPLS Forwarding Benchmarking Methodology for IP Flows (27 pages) RFC6201: Device Reset Characterization (17 pages) * Updates RFC1242 * Updates RFC2544 RFC6412: Terminology for Benchmarking Link-State IGP Data Plane Route Convergence (27 pages) RFC6413: Benchmarking Methodology for Link-State IGP Data Plane Route Convergence (43 pages) RFC6414: Benchmarking Terminology for Protection Performance (29 pages) Diameter Maintenance and Extensions (dime) ------------------------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Lionel Morand Jouni Korhonen Operations and Management Area Directors: Dan Romascanu Ronald Bonica Benoit Claise Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion: dime@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dime Archive: http://www.ietf.org/mail-archive/web/dime/current/maillist.html Description of Working Group: The Diameter Maintenance and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use for authentication, authorization, accounting, charging in network access, provisioning of configuration information within the network, and for new AAA session management uses within the extensibility rules of the Diameter base protocol. The DIME working group plans to address the following items: - Maintaining and/or progressing, along the standards track, the Diameter Base protocol and Diameter Applications. This includes extensions to Diameter Base protocol that can be considered as enhanced features or bug fixes. - Diameter application design guideline. This document will provide guidelines for design of Diameter extensions. It will detail when to consider reusing an existing application and when to develop a new application. - Protocol extensions for the management of Diameter entities. This work focuses on the standardization of Management Information Bases (MIBs) to configure Diameter entities (such as the Diameter Base protocol or Diameter Credit Control nodes). The usage of other management protocols for configuring Diameter entities may be future work within the group. - Protocol extensions for bulk and grouped AAA session management. The aim of this work is to study and standardize a solution for handling groups of AAA sessions within the Diameter base protocol context. The solution would define how to identify and handle grouped AAA sessions in commands and operations. Additionally, Diameter-based systems require interoperability in order to work. The working group, along with the AD, will need to evaluate any potential extensions and require verification that the proposed extension is needed, and is within the extensibility rules of Diameter and AAA scope. Coordination with other IETF working groups and other SDOs (e.g. 3GPP) will be used to ensure this. Goals and Milestones: Done - Submit the following two Diameter Mobility documents to the IESG for consideration as a Proposed Standards:* 'Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction' * 'Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction' Done - Submit 'Diameter API' to the IESG for consideration as an Informational RFC Done - Submit 'Quality of Service Parameters for Usage with Diameter' to the IESG for consideration as a Proposed Standard. Done - Submit 'Diameter QoS Application' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Support for EAP Re-authentication Protocol' as DIME working group item Done - Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' as DIME working group item Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working group item Done - Submit 'Quality of Service Attributes for Diameter' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter NAT Control Application' as DIME working group item Done - Submit 'Diameter Capabilities Update' as DIME working group item Done - Submit 'Diameter Credit Control Application MIB' to the IESG for consideration as an Informational RFC Done - Submit 'Diameter Base Protocol MIB' to the IESG for consideration as an Informational RFC Done - Submit 'Diameter Capabilities Update' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Extended NAPTR' as DIME working group item Done - Submit 'Realm-Based Redirection In Diameter' as DIME working group item Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized Routing' as DIME working group item Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic Key Transport' as DIME working group item Done - Submit 'Diameter Priority Attribute Value Pairs' as DIME working group item Done - Submit 'Diameter IKEv2 PSK' as DIME working group item Done - Submit Revision of 'Diameter Base Protocol' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic Key Transport' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Priority Attribute Value Pairs' to the IESG for consideration as a Proposed Standard Done - Submit Revision of 'Diameter Network Access Server Application - RFC 4005bis' as DIME working group item Done - Submit 'Diameter NAT Control Application' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter IKEv2 PSK' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Extended NAPTR' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized Routing' to the IESG for consideration as a Proposed Standard Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the IESG for consideration as a Proposed Standard Mar 2012 - Submit Revision of 'Diameter Network Access Server Application - RFC 4005bis' to the IESG for consideration as a Proposed Standard May 2012 - Submit 'Diameter Application Design Guidelines' to the IESG for consideration as a BCP document Jul 2012 - Submit 'Diameter Support for EAP Re-authentication Protocol' to the IESG for consideration as a Proposed Standard Aug 2012 - Submit 'problem statement and requirements for Diameter end-to-end security framework' as Dime working group item Aug 2012 - Submit a document on 'Protocol extension for bulk and group signaling' as a working group item Dec 2012 - Submit 'problem statement and requirements for Diameter end-to-end security framework' to the IESG for consideration as an Informational RFC Aug 2013 - Submit a document on 'Protocol extension for bulk and group signaling' to the IESG for consideration as a Proposed Standard Internet-Drafts: - The Diameter API [draft-ietf-dime-diameter-api-09] (46 pages) - Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction [draft-ietf-dime-mip6-split-18] (42 pages) - Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction [draft-ietf-dime-mip6-integrated-13] (18 pages) - Diameter Base Protocol [draft-ietf-dime-rfc3588bis-29] (151 pages) - Diameter Quality of Service Application [draft-ietf-dime-diameter-qos-16] (58 pages) - Quality of Service Parameters for Usage with Diameter [draft-ietf-dime-qos-parameters-12] (11 pages) - Diameter Applications Design Guidelines [draft-ietf-dime-app-design-guide-13] (27 pages) - Traffic Classification and Quality of Service Attributes for Diameter [draft-ietf-dime-qos-attributes-16] (44 pages) - Diameter support for EAP Re-authentication Protocol (ERP) [draft-ietf-dime-erp-08] (16 pages) - Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server [draft-ietf-dime-pmip6-05] (21 pages) - Diameter User-Name and Realm Based Request Routing Clarifications [draft-ietf-dime-nai-routing-05] (12 pages) - Diameter Credit Control Application MIB [draft-ietf-dime-diameter-cc-appl-mib-03] (21 pages) - Diameter Base Protocol MIB [draft-ietf-dime-diameter-base-protocol-mib-06] (51 pages) - Updated IANA Considerations for Diameter Command Code Allocations [draft-ietf-dime-diameter-cmd-iana-02] (10 pages) - Realm-Based Redirection In Diameter [draft-ietf-dime-realm-based-redirect-04] (7 pages) - The Diameter Capabilities Update Application [draft-ietf-dime-capablities-update-07] (7 pages) - Diameter Network Address and Port Translation Control Application [draft-ietf-dime-nat-control-13] (59 pages) - Diameter Support for Proxy Mobile IPv6 Localized Routing [draft-ietf-dime-pmip6-lr-07] (16 pages) - Diameter S-NAPTR Usage [draft-ietf-dime-extended-naptr-10] (14 pages) - Diameter IKEv2 SK: Shared Key-based Support for IKEv2 Server to Diameter Server Interaction [draft-ietf-dime-ikev2-psk-diameter-11] (22 pages) - Diameter Attribute-Value Pairs for Cryptographic Key Transport [draft-ietf-dime-local-keytran-14] (8 pages) - Diameter Priority Attribute Value Pairs [draft-ietf-dime-priority-avps-05] (8 pages) - Diameter Network Access Server Application [draft-ietf-dime-rfc4005bis-07] (65 pages) Requests for Comments: RFC5447: Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction (17 pages) RFC5624: Quality of Service Parameters for Usage with Diameter (11 pages) RFC5719: Updated IANA Considerations for Diameter Command Code Allocations (10 pages) * Updates RFC3588 RFC5777: Traffic Classification and Quality of Service (QoS) Attributes for Diameter (43 pages) RFC5778: Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction (34 pages) RFC5729: Clarifications on the Routing of Diameter Requests Based on the Username and the Realm (11 pages) * Updates RFC3588 RFC5779: Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server (20 pages) RFC5866: Diameter Quality of Service Application (58 pages) RFC6408: Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage (14 pages) * Updates RFC3588 Domain Name System Operations (dnsop) ------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Peter Koch Stephen Morris Operations and Management Area Directors: Dan Romascanu Ronald Bonica Benoit Claise Operations and Management Area Advisor: Ronald Bonica Mailing Lists: General Discussion: dnsop@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/dnsop Archive: http://www.ietf.org/mail-archive/web/dnsop Description of Working Group: The DNS Operations Working Group will develop guidelines for the operation of DNS software servers and the administration of DNS zone files. These guidelines will provide technical information relating to the implementation of the DNS protocol by the operators and administrators of DNS zones. The group will perform the following activities: 1. Define the processes by which Domain Name System (DNS) software may be efficiently and correctly administered, configured, and operated on Internet networks. This will include root zone name servers, gTLD name servers, name servers for other DNS zones, iterative DNS resolvers, and recursive DNS resolvers. As part of this effort, the group will produce documents explaining to the general Internet community what processes and mechanisms should be employed for the effective management and operation of DNS software. 2. Publish documents concerning DNSSEC operational procedures. 3. Publish documents concerning the IPv6 DNS operational procedures and DNS-related IPv6 transition and coexistence issues. 4. Publish documents concerning the operations of the root and TLD services, and DNS resolvers. Goals and Milestones: Done - Submit I-D: revised Root Server Requirements. Done - Submit I-D: revised version of Key Handling. Done - Submit I-D: first version of Servers Sharing IP#. Done - Submit I-D: first version of Performance and Measuring. Done - Submit I-D: revised version of Key Handling. Done - Submit I-D: revised version of Servers Sharing IP#. Done - Submit Root Server Requirements to the IESG for consideration as Informational (BCP?). Done - Submit I-D: 2nd revised version of Servers Sharing IP#. Done - Distributing Authoritative Name Servers via Shared Unicast Addresses to the IESG for Informational Done - Submit Observed DNS Resolution Misbehavior to the IESG for Informational Done - Submit document describing the outstanding problems and issues with DNS discovery for IPv6 to the IESG for Informational. Done - Submit Operational Guidelines for 'local' zones in the DNS to IESG. Category to be determined. Done - Submit Operational Considerations and Issues with IPv6 DNS to the IESG for Informational Done - Submit Common Misbehavior against DNS Queries for IPv6 Addresses to the IESG for Informational Done - Submit DNSSEC Operational Procedures to IESG for BCP Done - Submit Identifying an Authoritative Name Server to IESG for Informational Done - Submit I-D: revised version of Considerations for the use of DNS Reverse Mapping Done - Submit I-D: revised version of Considerations for the use of DNS Reverse Mapping Sep 2007 - Submit I-D: revised version of Considerations for the use of DNS Reverse Mapping Sep 2007 - Submit I'm Being Attacked by PRISONER.IANA.ORG! to IESG for FYI Sep 2007 - Submit Locally-served DNS Zones to IESG for BCP Oct 2007 - Submit DNS Response Size Issues to IESG for Informational Dec 2007 - Submit Considerations for the use of DNS Reverse Mapping to IESG for BCP Dec 2007 - Submit AS112 Nameserver Operations to IESG for Informational Feb 2008 - Submit Initializing a DNS Resolver with Priming Queries to IESG for BCP Internet-Drafts: - Domain Name System (DNS) Security Key Rollover [draft-ietf-dnsind-rollover-00] (11 pages) - Root Name Server Operational Requirements [draft-ietf-dnsop-root-opreq-05] (9 pages) - Handling of DNS Zone Signing Keys [draft-ietf-dnsop-keyhand-04] (9 pages) - Distributing Root Name Servers via Shared Unicast Addresses [draft-ietf-dnsop-shared-root-server-01] (4 pages) - Distributing Authorittative Name Servers via Shared Unicast Addresses [draft-ietf-dnsop-hardie-shared-root-server-07] (0 pages) - DNSSEC Implementation in the CAIRN Testbed [draft-ietf-dnsop-dnsseccairn-00] (22 pages) - Domain Name System (DNS) Security Key Rollover [draft-ietf-dnsop-rollover-01] (11 pages) - Root Name Servers with Inter Domain Anycast Addresses [draft-ietf-dnsop-ohta-shared-root-server-03] (5 pages) - Testing Root Name Servers with Inter Domain Anycast Addresses [draft-ietf-dnsop-ohta-shared-root-server-test-00] (3 pages) - Encouraging the use of DNS IN-ADDR Mapping [draft-ietf-dnsop-inaddr-required-07] (7 pages) - Parent's SIG over child's KEY [draft-ietf-dnsop-parent-sig-00] (0 pages) - DNS IPv6 transport operational guidelines [draft-ietf-dnsop-ipv6-transport-guidelines-03] (6 pages) - Rollover of statically configured resolver keys [draft-ietf-dnsop-resolver-rollover-00] (9 pages) - IP Addresses that should never appear in the public DNS [draft-ietf-dnsop-dontpublish-unreachable-03] (0 pages) - Observed DNS Resolution Misbehavior [draft-ietf-dnsop-bad-dns-res-07] (23 pages) - IPv4-to-IPv6 migration and DNS name space fragmentation [draft-ietf-dnsop-v6-name-space-fragmentation-01] (0 pages) - Requirements for a Mechanism Identifying a Name Server Instance [draft-ietf-dnsop-serverid-09] (13 pages) - Operational Considerations and Issues with IPv6 DNS [draft-ietf-dnsop-ipv6-dns-issues-13] (30 pages) - An Interim Scheme for Signing the Public DNS Root [draft-ietf-dnsop-interim-signed-root-01] (0 pages) - DNS Referral Response Size Issues [draft-ietf-dnsop-respsize-13] (13 pages) - IPv6 Host Configuration of DNS Server Information Approaches [draft-ietf-dnsop-ipv6-dns-configuration-07] (33 pages) - DNSSEC Operational Practices [draft-ietf-dnsop-dnssec-operational-practices-09] (36 pages) - Common Misbehavior against DNS Queries for IPv6 Addresses [draft-ietf-dnsop-misbehavior-against-aaaa-03] (8 pages) - Requirements for Automated Key Rollover in DNSsec [draft-ietf-dnsop-key-rollover-requirements-02] (8 pages) - Preventing Use of Recursive Nameservers in Reflector Attacks [draft-ietf-dnsop-reflectors-are-evil-07] (8 pages) - Locally-served DNS Zones [draft-ietf-dnsop-default-local-zones-16] (14 pages) - DNSSEC Trust Anchor Configuration and Maintenance [draft-ietf-dnsop-dnssec-trust-anchor-04] (14 pages) - Considerations for the use of DNS Reverse Mapping [draft-ietf-dnsop-reverse-mapping-considerations-06] (15 pages) - I'm Being Attacked by PRISONER.IANA.ORG! [draft-ietf-dnsop-as112-under-attack-help-help-07] (16 pages) - AS112 Nameserver Operations [draft-ietf-dnsop-as112-ops-10] (23 pages) - Initializing a DNS Resolver with Priming Queries [draft-ietf-dnsop-resolver-priming-02] (8 pages) - Requirements for Management of Name Servers for the DNS [draft-ietf-dnsop-name-server-management-reqs-06] (18 pages) - DNSSEC Operational Practices, Version 2 [draft-ietf-dnsop-rfc4641bis-08] (67 pages) - DNSSEC Policy & Practice Statement Framework [draft-ietf-dnsop-dnssec-dps-framework-05] (26 pages) - DNSSEC Key Timing Considerations [draft-ietf-dnsop-dnssec-key-timing-03] (33 pages) - DNSSEC Trust Anchor History Service [draft-ietf-dnsop-dnssec-trust-history-02] (11 pages) Requests for Comments: RFC2870: Root Name Server Operational Requirements (10 pages) * Obsoletes RFC2010 RFC3258: Distributing Authorittative Name Servers via Shared Unicast Addresses (11 pages) RFC3901: DNS IPv6 transport operational guidelines (6 pages) RFC4074: Common Misbehavior against DNS Queries for IPv6 Addresses (8 pages) RFC4339: IPv6 Host Configuration of DNS Server Information Approaches (33 pages) RFC4472: Operational Considerations and Issues with IPv6 DNS (30 pages) RFC4641: DNSSEC Operational Practices (36 pages) * Obsoletes RFC2541 RFC4697: Observed DNS Resolution Misbehavior (23 pages) RFC4892: Requirements for a Mechanism Identifying a Name Server Instance (13 pages) RFC5358: Preventing Use of Recursive Nameservers in Reflector Attacks (8 pages) RFC6168: Requirements for Management of Name Servers for the DNS (17 pages) Energy Management (eman) ------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Benoit Claise Bruce Nordman Operations and Management Area Directors: Dan Romascanu Ronald Bonica Benoit Claise Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion: eman@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/eman Archive: http://www.ietf.org/mail-archive/web/eman Description of Working Group: Energy management is becoming an additional requirement for network management systems due to several factors including the rising and fluctuating energy costs, the increased awareness of the ecological impact of operating networks and devices, and the regulation of governments on energy consumption and production. The basic objective of energy management is operating communication networks and other equipments with a minimal amount of energy while still providing sufficient performance to meet service level objectives. A discussion of detailed requirements has already started in the OPSAWG, but further exploration in the EMAN WG is needed. Today, most networking and network-attached devices neither monitor nor allow control energy usage as they are mainly instrumented for functions such as fault, configuration, accounting, performance, and security management. These devices are not instrumented to be aware of energy consumption. There are very few means specified in IETF documents for energy management, which includes the areas of power monitoring, energy monitoring, and power state control. The OPSAWG started working on a MIB module for monitoring energy consumption and power states of energy-aware devices and found that more than just a MIB module was needed to manage energy in networks. Rather a new framework for energy management needs to be developed first. A particular difference between energy management and other management tasks is that in some cases energy consumption of a device is not measured at the device itself but reported by a different place. For example, at a Power over Ethernet (PoE) sourcing device or at a smart power strip, in which cases one device is effectively metering another remote device. This requires a clear definition of the relationship between the reporting devices and identification of remote devices for which monitoring information is provided. Similar considerations will apply to power state control of remote devices, for example, at a PoE sourcing device that switches on and off power at its ports. Another example scenario for energy management is a gateway to low resourced and lossy network devices in wireless a building network. Here the energy management system talks directly to the gateway but not necessarily to other devices in the building network. The WG will investigate existing standards such as those from the IEC, ANSI, DMTF and others, and reuse existing work as much as possible. The EMAN WG will work on the management of energy-aware devices, Covered by the following items: 1. Requirements for energy management. The EMAN WG will develop a requirements document that will specify energy management properties that will allow networks and devices to become energy aware. In addition to energy awareness requirements, the need for control functions will be discussed. Specifically the need to monitor and control properties of devices that are remote to the reporting device should be discussed. 2. Energy management framework. The EMAN WG will create a framework document that will describe extensions to current management framework, required for energy management. This includes: power and energy monitoring, power states, power state control, and potential power state transitions. The framework will focus on energy management for IP-based network equipment (routers, switches, PCs, IP cameras, phones and the like). Particularly, the relationships between reporting devices, remote devices, and monitoring probes (such as might be used in low-power and lossy networks) need to be elaborated. For the case of a device reporting on behalf of other devices and controlling those devices, the framework will address the issues of discovery and identification of remote devices. 3. Energy-aware Networks and Devices MIB document The EMAN WG will develop a MIB module for monitoring energy-aware networks and devices. The module will address devices identification, context information, and potential relationship between reporting devices, remote devices, and monitoring probes. 4. Power and Energy Monitoring MIB document The EMAN WG will develop a document defining managed objects for monitoring of power states and energy consumption/production. The monitoring of power states includes: retrieving power states, properties of power states, current power state, power state transitions, and power state statistics. The managed objects will provide means for reporting detailed properties of the actual energy rate (power) and of accumulated energy. Further, it will provide information on electrical power quality. 5. Battery MIB document The EMAN WG will develop a document defining managed objects for battery monitoring, which will provide means for reporting detailed properties of the actual charge, age, and state of a battery and of battery statistics. 6. Applicability statement The EMAN WG will develop an applicability statement, describing the variety of applications that can use the energy framework and associated MIB modules. Potential examples are building networks, home energy gateway, etc. Finally, the document will also discuss relationships of the framework to other architectures and frameworks (such as smartgrid). The applicability statement will explain the relationship between the work in this WG and the other existing standards such as those from the IEC, ANSI, DMTF, and others. Goals and Milestones: Dec 2010 - Publish Internet draft on Energy Management Requirements Dec 2010 - Publish Internet draft on Battery MIB Dec 2010 - Publish Internet draft on Energy Management Framework Dec 2010 - Publish Internet draft on Energy-aware Networks and Devices MIB Dec 2010 - Publish Internet draft on Power and Energy Monitoring MIB Mar 2012 - Publish Internet draft on Energy Management Applicability Mar 2012 - Submit Internet draft on Energy Management Requirements for publication as Informational RFC Jul 2012 - Submit Internet draft on Energy Management Framework for publication as Informational RFC Jul 2012 - Submit Internet draft on Energy-aware Networks and Devices MIB for publication as Standard Track RFC Jul 2012 - Submit Internet draft on Power and Energy Monitoring MIB for publication as Standard Track RFC Jul 2012 - Submit Internet draft on Battery MIB for publication as Standard Track RFC Jul 2012 - Submit Internet draft on Energy Management Applicability for publication as Informational RFC Internet-Drafts: - Energy Management Framework [draft-ietf-eman-framework-03] (35 pages) - Requirements for Energy Management [draft-ietf-eman-requirements-05] (34 pages) - Energy-aware Networks and Devices MIB [draft-ietf-eman-energy-aware-mib-03] (32 pages) - Definition of Managed Objects for Battery Monitoring [draft-ietf-eman-battery-mib-04] (28 pages) - Power and Energy Monitoring MIB [draft-ietf-eman-energy-monitoring-mib-01] (77 pages) - Energy Management (EMAN) Applicability Statement [draft-ietf-eman-applicability-statement-00] (31 pages) No Requests for Comments Global Routing Operations (grow) -------------------------------- Charter Last Modified: 2012-02-01 Current Status: Active Chairs: Christopher Morrow Peter Schoenmaker Operations and Management Area Directors: Dan Romascanu Ronald Bonica Benoit Claise Operations and Management Area Advisor: Ronald Bonica Tech Advisors: Bill Fenner Vijay Gill Mailing Lists: General Discussion: grow@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/grow Archive: http://www.ietf.org/mail-archive/web/grow Description of Working Group: The Border Gateway Protocol (BGP) is fundamental to the operation of the Internet. In recent years, occurrences of BGP related operational issues have increased, and while overall understanding of the default-free routing system has improved, there is still a long and growing list of concerns. Among these are routing table growth rates, interaction of interior and exterior routing protocols, dynamic properties of the routing system, and the effects of routing policy on both the size and dynamic nature of the routing table. In addition, new and innovative uses of BGP, such as the use of BGP as a signaling protocol for some types of Virtual Private Networks, have created new and unexpected operational issues. The purpose of the GROW is to consider the operational problems associated with the IPv4 and IPv6 global routing systems, including but not limited to routing table growth, the effects of the interactions between interior and exterior routing protocols, and the effect of address allocation policies and practices on the global routing system. Finally, where appropriate, the GROW documents the operational aspects of measurement, policy, security, and VPN infrastructures. GROW will also advise various working groups, including the IDR and RPSEC working groups, with respect to whether it is addressing the relevant operational needs, and where appropriate, suggest course corrections. Finally, operational requirements developed in GROW can also be used by any new working group charged with standardizing a next generation inter-domain routing protocol. GOALS: ----- (i). Evaluate and develop various methodologies of controlling policy information in order to reduce the effect of prefix sub-aggregates beyond the necessary diameter, so as to reduce the Network Layer Reachability Information (or NLRI; see e.g.,draft-ietf-idr-bgp4-23.txt) load on network infrastructure. (ii). Document and suggest operational solutions to problematic aspects of the currently deployed routing system. Examples include instability caused by oscillation of MULTI_EXIT_DISC (or MED; see RFC 3345) values. (iii). Analyze aspects of supporting new applications, including extending existing routing protocols and creating new ones. This includes risk, interference and application fit. (iv). Determine the effect of IGP extensions on the stability of the Internet routing system. (v). Document the operational aspects of securing the Internet routing system, and provide recommendations to other WGs. Some Relevant References: ------------------------- http://www.routeviews.org http://bgp.potaroo.net http://www.cidr-report.org http://www.pch.net/routing/BGP_table_size.ital http://moat.nlanr.net/AS http://www.apnic.net/stats/bgp http://www.merit.edu/ipma http://www.caida.org/projects/routing/atoms Goals and Milestones: Done - Publish Risk, Interference and Fit (RIFT) document as WG I-D Done - Publish Embedding Globally ...Considered Harmful as WG I-D Done - Publish MED Considerations Draft as WG I-D Done - Publish Collection Communities as WG I-D Done - Submit Collection Communities to IESG for BCP Done - Submit Embedding Globally ...Considered Harmful to IESG for Info Done - Submit MED Considerations to IESG for Info Internet-Drafts: - BGP Communities for Data Collection [draft-ietf-grow-collection-communities-09] (13 pages) - Controlling the redistribution of BGP routes [draft-ietf-grow-bgp-redistribution-00] (16 pages) - Bounding Longest Match Considered [draft-grow-bounded-longest-match-00] (8 pages) - BGP MULTI_EXIT_DISC (MED) Considerations [draft-ietf-grow-bgp-med-considerations-06] (17 pages) - Embedding Globally Routable Internet Addresses Considered Harmful [draft-ietf-grow-embed-addr-06] (11 pages) - Operational Concerns and Considerations for Routing Protocol Design -- Risk, Interference, and Fit (RIFT) [draft-ietf-grow-rift-01] (39 pages) - BGP Wedgies [draft-ietf-grow-bgp-wedgies-04] (10 pages) - Operation of Anycast Services [draft-ietf-grow-anycast-05] (31 pages) - Classless Inter-Domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan [draft-ietf-grow-rfc1519bis-05] (29 pages) - MRT routing information export format [draft-ietf-grow-mrt-18] (37 pages) - BGP Monitoring Protocol [draft-ietf-grow-bmp-06] (17 pages) - Routing System Stability [draft-ietf-grow-rss-00] (13 pages) - MPLS Tunnels for Virtual Aggregation [draft-ietf-grow-va-mpls-00] (5 pages) - FIB Suppression with Virtual Aggregation [draft-ietf-grow-va-06] (24 pages) - Requirements for the graceful shutdown of BGP sessions [draft-ietf-grow-bgp-graceful-shutdown-requirements-08] (19 pages) - Graceful BGP session shutdown [draft-ietf-grow-bgp-gshut-03] (12 pages) - Performance of Virtual Aggregation [draft-ietf-grow-va-perf-00] (16 pages) - GRE and IP-in-IP Tunnels for Virtual Aggregation [draft-ietf-grow-va-gre-00] (7 pages) - Proposal to use an inner MPLS label to identify the remote ASBR VA [draft-ietf-grow-va-mpls-innerlabel-00] (6 pages) - Auto-Configuration in Virtual Aggregation [draft-ietf-grow-va-auto-05] (6 pages) - Simple Virtual Aggregation (S-VA) [draft-ietf-grow-simple-va-04] (10 pages) - Distribution of diverse BGP paths. [draft-ietf-grow-diverse-bgp-path-dist-06] (23 pages) - Multi-threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) routing information export format with geo-location extensions [draft-ietf-grow-geomrt-08] (15 pages) - Unique Per-Node Origin ASNs for Globally Anycasted Services [draft-ietf-grow-unique-origin-as-02] (12 pages) - Time to Remove Filters for Previously Unallocated IPv4 /8s [draft-ietf-grow-no-more-unallocated-slash8s-05] (6 pages) - Operational Requirements for Enhanced Error Handling Behaviour in BGP-4 [draft-ietf-grow-ops-reqs-for-bgp-error-handling-02] (27 pages) Requests for Comments: RFC4085: Embedding Globally Routable Internet Addresses Considered Harmful (11 pages) RFC4264: BGP Wedgies (10 pages) RFC4384: BGP Communities for Data Collection (13 pages) RFC4451: BGP MULTI_EXIT_DISC (MED) Considerations (17 pages) RFC4632: Classless Inter-Domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan (29 pages) RFC4786: Operation of Anycast Services (31 pages) RFC6198: Requirements for the Graceful Shutdown of BGP Sessions (20 pages) RFC6382: Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services (10 pages) RFC6396: Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format (33 pages) RFC6397: Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions (8 pages) RFC6441: Time to Remove Filters for Previously Unallocated IPv4 /8s (5 pages) IP Flow Information Export (ipfix) ---------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Nevil Brownlee Juergen Quittek Operations and Management Area Directors: Dan Romascanu Ronald Bonica Benoit Claise Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion: ipfix@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/ipfix Archive: http://www.ietf.org/mail-archive/web/ipfix Description of Working Group: The IPFIX working group has specified the information model (to describe IP flows) and the IPFIX protocol (to transfer IP flow data from IPFIX exporters to collectors). Several implementers have already built applications using the IPFIX protocol. As a result of a series of IPFIX interoperability testing events the WG has produced guidelines for IPFIX implementation and testing as well as recommendations for handling special cases such as bidirectional flow reporting and reducing redundancy in flow records. The IPFIX WG has developed a mediation framework, that defines IPFIX mediators for processing flow records for various purposes including aggregation, anonymization, etc. For configuring IPFIX devices, a YANG module has been developed. 1. Having a solid standardized base for IPFIX deployment and operation and several existing implementations, the IPFIX WG will revisit the IPFIX protocol specifications (RFC 5101) and the IPFIX information element specification (RFC 5102) in order to in order to advance them to the next stage on the standards track. All following items 2.-7. will be in line with the revised versions of the IPFIX protocol specifications and the IPFIX information model. 2. In order to provide guidelines to developers and reviewers (including IE doctors) of new IPFIX information elements and for better defining the process of registering new information elements at IANA the IPFIX WG will create an information element developers and reviewers guideline document. 3. The export of IPFIX flow records from IPFIX mediators introduces a set of potential issues at the protocol level, such as the loss of information on the original exporter, loss of base time information, loss of original options template information, etc. The IPFIX WG will define a set of specifications for applying the IPFIX protocol at mediators, including new specifications for protocol issues not envisioned by the IPFIX protocol itself. 4.In order to support the aggregation of flow records at IPFIX mediators the IPFIX WG will define how to export aggregated flow information using IPFIX. An aggregated flow is essentially an IPFIX flow representing packets from multiple original Flows sharing some set of common properties. 5. The IPFIX WG will investigate the use of the IPFIX protocol for exporting MIB objects, avoiding the need to define new IPFIX information elements for existing management information base objects that are already fully specified. This method requires the specification of new template set and options template sets to allow the export of MIB objects along with IPFIX information elements. 6. The IPFIX MIB module (RFC 5815) defined a way to register packet selector functions at IANA. The WG agreed that another method would be preferable that requires a minor change of RFC 5815. The IPFIX WG will produce a new version of RFC 5815 with small modifications of the IANA actions and DESCRIPTION clauses in the MIB modules. 7. Operational experiences showed that it would be useful to define several new information elements for data link monitoring covering frame size, type, sections of frames, and VLAN information. The IPFIX WG will create a document defining these new information elements. Goals and Milestones: Done - Submit Revised Internet-Draft on IP Flow Export Requirements Done - Submit Internet-Draft on IP Flow Export Architecture Done - Submit Internet-Draft on IP Flow Export Data Model Done - Submit Internet-Draft on IPFIX Protocol Evaluation Report Done - Submit Internet-Draft on IP Flow Export Applicability Statement Done - Select IPFIX protocol, revise Architecture and Data Model drafts Done - Submit IPFX-REQUIREMENTS to IESG for publication as Informational RFC Done - Submit IPFIX Protocol Evaluation Report to IESG for publication as Informational RFC Done - Submit IPFX-ARCHITECTURE to IESG for publication as Proposed Standard RFC Done - Submit IPFX-INFO_MODEL to IESG for publication as Informational RFC Done - Submit IPFX-APPLICABILITY to IESG for publication as Informational RFC Done - Submit IPFX-PROTOCOL to IESG for publication as Proposed Standard RFC Done - Publish Internet Draft on IPFIX Implementation Guidelines Done - Publish Internet Draft on IPFIX Testing Done - Publish Internet Draft on Reducing Redundancy in IPFIX data transfer Done - Publish Internet Draft on IPFIX MIB Done - Publish Internet Draft on Handling IPFIX Bidirectional Flows Done - Submit IPFIX Implementation Guidelines draft to IESG for publication as Informational RFC Done - Submit IPFIX Testing draft to IESG for publication as Informational RFC Done - Submit IPFIX Reducing Redundancy draft to IESG for publication as Informational RFC Done - Submit IPFIX Biflows draft to IESG for publication as Standards Track RFC Done - Publish Internet draft on IPFIX Type Information Export Done - Publish Internet draft on IPFIX Configuration Data Model Done - Publish Internet draft on IPFIX File Format Done - Publish Internet draft on Single SCTP Stream Reporting Done - Publish Internet draft on IPFIX Mediation Problem Statement Done - Submit File Format draft to IESG for publication as Standards track RFC Done - Submit IPFIX MIB draft to IESG for publication as Standards track RFC Done - Submit Type Export draft to IESG for publication as Standards track RFC Done - Submit Single SCTP Stream draft to IESG for publication as Informational RFC Done - Submit Mediation Problem Statement I-D to IESG for publication as Informational RFC Done - Submit initial draft on anonymization support Done - Submit initial draft on flow selection Done - Submit initial draft on structuring information elements Done - Submit final version of PSAMP MIB module Done - Submit Configuration Data Model draft to IESG for publication as Standards track RFC Done - Submit Mediation Framework I-D to IESG for publication as Informational RFC Done - Submit anonymization support I-D to IESG for publication as Experimental RFC Done - Submit structuring information elements I-D to IESG for publication as Standards Track RFC Nov 2011 - Publish Internet-Draft on guidelines for IE developers and Reviewers Nov 2011 - Publish Internet-Draft on IPFIX use at mediators Nov 2011 - Publish Internet-Draft on intermediate aggregation Nov 2011 - Publish Internet-Draft on exporting MIB objects Nov 2011 - Publish Internet-Draft on data link IEs Nov 2011 - Publish Internet-Draft on revised IPFIX MIB Dec 2011 - Publish Internet-Draft revising RFC 5101 Dec 2011 - Publish Internet-Draft revising RFC 5102 Dec 2011 - Submit flow selection I-D to IESG for publication as Standards Track RFC Apr 2012 - Submit guidelines for IE developers and reviewers for publication as Informational BCP RFC Apr 2012 - Submit IPFIX use at mediators for publication as Standards track RFC Apr 2012 - Submit intermediate aggregation for publication as Standards track RFC Apr 2012 - Submit data link IEs for publication as Standards track RFC Apr 2012 - Submit revised RFC 5101 for publication as Standards track RFC Apr 2012 - Submit revised IPFIX MIB for publications as Standards track RFC Apr 2012 - Submit revised RFC 5102 for publication as Standards track RFC Sep 2012 - Submit export of MIB objects for publication as Standards track RFC Internet-Drafts: - Requirements for IP Flow Information Export [draft-ietf-ipfix-reqs-17] (32 pages) - Architecture for IP Flow Information Export [draft-ietf-ipfix-architecture-13] (32 pages) - IPFIX Data Model Data Model for IP Flow Information Export [draft-ietf-ipfix-data-00] (25 pages) - Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX) [draft-leinen-ipfix-eval-contrib-04] (28 pages) - Information Model for IP Flow Information Export [draft-ietf-ipfix-info-16] (170 pages) - Architecture Model for IP Flow Information Export [draft-ietf-ipfix-arch-02] (28 pages) - Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information [draft-ietf-ipfix-protocol-27] (65 pages) - IPFIX Applicability [draft-ietf-ipfix-as-13] (32 pages) - IPFIX Implementation Guidelines [draft-ietf-ipfix-implementation-guidelines-09] (36 pages) - Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports [draft-ietf-ipfix-reducing-redundancy-05] (32 pages) - Bidirectional Flow Export using IPFIX [draft-ietf-ipfix-biflow-06] (23 pages) - Guidelines for IP Flow Information eXport (IPFIX) Testing [draft-ietf-ipfix-testing-06] (38 pages) - Definitions of Managed Objects for IP Flow Information Export [draft-ietf-ipfix-mib-11] (68 pages) - Specification of the IPFIX File Format [draft-ietf-ipfix-file-06] (66 pages) - Exporting Type Information for IPFIX Information Elements [draft-ietf-ipfix-exporting-type-06] (20 pages) - IPFIX Mediation: Problem Statement [draft-ietf-ipfix-mediators-problem-statement-10] (30 pages) - IPFIX Mediation: Framework [draft-ietf-ipfix-mediators-framework-10] (34 pages) - IPFIX Export per SCTP Stream [draft-ietf-ipfix-export-per-sctp-stream-08] (23 pages) - Configuration Data Model for IPFIX and PSAMP [draft-ietf-ipfix-configuration-model-10] (126 pages) - IP Flow Anonymization Support [draft-ietf-ipfix-anon-07] (43 pages) - Definitions of Managed Objects for Packet Sampling [draft-ietf-ipfix-psamp-mib-04] (28 pages) - Export of Structured Data in IPFIX [draft-ietf-ipfix-structured-data-07] (75 pages) - Flow Selection Techniques [draft-ietf-ipfix-flow-selection-tech-09] (35 pages) - Reliability Extension for IPFIX [draft-ietf-ipfix-reliability-template-ext-00] (11 pages) - Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of IP Traffic Flow Information [draft-ietf-ipfix-protocol-rfc5101bis-00] (73 pages) - Definitions of Managed Objects for IP Flow Information Export [draft-ietf-ipfix-rfc5815bis-01] (68 pages) - Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol [draft-ietf-ipfix-a9n-01] (46 pages) - Guidelines for Authors and Reviewers of IPFIX Information Elements [draft-ietf-ipfix-ie-doctors-00] (28 pages) - Specification of the Protocol for IPFIX Mediation [draft-ietf-ipfix-mediation-protocol-00] (33 pages) - Information Model for IP Flow Information eXport (IPFIX) [draft-ietf-ipfix-information-model-rfc5102bis-00] (30 pages) Requests for Comments: RFC3917: Requirements for IP Flow Information Export (32 pages) RFC3955: Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX) (28 pages) RFC5103: Bidirectional Flow Export using IP Flow Information Export (IPFIX) (23 pages) RFC5102: Information Model for IP Flow Information Export (170 pages) * Updated by RFC6313 RFC5101: Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information (65 pages) RFC5153: IPFIX Implementation Guidelines (36 pages) RFC5470: Architecture for IP Flow Information Export (32 pages) * Updated by RFC6183 RFC5471: Guidelines for IP Flow Information Export (IPFIX) Testing (32 pages) RFC5472: IP Flow Information Export (IPFIX) Applicability (31 pages) RFC5473: Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports (27 pages) RFC5610: Exporting Type Information for IPFIX Information Elements (20 pages) RFC5655: Specification of the IP Flow Information Export (IPFIX) File Format (66 pages) RFC5815: Definitions of Managed Objects for IP Flow Information Export (68 pages) RFC5982: IP Flow Information Export (IPFIX) Mediation: Problem Statement (25 pages) RFC6183: IP Flow Information Export (IPFIX) Mediation: Framework (29 pages) * Updates RFC5470 RFC6235: IP Flow Anonymization Support (43 pages) RFC6313: Export of Structured Data inIP Flow Information Export (IPFIX) (71 pages) * Updates RFC5102 IPv6 Operations (v6ops) ----------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Fred Baker Joel Jaeggli Operations and Management Area Directors: Dan Romascanu Ronald Bonica Benoit Claise Operations and Management Area Advisor: Ronald Bonica Mailing Lists: General Discussion: v6ops@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/v6ops Archive: http://www.ietf.org/mail-archive/web/v6ops/current/maillist.html 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-17] (35 pages) - Teredo Security Concerns [draft-ietf-v6ops-teredo-security-concerns-03] (20 pages) - IPv6 Router Advertisement Guard [draft-ietf-v6ops-ra-guard-09] (11 pages) - Security Concerns With IP Tunneling [draft-ietf-v6ops-tunnel-security-concerns-05] (19 pages) - Basic Requirements for IPv6 Customer Edge Routers [draft-ietf-v6ops-ipv6-cpe-router-10] (18 pages) - Rogue IPv6 Router Advertisement Problem Statement [draft-ietf-v6ops-rogue-ra-03] (16 pages) - IPv6 Deployment in Internet Exchange Points (IXPs) [draft-ietf-v6ops-v6inixp-10] (11 pages) - Mobile Networks Considerations for IPv6 Deployment [draft-ietf-v6ops-v6-in-mobile-networks-06] (19 pages) - An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition [draft-ietf-v6ops-incremental-cgn-04] (15 pages) - Emerging Service Provider Scenarios for IPv6 Deployment [draft-ietf-v6ops-isp-scenarios-01] (20 pages) - IPv6 Address Assignment to End Sites [draft-ietf-v6ops-3177bis-end-sites-02] (10 pages) - Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations [draft-ietf-v6ops-tunnel-loops-08] (20 pages) - Framework for IP Version Transition Scenarios [draft-ietf-v6ops-v4v6tran-framework-03] (7 pages) - Considerations for Transitioning Content to IPv6 [draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08] (31 pages) - IPv6 Multihoming without Network Address Translation [draft-ietf-v6ops-multihoming-without-nat66-01] (19 pages) - Happy Eyeballs: Success with Dual-Stack Hosts [draft-ietf-v6ops-happy-eyeballs-07] (17 pages) - Advanced Requirements for IPv6 Customer Edge Routers [draft-ietf-v6ops-ipv6-cpe-router-bis-02] (15 pages) - IPv6 Multihoming without Network Address Translation [draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03] (24 pages) - IPv6 in 3GPP Evolved Packet System [draft-ietf-v6ops-3gpp-eps-09] (35 pages) - Advisory Guidelines for 6to4 Deployment [draft-ietf-v6ops-6to4-advisory-03] (21 pages) - Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status [draft-ietf-v6ops-6to4-to-historic-06] (7 pages) - Basic Requirements for IPv6 Customer Edge Routers [draft-ietf-v6ops-6204bis-05] (21 pages) - A Discard Prefix for IPv6 [draft-ietf-v6ops-ipv6-discard-prefix-02] (5 pages) - Operational Neighbor Discovery Problems [draft-ietf-v6ops-v6nd-problems-04] (13 pages) - Stateless Source Address Mapping for ICMPv6 Packets [draft-ietf-v6ops-ivi-icmp-address-00] (7 pages) - Wireline Incremental IPv6 [draft-ietf-v6ops-wireline-incremental-ipv6-01] (25 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) RFC5963: IPv6 Deployment in Internet Exchange Points (IXPs) (10 pages) RFC6036: Emerging Service Provider Scenarios for IPv6 Deployment (23 pages) RFC6092: Recommended Simple Security Capabilities in Customer Premises Equipment (CPE for Providing Residential IPv6 Internet Service (36 pages) RFC6104: Rogue IPv6 Router Advertisement Problem Statement (16 pages) RFC6105: IPv6 Router Advertisement Guard (10 pages) RFC6177: IPv6 Address Assignment to End Sites (9 pages) * Obsoletes RFC3177 RFC6169: Security Concerns With IP Tunneling (20 pages) RFC6204: Basic Requirements for IPv6 Customer Edge Routers (17 pages) RFC6264: An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition (13 pages) RFC6343: Advisory Guidelines for 6to4 Deployment (20 pages) RFC6342: Mobile Networks Considerations for IPv6 Deployment (17 pages) RFC6324: Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations (19 pages) RFC6459: IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS) (36 pages) IPv6 Site Renumbering (6renum) ------------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Tim Chown Wesley George Operations and Management Area Directors: Dan Romascanu Ronald Bonica Benoit Claise Operations and Management Area Advisor: Ronald Bonica Secretary: Sheng Jiang Mailing Lists: General Discussion: renum@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/renum Archive: http://www.ietf.org/mail-archive/web/renum/ Description of Working Group: As outlined in RFC 5887, renumbering, especially for medium to large sites and networks, is currently viewed as an expensive, painful, and error-prone process, avoided by network managers as much as possible. As that RFC describes, there are triggers that mean some cases of renumbering are unavoidable, so it should be considered a given that a site may need partial or complete renumbering at some stage. It is thus important to implement and deploy techniques that facilitate simpler IPv6 site renumbering, so that as IPv6 becomes universally deployed, renumbering can be viewed as a more routine event. This includes consideration of how the initial assignment and subsequent management of address information is performed, as this will affect future renumbering operations. If IPv6 site renumbering continues to be considered difficult, network managers will turn to PI addressing for IPv6 to attempt to minimise the need for future renumbering. However, widespread use of PI may create very serious BGP4 scaling problems. It is thus desirable to develop tools and practices that may make renumbering a simpler process to reduce demand for IPv6 PI space. Renumbering, or partial renumbering, can be complicated in an enterprise site where a short prefix is divided into subnets with longer prefixes. Aggregation, synchronisation, coordination, etc., need to be carefully managed, and the use of manually inserted address literals minimised. Other factors such as applications binding long-term to low level IP addresses may add constraints to what can be realistically achieved, but identifying and documenting such factors is a useful objective. In some scenarios, consideration may also need to be made for 'flag day' renumbering (in contrast to the procedure described in RFC4192). The task of the 6RENUM working group is to document existing renumbering practices for enterprise site networks and to identify specific renumbering problems or 'gaps' in the context of partial or site-wide renumbering. Completion of these tasks should provide a basis for future work to identify and develop point solutions or system solutions to address those problems or to stimulate such development in other working groups as appropriate. 6RENUM is chartered to perform an analysis of IPv6 site renumbering. If the analysis leads to conclusions that are also applicable to IPv4 that will be an advantage, but it is not an objective of the WG to make its outputs more widely available than IPv6. Similarly the WG is targeting enterprise networks, but the analysis may also be applicable to SOHO or other (e.g. ad-hoc) scenarios. It may be that for site renumbering to become more routine, a systematic address management approach will be required. By documenting current practices and undertaking a gap analysis, we should become better informed of the requirements of such an approach. Post-analysis rechartering may lead to further work in this area. RFC 4192, RFC 5887, and draft-jiang-ipv6-site-renum-guideline are starting points for this work. Goals/deliverables ------------------ The goals of the 6RENUM working group are: 1. To undertake scenario descriptions, including documentation of current capability inventories and existing BCPs, for enterprise networks, including managed and unmanaged elements. These texts should contribute towards a gap analysis and provide an agreed basis for subsequent WG rechartering towards development of solutions (which may be more appropriate for other WGs to undertake) and improved practices. Operator input will be of high value for this text. 2. To perform a gap analysis for renumbering practices, to identify generic issues for network design, network management, address management and renumbering operations. The methodology for the WG will be to begin building the enterprise scenario description while in parallel constructing an initial gap analysis drawing on existing work in (at least) RFC4192 and RFC5887. As the scenario text hardens, its contributions will be incorporated into the more detailed gap analysis, which can be published once the scenario text is completed. The deliverables are thus the scenario and gap analysis texts. The following topics are out of scope for the working group: 1. Renumbering avoidance; this can perhaps be considered by appropriate IRTF groups. As documented in RFC5887, renumbering cannot be completely avoided. The WG is limited to dealing with how to renumber when it is unavoidable. 2. IPv4 renumbering. While many sites are likely to run dual-stack, IPv6 is the future and, especially given concerns over extensive use of IPv6 PI, the most appropriate place to focus effort. 3. ISP renumbering; this is potentially the most complex renumbering case. However, more benefit can be achieved by focusing effort on site renumbering. The enterprise site analysis should include the ISP's role in the site's renumbering events. 4. Neither SOHO nor manet networks are targeted by the WG. However, if outputs from the WG are applicable to those scenarios, that would be an advantage. A recharter of the WG will be possible once the gap analysis and scenario description are completed and published. Such rechartering would identify more specific work items within the 6RENUM WG or appropriate protocol WGs, and may include a proposal for work on a systematic address management approach. Goals and Milestones: Oct 2011 - IPv6 enterprise site scenario draft ready for WG adoption Nov 2011 - Gap analysis document ready for WG adoption Jun 2012 - IPv6 enterprise site scenario draft ready for WGLC Jul 2012 - Gap analysis document ready for WGLC Internet-Drafts: No Requests for Comments MBONE Deployment (mboned) ------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Leonard Giuliano Greg Shepherd Operations and Management Area Directors: Dan Romascanu Ronald Bonica Benoit Claise 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 Tunneling [draft-ietf-mboned-auto-multicast-12] (36 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-09] (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-08] (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-10] (18 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-12] (22 pages) - Lightweight IGMPv3 and MLDv2 Protocols [draft-ietf-mboned-lightweight-igmpv3-mldv2-07] (23 pages) - Moving MCAST.NET into the ARPA infrastructure top level domain [draft-ietf-mboned-mcast-arpa-04] (9 pages) - Multicast Ping Protocol [draft-ietf-mboned-ssmping-10] (24 pages) - Mtrace Version 2: Traceroute Facility for IP Multicast [draft-ietf-mboned-mtrace-v2-09] (41 pages) - Requirements for IP Multicast Session Announcement [draft-ietf-mboned-session-announcement-req-03] (14 pages) - Requirements for IP multicast performance monitoring [draft-ietf-mboned-ip-multicast-pm-requirement-02] (15 pages) - Multicast Addresses for Documentation [draft-ietf-mboned-mcaddrdoc-02] (13 pages) - IPv4-Embedded IPv6 Multicast Address Format [draft-ietf-mboned-64-multicast-address-format-00] (12 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) * OBSOLETED BY RFC5771 RFC3171: IANA Guidelines for IPv4 Multicast Address Assignments (8 pages) * OBSOLETED BY RFC5771 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) RFC5790: Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols (17 pages) RFC5771: IANA Guidelines for IPv4 Multicast Address Assignments (11 pages) * Obsoletes RFC3138 * Obsoletes RFC3171 * Updates RFC2780 RFC6034: Unicast-Prefix-Based IPv4 Multicast Addresses (5 pages) RFC6308: Overview of the Internet Multicast Addressing Architecture (14 pages) * Obsoletes RFC2908 RFC6450: Multicast Ping Protocol (24 pages) NETCONF Data Modeling Language (netmod) --------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: David Kessens Juergen Schoenwaelder Operations and Management Area Directors: Dan Romascanu Ronald Bonica Benoit Claise 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 modeling language or accompanying rules that can be used to model the management information that is to be configured using NETCONF. The NETMOD working group has defined the data modeling language YANG but no IETF models exist yet. The purpose of the NETMOD working group is to support the ongoing deployment of YANG by developing a set of core YANG data models and other activities that will allow network operators to use YANG for configuration and management of network elements. The NETMOD Working Group will work on the following items: 1. Core system data model 2. Core interface data model 3. Core routing data model that can be augmented with routing protocol specifics. This requires appropriate active editorial participation from routing experts and review at WGLC by the Routing Area working group. 4. SMIv2 translation to YANG for read-only operational data and notifications. Guidance will be provided on how to reference existing data structures in SMIv2 from YANG. 5. Data model for configuring SNMP engines. The model must be capable of representing all SNMP engine configurations possible with the standard SNMPv3 MIB modules that are common operational practice. Any differences in functionality and behavior should be documented. The NETMOD Working Group will not work on another version of YANG. Further, the NETMOD Working Group will not serve as a review team for YANG modules developed by other working groups. All new charter items must be fully interoperable with implementations of RFC 6241 and/or RFC 6020. The WG will consult with the NETCONF working group to ensure that NETMOD's decision do not conflict with planned work in NETCONF. Goals and Milestones: Done - 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) Done - 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 Done - Initial DSDL mapping rules document Done - 01 of YANG, DSDL, architecture, YIN, and standard library draft. If split out, -00 of on-the-wire XML draft. Done - Initial YANG Usage guidelines document available as a working group document Done - WGLC for YANG, YIN, XML on-the-wire (if split out), YANG standard library, DSDL mapping rules Done - 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 Done - Submission of individual draft(s) of Interface data model Done - Submission of individual draft(s) of Routing data model Done - Submission of individual draft(s) of SMIv2 translation to YANG Done - Submission of individual draft(s) of System data model draft Done - Submit first working group draft of System data model draft Done - Submit first working group draft of Interface data model Done - Submit first working group draft of Routing data model Done - Submit first working group draft of SMIv2 translation to YANG Mar 2012 - Submit SMIv2 to YANG translation to the IESG (proposed standard) Apr 2012 - Submit Interface data model to the IESG (proposed standard) Apr 2012 - Submit first working group draft of Data model for configuring SNMP engines Aug 2012 - Submit System data model to the IESG (proposed standard) Aug 2012 - Submit Routing data model to the IESG (proposed standard) Sep 2012 - Submit Data model for configuring SNMP engines to the IESG (proposed standard) Internet-Drafts: - YANG - A data modeling language for the Network Configuration Protocol (NETCONF) [draft-ietf-netmod-yang-14] (185 pages) - Common YANG Data Types [draft-ietf-netmod-yang-types-10] (31 pages) - Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content [draft-ietf-netmod-dsdl-map-11] (112 pages) - An Architecture for Network Management using NETCONF and YANG [draft-ietf-netmod-arch-11] (34 pages) - Guidelines for Authors and Reviewers of YANG Data Model Documents [draft-ietf-netmod-yang-usage-12] (36 pages) - A YANG Data Model for Routing Configuration [draft-ietf-netmod-routing-cfg-01] (51 pages) - A YANG Data Model for Interface Configuration [draft-ietf-netmod-interfaces-cfg-03] (24 pages) - IANA Interface Type YANG Module [draft-ietf-netmod-iana-if-type-01] (38 pages) - Translation of SMIv2 MIB Modules to YANG Modules [draft-ietf-netmod-smi-yang-04] (43 pages) - A YANG Data Model for IP Configuration [draft-ietf-netmod-ip-cfg-01] (13 pages) - YANG Data Model for System Management [draft-ietf-netmod-system-mgmt-00] (40 pages) Requests for Comments: RFC6021: Common YANG Data Types (26 pages) RFC6020: YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) (173 pages) RFC6087: Guidelines for Authors and Reviewers of YANG Data Model Documents (26 pages) RFC6110: Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content (100 pages) RFC6244: An Architecture for Network Management using NETCONF and YANG (30 pages) Network Configuration (netconf) ------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Bert Wijnen Mehmet Ersue Operations and Management Area Directors: Dan Romascanu Ronald Bonica Benoit Claise Operations and Management Area Advisor: Dan Romascanu Tech Advisor: Tim Polk 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: 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 has produced 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 can 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 an XML-based data representation, that can be easily manipulated using non-specialized XML manipulation tools. - Supports integration with existing user authentication methods - Supports integration with existing configuration database systems - Supports multiple (e.g. candidate and running) data-stores to optimize configuration preparation and activation - Supports network wide configuration transactions (with features such as locking and rollback capability) - Runs over a secure transport; SSH is mandatory to implement while TLS, BEEP, and SOAP are optional transports. - Provides support for asynchronous notifications. The NETCONF protocol has been designed independent of the data modeling language. The IETF recommends to use YANG as the NETCONF modeling language, which introduces advanced language features for configuration management. In the current phase of the incremental development of NETCONF the workgroup will focus on following items: 1. Netconf Access Control Model (NACM) Requirements and Solution. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre- configured (by operator) subset of all available NETCONF operations and content. The WG will produce a document which identifies the access control requirements specific to the NETCONF protocol, as defined in [4741bis]. This document will also provide a standard YANG data model which addresses these requirements. It is possible that the WG will not reach solution consensus on every possible requirement identified in the document. In this case, it is expected that the solution will evolve over time to meet the the remaining unmet requirements. 2. The NETCONF server may want to notify interested clients about particular NETCONF protocol/server events. The WG will work on a NETCONF specific YANG module(s) to define suitable notifications. 3. As implementation and deployment experience gained with the NETCONF monitoring data model, the WG may revise the NETCONF monitoring data model to add additional objects that can be used to check the status of the server and to discover additional information about the server implementation. The WG may choose to revise the NETCONF monitoring data model. 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 Done - WG Last Call on rfc4741bis Done - Send with-defaults to IESG for consideration as Proposed Standard Done - first WG draft (rev 00) on NACM posted Done - rfc4741bis to IESG for consideration as Proposed Standard Done - Send rfc4742bis to IESG for consideration as proposed Standard Done - first WG draft (rev 00) on NETCONF specific YANG modules posted Jul 2011 - WGLC for NACM document Jul 2011 - WGLC for NETCONF specific notifications document Sep 2011 - (if needed last) WGLC for NACM document Sep 2011 - (if needed last) WGLC for NETCONF specific notifications document Oct 2011 - submit NACM document to IESG for consideration as Proposed Standard Oct 2011 - submit NETCONF specific notifications document 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-16] (39 pages) - With-defaults capability for NETCONF [draft-ietf-netconf-with-defaults-15] (32 pages) - Network Configuration Protocol (NETCONF) [draft-ietf-netconf-4741bis-11] (121 pages) - Using the NETCONF Configuration Protocol over Secure Shell (SSH) [draft-ietf-netconf-rfc4742bis-09] (13 pages) - Network Configuration Protocol (NETCONF) Access Control Model [draft-ietf-netconf-access-control-07] (54 pages) - Network Configuration Protocol (NETCONF) Base Notifications [draft-ietf-netconf-system-notifications-07] (17 pages) Requests for Comments: RFC4741: NETCONF Configuration Protocol (105 pages) * OBSOLETED BY RFC6241 RFC4742: Using the NETCONF Configuration Protocol over Secure Shell (SSH) (11 pages) * OBSOLETED BY RFC6242 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) RFC6022: YANG Module for NETCONF Monitoring (28 pages) RFC6241: Network Configuration Protocol (NETCONF) (113 pages) * Obsoletes RFC4741 RFC6242: Using the NETCONF Configuration Protocol over Secure Shell (SSH) (13 pages) * Obsoletes RFC4742 RFC6243: With-defaults Capability for NETCONF (26 pages) Operational Security Capabilities for IP Network Infrastructure (opsec) ----------------------------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Gunter Van de Velde Warren Kumari Operations and Management Area Directors: Dan Romascanu Ronald Bonica Benoit Claise 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-17] (43 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-08] (20 pages) - Security Assessment of the Internet Protocol version 4 [draft-ietf-opsec-ip-security-08] (78 pages) - Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols [draft-ietf-opsec-igp-crypto-requirements-05] (19 pages) - Protecting The Router Control Plane [draft-ietf-opsec-protect-control-plane-07] (24 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) RFC6039: Issues with Existing Cryptographic Protection Methods for Routing Protocols (21 pages) RFC6094: Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols (11 pages) RFC6192: Protecting The Router Control Plane (25 pages) RFC6274: Security Assessment of the Internet Protocol Version 4 (75 pages) Operations and Management Area Working Group (opsawg) ----------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Scott Bradner Melinda Shore Chris Liljenstolpe Operations and Management Area Directors: Dan Romascanu Ronald Bonica Benoit Claise 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-07] (19 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-00] (21 pages) - "Guidelines for the use of the OAM acronym in the IETF" [draft-ietf-opsawg-mpls-tp-oam-def-11] (9 pages) - An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms [draft-ietf-opsawg-oam-overview-06] (35 pages) - Problem Statement for the Automated Configuration of Large IP Networks [draft-ietf-opsawg-automated-network-configuration-02] (23 pages) - Textual Conventions for the Representation of Floating-Point Numbers [draft-ietf-opsawg-mib-floats-03] (8 pages) - An Overview of the IETF Network Management Standards [draft-ietf-opsawg-management-stds-04] (79 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) RFC5935: Expressing SNMP SMI Datatypes in XML Schema Definition Language (14 pages) RFC6291: Guidelines for the Use of the 'OAM' acronym in the IETF (9 pages) RFC6340: Textual Conventions for the Representation of Floating-Point Numbers (7 pages) RADIUS EXTensions (radext) -------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Jouni Korhonen Mauricio Sanchez Operations and Management Area Directors: Dan Romascanu Ronald Bonica Benoit Claise Operations and Management Area Advisor: Dan Romascanu Tech Advisor: Paul Congdon Mailing Lists: General Discussion: radext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/radext Archive: http://www.ietf.org/mail-archive/web/radext/ 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 Done - Reliable Transport Profile for RADIUS I-D submitted as a Proposed Standard RFC Done - Status-Server I-D submitted as a Proposed Standard RFC Dec 2010 - IPv6 Access I-D submitted as a Proposed Standard RFC Mar 2011 - RADIUS over DTLS I-D submitted as an Experimental RFC Mar 2011 - RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC Mar 2011 - RADIUS Crypto-agility Requirements submitted as an Informational RFC Jun 2011 - Extended Attributes I-D submitted as a Proposed Standard RFC Oct 2011 - IEEE 802 Attributes I-D submitted as a Proposed Standard RFC Oct 2011 - Dynamic Discovery I-D submitted as a Proposed Standard 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-20] (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-08] (12 pages) - TLS encryption for RADIUS [draft-ietf-radext-radsec-11] (21 pages) - Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol [draft-ietf-radext-status-server-10] (25 pages) - New Tunnel-Type Values [draft-ietf-radext-tunnel-type-00] (6 pages) - RADIUS Over TCP [draft-ietf-radext-tcp-transport-09] (18 pages) - NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS [draft-ietf-radext-dynamic-discovery-04] (9 pages) - RADIUS attributes for IPv6 Access Networks [draft-ietf-radext-ipv6-access-06] (15 pages) - DTLS as a Transport Layer for RADIUS [draft-ietf-radext-dtls-01] (18 pages) - Remote Authentication Dial In User Service (RADIUS) Protocol Extensions [draft-ietf-radext-radius-extensions-04] (63 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) RFC5997: Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol (24 pages) * Updates RFC2866 RFC6158: RADIUS Design Guidelines (38 pages) RFC6421: Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS) (12 pages) Audio/Video Transport Core Maintenance (avtcore) ------------------------------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Magnus Westerlund Roni Even Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Robert Sparks Secretary: Tom Taylor Mailing Lists: General Discussion: avt@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/avt Archive: http://www.ietf.org/mail-archive/web/avt/index.html Description of Working Group: The Real-time Transport Protocol, RTP, along with its associated profiles and payload formats provides for real-time transmission of audio and video over unicast and multicast transports. RTP itself has been shepherded to Full Standard. Its associated profiles, extensions, and payload formats are currently at various levels of standards maturity. The AVTCORE working group is chartered to maintain the core RTP/RTCP specifications and the AVP, SAVP, AVPF, and SAVPF profiles. The group will provide architectural guidance for extending the protocols and guidelines for their proper use. While other working groups may be chartered to work on application-specific extensions to the protocols, extensions that are generally applicable will be developed in AVTCORE. The AVTCORE working group will coordinate closely with the Security Area while working on maintenance and enhancements to the SRTP Profile. In addition to the milestones called out below, the AVTCORE working group's initial tasks will include completing any remaining work identified in those drafts from the AVT working group already in IESG Evaluation, with the exception of the Rapid Acquisition of Multicast RTP sessions, which will complete in the AVTEXT working group. Goals and Milestones: Done - Submit Guideline for Choosing RTCP CNAME as Proposed Standard Done - Submit use of AES-192 and AES-256 in Secure RTP for Proposed Standard Done - Submit Port Mapping Between Unicast and Multicast RTP Sessions for Proposed Standard Feb 2011 - Submit Monitoring Architecture for RTP for Informational Done - Submit Guidelines for the use of Variable Bit Rate Audio with Secure RTP as Informational (or possibly BCP) Apr 2011 - Submit in band keying mechanism for SRTP draft for Proposed Standard Apr 2011 - Submit Explicit Congestion Notification (ECN) for RTP over UDP for Proposed Standard May 2011 - Submit RTCP indication for retransmission suppression as Proposed Standard Sep 2011 - Submit Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP) for Proposed Standard Dec 2011 - Submit Real-Time Transport Control Protocol (RTCP) in Overlay Multicast for Proposed Standard Mar 2012 - Submit Specification for Inter-destination Media Playout Synchronization in RTP to IESG for publication as Proposed Standard Internet-Drafts: - Application Mechanism for keeping alive the Network Address Translator (NAT) mappings associated to RTP/RTCP flows. [draft-ietf-avt-app-rtp-keepalive-11] (11 pages) - Forward-shifted RTP Redundancy Payload Support [draft-ietf-avt-forward-shifted-red-09] (13 pages) - Why RTP Does Not Mandate a Single Security Mechanism [draft-ietf-avt-srtp-not-mandatory-08] (11 pages) - AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) [draft-ietf-avt-srtp-aes-gcm-02] (19 pages) - Port Mapping Between Unicast and Multicast RTP Sessions [draft-ietf-avt-ports-for-ucast-mcast-rtp-12] (35 pages) - Explicit Congestion Notification (ECN) for RTP over UDP [draft-ietf-avt-ecn-for-rtp-04] (44 pages) - Encrypted Key Transport for Secure RTP [draft-ietf-avt-srtp-ekt-03] (53 pages) - Guidelines for the use of Variable Bit Rate Audio with Secure RTP [draft-ietf-avtcore-srtp-vbr-audio-04] (7 pages) - Explicit Congestion Notification (ECN) for RTP over UDP [draft-ietf-avtcore-ecn-for-rtp-05] (56 pages) - Port Mapping Between Unicast and Multicast RTP Sessions [draft-ietf-avtcore-ports-for-ucast-mcast-rtp-03] (37 pages) - RTCP Extension for Third-party Loss Report [draft-ietf-avtcore-feedback-supression-rtp-10] (17 pages) - Monitoring Architectures for RTP [draft-ietf-avtcore-monarch-09] (26 pages) - Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP) [draft-ietf-avtcore-srtp-encrypted-header-ext-01] (13 pages) - RTCP for inter-destination media synchronization [draft-ietf-avtcore-idms-02] (24 pages) Requests for Comments: RFC6263: Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows (12 pages) RFC6284: Port Mapping Between Unicast and Multicast RTP Sessions (30 pages) RFC6354: Forward-Shifted RTP Redundancy Payload Support (13 pages) * Updates RFC2198 * Updates RFC4102 Audio/Video Transport Extensions (avtext) ----------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Magnus Westerlund Keith Drage Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo Mailing Lists: General Discussion: avtext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/avtext Archive: http://www.ietf.org/mail-archive/web/avtext/index.html Description of Working Group: The Full-Standard Real-time Transport Protocol, RTP [RFC 3550], along with its associated profiles and payload formats provides for real- time transmission of audio and video over unicast and multicast transports. RTP is widely implemented, and deployed for a wide range of applications, ranging from telephony to television over IP. As new applications have emerged, the need for guidelines for the use of the RTP/RTCP protocols and extensions specific to those applications has been identified. The AVTEXT working group is charted to develop application-specific guidelines for the use of RTP/RTCP protocols with the AVP, SAVP, AVPF, and SAVPF profiles, and extensions to those protocols that are driven by application-specific needs. Proposals for extensions with general applicability to many different RTP/RTCP usages should be taken to the AVTCORE working group. The AVTEXT working group is constrained to use the protocol extension mechanisms defined in the core protocols (such as RTP Header extensions [RFC5285], AVPF Feedback Messages [RFC4585], and SDES Items [RFC3550]). If new ways to extend the core protocols are needed, they will be developed in the AVTCORE working group. In addition to the milestones called out below, the AVTEXT working group's initial tasks will include completing any new work identified during IESG evaluation for the Rapid Acquisition of Multicast RTP Sessions. Goals and Milestones: Jun 2011 - Submit Considerations for RAMS Scenarios for Informational Done - Submit RTP Header extension for mixer to client audio level indication as Proposed Standard Done - Submit RTP Header extension for client to mixer audio level indication as proposed standard Dec 2011 - Submit Support for multiple clock rates in an RTP session for Proposed Standard Dec 2011 - Content splicing for RTP sessions as Informational Internet-Drafts: - Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) [draft-ietf-avt-multicast-acq-rtcp-xr-01] (20 pages) - A Real-Time Transport Protocol (RTP) Header Extension for Mixer-to- Client Audio Level Indication [draft-ietf-avtext-mixer-to-client-audio-level-07] (17 pages) - A Real-Time Transport Protocol (RTP) Header Extension for Client-to- Mixer Audio Level Indication [draft-ietf-avtext-client-to-mixer-audio-level-07] (11 pages) - Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) [draft-ietf-avtext-multicast-acq-rtcp-xr-07] (21 pages) - Support for multiple clock rates in an RTP session [draft-ietf-avtext-multiple-clock-rates-02] (13 pages) - Considerations for Deploying the Rapid Acquisition of Multicast RTP Sessions (RAMS) Method [draft-ietf-avtext-rams-scenarios-02] (11 pages) - Content Splicing for RTP Sessions [draft-ietf-avtext-splicing-for-rtp-05] (17 pages) Requests for Comments: RFC6332: Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) (16 pages) RFC6464: A Real-Time Transport Protocol (RTP) Header Extension for Client-to- Mixer Audio Level Indication (9 pages) RFC6465: A Real-Time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication (15 pages) Audio/Video Transport Payloads (payload) ---------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Roni Even Ali Begen Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: General Discussion: payload@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/payload Archive: http://www.ietf.org/mail-archive/web/payload/index.html Description of Working Group: The PAYLOAD working group is tasked with the specification and maintenance of payload formats for use with the Real-Time Transport Protocol, RTP [RFC3550]. The group will follow the guidelines established in "Guidelines for Writers of RTP Payload Format Specifications" [BCP 36], the "How to Write an RTP Payload Format" (under development) and is responsible for maintaining those guidelines. This working group will develop RTP payload formats for new media codecs, review and revise existing payload formats to advance those which are useful to Draft Standard or Standard, and declare others Historic. Goals and Milestones: Done - Submit RTP Payload Format for MIDI for Proposed Standard Feb 2011 - Submit How to Write an RTP Payload Format for Informational Done - Submit RTP Payload Format for MPEG-4 Audio/Visual Streams for Proposed Standard Mar 2011 - Submit RTP Payload Format for EVBR/G.718 for Proposed Standard Mar 2011 - Submit RTP Payload Format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) for Proposed Standard Mar 2011 - Submit RTP Payload Format for Bluetooth's SBC audio codec for Proposed Standard Apr 2011 - Submit RTP Payload Format for MPEG2-TS preamble for Proposed Standard Done - Submit RTP Payload Format for DV (IEC 61834) Video for Proposed Standard Apr 2011 - Submit RTP Payload Format for the iSAC codec for Proposed Standard Apr 2011 - Submit RTP profile for the carriage of SMPTE 336M data for Proposed Standard Jun 2011 - Submit RTP Payload Format for MVC Video for Proposed Standard Aug 2011 - Submit RTP Payload Format for VP8 Video for Proposed Standard Dec 2011 - Submit RTP Payload Format for Opus Speech and Audio Codec as proposed standard Internet-Drafts: - RTP Payload Format for VP8 Video [draft-ietf-payload-vp8-03] (28 pages) - RTP Payload Format for Scalable Video Coding [draft-ietf-avt-rtp-svc-28] (105 pages) - RTP Payload Format for MIDI [draft-ietf-avt-rfc4695-bis-11] (171 pages) - RTP Payload Format for DV (IEC 61834) Video [draft-ietf-avt-rfc3189bis-04] (19 pages) - RTP Payload Format for IP-MR Speech Codec [draft-ietf-avt-rtp-ipmr-16] (20 pages) - RTP Payload Format for G.718 Speech/Audio [draft-ietf-avt-rtp-g718-05] (27 pages) - RTP Payload Format for MVC Video [draft-ietf-avt-rtp-mvc-02] (25 pages) - RTP Payload Format for SMPTE 336M Encoded Data [draft-ietf-avt-rtp-klv-03] (12 pages) - RTP Payload Format for the iSAC Codec [draft-ietf-avt-rtp-isac-00] (10 pages) - RTP Payload Format for MPEG-4 Audio/Visual Streams [draft-ietf-avt-rfc3016bis-03] (32 pages) - RTP payload format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) [draft-ietf-avt-rtp-evrc-nw-05] (30 pages) - RTP Payload Format for Bluetooth's SBC audio codec [draft-ietf-avt-rtp-sbc-01] (23 pages) - RTP Payload Format for MIDI [draft-ietf-payload-rfc4695-bis-03] (181 pages) - How to Write an RTP Payload Format [draft-ietf-payload-rtp-howto-02] (57 pages) - RTP Payload Format for DV (IEC 61834) Video [draft-ietf-payload-rfc3189bis-04] (20 pages) - RTP Payload Format for MVC Video [draft-ietf-payload-rtp-mvc-01] (27 pages) - RTP Payload Format for G.718 Speech/Audio [draft-ietf-payload-rtp-g718-01] (27 pages) - RTP Payload Format for MPEG-4 Audio/Visual Streams [draft-ietf-payload-rfc3016bis-04] (33 pages) - RTP Payload Format for SMPTE 336M Encoded Data [draft-ietf-payload-rtp-klv-03] (12 pages) - RTP Payload Format for Bluetooth's SBC Audio Codec [draft-ietf-payload-rtp-sbc-02] (24 pages) Requests for Comments: RFC6190: RTP Payload Format for Scalable Video Coding (100 pages) RFC6295: RTP Payload Format for MIDI (171 pages) * Obsoletes RFC4695 RFC6262: RTP Payload Format for IP-MR Speech Codec (19 pages) RFC6416: RTP Payload Format for MPEG-4 Audio/Visual Streams (35 pages) * Obsoletes RFC3016 RFC6469: RTP Payload Format for DV (IEC 61834) Video (18 pages) * Obsoletes RFC3189 Authority-to-Citizen Alert (atoca) ---------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Scott Bradner Martin Thomson Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: General Discussion: atoca@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/atoca Archive: http://www.ietf.org/mail-archive/web/atoca Description of Working Group: There are a variety of mechanisms that authorities have available to notify citizens and visitors during emergency events. Traditionally, they have done so with broadcast networks (radio and television). For commercial mobile devices, broadcasting services such as the Public Warning System (PWS), the Earthquake and Tsunami Warning System (ETWS), and the Commercial Mobile Alert System (CMAS) are standardized and are in various stages of deployment. The Internet provides another way for authority-to-citizen alerts to be sent, but it also presents new challenges. While there are some existing layer 2 mechanisms for delivering alerts, the work in this group focuses on delivering alerts to IP endpoints only. The general message pattern that this group is intended to address is the sending of alerts from a set of pre-authorized agents (e.g., governmental agencies) to a large population without undue impacts on the networks serving that population. In particular, the message pattern specified should avoid congestion and other denials of service. The goal of this group is not to specify how originators of alerts obtain authorization, but rather how an ATOCA system can verify authorization and deliver messages to the intended recipients. A critical element of the work are the mechanisms that assure that only those pre-authorized agents can send alerts via ATOCA, through an interface to authorized alert distribution networks (e.g., iPAWS/DM-Open in the U.S.). The ATOCA effort is differentiated from and is not intended to replace other alerting mechanisms (e.g., PWS, CMAS, ETWS), as the recipients of ATOCA alerts are the wide range of devices connected to the Internet and various private IP networks, which humans may have "at hand" to get such events, as well as automatons who may take action based on the alerts. This implies that the content of the alert contains some information, which is intended to be consumed by humans, and some which is intended to be consumed by automatons. Ideally, the alerts would contain, or refer to media other than text media (e.g., audio and/or video). The initial work in the group is focused on small messages, which may be mechanically rendered by the device in other forms (text to speech for example). Future work in the group may investigate rich media. In situations of a major emergency there could be scenarios where there are multiple alerts generated that may require that a priority mechanism (defined by alert originator policy) has to be used. The work on a resource priority mechanism is out of scope of the initial charter, but may be revisited at a later date. Which devices should get alerts is primarily driven by location. The first set of recipients that must be catered for are those within the area identified by the alert originator to be affected by the emergency event. In many jurisdictions, there are regulations that define whether recipients/devices within the affected area have opt-in or opt-out capability, but the protocols ATOCA will define will include both opt-in and opt-out mechanisms. The group will explore how to support both opt-in and opt-out at the level of communication protocols and/or device behavior. Another class of recipients that are in scope of the work are explicit opt-in subscriptions which ask for alerts for a specified location, not necessarily the physical location of the device itself. An example of such a subscription would be 'send me alerts for location x' (previously determined as the location of interest). This work may build on existing IETF GEOPRIV location work. There are efforts in other fora on early warning, which will be considered in this effort. For example, we expect to make use of the OASIS Common Alerting Protocol (CAP) for the encoding of alerts. OGC, ATIS, TIA, ITU-T, ETSI and 3GPP also have alert efforts underway, and consultation with these efforts will be undertaken to avoid unnecessary duplication of effort and also to avoid unintentional negative impacts on the networks. Of course, existing protocols for delivering messages (e.g., SIP, XMPP, or SMTP) will be the basis for the message delivery system of this working group. Any service discovery mechanisms defined by the group are expected to reuse existing discovery frameworks. The security implications of mechanisms that can send alerts to billions of devices are profound, but the utility of the mechanism encourages us to face the problems and solve them. In addition, the potential performance and congestion impacts to networks resulting from sending alert information to billions of devices must be considered and solved if such a service is implementable. To avoid manual configuration of servers distributing alerts a discovery mechanism will be specified. Goals and Milestones: Jan 2011 - Submit 'Terminology and Framework' to the IESG for publication as Informational Apr 2011 - Submit 'Addressing security, performance and congestion issues for alert distribution' to the IESG for publication as Informational Apr 2011 - Submit conveying point-to-point Authority to Citizen Alerts to the IESG for publication as Proposed Standard May 2011 - Submit 'Discovering alerting servers' to the IESG for publication as Proposed Standard Jun 2011 - Submit conveying point-to-multipoint Authority to Citizen Alerts to the IESG for publication as Proposed Standard Aug 2011 - Submit 'Considerations for interworking with currently deployed alert distribution systems' to the IESG for publication as Informational Internet-Drafts: - Requirements, Terminology and Framework for Exigent Communications [draft-ietf-atoca-requirements-02] (16 pages) No Requests for Comments Basic Level of Interoperability for SIP Services (bliss) -------------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chair: Shida Schubert Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Robert Sparks Tech Advisor: Jonathan Rosenberg Mailing Lists: General Discussion: bliss@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/bliss Archive: http://www.ietf.org/mail-archive/web/bliss Description of Working Group: The focus of the group is to facilitate effective feature interoperability for features sharing common functional primitives utilizing SIP in heterogeneous network environments as noted below. SIP's approach to supporting more advanced features and applications has been to specify a number of primitive operations, including refer, dialog replacement and joining, and event packages, and then to allow those primitives to be combined in many ways to realize different features. This approach avoids the need for standardized definitions of a feature, which can severely limit innovation and broad applicability. While this approach brings great flexibility and generality, it complicates interoperability. Without any kind of standardized definition of a particular feature, each implementation creates its own definition and corresponding set of call flows and primitives used to realize this feature. In practice, this has resulted in a poor track record for interoperability for more advanced features which make assumptions on supported SIP extensions and behaviors from other elements. The problem is exacerbated by the desire for these features to work across many types of SIP endpoints, including SIP hardphones, softphones, and gateways to the PSTN and other VoIP networks including non-centralized environments, and for the desire to work across domain boundaries and to interwork with the PSTN, when applicable. The focus will not be on rigorous definition of what the specific feature is and exactly how it works. Rather, the focus will be on documenting the variations that exist in the wild sharing common interop problems, figuring out a minimum baseline requirement for a UA and servers (minimum set of primitives etc.), defining minimum levels of functionality and functional primitives required to realize a broad class of related features, and on interoperating with other elements which might implement one of those features in different ways. The BLISS working group will coordinate closely with the SIP and SIPPING working groups. Like SIPPING, its role is to focus on applications of the SIP protocol and not on core extensions to SIP itself. The difference between SIPPING and BLISS, is that BLISS is focused on a particular type of SIP application - call features, and in particular, advanced call features requiring non-trivial call control. SIP applications such as configuration, presence, SIP extensions for IM, and session policy are clearly out of scope for BLISS and remain the sole province of SIPPING. Of course, any features considered by BLISS will support the full range of multimedia supported by SIP - audio, video, text, messaging, and so on. The BLISS working group will focus on resolving interpretability issues on four functional primitives as an initial milestone. Summary for each of the functional primitives are as follows. A "Problem Statement" document will also be charted as the first deliverable of this working group. This document will describe the problem this working group is trying to address, the criteria to be met for items to be accepted and a template for documenting a draft for this working group. Line Sharing Description: this covers the functionality required for multiple UA instances to be able to see and utilize sessions made to/from either one. It covers a range of features including: * multiple call appearances * call suspend/resume * retrieve * conference across appearances Parking Description: this covers functionality required to move calls from one instance to another without pre-arranged knowledge of the set of instances on which the call is to be shared. Basically a dynamic version of line sharing in a sense. It would cover features including: * park * park