appsawg hybi core eai httpbis iri marf precis paws repute spfbis sieve urnbis websec vcarddav ancp csi dnsext dmm dhc homenet hip 6man 6lowpan intarea l2tpext lwig lisp mip4 multimob mif ntp netext pppext pcp softwire savi tictoc trill sunset4 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 insipid codec mediactrl xrblock mmusic p2psip rtcweb sipclf soc siprec simple sipcore salud speechsc vipr bfd ccamp forces isis idr karp l2vpn l3vpn manet mpls nvo3 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: Alexey Melnikov Murray Kucherawy Applications Area Directors: Barry Leiba Pete Resnick Applications Area Advisor: Barry Leiba 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 Internationalized Domain Names for Applications (IDNA) - Unicode 6.0 [draft-faltstrom-5892bis-05] (5 pages) - Additional Media Type Structured Syntax Suffixes [draft-hansen-media-type-suffix-regs-02] (7 pages) - The "about" URI Scheme [draft-ietf-appsawg-about-uri-scheme-04] (7 pages) - Email Greylisting: An Applicability Statement for SMTP [draft-ietf-appsawg-greylisting-09] (17 pages) - Forwarded HTTP Extension [draft-ietf-appsawg-http-forwarded-02] (12 pages) - JSON Patch [draft-ietf-appsawg-json-patch-01] (12 pages) - JSON Pointer [draft-ietf-appsawg-json-pointer-01] (7 pages) - Best Current Practices for Handling of Malformed Messages [draft-ietf-appsawg-malformed-mail-01] (10 pages) - Media Type Specifications and Registration Procedures [draft-ietf-appsawg-media-type-regs-07] (31 pages) - Additional Media Type Structured Syntax Suffixes [draft-ietf-appsawg-media-type-suffix-regs-00] (9 pages) - Update to MIME regarding Charset Parameter Handling in Textual Media Types [draft-ietf-appsawg-mime-default-charset-04] (6 pages) - Indicating Email Handling States in Trace Fields [draft-ietf-appsawg-received-state-00] (11 pages) - The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages [draft-ietf-appsawg-rfc3462bis-04] (18 pages) - Terminology Used in Internationalization in the IETF [draft-ietf-appsawg-rfc3536bis-06] (46 pages) - Deprecating the X- Prefix and Similar Constructs in Application Protocols [draft-ietf-appsawg-xdash-05] (13 pages) - WebFinger [draft-jones-appsawg-webfinger-04] (21 pages) - Simple Web Discovery (SWD) [draft-jones-simple-web-discovery-02] (9 pages) - Indicating Email Handling States in Trace Fields [draft-kucherawy-received-state-02] (10 pages) - Spam reporting using IMAP: SREP [draft-ordogh-spam-reporting-using-imap-02] (16 pages) Requests for Comments: BCP0166: Terminology Used in Internationalization in the IETF (46 pages) * Obsoletes RFC3536 RFC6365: Terminology Used in Internationalization in the IETF (46 pages) * Obsoletes RFC3536 RFC6452: The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) - Unicode 6.0 (5 pages) RFC6522: The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages (18 pages) * Replaces DRAFT-KUCHERAWY-RFC3462BIS * Obsoletes RFC3462 * Updates RFC6533 STD0073: The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages (18 pages) * Replaces DRAFT-KUCHERAWY-RFC3462BIS * 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: Barry Leiba Pete Resnick Applications Area Advisor: Barry Leiba 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/ Description of Working Group: The BiDirectional or Server-Initiated HTTP (HyBi) working group defines the WebSocket Protocol, a technology for bidirectional communication between an HTTP client and an HTTP server that provides greater efficiency than previous approaches (e.g., use of hanging requests or long polling). Having completed work on the core protocol (RFC 6455), the group continues to define extensions for use by WebSocket implementations. The following extensions and optimizations are currently in scope: 1. A per-frame compression extension to improve bandwidth usage (draft-tyoshino-hybi-websocket-perframe-deflate is a likely starting point). 2. A multiplexing extension to improve the scalability of the WebSocket protocol (draft-tamplin-hybi-google-mux is a likely starting point). 3. Timeout-handling capabilities to reduce the chattiness of the protocol (draft-thomson-hybi-http-timeout is a likely starting point). The working group will also serve as a discussion venue for subprotocols. However, no subprotocol is currently chartered as a deliverable, and the WG must be rechartered to work on any subprotocols. The group will not work on an updated version of the WebSocket protocol, unless it is specifically rechartered to do so. The group will continue coordinating with the W3C WepApps working group with respect to the above deliverables and to ensure the best match possible between the WebSocket protocol and the WebSocket API. The group will also continue coordinating with other working groups within the IETF (e.g., HTTPBIS) as appropriate. Goals and Milestones: Feb 2012 - Adopt a WG item for the per-frame compression extension May 2012 - Issue WG last call on the per-frame compression extension Jun 2012 - Send per-frame compression extension to IESG for consideration as a Proposed Standard Jun 2012 - Adopt a WG item for timeout handling Jul 2012 - Adopt a WG for the multiplexing extension Aug 2012 - Issue WG last call on timeout handling Sep 2012 - Issue WG last call on the multiplexing extension Oct 2012 - Send timeout handling to IESG for consideration as a Proposed Standard Nov 2012 - end multiplexing extension to IESG for consideration as a Proposed Standard Internet-Drafts: - Design Space for Bidirectional Protocols [draft-ietf-hybi-design-space-00] (9 pages) - The WebSocket Protocol [draft-ietf-hybi-thewebsocketprotocol-17] (77 pages) - A Multiplexing Extension for WebSockets [draft-ietf-hybi-websocket-multiplexing-01] (33 pages) - WebSocket Per-frame Compression [draft-ietf-hybi-websocket-perframe-compression-03] (16 pages) - HyBi WebSocket Requirements and Features [draft-ietf-hybi-websocket-requirements-02] (9 pages) Requests for Comments: RFC6455: The WebSocket Protocol (77 pages) * Replaces DRAFT-HIXIE-THEWEBSOCKETPROTOCOL Constrained RESTful Environments (core) --------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Cullen Jennings Dr. Carsten Bormann Applications Area Directors: Barry Leiba Pete Resnick Applications Area Advisor: Barry Leiba 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/ 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: - Blockwise transfers in CoAP [draft-ietf-core-block-08] (30 pages) - Constrained Application Protocol (CoAP) [draft-ietf-core-coap-09] (91 pages) - Group Communication for CoAP [draft-ietf-core-groupcomm-01] (34 pages) - CoRE Link Format [draft-ietf-core-link-format-11] (20 pages) - Observing Resources in CoAP [draft-ietf-core-observe-05] (27 pages) No Requests for Comments Email Address Internationalization (eai) ---------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: John C. Klensin Joseph Yee Applications Area Directors: Barry Leiba Pete Resnick 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: - IMAP Support for UTF-8 [draft-ietf-eai-5378bis-00] (15 pages) - IMAP Support for UTF-8 [draft-ietf-eai-5738bis-03] (14 pages) - Downgrading Mechanism for Email Address Internationalization [draft-ietf-eai-downgrade-12] (28 pages) - Displaying Downgraded Messages for Email Address Internationalization [draft-ietf-eai-downgraded-display-03] (15 pages) - Internationalized Delivery Status and Disposition Notifications [draft-ietf-eai-dsn-06] (19 pages) - Internationalized Delivery Status and Disposition Notifications [draft-ietf-eai-dsnbis-01] (17 pages) - Guidelines for Internationalized Email Clients [draft-ietf-eai-email-clients-00] (16 pages) - Overview and Framework for Internationalized Email [draft-ietf-eai-framework-05] (23 pages) - Overview and Framework for Internationalized Email [draft-ietf-eai-frmwrk-4952bis-12] (30 pages) - IMAP Support for UTF-8 [draft-ietf-eai-imap-utf8-09] (15 pages) - Mailing Lists and Internationalized Email Addresses [draft-ietf-eai-mailinglist-07] (12 pages) - Mailing Lists and UTF-8 Addresses [draft-ietf-eai-mailinglistbis-01] (8 pages) - An update to the mailto URI scheme for Email Address Internationalization [draft-ietf-eai-mailto-01] (6 pages) - POP3 Support for UTF-8 [draft-ietf-eai-pop-09] (17 pages) - Post-delivery Message Downgrading for Internationalized Email Messages [draft-ietf-eai-popimap-downgrade-05] (20 pages) - Internationalized Email Headers [draft-ietf-eai-rfc5335bis-13] (14 pages) - SMTP Extension for Internationalized Email [draft-ietf-eai-rfc5336bis-16] (21 pages) - Internationalized Delivery Status and Disposition Notifications [draft-ietf-eai-rfc5337bis-dsn-06] (19 pages) - POP3 Support for UTF-8 [draft-ietf-eai-rfc5721bis-04] (14 pages) - UTF-8 Mail: Scenarios [draft-ietf-eai-scenarios-03] (9 pages) - EAI: Simplified POP/IMAP downgrading [draft-ietf-eai-simpledowngrade-04] (8 pages) - SMTP Extension for Internationalized Email Addresses [draft-ietf-eai-smtpext-13] (24 pages) - Internationalized Email Headers [draft-ietf-eai-utf8headers-12] (17 pages) Requests for Comments: RFC4952: Overview and Framework for Internationalized Email (23 pages) * Obsoletes RFC6530 * Updates RFC5336 RFC5335: Internationalized Email Headers (17 pages) * Updates RFC2045 * Updates RFC2822 * Obsoletes RFC6532 RFC5336: SMTP Extension for Internationalized Email Addresses (24 pages) * Updates RFC2821 * Updates RFC2822 * Updates RFC4952 * Obsoletes RFC6531 RFC5337: Internationalized Delivery Status and Disposition Notifications (19 pages) * Updates RFC3461 * Updates RFC3462 * Updates RFC3464 * Updates RFC3798 * Obsoletes RFC6533 RFC5504: Downgrading Mechanism for Email Address Internationalization (28 pages) * Obsoletes RFC6530 RFC5721: POP3 Support for UTF-8 (17 pages) RFC5738: IMAP Support for UTF-8 (15 pages) * Updates RFC3501 RFC5825: Displaying Downgraded Messages for Email Address Internationalization (15 pages) * Replaces DRAFT-FUJIWARA-EAI-DOWNGRADED-DISPLAY * Obsoletes RFC6530 RFC5983: Mailing Lists and Internationalized Email Addresses (12 pages) RFC6530: Overview and Framework for Internationalized Email (30 pages) * Obsoletes RFC4952 * Obsoletes RFC5504 * Obsoletes RFC5825 RFC6531: SMTP Extension for Internationalized Email (21 pages) * Obsoletes RFC5336 RFC6532: Internationalized Email Headers (14 pages) * Updates RFC2045 * Obsoletes RFC5335 RFC6533: Internationalized Delivery Status and Disposition Notifications (19 pages) * Updates RFC3461 * Updates RFC3464 * Updates RFC3798 * Obsoletes RFC5337 * Updates RFC6522 Hypertext Transfer Protocol Bis (httpbis) ----------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chair: Mark Nottingham Applications Area Directors: Barry Leiba Pete Resnick Applications Area Advisor: Barry Leiba 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: This Working Group is charged with maintaining and developing the "core" specifications for HTTP. The Working Group's specification deliverables are: * A document (or set of documents) that is suitable to supersede RFC 2616 (HTTP/1.1) and move RFC 2817 to Historic status * A document cataloguing the security properties of HTTP/1.1 * A document that specifies HTTP/2.0, an improved binding of HTTP's semantics to an underlying transport. HTTP/1.1 -------- 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 HTTP/2.0 -------- There is emerging implementation experience and interest in a protocol that retains the semantics of HTTP, without the legacy of HTTP/1.x message framing and syntax, which have been identified as hampering performance and encouraging misuse of the underlying transport. As such, there is an opportunity to create a new major (non-wire-compatible) version of HTTP. To do this, the Working Group will solicit candidates for this work from the community, to be submitted as Internet-Drafts. Expected focus areas for candidates include: * Significantly improved perceived performance in common use cases (e.g., browsers, mobile) * More efficient use of network resources; in particular, reducing the need to use multiple TCP connections * Ability to be deployed on today's Internet, using IPv4 and IPv6, in the presence of NATs * Maintaining HTTP's ease of deployment * Reflecting modern security requirements and practices With regard to security requirements, in the initial phase of work on HTTP/2.0, new proposals for authentication schemes can be made. The WG will have a a goal of choosing at least one scheme that is better than those available for HTTP/1.x. However, the WG might select zero schemes. In addition, non-selected schemes might be discussed with the IETF Security Area for further work there. Although proposals are not required to meet all of these goals, it is expected that the resulting work (if undertaken) will be chartered to meet them (and therefore, selecting one that meets the majority of them as a starting point is in everyone's interest). The Working Group will then select a starting point for the new work based upon the following criteria: * Compatibility with HTTP/1.1 semantics; i.e., it must be possible to pass through a HTTP/1.1 message with reasonable fidelity * Broad implementer interest (e.g., from Web browsers, "back-end" or "web api" uses of HTTP, servers, intermediaries, CDNs, etc.) Changes to the existing semantics of HTTP are out of scope in order to preserve the meaning of messages that might cross a 1.1 --> 2.0 --> 1.1 request chain. However, the resulting effort may define new semantics to further the goals above, along with suitable extensibility mechanisms for defining additional semantics. If the Working Group forms consensus around a proposal to use as a starting point, it is expected it will re-charter to begin work on that document (or set of documents). The resulting work will be known as "HTTP/2.0", unless the Working Group determines that this isn't suitable (e.g., for interoperability). Although work on this new version will begin in parallel with completion of work on HTTP/1.1, the Working Group will prioritize HTTP/1.1 work until it is complete. Goals and Milestones: Done - First HTTP/1.1 Revision Internet Draft Done - First HTTP Security Properties Internet Draft Mar 2012 - Working Group Last Call for HTTP/1.1 Revision Mar 2012 - Call for Proposals for HTTP/2.0 Jun 2012 - Working Group Last Call for HTTP Security Properties Jul 2012 - Submit HTTP/1.1 Revision to IESG for consideration as a Proposed Standard Jul 2012 - Submit HTTP Security Properties to IESG for consideration as Informational RFC Aug 2012 - Re-charter to work on HTTP/2.0 Internet-Drafts: - Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations [draft-ietf-httpbis-authscheme-registrations-03] (4 pages) - Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) [draft-ietf-httpbis-content-disp-09] (17 pages) - Initial Hypertext Transfer Protocol (HTTP) Method Registrations [draft-ietf-httpbis-method-registrations-07] (6 pages) - HTTP/1.1, part 1: URIs, Connections, and Message Parsing [draft-ietf-httpbis-p1-messaging-19] (92 pages) - HTTP/1.1, part 2: Message Semantics [draft-ietf-httpbis-p2-semantics-19] (73 pages) - HTTP/1.1, part 3: Message Payload and Content Negotiation [draft-ietf-httpbis-p3-payload-19] (43 pages) - HTTP/1.1, part 4: Conditional Requests [draft-ietf-httpbis-p4-conditional-19] (28 pages) - HTTP/1.1, part 5: Range Requests and Partial Responses [draft-ietf-httpbis-p5-range-19] (28 pages) - HTTP/1.1, part 6: Caching [draft-ietf-httpbis-p6-cache-19] (47 pages) - HTTP/1.1, part 7: Authentication [draft-ietf-httpbis-p7-auth-19] (22 pages) - Security Requirements for HTTP [draft-ietf-httpbis-security-properties-05] (14 pages) Requests for Comments: RFC6266: Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) (17 pages) * Replaces DRAFT-RESCHKE-RFC2183-IN-HTTP * Updates RFC2616 Internationalized Resource Identifiers (iri) -------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Chris Weber Peter Saint-Andre Applications Area Directors: Barry Leiba Pete Resnick Applications Area Advisor: Pete Resnick 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-11] (40 pages) - Guidelines and Registration Procedures for New URI/IRI Schemes [draft-ietf-iri-4395bis-irireg-04] (16 pages) - Guidelines for Internationalized Resource Identifiers with Bi- directional Characters (Bidi IRIs) [draft-ietf-iri-bidi-guidelines-02] (10 pages) - Equivalence and Canonicalization of Internationalized Resource Identifiers (IRIs) [draft-ietf-iri-comparison-01] (14 pages) No Requests for Comments Messaging Abuse Reporting Format (marf) --------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chair: Murray Kucherawy Applications Area Directors: Barry Leiba Pete Resnick Applications Area Advisor: Barry Leiba 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: - Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF) [draft-ietf-marf-as-16] (15 pages) - Authentication Failure Reporting Using the Abuse Reporting Format [draft-ietf-marf-authfailure-report-10] (21 pages) - An Extensible Format for Email Feedback Reports [draft-ietf-marf-base-06] (38 pages) - Extensions to DKIM for Failure Reporting [draft-ietf-marf-dkim-reporting-16] (23 pages) - Email Feedback Report Type Value: not-spam [draft-ietf-marf-not-spam-feedback-03] (7 pages) - Redaction of Potentially Sensitive Data from Mail Abuse Reports [draft-ietf-marf-redaction-08] (8 pages) - A DNS TXT Record for Advertising and Discovering Willingness to Provide or Receive ARF Reports [draft-ietf-marf-reporting-discovery-01] (14 pages) - SPF Authentication Failure Reporting using the Abuse Report Format [draft-ietf-marf-spf-reporting-10] (13 pages) Requests for Comments: RFC5965: An Extensible Format for Email Feedback Reports (38 pages) * Replaces DRAFT-SHAFRANOVICH-FEEDBACK-REPORT RFC6430: Email Feedback Report Type Value: not-spam (7 pages) * Replaces DRAFT-LI-MARF-NOT-SPAM-FEEDBACK RFC6590: Redaction of Potentially Sensitive Data from Mail Abuse Reports (8 pages) * Replaces DRAFT-JDFALK-MARF-REDACTION RFC6591: Authentication Failure Reporting Using the Abuse Reporting Format (21 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: Barry Leiba Pete Resnick 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: - PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols [draft-ietf-precis-framework-03] (63 pages) - Stringprep Revision Problem Statement [draft-ietf-precis-problem-statement-05] (30 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: Barry Leiba Pete Resnick Applications Area Advisor: Pete Resnick 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-04] (42 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: Barry Leiba Pete Resnick 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 Reputation Response Set for Email Identifiers [draft-ietf-repute-email-identifiers-03] (7 pages) - A Media Type for Reputation Interchange [draft-ietf-repute-media-type-02] (12 pages) - A Model for Reputation Reporting [draft-ietf-repute-model-01] (10 pages) - Reputation Data Interchange using HTTP and JSON [draft-ietf-repute-query-http-02] (7 pages) No Requests for Comments SPF Update (spfbis) ------------------- Charter Last Modified: 2012-02-07 Current Status: Active Chairs: S Moonesamy Andrew Sullivan Applications Area Directors: Barry Leiba Pete Resnick 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: - Resolution of The SPF and Sender ID Experiments [draft-ietf-spfbis-experiment-09] (12 pages) No Requests for Comments Sieve Mail Filtering Language (sieve) ------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Dr. Cyrus Daboo Aaron Stone Applications Area Directors: Barry Leiba Pete Resnick 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/ 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 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 - WGLC Notify-sip Jun 2010 - Submit Include/multi-script to IESG 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: Ihave Extension [draft-freed-sieve-ihave-04] (7 pages) - Sieve Email Filtering: Sieves and Display Directives in XML [draft-freed-sieve-in-xml-07] (33 pages) - Sieve Email Filtering: Delivery Status Notifications and Deliver-By Extensions [draft-freed-sieve-notary-09] (16 pages) - Sieve: An Email Filtering Language [draft-ietf-sieve-3028bis-13] (45 pages) - Sieve Email Filtering: Relational Extension [draft-ietf-sieve-3431bis-04] (15 pages) - Sieve Email Filtering: Use of Presence Information with Auto-Responder Functionality [draft-ietf-sieve-autoreply-04] (10 pages) - Sieve Email Filtering: Body Extension [draft-ietf-sieve-body-09] (13 pages) - Sieve Extension for Converting Messages before Delivery [draft-ietf-sieve-convert-06] (9 pages) - Sieve Email Filtering: Editheader Extension [draft-ietf-sieve-editheader-11] (12 pages) - Sieve Extension: Externally Stored Lists [draft-ietf-sieve-external-lists-10] (18 pages) - Support for Internet Message Access Protocol (IMAP) Events in Sieve [draft-ietf-sieve-imap-sieve-03] (25 pages) - Sieve Email Filtering: Imap4flags Extension [draft-ietf-sieve-imapflags-05] (0 pages) - Sieve Email Filtering: Include Extension [draft-ietf-sieve-include-15] (17 pages) - A Protocol for Remotely Managing Sieve Scripts [draft-ietf-sieve-managesieve-09] (52 pages) - Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure [draft-ietf-sieve-mime-loop-09] (22 pages) - Sieve Email Filtering: Extension for Notifications [draft-ietf-sieve-notify-12] (23 pages) - Sieve Notification Mechanism: mailto [draft-ietf-sieve-notify-mailto-10] (17 pages) - Sieve Notification Using Presence Information [draft-ietf-sieve-notify-presence-04] (9 pages) - Sieve Notification Mechanism: SIP MESSAGE [draft-ietf-sieve-notify-sip-message-08] (11 pages) - Sieve Notification Mechanism: Extensible Messaging and Presence Protocol (XMPP) [draft-ietf-sieve-notify-xmpp-09] (15 pages) - Sieve Email Filtering: Reject and Extended Reject Extensions [draft-ietf-sieve-refuse-reject-09] (15 pages) - Sieve Email Filtering: Regular Expression Extension [draft-ietf-sieve-regex-01] (9 pages) - Sieve Email Filtering: Subaddress Extension [draft-ietf-sieve-rfc3598bis-05] (13 pages) - Sieve Email Filtering: Spamtest and Virustest Extensions [draft-ietf-sieve-spamtestbis-05] (16 pages) - Sieve Email Filtering: Vacation Extension [draft-ietf-sieve-vacation-07] (16 pages) - Sieve Vacation Extension: "Seconds" Parameter [draft-ietf-sieve-vacation-seconds-03] (6 pages) - Sieve Email Filtering: Variables Extension [draft-ietf-sieve-variables-08] (16 pages) - The Sieve Mail-Filtering Language -- Extensions for Checking Mailbox Status and Accessing Mailbox Metadata [draft-melnikov-sieve-imapext-metadata-08] (10 pages) Requests for Comments: RFC5173: Sieve Email Filtering: Body Extension (13 pages) * Replaces DRAFT-DEGENER-SIEVE-BODY * Updates RFC5229 RFC5228: Sieve: An Email Filtering Language (45 pages) * Obsoletes RFC3028 * Updates RFC5229 * Updates RFC5429 RFC5229: Sieve Email Filtering: Variables Extension (16 pages) * Replaces DRAFT-HOMME-SIEVE-VARIABLES * Updates RFC5228 * Updates RFC5173 RFC5230: Sieve Email Filtering: Vacation Extension (16 pages) * Replaces DRAFT-SHOWALTER-SIEVE-VACATION RFC5231: Sieve Email Filtering: Relational Extension (15 pages) * Obsoletes RFC3431 RFC5232: Sieve Email Filtering: Imap4flags Extension (0 pages) * Replaces DRAFT-MELNIKOV-SIEVE-IMAPFLAGS RFC5233: Sieve Email Filtering: Subaddress Extension (13 pages) * Obsoletes RFC3598 RFC5235: Sieve Email Filtering: Spamtest and Virustest Extensions (16 pages) * Obsoletes RFC3685 RFC5293: Sieve Email Filtering: Editheader Extension (12 pages) * Replaces DRAFT-DEGENER-SIEVE-EDITHEADER RFC5429: Sieve Email Filtering: Reject and Extended Reject Extensions (15 pages) * Obsoletes RFC3028 * Updates RFC5228 RFC5435: Sieve Email Filtering: Extension for Notifications (23 pages) * Replaces DRAFT-MARTIN-SIEVE-NOTIFY RFC5436: Sieve Notification Mechanism: mailto (17 pages) * Updates RFC3834 RFC5437: Sieve Notification Mechanism: Extensible Messaging and Presence Protocol (XMPP) (15 pages) * Replaces DRAFT-SAINTANDRE-SIEVE-NOTIFY-XMPP RFC5463: Sieve Email Filtering: Ihave Extension (7 pages) RFC5490: The Sieve Mail-Filtering Language -- Extensions for Checking Mailbox Status and Accessing Mailbox Metadata (10 pages) RFC5703: Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure (22 pages) * Replaces DRAFT-HANSEN-SIEVE-LOOP RFC5784: Sieve Email Filtering: Sieves and Display Directives in XML (33 pages) RFC5804: A Protocol for Remotely Managing Sieve Scripts (52 pages) * Replaces DRAFT-MARTIN-MANAGESIEVE RFC6009: Sieve Email Filtering: Delivery Status Notifications and Deliver-By Extensions (16 pages) RFC6131: Sieve Vacation Extension: "Seconds" Parameter (6 pages) * Replaces DRAFT-GEORGE-SIEVE-VACATION-TIME RFC6132: Sieve Notification Using Presence Information (9 pages) * Replaces DRAFT-GEORGE-SIEVE-NOTIFY-PRESENCE RFC6133: Sieve Email Filtering: Use of Presence Information with Auto-Responder Functionality (10 pages) * Replaces DRAFT-GEORGE-SIEVE-AUTOREPLY RFC6134: Sieve Extension: Externally Stored Lists (18 pages) * Replaces DRAFT-MELNIKOV-SIEVE-EXTERNAL-LISTS RFC6468: Sieve Notification Mechanism: SIP MESSAGE (11 pages) * Replaces DRAFT-MELNIKOV-SIEVE-NOTIFY-SIP-MESSAGE RFC6558: Sieve Extension for Converting Messages before Delivery (9 pages) * Replaces DRAFT-MELNIKOV-SIEVE-CONVERT RFC6609: Sieve Email Filtering: Include Extension (17 pages) * Replaces DRAFT-DABOO-SIEVE-INCLUDE Uniform Resource Names, Revised (urnbis) ---------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Andrew Newton Alfred Hoenes Applications Area Directors: Barry Leiba Pete Resnick Applications Area Advisor: Barry Leiba 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/ 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-02] (32 pages) - Using International Standard Serial Numbers as Uniform Resource Names [draft-ietf-urnbis-rfc3044bis-issn-urn-00] (19 pages) - Using International Standard Book Numbers as Uniform Resource Names [draft-ietf-urnbis-rfc3187bis-isbn-urn-02] (21 pages) - Using National Bibliography Numbers as Uniform Resource Names [draft-ietf-urnbis-rfc3188bis-nbn-urn-03] (19 pages) - Uniform Resource Name (URN) Namespace Definition Mechanisms [draft-ietf-urnbis-rfc3406bis-urn-ns-reg-02] (30 pages) No Requests for Comments Web Security (websec) --------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Tobias Gondrom Alexey Melnikov Applications Area Directors: Barry Leiba Pete Resnick Applications Area Advisor: Barry Leiba 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/ 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: Done - 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. Done - Submit 'Web Origin Concept' to the IESG for consideration as a Standards Track RFC. Apr 2012 - Submit 'Strict Transport Security' to the IESG for consideration as a Standards Track RFC. Apr 2012 - Adopt 'Frame-Options' as initial WG item. Apr 2012 - Adopt 'X-Frame-Options' as initial WG item. Aug 2012 - Submit 'Public Key Pinning Extension for HTTP' to the IESG for consideration as a Standards Track RFC. Aug 2012 - Submit 'Media Type Sniffing' to the IESG for consideration as a Standards Track RFC. Oct 2012 - Submit 'X-Frame-Options' to the IESG for consideration as a Informational Track RFC. Nov 2012 - Submit 'Frame-Options' to the IESG for consideration as a Standards Track RFC. Feb 2013 - Submit 'HTTP Application Security Problem Statement and Requirements' to the IESG for consideration as an Informational RFC. Internet-Drafts: - HTTP Header Frame Options [draft-gondrom-frame-options-02] (9 pages) - HTTP Header X-Frame-Options [draft-gondrom-x-frame-options-00] (9 pages) - Public Key Pinning Extension for HTTP [draft-ietf-websec-key-pinning-01] (16 pages) - Media Type Sniffing [draft-ietf-websec-mime-sniff-03] (24 pages) - The Web Origin Concept [draft-ietf-websec-origin-06] (26 pages) - HTTP Strict Transport Security (HSTS) [draft-ietf-websec-strict-transport-sec-07] (45 pages) Requests for Comments: RFC6454: The Web Origin Concept (26 pages) vCard and CardDAV (vcarddav) ---------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chair: Simon Perreault Applications Area Directors: Barry Leiba Pete Resnick Applications Area Advisor: Pete Resnick 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 Format Extensions: Place of Birth, Place and Date of Death [draft-ietf-vcarddav-birth-death-extensions-02] (6 pages) - CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV) [draft-ietf-vcarddav-carddav-10] (56 pages) - vCard KIND:application [draft-ietf-vcarddav-kind-app-00] (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-02] (12 pages) - vCard Format Extension : To Represent the Social Network Information of an Individual [draft-ietf-vcarddav-social-networks-00] (12 pages) - vCard Format Specification [draft-ietf-vcarddav-vcardrev-22] (89 pages) - xCard: vCard XML Representation [draft-ietf-vcarddav-vcardxml-11] (25 pages) - Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV) [draft-ietf-vcarddav-webdav-mkcol-06] (13 pages) Requests for Comments: RFC5689: Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV) (13 pages) * Updates RFC4791 * Updates RFC4918 RFC6350: vCard Format Specification (89 pages) * Replaces DRAFT-RESNICK-VCARDDAV-VCARDREV * Obsoletes RFC2425 * Obsoletes RFC2426 * Updates RFC2739 * Obsoletes RFC4770 RFC6351: xCard: vCard XML Representation (25 pages) * Replaces DRAFT-PERREAULT-VCARDDAV-VCARDXML RFC6352: CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV) (56 pages) RFC6473: vCard KIND:application (6 pages) * Replaces DRAFT-SAINTANDRE-VCARDDAV-THING RFC6474: vCard Format Extensions: Place of Birth, Place and Date of Death (6 pages) * Replaces DRAFT-LI-VCARDDAV-VCARD-ID-PROPERTY-EXTENSIONS Access Node Control Protocol (ancp) ----------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Wojciech Dec Matthew Bocci Internet Area Directors: Ralph Droms Brian Haberman Internet Area Advisor: Ralph E. 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/ 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-13] (53 pages) - Multicast Control Extensions for ANCP [draft-ietf-ancp-mc-extensions-07] (97 pages) - Access Node Control Protocol (ANCP) MIB module for Access Nodes [draft-ietf-ancp-mib-an-09] (36 pages) - Applicability of Access Node Control Mechanism to PON based Broadband Networks [draft-ietf-ancp-pon-02] (35 pages) - Protocol for Access Node Control Mechanism in Broadband Networks [draft-ietf-ancp-protocol-17] (82 pages) - Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) [draft-ietf-ancp-security-threats-08] (18 pages) Requests for Comments: RFC5713: Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) (18 pages) * Replaces DRAFT-MOUSTAFA-ANCP-SECURITY-THREATS RFC5851: Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks (53 pages) * Replaces DRAFT-OOGHE-ANCP-FRAMEWORK RFC6320: Protocol for Access Node Control Mechanism in Broadband Networks (82 pages) Cga & Send maIntenance (csi) ---------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Marcelo Bagnulo Gabriel Montenegro Internet Area Directors: Ralph Droms Brian Haberman Internet Area Advisor: Ralph E. 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/ 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: - Analysis of Possible DHCPv6 and CGA Interactions [draft-ietf-csi-dhcpv6-cga-ps-09] (11 pages) - The Secure Neighbor Discovery (SEND) Hash Threat Analysis [draft-ietf-csi-hash-threat-12] (7 pages) - Secure Proxy ND Support for SEcure Neighbor Discovery (SEND) [draft-ietf-csi-proxy-send-05] (29 pages) - Certificate Profile and Certificate Management for SEcure Neighbor Discovery (SEND) [draft-ietf-csi-send-cert-10] (21 pages) - Subject Key Identifier (SKI) SEcure Neighbor Discovery (SEND) Name Type Fields [draft-ietf-csi-send-name-type-registry-06] (6 pages) - Securing Neighbor Discovery Proxy: Problem Statement [draft-ietf-csi-sndp-prob-04] (22 pages) Requests for Comments: RFC5909: Securing Neighbor Discovery Proxy: Problem Statement (22 pages) * Replaces DRAFT-DALEY-CSI-SNDP-PROB RFC6273: The Secure Neighbor Discovery (SEND) Hash Threat Analysis (7 pages) * Replaces DRAFT-KUKEC-CSI-HASH-THREAT RFC6494: Certificate Profile and Certificate Management for SEcure Neighbor Discovery (SEND) (21 pages) * Updates RFC3971 RFC6495: Subject Key Identifier (SKI) SEcure Neighbor Discovery (SEND) Name Type Fields (6 pages) * Updates RFC3971 RFC6496: Secure Proxy ND Support for SEcure Neighbor Discovery (SEND) (29 pages) * Replaces DRAFT-KRISHNAN-CSI-PROXY-SEND DNS Extensions (dnsext) ----------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Olafur Gudmundsson Andrew Sullivan Internet Area Directors: Ralph Droms Brian Haberman Internet Area Advisor: Ralph E. 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 Done - EDNS0-bis update advanced to IESG Done - DNAME-bis to IESG Done - Decision about new protocol elements, if any Dec 2011 - If new protocol elements, recharter Apr 2012 - Algorithm signaling document to IESG Apr 2012 - DNSSEC Errata document to IESG Apr 2012 - DNSKEY registry updates to IESG May 2012 - RFC6195bis IANA instructions to IESG May 2012 - IXFR-only to IESG Internet-Drafts: - The DISCOVER opcode [draft-dnsext-opcode-discover-02] (0 pages) - Domain Name System (DNS) IANA Considerations [draft-ietf-dnsext-2929bis-07] (21 pages) - Domain Name System (DNS) IANA Considerations [draft-ietf-dnsext-5395bis-03] (19 pages) - Comparison of AAAA and A6 (do we really need A6?) [draft-ietf-dnsext-aaaa-a6-01] (13 pages) - Redefinition of DNS Authenticated Data (AD) bit [draft-ietf-dnsext-ad-is-secure-06] (7 pages) - Problem Statement: DNS Resolution of Aliased Names [draft-ietf-dnsext-aliasing-requirements-01] (22 pages) - A DNS RR Type for Lists of Address Prefixes (APL RR) [draft-ietf-dnsext-apl-rr-02] (7 pages) - DNS Zone Transfer Protocol (AXFR) [draft-ietf-dnsext-axfr-clarify-14] (28 pages) - Delegation Signer (DS) Resource Record (RR) [draft-ietf-dnsext-delegation-signer-15] (16 pages) - A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR) [draft-ietf-dnsext-dhcid-rr-13] (12 pages) - Derivation of DNS Name Predecessor and Successor [draft-ietf-dnsext-dns-name-p-s-01] (26 pages) - The Modern DNS Implementation Guide [draft-ietf-dnsext-dns-protocol-profile-01] (26 pages) - DNS Transport over TCP - Implementation Requirements [draft-ietf-dnsext-dns-tcp-requirements-03] (9 pages) - Threat Analysis of the Domain Name System (DNS) [draft-ietf-dnsext-dns-threats-07] (16 pages) - Applicability Statement for DNS MIB Extensions [draft-ietf-dnsext-dnsmib-historical-00] (4 pages) - DNS Proxy Implementation Guidelines [draft-ietf-dnsext-dnsproxy-06] (14 pages) - Legacy Resolver Compatibility for Delegation Signer (DS) [draft-ietf-dnsext-dnssec-2535typecode-change-06] (5 pages) - Cryptographic Algorithm Identifier Allocation for DNSSEC [draft-ietf-dnsext-dnssec-alg-allocation-03] (6 pages) - Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status [draft-ietf-dnsext-dnssec-algo-imp-status-02] (6 pages) - Signaling Cryptographic Algorithm Understanding in DNSSEC [draft-ietf-dnsext-dnssec-algo-signal-06] (8 pages) - Clarifications and Implementation Notes for DNSSECbis [draft-ietf-dnsext-dnssec-bis-updates-18] (20 pages) - DNS Security (DNSSEC) Experiments [draft-ietf-dnsext-dnssec-experiments-04] (15 pages) - Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC [draft-ietf-dnsext-dnssec-gost-07] (9 pages) - DNS Security Introduction and Requirements [draft-ietf-dnsext-dnssec-intro-13] (26 pages) - Indicating Resolver Support of DNSSEC [draft-ietf-dnsext-dnssec-okbit-03] (5 pages) - Minimally Covering NSEC Records and DNSSEC On-line Signing [draft-ietf-dnsext-dnssec-online-signing-02] (11 pages) - DNS Security (DNSSEC) Opt-In [draft-ietf-dnsext-dnssec-opt-in-09] (16 pages) - Protocol Modifications for the DNS Security Extensions [draft-ietf-dnsext-dnssec-protocol-09] (58 pages) - Resource Records for the DNS Security Extensions [draft-ietf-dnsext-dnssec-records-11] (33 pages) - Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry [draft-ietf-dnsext-dnssec-registry-fixes-08] (8 pages) - DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates [draft-ietf-dnsext-dnssec-registry-update-02] (6 pages) - DNS Security Document Roadmap [draft-ietf-dnsext-dnssec-roadmap-07] (16 pages) - Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC [draft-ietf-dnsext-dnssec-rsasha256-14] (10 pages) - Evaluating DNSSEC Transition Mechanisms [draft-ietf-dnsext-dnssec-trans-06] (16 pages) - Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) [draft-ietf-dnsext-ds-sha256-05] (9 pages) - Elliptic Curve Keys and Signatures in the Domain Name System (DNS) [draft-ietf-dnsext-ecc-key-10] (16 pages) - Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC [draft-ietf-dnsext-ecdsa-07] (8 pages) - Bind VIEW option in DNS messages [draft-ietf-dnsext-edns-bind-view-option-00] (4 pages) - ZONE option in DNS messages [draft-ietf-dnsext-edns-zone-option-00] (4 pages) - A Proposed Enhancement to the EDNS0 Version Mechanism [draft-ietf-dnsext-edns0dot5-02] (6 pages) - Extensions to DNS (EDNS1) [draft-ietf-dnsext-edns1-03] (4 pages) - Handling of unknown EDNS0 attributes [draft-ietf-dnsext-ends-unknown-00] (6 pages) - Measures for Making DNS More Resilient against Forged Answers [draft-ietf-dnsext-forgery-resilience-10] (26 pages) - Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG) [draft-ietf-dnsext-gss-tsig-06] (22 pages) - Domain Name System (DNS) IANA Considerations [draft-ietf-dnsext-iana-dns-01] (12 pages) - Domain Name System (DNS) Case Insensitivity Clarification [draft-ietf-dnsext-insensitive-06] (13 pages) - RFC 3597 Interoperability Report [draft-ietf-dnsext-interop3597-02] (6 pages) - Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS) [draft-ietf-dnsext-ipv6-addresses-02] (6 pages) - Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6) [draft-ietf-dnsext-ipv6-dns-tradeoffs-02] (10 pages) - Domain Name Auto-Registration for Plugged-in IPv6 Nodes [draft-ietf-dnsext-ipv6-name-auto-reg-01] (21 pages) - Incremental Zone Transfer in DNS [draft-ietf-dnsext-ixfr-01] (10 pages) - Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag [draft-ietf-dnsext-keyrr-key-signing-flag-12] (10 pages) - Link-local Multicast Name Resolution (LLMNR) [draft-ietf-dnsext-mdns-47] (29 pages) - DNSSEC and IPv6 A6 aware server/resolver message size requirements [draft-ietf-dnsext-message-size-04] (6 pages) - A mechanism for synchronization across name servers on zone creation [draft-ietf-dnsext-newzone-notify-01] (9 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) - DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format [draft-ietf-dnsext-nsec-rdata-06] (9 pages) - DNS Security (DNSSEC) Hashed Authenticated Denial of Existence [draft-ietf-dnsext-nsec3-13] (52 pages) - DNS Name Server Identifier (NSID) Option [draft-ietf-dnsext-nsid-02] (16 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) - Limiting the Scope of the KEY Resource Record (RR) [draft-ietf-dnsext-restrict-key-for-dnssec-04] (15 pages) - DNS Extensions to Support IP Version 6 [draft-ietf-dnsext-rfc1886bis-03] (7 pages) - DNS Incremental Zone Transfer Protocol (IXFR) [draft-ietf-dnsext-rfc1995bis-ixfr-01] (34 pages) - DSA Keying and Signature Information in the DNS [draft-ietf-dnsext-rfc2536bis-dsa-08] (11 pages) - Storing Certificates in the Domain Name System (DNS) [draft-ietf-dnsext-rfc2538bis-09] (17 pages) - Storage of Diffie-Hellman Keying Information in the DNS [draft-ietf-dnsext-rfc2539bis-dhk-08] (12 pages) - Extension Mechanisms for DNS (EDNS0) [draft-ietf-dnsext-rfc2671bis-edns0-08] (15 pages) - DNAME Redirection in the DNS [draft-ietf-dnsext-rfc2672bis-dname-26] (22 pages) - A DNS RR for specifying the location of services (DNS SRV) [draft-ietf-dnsext-rfc2782bis-01] (12 pages) - Handling of Unknown DNS Resource Record (RR) Types [draft-ietf-dnsext-rfc3597-bis-02] (8 pages) - Domain Name System (DNS) IANA Considerations [draft-ietf-dnsext-rfc6195bis-01] (19 pages) - Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover [draft-ietf-dnsext-rollover-requirements-04] (11 pages) - RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) [draft-ietf-dnsext-rsa-03] (8 pages) - DNS Request and Transaction Signatures ( SIG(0)s ) [draft-ietf-dnsext-sig-zero-02] (9 pages) - Requirements related to DNSSEC Signed Proof of Non-Existence [draft-ietf-dnsext-signed-nonexistence-requirements-03] (14 pages) - Domain Name System Security (DNSSEC) Signing Authority [draft-ietf-dnsext-signing-auth-02] (7 pages) - Secure Domain Name System (DNS) Dynamic Update [draft-ietf-dnsext-simple-secure-update-02] (9 pages) - Secret Key Establishment for DNS (TKEY RR) [draft-ietf-dnsext-tkey-04] (17 pages) - TKEY Secret Key Renewal Mode [draft-ietf-dnsext-tkey-renewal-mode-05] (23 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) - Automated Updates of DNS Security (DNSSEC) Trust Anchors [draft-ietf-dnsext-trustupdate-timers-06] (13 pages) - Secret Key Transaction Authentication for DNS (TSIG) [draft-ietf-dnsext-tsig-00] (15 pages) - Deprecation of HMAC-MD5 in DNS TSIG and TKEY Resource Records [draft-ietf-dnsext-tsig-md5-deprecated-03] (6 pages) - HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers [draft-ietf-dnsext-tsig-sha-06] (9 pages) - Handling of Unknown DNS Resource Record (RR) Types [draft-ietf-dnsext-unknown-rrs-06] (8 pages) - The Role of Wildcards in the Domain Name System [draft-ietf-dnsext-wcard-clarify-11] (30 pages) - xNAME RCODE and Status Bits Clarification [draft-ietf-dnsext-xnamercode-00] (9 pages) - DNS Security Extension Clarification on Zone Status [draft-ietf-dnsext-zone-status-05] (9 pages) - A DNS RR Type for Lists of IP Address Prefixes (APL RR) [draft-ietf-dnsind-apl-rr-03] (6 pages) - A DNS RR for encoding DHCP information [draft-ietf-dnsind-dhcp-rr-00] (4 pages) - Domain Name System (DNS) IANA Considerations [draft-ietf-dnsind-iana-dns-04] (13 pages) - A DNS RR for specifying the location of services (DNS SRV) [draft-ietf-dnsind-rfc2052bis-05] (10 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) - 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) - Secret Key Transaction Authentication for DNS (TSIG) [draft-ietf-dnsind-tsig-13] (14 pages) - DNS Security Extension Clarification on Zone Status [draft-ietf-dnsind-zone-status-00] (9 pages) Requests for Comments: BCP0042: Domain Name System (DNS) IANA Considerations (19 pages) * Updates RFC1183 * Updates RFC3597 * Obsoletes RFC5395 BCP0152: DNS Proxy Implementation Guidelines (14 pages) * Replaces DRAFT-BELLIS-DNSEXT-DNSPROXY RFC2782: A DNS RR for specifying the location of services (DNS SRV) (10 pages) * Obsoletes RFC2052 * Updates RFC6335 RFC2845: Secret Key Transaction Authentication for DNS (TSIG) (15 pages) * Updates RFC1035 * Updates RFC3645 RFC2929: Domain Name System (DNS) IANA Considerations (12 pages) * Replaces DRAFT-EASTLAKE-DNSEXT-2929BIS * Obsoletes RFC5395 RFC2930: Secret Key Establishment for DNS (TKEY RR) (17 pages) RFC2931: DNS Request and Transaction Signatures ( SIG(0)s ) (9 pages) * Updates RFC2535 RFC3007: Secure Domain Name System (DNS) Dynamic Update (9 pages) * Updates RFC2136 * Obsoletes RFC2137 * Updates RFC2535 * Updates RFC4033 * Updates RFC4034 * Updates RFC4035 RFC3008: Domain Name System Security (DNSSEC) Signing Authority (7 pages) * Updates RFC2535 * Obsoletes RFC4035 * Obsoletes RFC4033 * Obsoletes RFC4034 * Updates RFC3658 RFC3090: DNS Security Extension Clarification on Zone Status (9 pages) * Updates RFC2535 * Obsoletes RFC4033 * Obsoletes RFC4034 * Obsoletes RFC4035 * Updates RFC3658 RFC3110: RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) (8 pages) * Obsoletes RFC2537 RFC3123: A DNS RR Type for Lists of Address Prefixes (APL RR) (7 pages) RFC3197: Applicability Statement for DNS MIB Extensions (4 pages) RFC3225: Indicating Resolver Support of DNSSEC (5 pages) * Updates RFC4033 * Updates RFC4034 * Updates RFC4035 RFC3226: DNSSEC and IPv6 A6 aware server/resolver message size requirements (6 pages) * Updates RFC2535 * Updates RFC2874 * Updates RFC4033 * Updates RFC4034 * Updates RFC4035 RFC3363: Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS) (6 pages) * Updates RFC2673 * Updates RFC2874 RFC3364: Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6) (10 pages) * Updates RFC2673 * Updates RFC2874 RFC3425: Obsoleting IQUERY (4 pages) * Updates RFC1035 RFC3445: Limiting the Scope of the KEY Resource Record (RR) (15 pages) * Updates RFC2535 * Obsoletes RFC4033 * Obsoletes RFC4034 * Obsoletes RFC4035 RFC3596: DNS Extensions to Support IP Version 6 (7 pages) * Obsoletes RFC1886 * Obsoletes RFC3152 RFC3597: Handling of Unknown DNS Resource Record (RR) Types (8 pages) * Updates RFC2163 * Updates RFC2535 * Updates RFC4033 * Updates RFC4034 * Updates RFC4035 * Updates RFC5395 * Updates RFC6195 RFC3645: Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG) (22 pages) * Updates RFC2845 RFC3655: Redefinition of DNS Authenticated Data (AD) bit (7 pages) * Updates RFC2535 * Obsoletes RFC4033 * Obsoletes RFC4034 * Obsoletes RFC4035 RFC3658: Delegation Signer (DS) Resource Record (RR) (16 pages) * Updates RFC1035 * Updates RFC2535 * Updates RFC3008 * Updates RFC3090 * Obsoletes RFC4033 * Obsoletes RFC4034 * Obsoletes RFC4035 * Updates RFC3755 RFC3755: Legacy Resolver Compatibility for Delegation Signer (DS) (5 pages) * Updates RFC2535 * Updates RFC3658 * Obsoletes RFC4033 * Obsoletes RFC4034 * Obsoletes RFC4035 * Updates RFC3757 * Updates RFC3845 RFC3757: Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag (10 pages) * Updates RFC2535 * Updates RFC3755 * Obsoletes RFC4033 * Obsoletes RFC4034 * Obsoletes RFC4035 RFC3833: Threat Analysis of the Domain Name System (DNS) (16 pages) RFC3845: DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format (9 pages) * Updates RFC2535 * Updates RFC3755 * Obsoletes RFC4033 * Obsoletes RFC4034 * Obsoletes RFC4035 RFC4033: DNS Security Introduction and Requirements (26 pages) * Updates RFC1034 * Updates RFC1035 * Updates RFC2136 * Updates RFC2181 * Updates RFC2308 * Obsoletes RFC2535 * Updates RFC3007 * Obsoletes RFC3008 * Obsoletes RFC3090 * Updates RFC3225 * Updates RFC3226 * Obsoletes RFC3445 * Updates RFC3597 * Obsoletes RFC3655 * Obsoletes RFC3658 * Obsoletes RFC3755 * Obsoletes RFC3757 * Obsoletes RFC3845 * Updates RFC6014 RFC4034: Resource Records for the DNS Security Extensions (33 pages) * Updates RFC1034 * Updates RFC1035 * Updates RFC2136 * Updates RFC2181 * Updates RFC2308 * Obsoletes RFC2535 * Updates RFC3007 * Obsoletes RFC3008 * Obsoletes RFC3090 * Updates RFC3225 * Updates RFC3226 * Obsoletes RFC3445 * Updates RFC3597 * Obsoletes RFC3655 * Obsoletes RFC3658 * Obsoletes RFC3755 * Obsoletes RFC3757 * Obsoletes RFC3845 * Updates RFC4470 * Updates RFC6014 RFC4035: Protocol Modifications for the DNS Security Extensions (58 pages) * Updates RFC1034 * Updates RFC1035 * Updates RFC2136 * Updates RFC2181 * Updates RFC2308 * Obsoletes RFC2535 * Updates RFC3007 * Obsoletes RFC3008 * Obsoletes RFC3090 * Updates RFC3225 * Updates RFC3226 * Obsoletes RFC3445 * Updates RFC3597 * Obsoletes RFC3655 * Obsoletes RFC3658 * Obsoletes RFC3755 * Obsoletes RFC3757 * Obsoletes RFC3845 * Updates RFC4470 * Updates 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) * Replaces DRAFT-WEILER-DNSEXT-DNSSEC-ONLINE-SIGNING * Updates RFC4034 * Updates RFC4035 RFC4471: Derivation of DNS Name Predecessor and Successor (26 pages) * Replaces DRAFT-SISSON-DNSEXT-DNS-NAME-P-S 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 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) * Updates RFC5494 RFC4795: Link-local Multicast Name Resolution (LLMNR) (29 pages) * Replaces DRAFT-ABOBA-DNSEXT-MDNS RFC4955: DNS Security (DNSSEC) Experiments (15 pages) RFC4956: DNS Security (DNSSEC) Opt-In (16 pages) RFC4986: Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover (11 pages) RFC5001: DNS Name Server Identifier (NSID) Option (16 pages) * Replaces DRAFT-AUSTEIN-DNSEXT-NSID 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 (21 pages) * Updates RFC1183 * Obsoletes RFC2929 * Updates RFC3597 * Obsoletes RFC6195 RFC5452: Measures for Making DNS More Resilient against Forged Answers (26 pages) * Updates RFC2181 RFC5625: DNS Proxy Implementation Guidelines (14 pages) * Replaces DRAFT-BELLIS-DNSEXT-DNSPROXY RFC5702: Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC (10 pages) RFC5933: Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC (9 pages) * Replaces DRAFT-DOLMATOV-DNSEXT-DNSSEC-GOST RFC5936: DNS Zone Transfer Protocol (AXFR) (28 pages) * Updates RFC1034 * Updates RFC1035 RFC5966: DNS Transport over TCP - Implementation Requirements (9 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 (19 pages) * Updates RFC1183 * Updates RFC3597 * Obsoletes RFC5395 RFC6604: xNAME RCODE and Status Bits Clarification (9 pages) * Replaces DRAFT-EASTLAKE-DNSEXT-XNAMERCODE * Updates RFC1035 * Updates RFC2308 * Updates RFC2672 RFC6605: Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC (8 pages) Distributed Mobility Management (dmm) ------------------------------------- Charter Last Modified: 2012-03-05 Current Status: Active Chairs: Julien Laganier Jouni Korhonen Internet Area Directors: Ralph Droms Brian Haberman Internet Area Advisor: Brian K. Haberman Mailing Lists: General Discussion: dmm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dmm Archive: http://www.ietf.org/mail-archive/web/dmm 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: 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 Brian Haberman Internet Area Advisor: Ralph E. 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/ 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: - Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4) [draft-ietf-dhc-3315id-for-v4-05] (11 pages) - IEEE 802.11 parameters DHCP Option [draft-ietf-dhc-80211-option-01] (5 pages) - Triggering AAA from DHCP Relay Agents [draft-ietf-dhc-aaa-ra-00] (7 pages) - Authentication, Authorization, and Accounting Requirements for Roaming Nodes using DHCP [draft-ietf-dhc-aaa-requirements-00] (8 pages) - A Generic IPv6 Addresses Registration Solution Using DHCPv6 [draft-ietf-dhc-addr-registration-00] (10 pages) - DHCP Relay Agent Information Option [draft-ietf-dhc-agent-options-11] (15 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) - Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option [draft-ietf-dhc-agentopt-radius-08] (9 pages) - The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option [draft-ietf-dhc-agentoptions-device-class-04] (5 pages) - The Autonomous System Option for DHCP [draft-ietf-dhc-asnum-00] (5 pages) - DHCP RSA/DSA Authentication using DNS KEY records [draft-ietf-dhc-auth-sigzero-00] (0 pages) - The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option [draft-ietf-dhc-auth-suboption-05] (15 pages) - Authentication for DHCP Messages [draft-ietf-dhc-authentication-16] (17 pages) - DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients [draft-ietf-dhc-autoconfig-04] (9 pages) - Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers [draft-ietf-dhc-bcmc-options-05] (15 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) - Interoperation Between DHCP and BOOTP [draft-ietf-dhc-between-bootp-02] (4 pages) - Clarifications and Extensions for the Bootstrap Protocol [draft-ietf-dhc-bootp-01] (27 pages) - DHCP Options for Call Control Servers [draft-ietf-dhc-callcontrolserv-00] (4 pages) - Configuring Cryptographically Generated Addresses (CGA) using DHCPv6 [draft-ietf-dhc-cga-config-dhcpv6-02] (11 pages) - Client Identifier Option in DHCP Server Replies [draft-ietf-dhc-client-id-02] (5 pages) - Interpreting Client Options for the Dynamic Host Configuration Protocol [draft-ietf-dhc-client-options-00] (24 pages) - Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4) [draft-ietf-dhc-concat-05] (0 pages) - Container Option for Server Configuration [draft-ietf-dhc-container-opt-05] (10 pages) - The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4 [draft-ietf-dhc-csr-07] (0 pages) - Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients [draft-ietf-dhc-ddns-resolution-12] (14 pages) - Dynamic Host Configuration Protocol [draft-ietf-dhc-dhcp-08] (45 pages) - Interaction between DHCP and DNS [draft-ietf-dhc-dhcp-dns-12] (19 pages) - Dynamic Host Configuration Protocol DHCPINFORM Message Clarifications [draft-ietf-dhc-dhcpinform-clarify-06] (9 pages) - Extensions to DHCP for Roaming Users [draft-ietf-dhc-dhcproam-00] (15 pages) - Bulk DHCPv4 Lease Query [draft-ietf-dhc-dhcpv4-bulk-leasequery-06] (39 pages) - DHCPv4 over IPv6 Transport [draft-ietf-dhc-dhcpv4-over-ipv6-02] (11 pages) - Relay Agent Encapsulation for DHCPv4 [draft-ietf-dhc-dhcpv4-relay-encapsulation-01] (22 pages) - DHCPv4 Vendor-specific Message [draft-ietf-dhc-dhcpv4-vendor-message-01] (7 pages) - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-ietf-dhc-dhcpv6-28] (89 pages) - DHCPv6 Relay Agent Assignment Notification (RAAN) Option [draft-ietf-dhc-dhcpv6-agentopt-delegate-04] (8 pages) - DHCPv6 Bulk Leasequery [draft-ietf-dhc-dhcpv6-bulk-leasequery-06] (18 pages) - Clarifications on DHCPv6 Authentication [draft-ietf-dhc-dhcpv6-clarify-auth-01] (14 pages) - Configured Tunnel End Point Option for DHCPv6 [draft-ietf-dhc-dhcpv6-ctep-opt-02] (6 pages) - DHCPv6 Relay Agent Echo Request Option [draft-ietf-dhc-dhcpv6-ero-01] (7 pages) - DHCPv6 Failover Requirements [draft-ietf-dhc-dhcpv6-failover-requirements-00] (19 pages) - The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option [draft-ietf-dhc-dhcpv6-fqdn-05] (15 pages) - Results from Interoperability Tests of DHCPv6 Implementations [draft-ietf-dhc-dhcpv6-interop-01] (12 pages) - Lightweight DHCPv6 Relay Agent [draft-ietf-dhc-dhcpv6-ldra-03] (14 pages) - DHCPv6 Leasequery [draft-ietf-dhc-dhcpv6-leasequery-01] (23 pages) - Load Balancing for DHCPv6 [draft-ietf-dhc-dhcpv6-loadb-02] (6 pages) - Client Preferred Prefix option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-cliprefprefix-01] (6 pages) - DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-ietf-dhc-dhcpv6-opt-dnsconfig-04] (8 pages) - Domain Suffix Option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-dnsdomain-04] (7 pages) - DSTM Options for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-dstm-01] (7 pages) - DSTM Ports Option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-dstm-ports-01] (4 pages) - DHCPv6 Options for Network Boot [draft-ietf-dhc-dhcpv6-opt-netboot-10] (11 pages) - Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-ietf-dhc-dhcpv6-opt-nisconfig-05] (6 pages) - The Name Service Search Option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-nss-00] (6 pages) - IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 [draft-ietf-dhc-dhcpv6-opt-prefix-delegation-05] (20 pages) - DHCPv6 Support for Remote Boot [draft-ietf-dhc-dhcpv6-opt-rboot-00] (6 pages) - Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-sntp-01] (5 pages) - Time Configuration Options for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-timeconfig-03] (8 pages) - Timezone Specifier Option for DHCPv6 [draft-ietf-dhc-dhcpv6-opt-tz-00] (6 pages) - RADIUS Option for DHCPv6 Relay Agents on Broadband Access Server [draft-ietf-dhc-dhcpv6-radius-opt-00] (9 pages) - Rebind Capability in DHCPv6 Reconfigure Messages [draft-ietf-dhc-dhcpv6-reconfigure-rebind-10] (11 pages) - DHCPv6 Redundancy Deployment Considerations [draft-ietf-dhc-dhcpv6-redundancy-consider-02] (16 pages) - Relay-Supplied DHCP Options [draft-ietf-dhc-dhcpv6-relay-supplied-options-09] (8 pages) - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option [draft-ietf-dhc-dhcpv6-remoteid-01] (8 pages) - Time Protocol Servers and Time Offset Options for IPv6 DHCP [draft-ietf-dhc-dhcpv6-rfc868-servers-00] (6 pages) - DHCPv6 Server Reply Sequence Number Option [draft-ietf-dhc-dhcpv6-srsn-option-02] (7 pages) - Issues with multiple stateful DHCPv6 options [draft-ietf-dhc-dhcpv6-stateful-issues-00] (8 pages) - Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 [draft-ietf-dhc-dhcpv6-stateless-04] (10 pages) - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option [draft-ietf-dhc-dhcpv6-subid-01] (8 pages) - DHCPv6 through Tunnels [draft-ietf-dhc-dhcpv6-tunnel-01] (5 pages) - DHCPv6 Vendor-specific Message [draft-ietf-dhc-dhcpv6-vendor-message-01] (6 pages) - Extensions for the Dynamic Host Configuration Protocol for IPv6 [draft-ietf-dhc-dhcpv6exts-12] (39 pages) - DHCPv6 Leasequery [draft-ietf-dhc-dhcvp6-leasequery-01] (21 pages) - Detecting Network Attachment in IPv4 (DNAv4) [draft-ietf-dhc-dna-ipv4-18] (16 pages) - The Domain Search Option for DHCP [draft-ietf-dhc-domsrch-02] (4 pages) - Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues [draft-ietf-dhc-dual-stack-04] (14 pages) - Dual-stack clients and merging of data from DHCPv4 and DHCPv6 [draft-ietf-dhc-dual-stack-merge-01] (8 pages) - Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID) [draft-ietf-dhc-duid-uuid-03] (6 pages) - Subnet Configuration Option Set for DHCP [draft-ietf-dhc-dyn-subnet-conf-02] (14 pages) - Requirements for Extending DHCP into New Environments [draft-ietf-dhc-enhance-requirements-00] (15 pages) - Extending DHCP Options Codes [draft-ietf-dhc-extended-optioncodes-00] (9 pages) - DHCP Failover Protocol [draft-ietf-dhc-failover-12] (133 pages) - Forcerenew Nonce Authentication [draft-ietf-dhc-forcerenew-nonce-06] (12 pages) - An option for FQDNs in DHCP options [draft-ietf-dhc-fqdn-opt-03] (4 pages) - The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option [draft-ietf-dhc-fqdn-option-13] (17 pages) - Prefix Assignment in DHCPv6 [draft-ietf-dhc-host-gen-id-01] (10 pages) - Considerations for the use of the Host Name option [draft-ietf-dhc-host-option-considerations-02] (8 pages) - Implementation Issues with RFC 2131, "Dynamic Host Configuration Protocol (DHCPv4)" [draft-ietf-dhc-implementation-02] (41 pages) - An Inter-server Protocol for DHCP [draft-ietf-dhc-interserver-02] (89 pages) - An Inter-server Protocol for DHCP [draft-ietf-dhc-interserver-alt-00] (53 pages) - Automatically Choosing an IP Address in an Ad-Hoc IPv4 Network [draft-ietf-dhc-ipv4-autoconfig-05] (8 pages) - The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service [draft-ietf-dhc-isnsoption-13] (14 pages) - Wireless Key Management using DHCP [draft-ietf-dhc-key-management-00] (0 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) - LDAP Schema for DHCP [draft-ietf-dhc-ldap-schema-00] (18 pages) - Dynamic Host Configuration Protocol (DHCP) Leasequery [draft-ietf-dhc-leasequery-09] (27 pages) - DHCPv4 Lease Query by Relay Agent Remote ID [draft-ietf-dhc-leasequery-by-remote-id-09] (18 pages) - Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-ietf-dhc-lifetime-03] (8 pages) - DHC Load Balancing Algorithm [draft-ietf-dhc-loadb-03] (9 pages) - Multicast address allocation extensions to the Dynamic Host Configuration Protocol [draft-ietf-dhc-mdhcp-03] (14 pages) - The Migration Agent List Option for DHCP [draft-ietf-dhc-migagntlist-00] (4 pages) - DHCP Option for Mobile IP Mobility Agents [draft-ietf-dhc-mipadvert-opt-02] (15 pages) - Multicast Address Allocation Configuration Options [draft-ietf-dhc-multopt-03] (5 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-00] (6 pages) - Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types [draft-ietf-dhc-new-opt-msg-02] (7 pages) - New Option Review Guidelines for DHCP [draft-ietf-dhc-new-opt-review-00] (8 pages) - Procedure for Defining New DHCP Options [draft-ietf-dhc-new-options-05] (6 pages) - DHCP Next Server Option [draft-ietf-dhc-nextserver-02] (0 pages) - The Name Service Search Option for DHCP [draft-ietf-dhc-nsso-05] (4 pages) - The Extended Remote Boot Option for DHCPv4 [draft-ietf-dhc-opt-extrboot-00] (7 pages) - Guidelines for Creating New DHCP Options [draft-ietf-dhc-option-guidelines-07] (18 pages) - New Option Review Guidelines and Additional Option Namespace [draft-ietf-dhc-option-review-and-namespace-02] (14 pages) - DHCP Options and BOOTP Vendor Extensions [draft-ietf-dhc-options-03] (27 pages) - DHCP Options and BOOTP Vendor Extensions [draft-ietf-dhc-options-1533update-05] (38 pages) - DHCP Continuation Option Code [draft-ietf-dhc-options-cont-01] (3 pages) - An Extension to the DHCP Option Codes [draft-ietf-dhc-options-opt127-03] (3 pages) - DHCP Option for The Open Group's User Authentication Protocol [draft-ietf-dhc-options-uap-02] (3 pages) - DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents [draft-ietf-dhc-paa-option-05] (9 pages) - Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration [draft-ietf-dhc-packetcable-06] (12 pages) - Prefix Exclude Option for DHCPv6-based Prefix Delegation [draft-ietf-dhc-pd-exclude-04] (10 pages) - PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option [draft-ietf-dhc-pktc-kerb-tckt-03] (7 pages) - Dynamic Configuration of Internet Hosts [draft-ietf-dhc-problem-stmt-00] (0 pages) - Dynamic Host Configuration Protocol [draft-ietf-dhc-protocol-06] (38 pages) - DHCP Option for Proxy Server Configuration [draft-ietf-dhc-proxyserver-opt-05] (8 pages) - DHCP reconfigure extension [draft-ietf-dhc-pv4-reconfigure-06] (6 pages) - Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE) [draft-ietf-dhc-pxe-options-03] (8 pages) - Dynamic Host Configuration Protocol Options Used by PXELINUX [draft-ietf-dhc-pxelinux-03] (14 pages) - The Server Range Option for DHCP [draft-ietf-dhc-range-00] (2 pages) - Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4) [draft-ietf-dhc-rapid-commit-opt-05] (12 pages) - Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options [draft-ietf-dhc-reclassify-options-01] (8 pages) - The Authentication Suboption for the DHCP Relay Agent Option [draft-ietf-dhc-relay-agent-auth-01] (16 pages) - The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption [draft-ietf-dhc-relay-agent-flags-03] (8 pages) - Authentication of DHCP Relay Agent Options Using IPsec [draft-ietf-dhc-relay-agent-ipsec-02] (10 pages) - The DHCPv4 Relay Agent Identifier Suboption [draft-ietf-dhc-relay-id-suboption-10] (7 pages) - Graceful renumbering of networks with DHCP [draft-ietf-dhc-renumbering-00] (8 pages) - DHCP Safe Failover Protocol [draft-ietf-dhc-safe-failover-proto-00] (29 pages) - DHCP Schema for LDAP [draft-ietf-dhc-schema-02] (23 pages) - Secure DHCPv6 Using CGAs [draft-ietf-dhc-secure-dhcpv6-06] (15 pages) - Securing DHCP [draft-ietf-dhc-securing-dhc-00] (5 pages) - Security Architecture for DHCP [draft-ietf-dhc-security-arch-01] (14 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 Server Identifier Override Suboption [draft-ietf-dhc-server-override-05] (12 pages) - The Server Identification Option for DHCP [draft-ietf-dhc-sio-00] (6 pages) - DHCP Options for Service Location Protocol [draft-ietf-dhc-slp-07] (5 pages) - Service-Oriented Address Assignment using DHCPv6 [draft-ietf-dhc-soa-option-00] (9 pages) - The Server Selection Option for DHCP [draft-ietf-dhc-sso-03] (14 pages) - Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [draft-ietf-dhc-stateless-dhcpv6-renumbering-02] (8 pages) - Description of Cisco Systems' Subnet Allocation Option for DHCPv4 [draft-ietf-dhc-subnet-alloc-13] (30 pages) - The IPv4 Subnet Selection Option for DHCP [draft-ietf-dhc-subnet-option-07] (6 pages) - Key Distribution Center (KDC) Server Address Sub-option for the Dynamic Host Configuration Protocol (DHCP) CableLabs Client Configuration (CCC) Option [draft-ietf-dhc-suboptions-kdc-serveraddress-04] (5 pages) - Subscriber-ID Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option [draft-ietf-dhc-subscriber-id-07] (10 pages) - Subnet Selection Option for DHCP [draft-ietf-dhc-subsel-00] (5 pages) - DHCP Option for IEEE 1003.1 POSIX Timezone Specifications [draft-ietf-dhc-timezone-03] (3 pages) - Timezone Options for DHCP [draft-ietf-dhc-timezone-option-05] (11 pages) - Unused Dynamic Host Configuration Protocol (DHCP) Option Codes [draft-ietf-dhc-unused-optioncodes-07] (11 pages) - DHCP Use of the User Class Option for Address Assignment [draft-ietf-dhc-useraddr-00] (5 pages) - The User Class Option for DHCP [draft-ietf-dhc-userclass-10] (5 pages) - Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis [draft-ietf-dhc-v4-threat-analysis-03] (20 pages) - DHCPv6 Relay agent RADIUS Attribute Option [draft-ietf-dhc-v6-relay-radius-02] (12 pages) - Options for DHCPv6 [draft-ietf-dhc-v6opts-00] (15 pages) - Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4) [draft-ietf-dhc-vendor-03] (10 pages) - Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option [draft-ietf-dhc-vendor-suboption-00] (9 pages) - Virtual Subnet Selection Options for DHCPv4 and DHCPv6 [draft-ietf-dhc-vpn-option-15] (26 pages) - DHCP Options for Novell Directory Services [draft-provan-dhcp-options-dir-serv-01] (3 pages) Requests for Comments: BCP0029: Procedure for Defining New DHCP Options (6 pages) BCP0043: Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types (7 pages) * Obsoletes RFC2489 RFC1531: Dynamic Host Configuration Protocol (38 pages) * Obsoletes RFC1541 RFC1532: Clarifications and Extensions for the Bootstrap Protocol (27 pages) * Updates RFC951 * Obsoletes RFC1542 RFC1533: DHCP Options and BOOTP Vendor Extensions (27 pages) * Obsoletes RFC1048 * Obsoletes RFC1084 * Obsoletes RFC1395 * Obsoletes RFC1497 * Obsoletes RFC2132 RFC1534: Interoperation Between DHCP and BOOTP (4 pages) RFC2131: Dynamic Host Configuration Protocol (45 pages) * Obsoletes RFC1541 * Updates RFC3396 * Updates RFC4361 * Updates RFC5494 RFC2132: DHCP Options and BOOTP Vendor Extensions (38 pages) * Obsoletes RFC1533 * Updates RFC3442 * Updates RFC3942 * Updates RFC4361 * Updates RFC4833 * Updates RFC5494 RFC2241: DHCP Options for Novell Directory Services (3 pages) RFC2242: NetWare/IP Domain Name and Information (6 pages) RFC2485: DHCP Option for The Open Group's User Authentication Protocol (3 pages) RFC2489: Procedure for Defining New DHCP Options (6 pages) * Obsoletes RFC2939 RFC2563: DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients (9 pages) RFC2610: DHCP Options for Service Location Protocol (5 pages) RFC2937: The Name Service Search Option for DHCP (4 pages) RFC2939: Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types (7 pages) * Obsoletes RFC2489 RFC3004: The User Class Option for DHCP (5 pages) RFC3011: The IPv4 Subnet Selection Option for DHCP (6 pages) RFC3046: DHCP Relay Agent Information Option (15 pages) * Updates RFC6607 RFC3074: DHC Load Balancing Algorithm (9 pages) RFC3118: Authentication for DHCP Messages (17 pages) RFC3203: DHCP reconfigure extension (6 pages) RFC3256: The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option (5 pages) RFC3315: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (89 pages) * Updates RFC4361 * Updates RFC5494 * Updates RFC6221 * Updates RFC6422 RFC3396: Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4) (0 pages) * Updates RFC2131 RFC3442: The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4 (0 pages) * Updates RFC2132 RFC3495: Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration (12 pages) RFC3527: Link Selection sub-option for the Relay Agent Information Option for DHCPv4 (8 pages) RFC3594: PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option (7 pages) RFC3633: IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 (20 pages) RFC3634: Key Distribution Center (KDC) Server Address Sub-option for the Dynamic Host Configuration Protocol (DHCP) CableLabs Client Configuration (CCC) Option (5 pages) RFC3646: DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (8 pages) RFC3679: Unused Dynamic Host Configuration Protocol (DHCP) Option Codes (11 pages) RFC3736: Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 (10 pages) RFC3898: Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (6 pages) RFC3925: Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4) (10 pages) RFC3942: Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options (8 pages) * Updates RFC2132 RFC3993: Subscriber-ID Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option (10 pages) RFC4014: Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option (9 pages) RFC4030: The Authentication Suboption for the Dynamic Host Configuration Protocol (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) Option for the Internet Storage Name Service (14 pages) RFC4242: Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (8 pages) RFC4243: Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option (9 pages) RFC4280: Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers (15 pages) * Replaces DRAFT-IETF-DHC-BCMCV4-OPTION * Replaces DRAFT-IETF-DHC-BCMCV6-OPTION RFC4361: Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4) (11 pages) * Updates RFC2131 * Updates RFC2132 * Updates RFC3315 * Updates RFC5494 RFC4388: Dynamic Host Configuration Protocol (DHCP) Leasequery (27 pages) * Updates RFC6148 RFC4436: Detecting Network Attachment in IPv4 (DNAv4) (16 pages) RFC4477: Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues (14 pages) RFC4578: Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE) (8 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) RFC4702: The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option (17 pages) RFC4703: Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients (14 pages) RFC4704: The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option (15 pages) RFC4833: Timezone Options for DHCP (11 pages) * Replaces DRAFT-LEAR-DHC-TIMEZONE-OPTION * Updates RFC2132 RFC4994: DHCPv6 Relay Agent Echo Request Option (7 pages) * Replaces DRAFT-SZENG-DHC-DHCPV6-ERO RFC5007: DHCPv6 Leasequery (23 pages) * Replaces DRAFT-IETF-DHC-DHCVP6-LEASEQUERY RFC5010: The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption (8 pages) * Replaces DRAFT-KINNEAR-DHC-RELAY-AGENT-FLAGS 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 (9 pages) RFC5460: DHCPv6 Bulk Leasequery (18 pages) * Replaces DRAFT-STAPP-DHC-DHCPV6-BULK-LEASEQUERY RFC5970: DHCPv6 Options for Network Boot (11 pages) RFC6148: DHCPv4 Lease Query by Relay Agent Remote ID (18 pages) * Replaces DRAFT-KURAPATI-DHC-LEASEQUERY-BY-REMOTE-ID * Updates RFC4388 RFC6221: Lightweight DHCPv6 Relay Agent (14 pages) * Updates RFC3315 RFC6355: Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID) (6 pages) * Replaces DRAFT-NARTEN-DHC-DUID-UUID RFC6422: Relay-Supplied DHCP Options (8 pages) * Updates RFC3315 RFC6607: Virtual Subnet Selection Options for DHCPv4 and DHCPv6 (26 pages) * Updates RFC3046 Home Networking (homenet) ------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Mark Townsley Ray Bellis Internet Area Directors: Ralph Droms Brian Haberman Internet Area Advisor: Ralph E. 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-02] (36 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 Brian Haberman Internet Area Advisor: Ralph E. 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/ 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: - Using the Host Identity Protocol with Legacy Applications [draft-ietf-hip-applications-04] (22 pages) - Host Identity Protocol (HIP) Architecture [draft-ietf-hip-arch-03] (24 pages) - Host Identity Protocol [draft-ietf-hip-base-10] (108 pages) - HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE) [draft-ietf-hip-bone-07] (22 pages) - Host Identity Protocol Certificates [draft-ietf-hip-cert-12] (14 pages) - Host Identity Protocol (HIP) Domain Name System (DNS) Extensions [draft-ietf-hip-dns-09] (21 pages) - Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) [draft-ietf-hip-esp-06] (37 pages) - Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS) [draft-ietf-hip-hiccups-05] (17 pages) - End-Host Mobility and Multihoming with the Host Identity Protocol [draft-ietf-hip-mm-05] (48 pages) - Host Multihoming with the Host Identity Protocol [draft-ietf-hip-multihoming-00] (22 pages) - Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators [draft-ietf-hip-nat-traversal-09] (33 pages) - Basic Socket Interface Extensions for the Host Identity Protocol (HIP) [draft-ietf-hip-native-api-12] (19 pages) - Native NAT Traversal Mode for the Host Identity Protocol [draft-ietf-hip-native-nat-traversal-02] (15 pages) - Encrypted Signaling Transport Modes for the Host Identity Protocol [draft-ietf-hip-over-hip-06] (13 pages) - Host Identity Protocol (HIP) Registration Extension [draft-ietf-hip-registration-02] (14 pages) - Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD) [draft-ietf-hip-reload-instance-05] (10 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-01] (13 pages) - Host Identity Protocol Version 2 (HIPv2) [draft-ietf-hip-rfc5201-bis-08] (124 pages) - Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) [draft-ietf-hip-rfc5202-bis-00] (37 pages) - Host Identity Protocol (HIP) Registration Extension [draft-ietf-hip-rfc5203-bis-01] (13 pages) - Host Identity Protocol (HIP) Rendezvous Extension [draft-ietf-hip-rfc5204-bis-01] (15 pages) - Host Identity Protocol (HIP) Domain Name System (DNS) Extension [draft-ietf-hip-rfc5205-bis-01] (17 pages) - Host Mobility with the Host Identity Protocol [draft-ietf-hip-rfc5206-bis-03] (33 pages) - Host Identity Protocol (HIP) Rendezvous Extension [draft-ietf-hip-rvs-05] (15 pages) - Host Identity Protocol (HIP) Multi-Hop Routing Extension [draft-ietf-hip-via-03] (10 pages) Requests for Comments: RFC4423: Host Identity Protocol (HIP) Architecture (24 pages) RFC5201: Host Identity Protocol (108 pages) * Updates RFC6253 RFC5202: Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) (37 pages) RFC5203: Host Identity Protocol (HIP) Registration Extension (14 pages) RFC5204: Host Identity Protocol (HIP) Rendezvous Extension (15 pages) RFC5205: Host Identity Protocol (HIP) Domain Name System (DNS) Extensions (21 pages) RFC5206: End-Host Mobility and Multihoming with the Host Identity Protocol (48 pages) RFC5338: Using the Host Identity Protocol with Legacy Applications (22 pages) * Replaces DRAFT-HENDERSON-HIP-APPLICATIONS RFC5770: Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators (33 pages) * Replaces DRAFT-SCHMITT-HIP-NAT-TRAVERSAL 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) (22 pages) * Replaces DRAFT-CAMARILLO-HIP-BONE RFC6253: Host Identity Protocol Certificates (14 pages) * Replaces DRAFT-VARJONEN-HIP-CERT * 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) (19 pages) IPv6 Maintenance (6man) ----------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Robert M. Hinden Ole Troan Internet Area Directors: Ralph Droms Brian Haberman Internet Area Advisor: Brian K. Haberman 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: - RFC 3627 to Historic Status [draft-ietf-6man-3627-historic-01] (4 pages) - Transmission of IPv6 over MS/TP Networks [draft-ietf-6man-6lobac-01] (20 pages) - Considerations for IPv6 Address Selection Policy Changes [draft-ietf-6man-addr-select-considerations-04] (19 pages) - Distributing Address Selection Policy using DHCPv6 [draft-ietf-6man-addr-select-opt-03] (10 pages) - Solution approaches for address-selection problems [draft-ietf-6man-addr-select-sol-03] (17 pages) - Duplicate Address Detection Proxy [draft-ietf-6man-dad-proxy-02] (13 pages) - IPv6 Router Advertisement Options for DNS Configuration [draft-ietf-6man-dns-options-bis-08] (18 pages) - Enhanced Duplicate Address Detection [draft-ietf-6man-enhanced-dad-00] (11 pages) - A Uniform Format for IPv6 Extension Headers [draft-ietf-6man-exthdr-06] (8 pages) - IPv6 Flow Label Specification [draft-ietf-6man-flow-3697bis-07] (17 pages) - Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels [draft-ietf-6man-flow-ecmp-05] (10 pages) - Rationale for Update to the IPv6 Flow Label Specification [draft-ietf-6man-flow-update-07] (13 pages) - IANA Allocation Guidelines for the IPv6 Routing Header [draft-ietf-6man-iana-routing-header-00] (3 pages) - Neighbor Unreachability Detection is too impatient [draft-ietf-6man-impatient-nud-01] (8 pages) - Processing of IPv6 "atomic" fragments [draft-ietf-6man-ipv6-atomic-fragments-00] (14 pages) - IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes [draft-ietf-6man-ipv6-subnet-model-12] (13 pages) - The Line Identification Destination Option [draft-ietf-6man-lineid-04] (15 pages) - Interface Identifier Assignment in IPv6 SLAAC [draft-ietf-6man-neighbor-inform-00] (17 pages) - IPv6 Node Requirements [draft-ietf-6man-node-req-bis-11] (31 pages) - Handling of Overlapping IPv6 Fragments [draft-ietf-6man-overlap-fragment-03] (7 pages) - Using 127-Bit IPv6 Prefixes on Inter-Router Links [draft-ietf-6man-prefixlen-p2p-01] (9 pages) - Reserved IPv6 Interface Identifiers [draft-ietf-6man-reserved-iids-03] (12 pages) - Update to RFC 3484 Default Address Selection for IPv6 [draft-ietf-6man-rfc3484-revise-05] (12 pages) - Default Address Selection for Internet Protocol version 6 (IPv6) [draft-ietf-6man-rfc3484bis-03] (30 pages) - The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams [draft-ietf-6man-rpl-option-06] (14 pages) - An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL) [draft-ietf-6man-rpl-routing-header-07] (20 pages) - A Recommendation for IPv6 Address Text Representation [draft-ietf-6man-text-addr-representation-07] (14 pages) - UDP Checksums for Tunneled Packets [draft-ietf-6man-udpchecksums-02] (12 pages) - IPv6 UDP Checksum Considerations [draft-ietf-6man-udpzero-05] (34 pages) - Representing IPv6 Zone Identifiers in Uniform Resource Identifiers [draft-ietf-6man-uri-zoneid-00] (7 pages) - Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol [draft-ietf-ipv6-compression-nego-v2-02] (8 pages) - Centrally Assigned Unique Local IPv6 Unicast Addresses [draft-ietf-ipv6-ula-central-02] (11 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 (7 pages) * Replaces DRAFT-KRISHNAN-6MAN-OVERLAP-FRAGMENT * 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 (13 pages) * Updates RFC4861 RFC5952: A Recommendation for IPv6 Address Text Representation (14 pages) * Replaces DRAFT-KAWAMURA-IPV6-TEXT-REPRESENTATION * Updates RFC4291 RFC6106: IPv6 Router Advertisement Options for DNS Configuration (18 pages) * Obsoletes RFC5006 RFC6164: Using 127-Bit IPv6 Prefixes on Inter-Router Links (9 pages) * Replaces DRAFT-KOHNO-IPV6-PREFIXLEN-P2P * Updates RFC6547 RFC6434: IPv6 Node Requirements (31 pages) * Obsoletes RFC4294 RFC6436: Rationale for Update to the IPv6 Flow Label Specification (13 pages) * Replaces DRAFT-CARPENTER-6MAN-FLOW-UPDATE RFC6437: IPv6 Flow Label Specification (17 pages) * Updates RFC2205 * Updates RFC2460 * Obsoletes RFC3697 RFC6438: Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels (10 pages) * Replaces DRAFT-CARPENTER-FLOW-ECMP RFC6547: RFC 3627 to Historic Status (4 pages) * Obsoletes RFC3627 * Updates RFC6164 RFC6553: The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams (14 pages) * Replaces DRAFT-HUI-6MAN-RPL-OPTION RFC6554: An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL) (20 pages) * Replaces DRAFT-HUI-6MAN-RPL-ROUTING-HEADER RFC6564: A Uniform Format for IPv6 Extension Headers (8 pages) * Updates RFC2460 IPv6 over Low power WPAN (6lowpan) ---------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Geoffrey C. Mulligan Dr. Carsten Bormann Internet Area Directors: Ralph Droms Brian Haberman Internet Area Advisor: Ralph E. Droms Mailing Lists: General Discussion: 6lowpan@lists.ietf.org To Subscribe: 6lowpan-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/6lowpan/ 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 Bluetooth Low Energy [draft-ietf-6lowpan-btle-07] (14 pages) - Transmission of IPv6 Packets over IEEE 802.15.4 Networks [draft-ietf-6lowpan-format-13] (31 pages) - Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks [draft-ietf-6lowpan-hc-15] (25 pages) - Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN) [draft-ietf-6lowpan-nd-18] (59 pages) - IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals [draft-ietf-6lowpan-problem-08] (13 pages) - Problem Statement and Requirements for 6LoWPAN Routing [draft-ietf-6lowpan-routing-requirements-10] (35 pages) - Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) [draft-ietf-6lowpan-usecases-10] (33 pages) - Design Considerations for Session Initiation Protocol (SIP) Overload Control [draft-ietf-sipping-overload-design-03] (21 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) * Updates RFC6282 RFC6282: Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks (25 pages) * Replaces DRAFT-HUI-6LOWPAN-HC * Updates RFC4944 RFC6568: Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) (33 pages) * Replaces DRAFT-EKIM-6LOWPAN-SCENARIOS Internet Area Working Group (intarea) ------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Julien Laganier Suresh Krishnan Internet Area Directors: Ralph Droms 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/ 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: - Updated Specification of the IPv4 ID Field [draft-ietf-intarea-ipv4-id-update-04] (16 pages) - IPv6 Support Required for All IP-Capable Nodes [draft-ietf-intarea-ipv6-required-02] (7 pages) - Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID) in Shared Address Deployments [draft-ietf-intarea-nat-reveal-analysis-02] (21 pages) - IP Router Alert Considerations and Usage [draft-ietf-intarea-router-alert-considerations-10] (24 pages) - Logging Recommendations for Internet-Facing Servers [draft-ietf-intarea-server-logging-recommendations-04] (6 pages) - Issues with IP Address Sharing [draft-ietf-intarea-shared-addressing-issues-05] (29 pages) - Tunnels in the Internet Architecture [draft-ietf-intarea-tunnels-00] (22 pages) Requests for Comments: BCP0162: Logging Recommendations for Internet-Facing Servers (6 pages) BCP0168: IP Router Alert Considerations and Usage (24 pages) * Replaces DRAFT-RAHMAN-RTG-ROUTER-ALERT-CONSIDERATIONS * Updates RFC2113 * Updates RFC2711 BCP0177: IPv6 Support Required for All IP-Capable Nodes (7 pages) RFC6269: Issues with IP Address Sharing (29 pages) * Replaces DRAFT-FORD-SHARED-ADDRESSING-ISSUES RFC6302: Logging Recommendations for Internet-Facing Servers (6 pages) RFC6398: IP Router Alert Considerations and Usage (24 pages) * Replaces DRAFT-RAHMAN-RTG-ROUTER-ALERT-CONSIDERATIONS * Updates RFC2113 * Updates RFC2711 RFC6540: IPv6 Support Required for All IP-Capable Nodes (7 pages) 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 Brian Haberman Internet Area Advisor: Ralph E. Droms Mailing Lists: General Discussion: l2tpext@ietf.org To Subscribe: l2tpext-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/l2tpext/ 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 2 Tunneling Protocol (L2TP) Active Discovery Relay for PPP over Ethernet (PPPoE) [draft-dasilva-l2tp-relaysvc-08] (16 pages) - Layer Two Tunneling Protocol - Setup of TDM Pseudowires [draft-ieft-l2tpext-tdm-03] (8 pages) - L2TP Alternate Data Channel ('ADC') [draft-ietf-l2tpext-adc-00] (4 pages) - Layer Two Tunnelling Protocol (L2TP): ATM access network extensions [draft-ietf-l2tpext-atmext-04] (19 pages) - Layer Two Tunneling Protocol : ATM Access Network Extensions [draft-ietf-l2tpext-atmext-rfc3301-bis-00] (18 pages) - Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values [draft-ietf-l2tpext-circuit-status-extensions-05] (12 pages) - Layer Two Tunneling Protocol (L2TP) Differentiated Services Extension [draft-ietf-l2tpext-ds-05] (10 pages) - Ethernet Service Type for Layer Two Tunneling Protocol [draft-ietf-l2tpext-eth-00] (6 pages) - Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) "failover" [draft-ietf-l2tpext-failover-12] (22 pages) - Layer Two Tunneling Protocol (L2TP) over Frame Relay [draft-ietf-l2tpext-fr-01] (7 pages) - Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 (AAL5) [draft-ietf-l2tpext-l2tp-atm-03] (12 pages) - Layer Two Tunneling Protocol - Version 3 (L2TPv3) [draft-ietf-l2tpext-l2tp-base-15] (93 pages) - Layer Two Tunneling Protocol "L2TP" Management Information Base [draft-ietf-l2tpext-l2tp-mib-04] (86 pages) - PPP Tunneling Using Layer Two Tunneling Protocol Version 3 (L2TPv3) [draft-ietf-l2tpext-l2tp-ppp-08] (44 pages) - Layer Two Tunneling Protocol 'L2TP' [draft-ietf-l2tpext-l2tpbis-01] (77 pages) - L2TP Header Compression ('L2TPHC') [draft-ietf-l2tpext-l2tphc-06] (7 pages) - Layer Two Tunneling Protocol (Version 3) "L2TPv3" Management Information Base [draft-ietf-l2tpext-l2tpmib-base-02] (55 pages) - Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP) [draft-ietf-l2tpext-l2vpn-07] (15 pages) - Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation [draft-ietf-l2tpext-link-07] (10 pages) - Extensions to Support Efficient Carrying of Multicast Traffic in Layer-2 Tunneling Protocol (L2TP) [draft-ietf-l2tpext-mcast-05] (25 pages) - Layer Two Tunneling Protocol 'L2TP' Multi-Protocol Label Switching Extension [draft-ietf-l2tpext-mpls-00] (5 pages) - L2TP Disconnect Cause Information [draft-ietf-l2tpext-ppp-discinfo-04] (9 pages) - L2TP Proxy Authenticate Extensions for EAP [draft-ietf-l2tpext-proxy-authen-ext-eap-02] (11 pages) - Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3) [draft-ietf-l2tpext-pwe3-atm-04] (21 pages) - Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3) [draft-ietf-l2tpext-pwe3-ethernet-09] (15 pages) - Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3) [draft-ietf-l2tpext-pwe3-fr-07] (14 pages) - High-Level Data Link Control (HDLC) Frames over Layer 2 Tunneling Protocol, Version 3 (L2TPv3) [draft-ietf-l2tpext-pwe3-hdlc-07] (12 pages) - Signaling and Encapsulation for the Transport of IP over L2TPv3 [draft-ietf-l2tpext-pwe3-ip-05] (20 pages) - RADIUS & L2TP Extended NAS-Port AVPs [draft-ietf-l2tpext-radius-ext-nas-port-02] (14 pages) - Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update [draft-ietf-l2tpext-rfc2661-iana-01] (5 pages) - Securing L2TP using IPsec [draft-ietf-l2tpext-security-08] (27 pages) - L2TP Session Information (``SESINFO'') [draft-ietf-l2tpext-sesinfo-04] (4 pages) - L2TP Service Type [draft-ietf-l2tpext-svctype-01] (7 pages) - Layer Two Tunneling Protocol version 3 - Setup of Time-Division Multiplexing (TDM) Pseudowires [draft-ietf-l2tpext-tdm-07] (10 pages) - PPP over L2TP Tunnel Switching [draft-ietf-l2tpext-tunnel-switching-08] (16 pages) - Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP) [draft-ietf-l2tpext-v92-moh-05] (13 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) - Layer Two Tunneling Protocol ''L2TP'' IP Differential Services Extension [draft-ietf-pppext-l2tp-ds-03] (5 pages) - Layer Two Tunneling Protocol (L2TP) over Frame Relay [draft-ietf-pppext-l2tp-fr-02] (7 pages) - Layer Two Tunneling Protocol 'L2TP' Management Information Base [draft-ietf-pppext-l2tp-mib-05] (68 pages) - Layer Two Tunneling Protocol ''L2TP'' Multi-Protocol Label Switching Extension [draft-ietf-pppext-l2tp-mpls-02] (5 pages) - Securing L2TP using IPSEC [draft-ietf-pppext-l2tp-security-05] (14 pages) Requests for Comments: BCP0068: Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update (5 pages) RFC3070: Layer Two Tunneling Protocol (L2TP) over Frame Relay (7 pages) RFC3145: L2TP Disconnect Cause Information (9 pages) RFC3193: Securing L2TP using IPsec (27 pages) RFC3301: Layer Two Tunnelling Protocol (L2TP): ATM access network extensions (19 pages) RFC3308: Layer Two Tunneling Protocol (L2TP) Differentiated Services Extension (10 pages) RFC3355: Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 (AAL5) (12 pages) RFC3371: Layer Two Tunneling Protocol "L2TP" Management Information Base (86 pages) RFC3437: Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation (10 pages) RFC3438: Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update (5 pages) RFC3573: Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP) (13 pages) RFC3817: Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay for PPP over Ethernet (PPPoE) (16 pages) RFC3931: Layer Two Tunneling Protocol - Version 3 (L2TPv3) (93 pages) * Updates 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) * Updates RFC5641 RFC4454: Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3) (21 pages) * Updates RFC5641 RFC4591: Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3) (14 pages) * Updates 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) * Updates RFC5641 RFC4951: Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) "failover" (22 pages) * Replaces DRAFT-VIPIN-L2TPEXT-FAILOVER RFC5611: Layer Two Tunneling Protocol version 3 - Setup of Time-Division Multiplexing (TDM) Pseudowires (10 pages) * Replaces DRAFT-IEFT-L2TPEXT-TDM RFC5641: Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values (12 pages) * Replaces DRAFT-NMCGILL-L2TPEXT-CIRCUIT-STATUS-EXTENSIONS * 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: Robert Cragie Zhen Cao Internet Area Directors: Ralph Droms Brian Haberman Internet Area Advisor: Brian K. Haberman 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: Terry Manderson Joel M. Halpern Internet Area Directors: Ralph Droms Brian Haberman Internet Area Advisor: Brian K. Haberman 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/ 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. 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. A number of approaches are being looked at in parallel in other contexts. The IRTF RRG examined several proposals, some of which were published as IRTF-track Experimental RFCs. The LISP WG has completed the first set of Experimental RFCs describing the Locator/ID Separation Protocol. LISP requires no changes to end-systems or to routers that do not directly participate in the LISP deployment. LISP aims for an incrementally deployable protocol. The LISP WG is chartered to continue work on the LISP base protocol, completing the ongoing work, and any items which directly impact LISP protocol structures and which are related to using LISP for improving Internet routing scalability. Specifically, the group will work on: - Architecture description: This document will describe the architecture of the entire LISP system, making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols. The document will include a description of the cache management and ETR synchronization essential characteristics needed to ensure the correct operation of the protocol. - Deployment models: This document will describe what kind of deployments can be expected for LISP, and give operational advice on how they can be set up. - A description of the impacts of LISP: This document will describe the problems that LISP is intended to address and the impacts that employing LISP has. While the work on LISP was initiated by Internet routing scaling concerns, there has also been an interest on improved solutions to a number of different problems, such as traffic engineering. This document should describe problem areas (such as scaling or traffic engineer) where LISP is expected to have a positive effect, as well as any tradeoffs that are caused by LISP's design. - LISP security threats and solutions: This document will describe the security analysis of the LISP system, what issues it needs to protect against, and a solution that helps defend against those issues. The replay attack problem discussed on the mailing list should be included in this work. - Allocation of Endpoint IDentifier (EID) space: This document requests address space to be used for the LISP experiment as identifier space - Alternate mapping system designs: Develop alternative mapping designs to be tested. - Data models for management of LISP. The first three items (architecture, deployment models, impacts) need to be completed first before other items can be submitted as RFCs. The three first documents also need to complement each other, by describing how the architecture supports a solution for a particular problem area and how the solution can be deployed to help with that problem. In addition, if work chartered in some other IETF WG requires changes in the LISP base protocol or any items which directly impact LISP protocol structures, then the LISP WG is chartered to work on such changes. It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF to understand which type of a solution is optimal. The LISP WG is not chartered to develop a standard solution for solving the routing scalability problem at this time. The specifications developed by the WG 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. Goals and Milestones: Sep 2012 - Submit an architecture description to the IESG for publication as an Experimental RFC Sep 2012 - Submit a deployment model document to the IESG for publication as an Experimental RFC Sep 2012 - Submit a LISP impact discussion document to the IESG for publication as an Experimental RFC Oct 2012 - Submit a LISP threats analysis document to the IESG for publication as an Experimental RFC Oct 2012 - Submit an EID allocation document to the IESG for publication as an Experimental RFC Jan 2013 - Submit an lternate mapping system designs to the IESG for publication as an Experimental RFC Mar 2013 - Submit a data model (e.g., a MIB) document to the IESG for publication as an Experimental RFC Mar 2013 - Summarize results of specifying, implementing, and testing LISP and forward to IESG and/or IRTF. Internet-Drafts: - Locator/ID Separation Protocol (LISP) [draft-ietf-lisp-23] (97 pages) - LISP Alternative Topology (LISP+ALT) [draft-ietf-lisp-alt-10] (30 pages) - LISP Network Element Deployment Considerations [draft-ietf-lisp-deployment-03] (25 pages) - LISP EID Block [draft-ietf-lisp-eid-block-02] (10 pages) - Interworking LISP with IPv4 and IPv6 [draft-ietf-lisp-interworking-06] (25 pages) - LISP Internet Groper (LIG) [draft-ietf-lisp-lig-06] (19 pages) - LISP Map-Versioning [draft-ietf-lisp-map-versioning-09] (24 pages) - LISP MIB [draft-ietf-lisp-mib-03] (54 pages) - LISP Map Server Interface [draft-ietf-lisp-ms-16] (16 pages) - LISP for Multicast Environments [draft-ietf-lisp-multicast-14] (40 pages) - LISP-Security (LISP-SEC) [draft-ietf-lisp-sec-02] (20 pages) - LISP Threats Analysis [draft-ietf-lisp-threats-01] (31 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 Brian Haberman Internet Area Advisor: Brian K. Haberman Mailing Lists: General Discussion: mip4@ietf.org To Subscribe: mip4-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/mip4/ 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: - Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4 [draft-ietf-mip4-aaa-key-06] (29 pages) - Mobile IPv4 Extension for Carrying Network Access Identifiers [draft-ietf-mip4-aaa-nai-02] (10 pages) - Dual-Stack Mobile IPv4 [draft-ietf-mip4-dsmipv4-10] (22 pages) - Mobile IPv4 Dynamic Home Agent (HA) Assignment [draft-ietf-mip4-dynamic-assignment-07] (24 pages) - Experimental Message, Extensions, and Error Codes for Mobile IPv4 [draft-ietf-mip4-experimental-messages-02] (12 pages) - Foreign Agent Error Extension for Mobile IPv4 [draft-ietf-mip4-faerr-02] (6 pages) - Mobile IPv4 Fast Handovers [draft-ietf-mip4-fmipv4-07] (28 pages) - Mobile IPv4 Extension for Configuration Options Exchange [draft-ietf-mip4-gen-ext-04] (13 pages) - Generic Notification Message for Mobile IPv4 [draft-ietf-mip4-generic-notification-message-16] (37 pages) - Generic Routing Encapsulation (GRE) Key Extension for Mobile IPv4 [draft-ietf-mip4-gre-key-extension-05] (10 pages) - IPv4 Mobility Extension for Multicast and Broadcast Packets [draft-ietf-mip4-mcbc-01] (12 pages) - Mobile IPv4 Message String Extension [draft-ietf-mip4-message-string-ext-03] (12 pages) - Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE) [draft-ietf-mip4-mobike-connectivity-03] (15 pages) - Flow Binding Support for Mobile IPv4 [draft-ietf-mip4-multiple-tunnel-support-03] (26 pages) - Home Agent-Assisted Route Optimization between Mobile IPv4 Networks [draft-ietf-mip4-nemo-haaro-07] (52 pages) - Network Mobility (NEMO) Extensions for Mobile IPv4 [draft-ietf-mip4-nemo-v4-base-11] (30 pages) - Dynamic Prefix Allocation for NEMOv4 [draft-ietf-mip4-nemov4-dynamic-06] (11 pages) - FA extensions to NEMOv4 Base [draft-ietf-mip4-nemov4-fa-03] (10 pages) - Mobile IPv4 RADIUS Requirements [draft-ietf-mip4-radius-requirements-04] (10 pages) - Mobile IPv4 Regional Registration [draft-ietf-mip4-reg-tunnel-04] (35 pages) - The Definitions of Managed Objects for IP Mobility Support using SMIv2, revised [draft-ietf-mip4-rfc2006bis-06] (112 pages) - Mobile IPv4 Challenge/Response Extensions (Revised) [draft-ietf-mip4-rfc3012bis-05] (33 pages) - IP Mobility Support for IPv4, Revised [draft-ietf-mip4-rfc3344bis-10] (105 pages) - The Definitions of Managed Objects for Mobile IP UDP Tunneling [draft-ietf-mip4-udptunnel-mib-02] (14 pages) - Mobile IPv4 Traversal across IPsec-Based VPN Gateways [draft-ietf-mip4-vpn-problem-solution-05] (39 pages) - Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways [draft-ietf-mip4-vpn-problem-statement-03] (19 pages) - Low-Latency Handoffs in Mobile IPv4 [draft-ietf-mobileip-lowlatency-handoffs-v4-11] (56 pages) - Mobile IPv4 Traversal Across IPsec-based VPN Gateways [draft-ietf-mobileip-vpn-problem-solution-03] (49 pages) Requests for Comments: BCP0136: Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE) (15 pages) * Replaces DRAFT-DEVARAPALLI-MIP4-MOBIKE-CONNECTIVITY RFC3846: Mobile IPv4 Extension for Carrying Network Access Identifiers (10 pages) RFC3957: Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4 (29 pages) * Replaces DRAFT-IETF-MOBILEIP-AAA-KEY RFC4064: Experimental Message, Extensions, and Error Codes for Mobile IPv4 (12 pages) RFC4093: Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways (19 pages) * Replaces DRAFT-IETF-MOBILEIP-VPN-PROBLEM-STATEMENT-REQ RFC4433: Mobile IPv4 Dynamic Home Agent (HA) Assignment (24 pages) RFC4636: Foreign Agent Error Extension for Mobile IPv4 (6 pages) RFC4721: Mobile IPv4 Challenge/Response Extensions (Revised) (33 pages) * Replaces DRAFT-IETF-MOBILEIP-RFC3012BIS * Obsoletes RFC3012 * Updates RFC3344 RFC4857: Mobile IPv4 Regional Registration (35 pages) RFC4881: Low-Latency Handoffs in Mobile IPv4 (56 pages) RFC4917: Mobile IPv4 Message String Extension (12 pages) RFC4988: Mobile IPv4 Fast Handovers (28 pages) RFC5030: Mobile IPv4 RADIUS Requirements (10 pages) RFC5177: Network Mobility (NEMO) Extensions for Mobile IPv4 (30 pages) RFC5265: Mobile IPv4 Traversal across IPsec-Based VPN Gateways (39 pages) * Replaces DRAFT-IETF-MOBILEIP-VPN-PROBLEM-SOLUTION RFC5266: Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE) (15 pages) * Replaces DRAFT-DEVARAPALLI-MIP4-MOBIKE-CONNECTIVITY RFC5454: Dual-Stack Mobile IPv4 (22 pages) RFC5944: IP Mobility Support for IPv4, Revised (105 pages) * Obsoletes RFC3344 RFC6098: Generic Notification Message for Mobile IPv4 (37 pages) * Replaces DRAFT-DENG-MIP4-GENERIC-NOTIFICATION-MESSAGE RFC6245: Generic Routing Encapsulation (GRE) Key Extension for Mobile IPv4 (10 pages) RFC6521: Home Agent-Assisted Route Optimization between Mobile IPv4 Networks (52 pages) * Replaces DRAFT-MAKELA-MIP4-NEMO-HAARO Multicast Mobility (multimob) ----------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Stig Venaas Behcet Sarikaya Internet Area Directors: Ralph Droms Brian Haberman Internet Area Advisor: Brian K. Haberman 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/ 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: - Tuning the Behavior of IGMP and MLD for Routers in Mobile and Wireless Networks [draft-ietf-multimob-igmp-mld-tuning-06] (13 pages) - Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains [draft-ietf-multimob-pmipv6-base-solution-07] (21 pages) - Multicast Mobility Routing Optimizations for Proxy Mobile IPv6 [draft-ietf-multimob-pmipv6-ropt-00] (29 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 (21 pages) * Replaces DRAFT-SCHMIDT-MULTIMOB-PMIPV6-MCAST-DEPLOYMENT Multiple Interfaces (mif) ------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Margaret Wasserman Hui Deng Internet Area Directors: Ralph Droms Brian Haberman Internet Area Advisor: Ralph E. Droms 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: - MIF API consideration [draft-ietf-mif-api-extension-00] (17 pages) - Current Practices for Multiple-Interface Hosts [draft-ietf-mif-current-practices-12] (22 pages) - DHCPv6 Route Options [draft-ietf-mif-dhcpv6-route-option-04] (22 pages) - Improved DNS Server Selection for Multi-Interfaced Nodes [draft-ietf-mif-dns-server-selection-08] (25 pages) - Multiple Interfaces and Provisioning Domains Problem Statement [draft-ietf-mif-problem-statement-15] (20 pages) Requests for Comments: RFC6418: Multiple Interfaces and Provisioning Domains Problem Statement (20 pages) * Replaces DRAFT-BLANCHET-MIF-PROBLEM-STATEMENT RFC6419: Current Practices for Multiple-Interface Hosts (22 pages) * Replaces DRAFT-MRW-MIF-CURRENT-PRACTICES Network Time Protocol (ntp) --------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chair: Karen O'Donoghue Internet Area Directors: Ralph Droms Brian Haberman Internet Area Advisor: Brian K. Haberman 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: Autokey Specification [draft-ietf-ntp-autokey-08] (54 pages) - Network Time Protocol (NTP) Server Option for DHCPv6 [draft-ietf-ntp-dhcpv6-ntp-opt-06] (10 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-07] (27 pages) - Network Time Protocol Version 4: Protocol and Algorithms Specification [draft-ietf-ntp-ntpv4-proto-13] (112 pages) - Requirements for Network Time Protocol Version 4 [draft-ietf-ntp-reqs-01] (16 pages) Requests for Comments: RFC5905: Network Time Protocol Version 4: Protocol and Algorithms Specification (112 pages) * Obsoletes RFC1305 * Obsoletes RFC4330 RFC5906: Network Time Protocol Version 4: Autokey Specification (54 pages) RFC5907: Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4) (27 pages) RFC5908: Network Time Protocol (NTP) Server Option for DHCPv6 (10 pages) Network-Based Mobility Extensions (netext) ------------------------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Rajeev Koodli Basavaraj Patil Internet Area Directors: Ralph Droms Brian Haberman Internet Area Advisor: Brian K. Haberman 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/ 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: - Access Network Identifier (ANI) Option for Proxy Mobile IPv6 [draft-ietf-netext-access-network-option-10] (18 pages) - Bulk Binding Update Support for Proxy Mobile IPv6 [draft-ietf-netext-bulk-re-registration-12] (23 pages) - Logical Interface Support for multi-mode IP Hosts [draft-ietf-netext-logical-interface-support-05] (25 pages) - Prefix Delegation for Proxy Mobile IPv6 [draft-ietf-netext-pd-pmip-02] (14 pages) - Localized Routing for Proxy Mobile IPv6 [draft-ietf-netext-pmip-lr-10] (29 pages) - A central policy controlling based PMIPv6 Solutions [draft-ietf-netext-pmip6-cpc-00] (19 pages) - Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement [draft-ietf-netext-pmip6-lr-ps-06] (19 pages) - Proxy Mobile IPv6 Extensions to Support Flow Mobility [draft-ietf-netext-pmipv6-flowmob-03] (21 pages) - IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6 [draft-ietf-netext-pmipv6-sipto-option-04] (12 pages) - RADIUS Support for Proxy Mobile IPv6 [draft-ietf-netext-radius-pmip6-08] (37 pages) - Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6 [draft-ietf-netext-redirect-12] (22 pages) - Service Selection for Mobile IPv6 [draft-ietf-netext-rfc5149bis-00] (12 pages) - EAP Attributes for WiFi - EPC Integration [draft-ietf-netext-wifi-epc-eap-attributes-00] (12 pages) Requests for Comments: RFC6279: Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement (19 pages) RFC6463: Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6 (22 pages) RFC6602: Bulk Binding Update Support for Proxy Mobile IPv6 (23 pages) Point-to-Point Protocol Extensions (pppext) ------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chair: Donald E. Eastlake 3rd Internet Area Directors: Ralph Droms Brian Haberman Internet Area Advisor: Brian K. Haberman 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/ 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: - Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE) [draft-arberg-pppoe-mtu-gt1492-03] (10 pages) - IP Header Compression over PPP [draft-engan-ip-compress-02] (9 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 Triple-DES Encryption Protocol (3DESE) [draft-ietf-pppext-3des-encrypt-00] (8 pages) - PPP Over AAL5 [draft-ietf-pppext-aal5-05] (11 pages) - The Arbitrary Handshake Authentication (AHA) protocol [draft-ietf-pppext-aha-auth-00] (16 pages) - Always On Dynamic ISDN (AODI). [draft-ietf-pppext-aodi-03] (15 pages) - The PPP AppleTalk Control Protocol (ATCP) [draft-ietf-pppext-appletalk-03] (20 pages) - The PPP AppleTalk Control Protocol (ATCP) [draft-ietf-pppext-atcp2-00] (21 pages) - PPP Authentication Protocols [draft-ietf-pppext-authentication-06] (20 pages) - The PPP Bandwidth Allocation Protocol (BAP) / The PPP Bandwidth Allocation Control Protocol (BACP) [draft-ietf-pppext-bacp-05] (22 pages) - PPP Bridging Control Protocol (BCP) [draft-ietf-pppext-bcp-04] (38 pages) - The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol [draft-ietf-pppext-bridgemib-03] (23 pages) - Point-to-Point Protocol extensions for bridging [draft-ietf-pppext-bridging-01] (0 pages) - PPP BSD Compression Protocol [draft-ietf-pppext-bsd-compress-05] (27 pages) - Proposal for Callback Control Protocol (CBCP). [draft-ietf-pppext-callback-cp-02] (9 pages) - PPP LCP CallBack [draft-ietf-pppext-callback-ds-02] (7 pages) - PPP Challenge Handshake Authentication Protocol (CHAP) [draft-ietf-pppext-chap-ds-00] (14 pages) - Compressing IPX Headers Over WAN Media (CIPX) [draft-ietf-pppext-cipx-04] (27 pages) - PPP Consistent Overhead Byte Stuffing (COBS) [draft-ietf-pppext-cobs-00] (27 pages) - The PPP Compression Control Protocol (CCP) [draft-ietf-pppext-compression-04] (12 pages) - PPP with Framing Conversion [draft-ietf-pppext-conversion-01] (4 pages) - PPP Certificate Exchange Protocol [draft-ietf-pppext-crtxchg-01] (16 pages) - PPP LCP Option for Data Encapsulation Selection [draft-ietf-pppext-dataencap-03] (6 pages) - PPP for Data Compression in Data Circuit-Terminating Equipment (DCE) [draft-ietf-pppext-dce-compress-00] (9 pages) - The PPP DECnet Phase IV Control Protocol (DNCP) [draft-ietf-pppext-decnet-03] (8 pages) - PPP Deflate Protocol [draft-ietf-pppext-deflate-00] (11 pages) - The PPP DES Encryption Protocol (DESE) [draft-ietf-pppext-des-encrypt-01] (10 pages) - The PPP DES Encryption Protocol, Version 2 (DESE-bis) [draft-ietf-pppext-des-encrypt-v2-02] (11 pages) - The PPP DECnet Phase IV Control Protocol (DNCP) [draft-ietf-pppext-dncp-00] (7 pages) - PPP Extensible Authentication Protocol (EAP) [draft-ietf-pppext-eap-auth-02] (18 pages) - PPP EAP SRP-SHA1 Authentication Protocol [draft-ietf-pppext-eap-srp-03] (25 pages) - EAP Tunneled TLS Authentication Protocol (EAP-TTLS) [draft-ietf-pppext-eap-ttls-05] (52 pages) - PPP EAP DSS Public Key Authentication Protocol [draft-ietf-pppext-eapdss-01] (13 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 EAP RSA Public Key Authentication Protocol [draft-ietf-pppext-eaprsa-07] (14 pages) - PPP EAP TLS Authentication Protocol [draft-ietf-pppext-eaptls-06] (25 pages) - The PPP Encryption Control Protocol (ECP) [draft-ietf-pppext-encryption-04] (11 pages) - PPP in Ether-like Framing [draft-ietf-pppext-ether-00] (6 pages) - PPP Fortezza Encryption Encapsulation Protocol [draft-ietf-pppext-feep-01] (12 pages) - PPP Bridging Control Protocol (BCP) [draft-ietf-pppext-for-bridging-04] (31 pages) - PPP in Frame Relay [draft-ietf-pppext-frame-relay-03] (8 pages) - PPP in Frame Relay [draft-ietf-pppext-framerelay-ds-01] (8 pages) - PPP Over FUNI [draft-ietf-pppext-funi-05] (10 pages) - PPP Gandalf FZA Compression Protocol [draft-ietf-pppext-gandalf-00] (6 pages) - The Generic Athentication Protocol (GAP) [draft-ietf-pppext-gap-auth-00] (8 pages) - PPP in HDLC Framing [draft-ietf-pppext-hdlc-framing-02] (20 pages) - PPP in HDLC-like Framing [draft-ietf-pppext-hdlc-fs-02] (25 pages) - PPP Hewlett-Packard Packet-by-Packet Compression (HP PPC) Protocol [draft-ietf-pppext-hpppc-00] (5 pages) - The PPP Internet Protocol Control Protocol (IPCP) [draft-ietf-pppext-ipcp-02] (13 pages) - Mobile-IPv4 Configuration Option for PPP IPCP [draft-ietf-pppext-ipcp-mip-02] (18 pages) - The PPP Internet Protocol Control Protocol (IPCP) [draft-ietf-pppext-ipcp-network-04] (13 pages) - The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol [draft-ietf-pppext-ipcpmib-04] (18 pages) - PPP IPV6 Control Protocol Extensions for DNS Server Addresses [draft-ietf-pppext-ipv6-dns-addr-03] (7 pages) - The PPP Internetworking Packet Exchange Control Protocol (IPXCP) [draft-ietf-pppext-ipxcp-04] (19 pages) - PPP over ISDN [draft-ietf-pppext-isdn-03] (7 pages) - PPP Kerberos Authentication Protocol (KAP) [draft-ietf-pppext-kap-auth-00] (15 pages) - PPP Kerberos version 4 Authentication Protocol (KAPv4) [draft-ietf-pppext-kapv4-auth-00] (19 pages) - Layer Two Tunneling Protocol "L2TP" [draft-ietf-pppext-l2tp-16] (75 pages) - Layer Two Tunneling Protocol (L2TP) over AAL5 and FUNI [draft-ietf-pppext-l2tp-aal5-funi-00] (7 pages) - L2TP Link Extensions [draft-ietf-pppext-l2tp-link-00] (6 pages) - Layer Two Tunneling Protocol 'L2TP' Security Extensions for Non-IP networks [draft-ietf-pppext-l2tp-sec-04] (13 pages) - L2TP Alternate Data Channel (``L2TPADC'') [draft-ietf-pppext-l2tpadc-00] (3 pages) - L2TP Dynamic Data Window Adjustment [draft-ietf-pppext-l2tpdwin-01] (7 pages) - L2TP Header Compression (''L2TPHC'') [draft-ietf-pppext-l2tphc-01] (6 pages) - Framework for L2TP Message Extensions [draft-ietf-pppext-l2tpmsgext-00] (5 pages) - L2TP-over-IP Path MTU Discovery (''L2TPMTU'') [draft-ietf-pppext-l2tpmtu-00] (26 pages) - PPP Link Balancing Detection (LBD) [draft-ietf-pppext-lbd-03] (5 pages) - The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links [draft-ietf-pppext-lcp-02] (68 pages) - PPP LCP Internationalization Configuration Option [draft-ietf-pppext-lcp-charset-07] (5 pages) - The Point-to-Point Protocol (PPP) [draft-ietf-pppext-lcp-fs-02] (52 pages) - The Point-to-Point Protocol (PPP) [draft-ietf-pppext-lcp-main-02] (62 pages) - PPP LCP Extensions [draft-ietf-pppext-lcpext-04] (22 pages) - PPP LCP Extensions [draft-ietf-pppext-lcpext-ds-03] (7 pages) - The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol [draft-ietf-pppext-lcpmib-03] (34 pages) - Proposal for LCP Authentication Option [draft-ietf-pppext-link-negot-00] (7 pages) - Proposal for LCP Authentication Option [draft-ietf-pppext-linknegot-00] (7 pages) - PPP Link Quality Monitoring [draft-ietf-pppext-lqm-01] (16 pages) - PPP Link Quality Monitoring [draft-ietf-pppext-lqm-ds-00] (15 pages) - PPP LZS-DCP Compression Protocol (LZS-DCP) [draft-ietf-pppext-lzs-dcp-01] (15 pages) - PPP Magnalink Variable Resource Compression [draft-ietf-pppext-magnalink-01] (6 pages) - Nortel Networks Multi-link Multi-node PPP Bundle Discovery Protocol [draft-ietf-pppext-mmp-discovery-02] (8 pages) - QoS Mapping Extensions to Multilink PPP [draft-ietf-pppext-mp-qos-00] (13 pages) - Microsoft Point-To-Point Compression (MPPC) Protocol [draft-ietf-pppext-mppc-00] (9 pages) - Microsoft Point-To-Point Encryption (MPPE) Protocol [draft-ietf-pppext-mppe-05] (12 pages) - Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE) [draft-ietf-pppext-mppe-keys-03] (20 pages) - Mobile PPP (MPPP) [draft-ietf-pppext-mppp-01] (15 pages) - Microsoft PPP CHAP Extensions [draft-ietf-pppext-mschap-00] (19 pages) - Microsoft PPP CHAP Extensions, Version 2 [draft-ietf-pppext-mschap-v2-04] (21 pages) - Deriving MPPE Keys From MS-CHAP V1 Credentials [draft-ietf-pppext-mschapv1-keys-00] (7 pages) - Deriving MPPE Keys From MS-CHAP V2 Credentials [draft-ietf-pppext-mschapv2-keys-02] (10 pages) - The PPP Multilink Protocol (MP) [draft-ietf-pppext-multilink-12] (25 pages) - The PPP NetBIOS Frames Control Protocol (NBFCP) [draft-ietf-pppext-netbios-fcp-07] (14 pages) - Proposal for a PPP Network Layer Entity Selection Protocol [draft-ietf-pppext-nles-00] (7 pages) - The PPP OSI Network Layer Control Protocol (OSINLCP) [draft-ietf-pppext-osinlcp-02] (12 pages) - The One Time Password (OTP) and Generic Token Card Authentication Protocols [draft-ietf-pppext-otp-00] (12 pages) - PPP LCP Self Describing Padding [draft-ietf-pppext-padding-ds-01] (6 pages) - Extending Point-to-Point Protocol (PPP) over Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) with virtual concatenation, high order and low order payloads [draft-ietf-pppext-posvcholo-06] (8 pages) - PPP Over Asynchronous Transfer Mode Adaptation Layer 2 (AAL2) [draft-ietf-pppext-ppp-over-aal2-03] (0 pages) - Class Extensions for PPP over Asynchronous Transfer Mode Adaptation Layer 2 [draft-ietf-pppext-ppp-over-aal2-class-02] (0 pages) - PPP Multiplexing [draft-ietf-pppext-pppmux-03] (8 pages) - Accommodating an MTU of 1500 in PPPoE [draft-ietf-pppext-pppoe-mtu-1500-00] (0 pages) - PPP over SONET/SDH [draft-ietf-pppext-pppoversonet-update-04] (9 pages) - PPP over SONET/SDH [draft-ietf-pppext-pppsonet-scrambler-00] (14 pages) - Point-to-Point Tunneling Protocol (PPTP) [draft-ietf-pppext-pptp-10] (57 pages) - PPP Predictor Compression Protocol [draft-ietf-pppext-predictor-00] (9 pages) - PPP Public Key Encryption Based Authentication [draft-ietf-pppext-public-key-00] (10 pages) - PPP Reliable Transmission [draft-ietf-pppext-reliable-00] (10 pages) - Requirements for an Internet Standard Point-to-Point Protocol [draft-ietf-pppext-requirements-01] (21 pages) - Extensible Authentication Protocol (EAP) [draft-ietf-pppext-rfc2284bis-10] (40 pages) - Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP) [draft-ietf-pppext-rfc2878bis-01] (38 pages) - Semi Connected Mode for PPP links [draft-ietf-pppext-scm-01] (20 pages) - PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing [draft-ietf-pppext-sdl-05] (29 pages) - PPP over Simple Data Link (SDL) using raw lightwave channels with ATM-like framing [draft-ietf-pppext-sdl-pol-00] (25 pages) - PPP Serial Data Transport Protocol (SDTP) [draft-ietf-pppext-sdtp-00] (19 pages) - The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol [draft-ietf-pppext-secmib-03] (21 pages) - Secure Remote Access with L2TP [draft-ietf-pppext-secure-ra-00] (18 pages) - The PPP SNA Control Protocol (SNACP) [draft-ietf-pppext-snacp-01] (8 pages) - PPP over SONET/SDH [draft-ietf-pppext-sonet-01] (5 pages) - Applicability Statement for PPP over SONET/SDH [draft-ietf-pppext-sonet-as-00] (21 pages) - PPP over SONET/SDH [draft-ietf-pppext-sonet-ds-01] (12 pages) - PPP Protocol Spoofing Control Protocol (PSCP) [draft-ietf-pppext-spoof-00] (26 pages) - PPP Stac LZS Compression Protocol [draft-ietf-pppext-stacker-10] (18 pages) - PPP Vendor Extensions [draft-ietf-pppext-vendor-00] (6 pages) - Point-to-Point Protocol (PPP) Vendor Protocol [draft-ietf-pppext-vendor-protocol-02] (11 pages) - The PPP Banyan Vines Control Protocol (BVCP) [draft-ietf-pppext-vines-01] (10 pages) - PPP WAN Compression Protocol [draft-ietf-pppext-wcp-00] (20 pages) - PPP in X.25 [draft-ietf-pppext-x25-02] (7 pages) - PPP in X.25 [draft-ietf-pppext-x25-ds-01] (8 pages) - The PPP XNS IDP Control Protocol (XNSCP) [draft-ietf-pppext-xnscp-00] (5 pages) - IANA Considerations for the Point-to-Point Protocol (PPP) [draft-schryver-pppext-iana-01] (4 pages) Requests for Comments: BCP0088: IANA Considerations for the Point-to-Point Protocol (PPP) (4 pages) RFC1220: Point-to-Point Protocol extensions for bridging (0 pages) * Obsoletes RFC1638 RFC1331: The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links (68 pages) * Obsoletes RFC1171 * Obsoletes RFC1172 * Obsoletes RFC1548 RFC1332: The PPP Internet Protocol Control Protocol (IPCP) (13 pages) * Obsoletes RFC1172 * Updates RFC3241 RFC1333: PPP Link Quality Monitoring (16 pages) * Obsoletes RFC1989 RFC1334: PPP Authentication Protocols (20 pages) * Obsoletes RFC1994 RFC1376: The PPP DECnet Phase IV Control Protocol (DNCP) (8 pages) * Obsoletes RFC1762 RFC1377: The PPP OSI Network Layer Control Protocol (OSINLCP) (12 pages) RFC1378: The PPP AppleTalk Control Protocol (ATCP) (20 pages) RFC1471: The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol (34 pages) RFC1472: The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol (21 pages) RFC1473: The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol (18 pages) RFC1474: The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol (23 pages) RFC1547: Requirements for an Internet Standard Point-to-Point Protocol (21 pages) RFC1548: The Point-to-Point Protocol (PPP) (62 pages) * Obsoletes RFC1331 * Obsoletes RFC1661 * Updates RFC1570 RFC1549: PPP in HDLC Framing (20 pages) * Obsoletes RFC1662 RFC1552: The PPP Internetworking Packet Exchange Control Protocol (IPXCP) (19 pages) RFC1553: Compressing IPX Headers Over WAN Media (CIPX) (27 pages) RFC1570: PPP LCP Extensions (22 pages) * Updates RFC1548 * Updates RFC2484 RFC1598: PPP in X.25 (7 pages) RFC1618: PPP over ISDN (7 pages) RFC1619: PPP over SONET/SDH (5 pages) * Obsoletes RFC2615 RFC1638: PPP Bridging Control Protocol (BCP) (31 pages) * Obsoletes RFC1220 * Obsoletes RFC2878 RFC1661: The Point-to-Point Protocol (PPP) (52 pages) * Obsoletes RFC1548 * Updates RFC2153 RFC1662: PPP in HDLC-like Framing (25 pages) * Obsoletes RFC1549 RFC1663: PPP Reliable Transmission (10 pages) RFC1762: The PPP DECnet Phase IV Control Protocol (DNCP) (7 pages) * Obsoletes RFC1376 RFC1763: The PPP Banyan Vines Control Protocol (BVCP) (10 pages) RFC1764: The PPP XNS IDP Control Protocol (XNSCP) (5 pages) RFC1962: The PPP Compression Control Protocol (CCP) (12 pages) * Updates RFC2153 RFC1963: PPP Serial Data Transport Protocol (SDTP) (19 pages) RFC1967: PPP LZS-DCP Compression Protocol (LZS-DCP) (15 pages) RFC1968: The PPP Encryption Control Protocol (ECP) (11 pages) RFC1969: The PPP DES Encryption Protocol (DESE) (10 pages) * Obsoletes RFC2419 RFC1973: PPP in Frame Relay (8 pages) RFC1974: PPP Stac LZS Compression Protocol (18 pages) RFC1975: PPP Magnalink Variable Resource Compression (6 pages) RFC1976: PPP for Data Compression in Data Circuit-Terminating Equipment (DCE) (9 pages) RFC1977: PPP BSD Compression Protocol (27 pages) RFC1978: PPP Predictor Compression Protocol (9 pages) RFC1979: PPP Deflate Protocol (11 pages) RFC1989: PPP Link Quality Monitoring (15 pages) * Obsoletes RFC1333 RFC1990: The PPP Multilink Protocol (MP) (25 pages) * Obsoletes RFC1717 RFC1993: PPP Gandalf FZA Compression Protocol (6 pages) RFC1994: PPP Challenge Handshake Authentication Protocol (CHAP) (14 pages) * Obsoletes RFC1334 * Updates RFC2484 RFC2043: The PPP SNA Control Protocol (SNACP) (8 pages) RFC2097: The PPP NetBIOS Frames Control Protocol (NBFCP) (14 pages) RFC2118: Microsoft Point-To-Point Compression (MPPC) Protocol (9 pages) RFC2125: The PPP Bandwidth Allocation Protocol (BAP) / The PPP Bandwidth Allocation Control Protocol (BACP) (22 pages) RFC2153: PPP Vendor Extensions (6 pages) * Updates RFC1661 * Updates RFC1962 * Updates RFC5342 RFC2284: PPP Extensible Authentication Protocol (EAP) (18 pages) * Obsoletes RFC3748 * Updates RFC2484 RFC2290: Mobile-IPv4 Configuration Option for PPP IPCP (18 pages) * Updates RFC2002 * Updates RFC2794 RFC2363: PPP Over FUNI (10 pages) RFC2364: PPP Over AAL5 (11 pages) RFC2419: The PPP DES Encryption Protocol, Version 2 (DESE-bis) (11 pages) * Obsoletes RFC1969 RFC2420: The PPP Triple-DES Encryption Protocol (3DESE) (8 pages) RFC2433: Microsoft PPP CHAP Extensions (19 pages) RFC2484: PPP LCP Internationalization Configuration Option (5 pages) * Updates RFC1570 * Updates RFC1994 * Updates RFC2284 RFC2509: IP Header Compression over PPP (9 pages) * Obsoletes RFC3544 RFC2615: PPP over SONET/SDH (9 pages) * Obsoletes RFC1619 RFC2637: Point-to-Point Tunneling Protocol (PPTP) (57 pages) RFC2661: Layer Two Tunneling Protocol "L2TP" (75 pages) RFC2701: Nortel Networks Multi-link Multi-node PPP Bundle Discovery Protocol (8 pages) RFC2716: PPP EAP TLS Authentication Protocol (25 pages) * Obsoletes RFC5216 RFC2759: Microsoft PPP CHAP Extensions, Version 2 (21 pages) RFC2823: PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing (29 pages) RFC2878: PPP Bridging Control Protocol (BCP) (38 pages) * Obsoletes RFC1638 * Obsoletes RFC3518 RFC3078: Microsoft Point-To-Point Encryption (MPPE) Protocol (12 pages) RFC3079: Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE) (20 pages) RFC3153: PPP Multiplexing (8 pages) RFC3255: Extending Point-to-Point Protocol (PPP) over Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) with virtual concatenation, high order and low order payloads (8 pages) RFC3336: PPP Over Asynchronous Transfer Mode Adaptation Layer 2 (AAL2) (0 pages) RFC3337: Class Extensions for PPP over Asynchronous Transfer Mode Adaptation Layer 2 (0 pages) RFC3518: Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP) (38 pages) * Obsoletes RFC2878 RFC3772: Point-to-Point Protocol (PPP) Vendor Protocol (11 pages) RFC3818: IANA Considerations for the Point-to-Point Protocol (PPP) (4 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) STD0051: PPP in HDLC-like Framing (25 pages) * Obsoletes RFC1549 Port Control Protocol (pcp) --------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Alain Durand Dave Thaler Internet Area Directors: Ralph Droms Brian Haberman Internet Area Advisor: Ralph E. Droms 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/ 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-24] (97 pages) - DHCP Options for the Port Control Protocol (PCP) [draft-ietf-pcp-dhcp-03] (12 pages) - Port Control Protocol (PCP) Proxy Function [draft-ietf-pcp-proxy-00] (12 pages) - Universal Plug and Play (UPnP) Internet Gateway Device (IGD)-Port Control Protocol (PCP) Interworking Function [draft-ietf-pcp-upnp-igd-interworking-01] (24 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 Brian Haberman Internet Area Advisor: Ralph E. 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/ 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) - RADIUS Attribute for 6rd [draft-ietf-softwire-6rd-radius-attrib-05] (10 pages) - BGP Traffic Engineering Attribute [draft-ietf-softwire-bgp-te-attribute-04] (7 pages) - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite [draft-ietf-softwire-ds-lite-tunnel-option-10] (8 pages) - Deployment Considerations for Dual-Stack Lite [draft-ietf-softwire-dslite-deployment-03] (14 pages) - Multicast Extensions to DS-Lite Technique in Broadband Deployments [draft-ietf-softwire-dslite-multicast-02] (20 pages) - RADIUS Extensions for Dual-Stack Lite [draft-ietf-softwire-dslite-radius-ext-07] (12 pages) - Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion [draft-ietf-softwire-dual-stack-lite-11] (33 pages) - BGP IPsec Tunnel Encapsulation Attribute [draft-ietf-softwire-encaps-ipsec-03] (9 pages) - The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute [draft-ietf-softwire-encaps-safi-05] (14 pages) - Gateway Initiated Dual-Stack Lite Deployment [draft-ietf-softwire-gateway-init-ds-lite-08] (14 pages) - Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2) [draft-ietf-softwire-hs-framework-l2tpv2-13] (42 pages) - IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification [draft-ietf-softwire-ipv6-6rd-10] (19 pages) - Load-Balancing for Mesh Softwires [draft-ietf-softwire-lb-03] (7 pages) - Softwire Mesh Framework [draft-ietf-softwire-mesh-framework-06] (32 pages) - Softwire Mesh Multicast [draft-ietf-softwire-mesh-multicast-02] (27 pages) - DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes [draft-ietf-softwire-multicast-prefix-option-00] (8 pages) - Softwire Problem Statement [draft-ietf-softwire-problem-statement-03] (29 pages) - Public IPv4 over IPv6 Access Network [draft-ietf-softwire-public-4over6-01] (12 pages) - Softwire Security Analysis and Requirements [draft-ietf-softwire-security-requirements-09] (28 pages) - Motivations for Stateless IPv4 over IPv6 Migration Solutions [draft-ietf-softwire-stateless-4v6-motivation-01] (16 pages) - Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop [draft-ietf-softwire-v4nlri-v6nh-02] (12 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 (14 pages) RFC5543: BGP Traffic Engineering Attribute (7 pages) RFC5549: Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop (12 pages) RFC5565: Softwire Mesh Framework (32 pages) * Replaces DRAFT-WU-SOFTWIRE-MESH-FRAMEWORK RFC5566: BGP IPsec Tunnel Encapsulation Attribute (9 pages) RFC5571: Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2) (42 pages) RFC5619: Softwire Security Analysis and Requirements (28 pages) RFC5640: Load-Balancing for Mesh Softwires (7 pages) * Replaces DRAFT-PMOHAPAT-SOFTWIRE-LB RFC5969: IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification (19 pages) RFC6333: Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion (33 pages) * Replaces DRAFT-DURAND-SOFTWIRE-DUAL-STACK-LITE RFC6334: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite (8 pages) * Replaces DRAFT-DHANKINS-SOFTWIRE-TUNNEL-OPTION RFC6519: RADIUS Extensions for Dual-Stack Lite (12 pages) Source Address Validation Improvements (savi) --------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Jean-Michel Combes Christian Vogt Internet Area Directors: Ralph Droms Brian Haberman Internet Area Advisor: Ralph E. Droms 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/ 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 Solution for DHCP [draft-ietf-savi-dhcp-12] (26 pages) - FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses [draft-ietf-savi-fcfs-14] (32 pages) - Source Address Validation Improvement Framework [draft-ietf-savi-framework-06] (15 pages) - SAVI for Mixed Address Assignment Methods Scenario [draft-ietf-savi-mix-02] (9 pages) - A Solution Space Analysis for First-Hop IP Source Address Validation [draft-ietf-savi-rationale-00] (6 pages) - SEND-based Source-Address Validation Implementation [draft-ietf-savi-send-07] (32 pages) - SAVI Threat Scope [draft-ietf-savi-threat-scope-05] (22 pages) Requests for Comments: RFC6620: FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses (32 pages) * Replaces DRAFT-BAGNULO-SAVI-FCFS Timing over IP Connection and Transfer of Clock (tictoc) -------------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Yaakov Stein Karen O'Donoghue Internet Area Directors: Ralph Droms Brian Haberman Internet Area Advisor: Brian K. Haberman 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) - 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 Requirement [draft-ietf-tictoc-requirements-01] (32 pages) - TICTOC Security Requirements [draft-ietf-tictoc-security-requirements-01] (16 pages) - Architecture for the Transmission of Timing over Packet Networks [draft-stein-tictoc-modules-03] (22 pages) No Requests for Comments Transparent Interconnection of Lots of Links (trill) ---------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Donald E. Eastlake 3rd Erik Nordmark Internet Area Directors: Ralph Droms Brian Haberman Internet Area Advisor: Ralph E. Droms Mailing Lists: General Discussion: trill@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/trill Archive: http://www.ietf.org/mail-archive/web/trill/current/maillist.html 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: - PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol [draft-ietf-pppext-trill-protocol-08] (11 pages) - Routing Bridges (RBridges): Adjacency [draft-ietf-trill-adj-07] (32 pages) - TRILL: Clarifications, Corrections, and Updates [draft-ietf-trill-clear-correct-03] (29 pages) - Coordinated Multicast Trees (CMT)for TRILL [draft-ietf-trill-cmt-00] (14 pages) - TRILL: Fine-Grained Labeling [draft-ietf-trill-fine-labeling-00] (20 pages) - Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement [draft-ietf-trill-prob-06] (18 pages) - Routing Bridges (RBridges): Appointed Forwarders [draft-ietf-trill-rbridge-af-05] (23 pages) - The Architecture of an RBridge Solution to TRILL [draft-ietf-trill-rbridge-arch-05] (36 pages) - TRILL: Bidirectional Forwarding Detection (BFD) Support [draft-ietf-trill-rbridge-bfd-05] (16 pages) - TRILL: RBridge Channel Support [draft-ietf-trill-rbridge-channel-05] (26 pages) - TRILL: Header Extension [draft-ietf-trill-rbridge-extension-04] (15 pages) - Definitions of Managed Objects for RBridges (Routing Bridges) [draft-ietf-trill-rbridge-mib-07] (56 pages) - Routing Bridges (RBridges): Operations, Administration, and Maintenance (OAM) Support [draft-ietf-trill-rbridge-oam-02] (33 pages) - RBridges: Further TRILL Header Extensions [draft-ietf-trill-rbridge-options-06] (19 pages) - Routing Bridges (RBridges): Base Protocol Specification [draft-ietf-trill-rbridge-protocol-16] (117 pages) - RBridges: Campus VLAN and Priority Regions [draft-ietf-trill-rbridge-vlan-mapping-07] (19 pages) - TRILL Routing Requirements in Support of RBridges [draft-ietf-trill-routing-reqs-02] (11 pages) Requests for Comments: RFC5556: Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement (18 pages) * Replaces DRAFT-TOUCH-TRILL-PROB RFC6325: Routing Bridges (RBridges): Base Protocol Specification (117 pages) * Replaces DRAFT-PERLMAN-TRILL-RBRIDGE-PROTOCOL * Updates RFC6327 * Updates RFC6439 RFC6327: Routing Bridges (RBridges): Adjacency (32 pages) * Updates RFC6325 RFC6361: PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol (11 pages) RFC6439: Routing Bridges (RBridges): Appointed Forwarders (23 pages) * Replaces DRAFT-PERLMAN-TRILL-RBRIDGE-AF * Updates RFC6325 sunset4 (sunset4) ----------------- Charter Last Modified: 2012-04-05 Current Status: Active Chairs: Marc Blanchet Wesley George Internet Area Directors: Ralph Droms Brian Haberman Internet Area Advisor: Ralph E. Droms Tech Advisors: Martin Stiemerling Stewart Bryant Fred Baker Mailing Lists: General Discussion: sunset4@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sunset4 Archive: http://www.ietf.org/mail-archive/web/sunset4/ Description of Working Group: The IETF is committed to the deployment of IPv6 to ensure the evolution of the Internet. However, the IPv4-only components of the Internet must continue to operate as much as possible during the transition from IPv4 to IPv6. The Working Group will standardize technologies that facilitate the graceful sunsetting of the IPv4 Internet in the context of the exhaustion of IPv4 address space while IPv6 is deployed. These technologies will likely be less optimal than equivalent technologies for IPv6-only and dual-stack networks. The Working Group works only on IPv4 protocols to facilitate IPv4 sunsetting. The Working Group may work on fixing security bugs in existing IPv4-specific protocols but is not chartered to add new security functionality to those protocols. The working group will provide a single venue for the consideration of IPv4 sunsetting, while ensuring that any such technologies do not impede the deployment of IPv6 and do not duplicate functions and capabilities already available in existing technologies. Therefore, along the lines of draft-george-ipv6-support, before the working group adopts any technology, it must: 1) describe the problem to be solved and show that there is widespread demand for a solution 2) demonstrate that the problem can not be solved with existing technologies 3) provide a description of the proposed solution along with the impact on current IPv4-only use and its ability to promote the deployment of IPv6 These steps will likely be described in the form of a use case and requirements document. Only after the above mentioned steps have been completed and the results accepted by the community will the IETF consider adding new work items to the Working Group charter. This new work may include protocol specifications. The work spans over multiple IETF areas including as Internet, Operations, Transport and Routing. Therefore, cross-area coordination and support is essential and required. Any work on IPv4 to IPv6 transition methods is out of scope. The initial work items are: * Review current Carrier-Grade NAT (CGN) documents and related issues, including requirements for standardization, and determine if CGN is a suitable sunsetting technology to become a work item: draft-ietf-behave-lsn-requirements draft-ietf-behave-nat-mib CGN port allocation methods * Gap analysis of IPv4 features to facilitate IPv4 sunsetting Goals and Milestones: Sep 2012 - Complete review of CGN and, if necessary, propose CGN work items Jun 2013 - Send gap analysis on IPv4 sunsetting to IESG Internet-Drafts: No Requests for Comments ADSL MIB (adslmib) ------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chair: Menachem Dodge Operations and Management Area Directors: Ronald Bonica Benoit Claise Operations and Management Area Advisor: Benoit Claise Editors: Edward Beili <> Moti Morgenstern <> Scott Baillie <> 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/ 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 Asymmetric Digital Subscriber Line 2 (ADSL2) [draft-ietf-adslmib-adsl2-08] (166 pages) - Definitions of Extension Managed Objects for Asymmetric Digital Subscriber Lines [draft-ietf-adslmib-adslext-12] (36 pages) - Definitions of Managed Objects for the ADSL Lines [draft-ietf-adslmib-adsllinemib-09] (113 pages) - ATM-Based xDSL Bonded Interfaces MIB [draft-ietf-adslmib-gbond-atm-mib-06] (33 pages) - Ethernet-based xDSL multi-pair bonding (G.Bond/Ethernet) MIB [draft-ietf-adslmib-gbond-eth-mib-06] (53 pages) - xDSL multi-pair bonding (G.Bond) MIB [draft-ietf-adslmib-gbond-mib-10] (70 pages) - xDSL multi-pair bonding using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB [draft-ietf-adslmib-gbond-tdim-mib-08] (54 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-11] (76 pages) - High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals [draft-ietf-adslmib-hc-tc-07] (10 pages) - Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines Processing [draft-ietf-adslmib-hdsl2-12] (61 pages) - Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL) [draft-ietf-adslmib-vdsl-12] (68 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-06] (23 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-08] (18 pages) - Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2) [draft-ietf-adslmib-vdsl2-07] (215 pages) Requests for Comments: RFC2662: Definitions of Managed Objects for the ADSL Lines (113 pages) RFC3276: Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines Processing (61 pages) * Obsoletes 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: 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-00] (5 pages) - Problem Statement for ARMD [draft-ietf-armd-problem-statement-02] (16 pages) No Requests for Comments Benchmarking Methodology (bmwg) ------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chair: Al C. Morton Operations and Management Area Directors: 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/ 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: - RFC 2544 Applicability Statement: Use on Production Networks Considered Harmful [draft-ietf-bmwg-2544-as-03] (9 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) - 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) - Terminology for Accelerated Stress Benchmarking [draft-ietf-bmwg-acc-bench-term-13] (27 pages) - Methodology for ATM Benchmarking [draft-ietf-bmwg-atm-method-03] (168 pages) - Terminology for ATM Benchmarking [draft-ietf-bmwg-atm-term-00] (29 pages) - Terminology for ATM ABR Benchmarking [draft-ietf-bmwg-atm-term-abr-03] (18 pages) - Benchmarking Methodology for Routers Supporting Resource Reservation [draft-ietf-bmwg-benchres-method-00] (15 pages) - Benchmarking Terminology for Resource Reservation Capable Routers [draft-ietf-bmwg-benchres-term-08] (22 pages) - Benchmarking Methodology for Basic BGP Convergence [draft-ietf-bmwg-bgpbas-01] (16 pages) - Benchmarking Methodology for Content-Aware Network Devices [draft-ietf-bmwg-ca-bench-meth-01] (19 pages) - Terminology for Cell/Call Benchmarking [draft-ietf-bmwg-call-04] (29 pages) - Terminology for Benchmarking BGP Device Convergence in the Control Plane [draft-ietf-bmwg-conterm-06] (35 pages) - Methodology for Benchmarking Network-layer Traffic Control Mechanisms [draft-ietf-bmwg-dsmmeth-02] (13 pages) - Terminology for Benchmarking Network-layer Traffic Control Mechanisms [draft-ietf-bmwg-dsmterm-13] (32 pages) - Benchmarking Methodology for Ethernet Switches [draft-ietf-bmwg-ethernet-switches-01] (13 pages) - Methodology for Forwarding Information Base (FIB) based Router Performance [draft-ietf-bmwg-fib-meth-03] (13 pages) - Terminology for Forwarding Information Base (FIB) based Router Performance [draft-ietf-bmwg-fib-term-04] (13 pages) - Benchmarking Methodology for Firewall Performance [draft-ietf-bmwg-firewall-08] (30 pages) - Terminology for Frame Relay Benchmarking [draft-ietf-bmwg-fr-term-06] (24 pages) - Hash and Stuffing: Overlooked Factors in Network Device Benchmarking [draft-ietf-bmwg-hash-stuffing-08] (34 pages) - Considerations for Benchmarking Link-State IGP Data Plane Route Convergence [draft-ietf-bmwg-igp-dataplane-conv-app-17] (6 pages) - Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence [draft-ietf-bmwg-igp-dataplane-conv-meth-23] (43 pages) - Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence [draft-ietf-bmwg-igp-dataplane-conv-term-23] (27 pages) - IMIX Genome: Specification of variable packet sizes for additional testing [draft-ietf-bmwg-imix-genome-01] (9 pages) - IP Flow Information Accounting and Export Benchmarking Methodology [draft-ietf-bmwg-ipflow-meth-10] (33 pages) - Connectivity [draft-ietf-bmwg-ippm-connect-00] (9 pages) - Methodology for Benchmarking IPsec Devices [draft-ietf-bmwg-ipsec-meth-05] (41 pages) - Terminology for Benchmarking IPsec Devices [draft-ietf-bmwg-ipsec-term-12] (46 pages) - IPv6 Benchmarking Methodology for Network Interconnect Devices [draft-ietf-bmwg-ipv6-meth-05] (19 pages) - Benchmarking Terminology for LAN Switching Devices [draft-ietf-bmwg-lanswitch-06] (25 pages) - Terminology for IP Multicast Benchmarking [draft-ietf-bmwg-mcast-08] (15 pages) - Methodology for IP Multicast Benchmarking [draft-ietf-bmwg-mcastm-14] (31 pages) - Benchmarking Methodology for Network Interconnect Devices [draft-ietf-bmwg-methodology-02] (23 pages) - MPLS Forwarding Benchmarking Methodology for IP Flows [draft-ietf-bmwg-mpls-forwarding-meth-06] (31 pages) - Benchmarking Methodology for LAN Switching Devices [draft-ietf-bmwg-mswitch-04] (34 pages) - Considerations When Using Basic OSPF Convergence Benchmarks [draft-ietf-bmwg-ospfconv-applicability-07] (12 pages) - Benchmarking Basic OSPF Single Router Control Plane Convergence [draft-ietf-bmwg-ospfconv-intraarea-10] (16 pages) - OSPF Benchmarking Terminology and Concepts [draft-ietf-bmwg-ospfconv-term-10] (10 pages) - Benchmarking Methodologies for Overall Network Performance [draft-ietf-bmwg-overallperf-00] (6 pages) - Methodology for benchmarking MPLS protection mechanisms [draft-ietf-bmwg-protection-meth-09] (35 pages) - Benchmarking Terminology for Protection Performance [draft-ietf-bmwg-protection-term-09] (29 pages) - Device Reset Characterization [draft-ietf-bmwg-reset-06] (20 pages) - Framework for Router Benchmarking [draft-ietf-bmwg-rtr-framework-00] (8 pages) - Benchmarking Terminology for Firewall Performance [draft-ietf-bmwg-secperf-08] (23 pages) - Methodology for Benchmarking SIP Networking Devices [draft-ietf-bmwg-sip-bench-meth-04] (20 pages) - Terminology for Benchmarking Session Initiation Protocol (SIP) Networking Devices [draft-ietf-bmwg-sip-bench-term-04] (36 pages) - Benchmarking Terminology for Network Interconnection Devices [draft-ietf-bmwg-terms-01] (0 pages) Requests for Comments: RFC1242: Benchmarking Terminology for Network Interconnection Devices (0 pages) * Updates RFC6201 RFC1944: Benchmarking Methodology for Network Interconnect Devices (23 pages) * Obsoletes RFC2544 RFC2285: Benchmarking Terminology for LAN Switching Devices (25 pages) RFC2432: Terminology for IP Multicast Benchmarking (15 pages) RFC2647: Benchmarking Terminology for Firewall Performance (23 pages) RFC2761: Terminology for ATM Benchmarking (29 pages) RFC2889: Benchmarking Methodology for LAN Switching Devices (34 pages) RFC3116: Methodology for ATM Benchmarking (168 pages) RFC3133: Terminology for Frame Relay Benchmarking (24 pages) RFC3134: Terminology for ATM ABR Benchmarking (18 pages) RFC3222: Terminology for Forwarding Information Base (FIB) based Router Performance (13 pages) RFC3511: Benchmarking Methodology for Firewall Performance (30 pages) RFC3918: Methodology for IP Multicast Benchmarking (31 pages) RFC4061: Benchmarking Basic OSPF Single Router Control Plane Convergence (16 pages) RFC4062: OSPF Benchmarking Terminology and Concepts (10 pages) RFC4063: Considerations When Using Basic OSPF Convergence Benchmarks (12 pages) RFC4098: Terminology for Benchmarking BGP Device Convergence in the Control Plane (35 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 (31 pages) RFC6201: Device Reset Characterization (20 pages) * Replaces DRAFT-ASATI-BMWG-RESET * 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: Jouni Korhonen Lionel Morand Operations and Management Area Directors: Ronald Bonica Benoit Claise Operations and Management Area Advisor: Benoit Claise 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/ 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: - Diameter Applications Design Guidelines [draft-ietf-dime-app-design-guide-14] (26 pages) - The Diameter Capabilities Update Application [draft-ietf-dime-capablities-update-07] (7 pages) - The Diameter API [draft-ietf-dime-diameter-api-08] (46 pages) - Diameter Base Protocol MIB [draft-ietf-dime-diameter-base-protocol-mib-06] (51 pages) - Diameter Credit Control Application MIB [draft-ietf-dime-diameter-cc-appl-mib-03] (21 pages) - Updated IANA Considerations for Diameter Command Code Allocations [draft-ietf-dime-diameter-cmd-iana-01] (10 pages) - Diameter Quality-of-Service Application [draft-ietf-dime-diameter-qos-15] (58 pages) - Diameter Support for the EAP Re-authentication Protocol (ERP) [draft-ietf-dime-erp-09] (16 pages) - Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage [draft-ietf-dime-extended-naptr-09] (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 Mobile IPv6: Support for Network Access Server to Diameter Server Interaction [draft-ietf-dime-mip6-integrated-12] (18 pages) - Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction [draft-ietf-dime-mip6-split-17] (42 pages) - Clarifications on the Routing of Diameter Requests Based on the Username and the Realm [draft-ietf-dime-nai-routing-04] (12 pages) - Diameter Network Address and Port Translation Control Application [draft-ietf-dime-nat-control-17] (62 pages) - Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server [draft-ietf-dime-pmip6-04] (21 pages) - Diameter Support for Proxy Mobile IPv6 Localized Routing [draft-ietf-dime-pmip6-lr-12] (12 pages) - Diameter Priority Attribute Value Pairs [draft-ietf-dime-priority-avps-05] (8 pages) - Traffic Classification and Quality of Service (QoS) Attributes for Diameter [draft-ietf-dime-qos-attributes-15] (44 pages) - Quality of Service Parameters for Usage with Diameter [draft-ietf-dime-qos-parameters-11] (11 pages) - Realm-Based Redirection In Diameter [draft-ietf-dime-realm-based-redirect-04] (7 pages) - Diameter Base Protocol [draft-ietf-dime-rfc3588bis-33] (154 pages) - Diameter Network Access Server Application [draft-ietf-dime-rfc4005bis-08] (66 pages) Requests for Comments: RFC5447: Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction (18 pages) * Replaces DRAFT-TSCHOFENIG-DIME-MIP6-INTEGRATED RFC5624: Quality of Service Parameters for Usage with Diameter (11 pages) * Replaces DRAFT-KORHONEN-DIME-QOS-PARAMETERS RFC5719: Updated IANA Considerations for Diameter Command Code Allocations (10 pages) * Updates RFC3588 RFC5729: Clarifications on the Routing of Diameter Requests Based on the Username and the Realm (12 pages) * Replaces DRAFT-KORHONEN-DIME-NAI-ROUTING * Updates RFC3588 RFC5777: Traffic Classification and Quality of Service (QoS) Attributes for Diameter (44 pages) * Replaces DRAFT-KORHONEN-DIME-QOS-ATTRIBUTES RFC5778: Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction (42 pages) * Replaces DRAFT-TSCHOFENIG-DIME-MIP6-SPLIT RFC5779: Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server (21 pages) * Replaces DRAFT-KORHONEN-DIME-PMIP6 RFC5866: Diameter Quality-of-Service Application (58 pages) * Replaces DRAFT-TSCHOFENIG-DIME-DIAMETER-QOS RFC6408: Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage (14 pages) * Replaces DRAFT-JONES-DIME-EXTENDED-NAPTR * 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: 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: 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 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) - AS112 Nameserver Operations [draft-ietf-dnsop-as112-ops-09] (23 pages) - I'm Being Attacked by PRISONER.IANA.ORG! [draft-ietf-dnsop-as112-under-attack-help-help-06] (16 pages) - Observed DNS Resolution Misbehavior [draft-ietf-dnsop-bad-dns-res-06] (23 pages) - Locally Served DNS Zones [draft-ietf-dnsop-default-local-zones-15] (14 pages) - DNSSEC Policy & Practice Statement Framework [draft-ietf-dnsop-dnssec-dps-framework-07] (28 pages) - DNSSEC Key Timing Considerations [draft-ietf-dnsop-dnssec-key-timing-02] (33 pages) - DNSSEC Operational Practices [draft-ietf-dnsop-dnssec-operational-practices-08] (36 pages) - DNSSEC Trust Anchor Configuration and Maintenance [draft-ietf-dnsop-dnssec-trust-anchor-04] (14 pages) - DNSSEC Trust Anchor History Service [draft-ietf-dnsop-dnssec-trust-history-02] (11 pages) - DNSSEC Implementation in the CAIRN Testbed [draft-ietf-dnsop-dnsseccairn-00] (22 pages) - IP Addresses that should never appear in the public DNS [draft-ietf-dnsop-dontpublish-unreachable-03] (0 pages) - Distributing Authoritative Name Servers via Shared Unicast Addresses [draft-ietf-dnsop-hardie-shared-root-server-07] (0 pages) - Encouraging the use of DNS IN-ADDR Mapping [draft-ietf-dnsop-inaddr-required-07] (7 pages) - An Interim Scheme for Signing the Public DNS Root [draft-ietf-dnsop-interim-signed-root-01] (0 pages) - IPv6 Host Configuration of DNS Server Information Approaches [draft-ietf-dnsop-ipv6-dns-configuration-06] (33 pages) - Operational Considerations and Issues with IPv6 DNS [draft-ietf-dnsop-ipv6-dns-issues-12] (30 pages) - DNS IPv6 Transport Operational Guidelines [draft-ietf-dnsop-ipv6-transport-guidelines-02] (6 pages) - Requirements for Automated Key Rollover in DNSsec [draft-ietf-dnsop-key-rollover-requirements-02] (8 pages) - Handling of DNS Zone Signing Keys [draft-ietf-dnsop-keyhand-04] (9 pages) - Common Misbehavior Against DNS Queries for IPv6 Addresses [draft-ietf-dnsop-misbehavior-against-aaaa-02] (8 pages) - Requirements for Management of Name Servers for the DNS [draft-ietf-dnsop-name-server-management-reqs-05] (18 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) - Parent's SIG over child's KEY [draft-ietf-dnsop-parent-sig-00] (0 pages) - Preventing Use of Recursive Nameservers in Reflector Attacks [draft-ietf-dnsop-reflectors-are-evil-06] (8 pages) - Initializing a DNS Resolver with Priming Queries [draft-ietf-dnsop-resolver-priming-02] (8 pages) - Rollover of statically configured resolver keys [draft-ietf-dnsop-resolver-rollover-00] (9 pages) - DNS Referral Response Size Issues [draft-ietf-dnsop-respsize-14] (14 pages) - Considerations for the use of DNS Reverse Mapping [draft-ietf-dnsop-reverse-mapping-considerations-06] (15 pages) - DNSSEC Operational Practices, Version 2 [draft-ietf-dnsop-rfc4641bis-11] (79 pages) - Domain Name System (DNS) Security Key Rollover [draft-ietf-dnsop-rollover-01] (11 pages) - Root Name Server Operational Requirements [draft-ietf-dnsop-root-opreq-04] (9 pages) - Requirements for a Mechanism Identifying a Name Server Instance [draft-ietf-dnsop-serverid-08] (13 pages) - Distributing Root Name Servers via Shared Unicast Addresses [draft-ietf-dnsop-shared-root-server-01] (4 pages) - IPv4-to-IPv6 migration and DNS name space fragmentation [draft-ietf-dnsop-v6-name-space-fragmentation-01] (0 pages) Requests for Comments: BCP0040: Root Name Server Operational Requirements (9 pages) * Replaces DRAFT-BUSH-DNSOP-ROOT-OPREQ * Obsoletes RFC2010 BCP0091: DNS IPv6 Transport Operational Guidelines (6 pages) BCP0123: Observed DNS Resolution Misbehavior (23 pages) BCP0140: Preventing Use of Recursive Nameservers in Reflector Attacks (8 pages) BCP0163: Locally Served DNS Zones (14 pages) RFC2870: Root Name Server Operational Requirements (9 pages) * Replaces DRAFT-BUSH-DNSOP-ROOT-OPREQ * Obsoletes RFC2010 RFC3258: Distributing Authoritative Name Servers via Shared Unicast Addresses (0 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) * Replaces DRAFT-DURAND-NGTRANS-DNS-ISSUES 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 (18 pages) * Replaces DRAFT-HARDAKER-DNSOPS-NAME-SERVER-MANAGEMENT-REQS RFC6303: Locally Served DNS Zones (14 pages) RFC6304: AS112 Nameserver Operations (23 pages) RFC6305: I'm Being Attacked by PRISONER.IANA.ORG! (16 pages) Energy Management (eman) ------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Bruce Nordman Nevil Brownlee Operations and Management Area Directors: Ronald Bonica Benoit Claise Operations and Management Area Advisor: Benoit Claise 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 (EMAN) Applicability Statement [draft-ietf-eman-applicability-statement-00] (31 pages) - Definition of Managed Objects for Battery Monitoring [draft-ietf-eman-battery-mib-05] (30 pages) - Energy Object Context MIB [draft-ietf-eman-energy-aware-mib-05] (43 pages) - Power and Energy Monitoring MIB [draft-ietf-eman-energy-monitoring-mib-02] (87 pages) - Energy Management Framework [draft-ietf-eman-framework-04] (62 pages) - Requirements for Energy Management [draft-ietf-eman-requirements-06] (30 pages) No Requests for Comments Global Routing Operations (grow) -------------------------------- Charter Last Modified: 2012-02-01 Current Status: Active Chairs: Peter Schoenmaker Christopher Morrow Operations and Management Area Directors: Ronald Bonica Benoit Claise Operations and Management Area Advisor: Ronald Bonica Tech Advisors: Vijay Gill Bill Fenner 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: - Bounding Longest Match Considered [draft-grow-bounded-longest-match-00] (8 pages) - Operation of Anycast Services [draft-ietf-grow-anycast-04] (31 pages) - Requirements for the Graceful Shutdown of BGP Sessions [draft-ietf-grow-bgp-graceful-shutdown-requirements-07] (19 pages) - Graceful BGP session shutdown [draft-ietf-grow-bgp-gshut-03] (12 pages) - BGP MULTI_EXIT_DISC (MED) Considerations [draft-ietf-grow-bgp-med-considerations-05] (17 pages) - Controlling the redistribution of BGP routes [draft-ietf-grow-bgp-redistribution-00] (16 pages) - BGP Wedgies [draft-ietf-grow-bgp-wedgies-03] (10 pages) - BGP Monitoring Protocol [draft-ietf-grow-bmp-06] (17 pages) - BGP Communities for Data Collection [draft-ietf-grow-collection-communities-08] (13 pages) - Distribution of diverse BGP paths. [draft-ietf-grow-diverse-bgp-path-dist-07] (23 pages) - Embedding Globally-Routable Internet Addresses Considered Harmful [draft-ietf-grow-embed-addr-05] (11 pages) - Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions [draft-ietf-grow-geomrt-07] (15 pages) - Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format [draft-ietf-grow-mrt-17] (37 pages) - Time to Remove Filters for Previously Unallocated IPv4 /8s [draft-ietf-grow-no-more-unallocated-slash8s-04] (6 pages) - Operational Requirements for Enhanced Error Handling Behaviour in BGP-4 [draft-ietf-grow-ops-reqs-for-bgp-error-handling-03] (27 pages) - Issues with Private IP Addressing in the Internet [draft-ietf-grow-private-ip-sp-cores-04] (14 pages) - Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan [draft-ietf-grow-rfc1519bis-04] (29 pages) - Operational Concerns and Considerations for Routing Protocol Design -- Risk, Interference, and Fit (RIFT) [draft-ietf-grow-rift-01] (39 pages) - Routing System Stability [draft-ietf-grow-rss-00] (13 pages) - Simple Virtual Aggregation (S-VA) [draft-ietf-grow-simple-va-05] (10 pages) - Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services [draft-ietf-grow-unique-origin-as-01] (12 pages) - FIB Suppression with Virtual Aggregation [draft-ietf-grow-va-06] (24 pages) - Auto-Configuration in Virtual Aggregation [draft-ietf-grow-va-auto-05] (6 pages) - GRE and IP-in-IP Tunnels for Virtual Aggregation [draft-ietf-grow-va-gre-00] (7 pages) - MPLS Tunnels for Virtual Aggregation [draft-ietf-grow-va-mpls-00] (5 pages) - Proposal to use an inner MPLS label to identify the remote ASBR VA [draft-ietf-grow-va-mpls-innerlabel-00] (6 pages) - Performance of Virtual Aggregation [draft-ietf-grow-va-perf-00] (16 pages) Requests for Comments: BCP0105: Embedding Globally-Routable Internet Addresses Considered Harmful (11 pages) BCP0114: BGP Communities for Data Collection (13 pages) BCP0122: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan (29 pages) * Obsoletes RFC1519 BCP0126: Operation of Anycast Services (31 pages) BCP0169: Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services (12 pages) BCP0171: Time to Remove Filters for Previously Unallocated IPv4 /8s (6 pages) 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) * Obsoletes RFC1519 RFC4786: Operation of Anycast Services (31 pages) RFC6198: Requirements for the Graceful Shutdown of BGP Sessions (19 pages) RFC6382: Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services (12 pages) RFC6396: Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format (37 pages) RFC6397: Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions (15 pages) RFC6441: Time to Remove Filters for Previously Unallocated IPv4 /8s (6 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: Ronald Bonica Benoit Claise Operations and Management Area Advisor: Benoit Claise 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: - Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol [draft-ietf-ipfix-a9n-03] (47 pages) - IP Flow Anonymization Support [draft-ietf-ipfix-anon-06] (43 pages) - Architecture Model for IP Flow Information Export [draft-ietf-ipfix-arch-02] (28 pages) - Architecture for IP Flow Information Export [draft-ietf-ipfix-architecture-12] (32 pages) - IP Flow Information Export (IPFIX) Applicability [draft-ietf-ipfix-as-12] (32 pages) - Bidirectional Flow Export Using IP Flow Information Export (IPFIX) [draft-ietf-ipfix-biflow-05] (23 pages) - Configuration Data Model for IPFIX and PSAMP [draft-ietf-ipfix-configuration-model-10] (126 pages) - IPFIX Data Model Data Model for IP Flow Information Export [draft-ietf-ipfix-data-00] (25 pages) - IP Flow Information Export (IPFIX) Per Stream Control Transmission Protocol (SCTP) Stream [draft-ietf-ipfix-export-per-sctp-stream-08] (23 pages) - Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements [draft-ietf-ipfix-exporting-type-05] (20 pages) - Specification of the IP Flow Information Export (IPFIX) File Format [draft-ietf-ipfix-file-05] (66 pages) - Flow Selection Techniques [draft-ietf-ipfix-flow-selection-tech-11] (36 pages) - Guidelines for Authors and Reviewers of IPFIX Information Elements [draft-ietf-ipfix-ie-doctors-02] (33 pages) - IP Flow Information Export (IPFIX) Implementation Guidelines [draft-ietf-ipfix-implementation-guidelines-08] (36 pages) - Information Model for IP Flow Information Export [draft-ietf-ipfix-info-15] (170 pages) - Information Model for IP Flow Information eXport (IPFIX) [draft-ietf-ipfix-information-model-rfc5102bis-01] (30 pages) - Specification of the Protocol for IPFIX Mediation [draft-ietf-ipfix-mediation-protocol-00] (33 pages) - IP Flow Information Export (IPFIX) Mediation: Framework [draft-ietf-ipfix-mediators-framework-09] (34 pages) - IP Flow Information Export (IPFIX) Mediation: Problem Statement [draft-ietf-ipfix-mediators-problem-statement-09] (30 pages) - Definitions of Managed Objects for IP Flow Information Export [draft-ietf-ipfix-mib-10] (68 pages) - Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information [draft-ietf-ipfix-protocol-26] (65 pages) - Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information [draft-ietf-ipfix-protocol-rfc5101bis-01] (66 pages) - Definitions of Managed Objects for Packet Sampling [draft-ietf-ipfix-psamp-mib-04] (28 pages) - Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports [draft-ietf-ipfix-reducing-redundancy-04] (32 pages) - Reliability Extension for IPFIX [draft-ietf-ipfix-reliability-template-ext-00] (11 pages) - Requirements for IP Flow Information Export (IPFIX) [draft-ietf-ipfix-reqs-16] (32 pages) - Definitions of Managed Objects for IP Flow Information Export [draft-ietf-ipfix-rfc5815bis-03] (69 pages) - Export of Structured Data in IP Flow Information Export (IPFIX) [draft-ietf-ipfix-structured-data-06] (75 pages) - Guidelines for IP Flow Information Export (IPFIX) Testing [draft-ietf-ipfix-testing-05] (38 pages) - Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX) [draft-leinen-ipfix-eval-contrib-03] (28 pages) Requests for Comments: RFC3917: Requirements for IP Flow Information Export (IPFIX) (32 pages) RFC3955: Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX) (28 pages) RFC5101: Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information (65 pages) RFC5102: Information Model for IP Flow Information Export (170 pages) * Updates RFC6313 RFC5103: Bidirectional Flow Export Using IP Flow Information Export (IPFIX) (23 pages) * Replaces DRAFT-BOSCHI-IPFIX-BIFLOW * Replaces DRAFT-TRAMMELL-IPFIX-BIFLOW RFC5153: IP Flow Information Export (IPFIX) Implementation Guidelines (36 pages) * Replaces DRAFT-BOSCHI-IPFIX-IMPLEMENTATION-GUIDELINES RFC5470: Architecture for IP Flow Information Export (32 pages) * Updates RFC6183 RFC5471: Guidelines for IP Flow Information Export (IPFIX) Testing (38 pages) * Replaces DRAFT-SCHMOLL-IPFIX-TESTING RFC5472: IP Flow Information Export (IPFIX) Applicability (32 pages) RFC5473: Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports (32 pages) * Replaces DRAFT-BOSCHI-IPFIX-REDUCING-REDUNDANCY RFC5610: Exporting Type Information for IP Flow Information Export (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) * Replaces DRAFT-DIETZ-IPFIX-MIB RFC5982: IP Flow Information Export (IPFIX) Mediation: Problem Statement (30 pages) RFC6183: IP Flow Information Export (IPFIX) Mediation: Framework (34 pages) * Updates RFC5470 RFC6235: IP Flow Anonymization Support (43 pages) RFC6313: Export of Structured Data in IP Flow Information Export (IPFIX) (75 pages) * Updates RFC5102 RFC6526: IP Flow Information Export (IPFIX) Per Stream Control Transmission Protocol (SCTP) Stream (23 pages) IPv6 Operations (v6ops) ----------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Fred Baker Joel Jaeggli Operations and Management Area Directors: 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/ 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: - IPv6 Address Assignment to End Sites [draft-ietf-v6ops-3177bis-end-sites-01] (10 pages) - Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks [draft-ietf-v6ops-3gpp-analysis-11] (22 pages) - Transition Scenarios for 3GPP Networks [draft-ietf-v6ops-3gpp-cases-03] (11 pages) - IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS) [draft-ietf-v6ops-3gpp-eps-08] (35 pages) - 464XLAT: Combination of Stateful and Stateless Translation [draft-ietf-v6ops-464xlat-03] (15 pages) - Basic Requirements for IPv6 Customer Edge Routers [draft-ietf-v6ops-6204bis-08] (22 pages) - Advisory Guidelines for 6to4 Deployment [draft-ietf-v6ops-6to4-advisory-02] (21 pages) - Security Considerations for 6to4 [draft-ietf-v6ops-6to4-security-04] (41 pages) - Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status [draft-ietf-v6ops-6to4-to-historic-05] (7 pages) - IPv6 Deployment Scenarios in 802.16 Networks [draft-ietf-v6ops-802-16-deployment-scenarios-07] (17 pages) - IPv6 Unicast Address Assignment Considerations [draft-ietf-v6ops-addcon-10] (35 pages) - Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules [draft-ietf-v6ops-addr-select-ps-09] (17 pages) - Requirements for Address Selection Mechanisms [draft-ietf-v6ops-addr-select-req-07] (9 pages) - Application Aspects of IPv6 Transition [draft-ietf-v6ops-application-transition-03] (30 pages) - Goals for Registered Assisted Tunneling [draft-ietf-v6ops-assisted-tunneling-requirements-01] (14 pages) - ISP IPv6 Deployment Scenarios in Broadband Access Networks [draft-ietf-v6ops-bb-deployment-scenarios-05] (79 pages) - IPv6 Campus Transition Scenario Description and Analysis [draft-ietf-v6ops-campus-transition-01] (28 pages) - Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service [draft-ietf-v6ops-cpe-simple-security-16] (35 pages) - IPv6 Enterprise Network Analysis - IP Layer 3 Focus [draft-ietf-v6ops-ent-analysis-07] (42 pages) - IPv6 Enterprise Network Scenarios [draft-ietf-v6ops-ent-scenarios-05] (18 pages) - IPv6 Enterprise Networks Scenarios [draft-ietf-v6ops-entnet-scenarios-00] (17 pages) - Happy Eyeballs: Success with Dual-Stack Hosts [draft-ietf-v6ops-happy-eyeballs-07] (17 pages) - Best Current Practice for Filtering ICMPv6 Messages in Firewalls [draft-ietf-v6ops-icmpv6-filtering-bcp-01] (34 pages) - Recommendations for Filtering ICMPv6 Messages in Firewalls [draft-ietf-v6ops-icmpv6-filtering-recs-03] (36 pages) - IPv6 Guidance for Internet Content and Application Service Providers [draft-ietf-v6ops-icp-guidance-00] (19 pages) - An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition [draft-ietf-v6ops-incremental-cgn-03] (15 pages) - Using IPsec to Secure IPv6-in-IPv4 Tunnels [draft-ietf-v6ops-ipsec-tunnels-05] (22 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 Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-apps-04] (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 Internet Area Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-int-03] (56 pages) - Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-intro-06] (0 pages) - Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-ops-05] (0 pages) - Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-routing-03] (17 pages) - Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-sec-04] (0 pages) - Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-subip-04] (0 pages) - Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents [draft-ietf-v6ops-ipv4survey-trans-05] (0 pages) - Basic Requirements for IPv6 Customer Edge Routers [draft-ietf-v6ops-ipv6-cpe-router-09] (18 pages) - Advanced Requirements for IPv6 Customer Edge Routers [draft-ietf-v6ops-ipv6-cpe-router-bis-01] (15 pages) - A Discard Prefix for IPv6 [draft-ietf-v6ops-ipv6-discard-prefix-03] (6 pages) - IPv6 Multihoming without Network Address Translation [draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04] (23 pages) - Emerging Service Provider Scenarios for IPv6 Deployment [draft-ietf-v6ops-isp-scenarios-00] (20 pages) - Scenarios and Analysis for Introducing IPv6 into ISP Networks [draft-ietf-v6ops-isp-scenarios-analysis-03] (27 pages) - Stateless Source Address Mapping for ICMPv6 Packets [draft-ietf-v6ops-ivi-icmp-address-01] (8 pages) - Basic Transition Mechanisms for IPv6 Hosts and Routers [draft-ietf-v6ops-mech-v2-07] (29 pages) - IPv6 Multihoming without Network Address Translation [draft-ietf-v6ops-multihoming-without-nat66-00] (19 pages) - Local Network Protection for IPv6 [draft-ietf-v6ops-nap-06] (46 pages) - IPv4/IPv6 Coexistence and Transition: Requirements for solutions [draft-ietf-v6ops-nat64-pb-statement-req-00] (17 pages) - Reasons to Move NAT-PT to Experimental [draft-ietf-v6ops-natpt-to-exprmntl-03] (25 pages) - Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status [draft-ietf-v6ops-natpt-to-historic-00] (25 pages) - IPv6 Neighbor Discovery On-Link Assumption Considered Harmful [draft-ietf-v6ops-onlinkassumption-04] (11 pages) - IPv6 Router Advertisement Guard [draft-ietf-v6ops-ra-guard-08] (11 pages) - Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) [draft-ietf-v6ops-ra-guard-implementation-03] (18 pages) - Procedures for Renumbering an IPv6 Network without a Flag Day [draft-ietf-v6ops-renumbering-procedure-05] (25 pages) - Special-Use IPv6 Addresses [draft-ietf-v6ops-rfc3330-for-ipv6-04] (8 pages) - Rogue IPv6 Router Advertisement Problem Statement [draft-ietf-v6ops-rogue-ra-02] (16 pages) - IPv6 Routing Policies Guidelines [draft-ietf-v6ops-routing-guidelines-01] (8 pages) - IPv6 Implications for Network Scanning [draft-ietf-v6ops-scanning-implications-04] (13 pages) - IPv6 Transition/Co-existence Security Considerations [draft-ietf-v6ops-security-overview-06] (40 pages) - Teredo Security Concerns [draft-ietf-v6ops-teredo-security-concerns-02] (20 pages) - Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations [draft-ietf-v6ops-tunnel-loops-07] (20 pages) - Security Concerns with IP Tunneling [draft-ietf-v6ops-tunnel-security-concerns-04] (19 pages) - Unmanaged Networks IPv6 Transition Scenarios [draft-ietf-v6ops-unman-scenarios-03] (19 pages) - Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks [draft-ietf-v6ops-unmaneval-03] (18 pages) - Framework for IP Version Transition Scenarios [draft-ietf-v6ops-v4v6tran-framework-02] (7 pages) - Considerations for Transitioning Content to IPv6 [draft-ietf-v6ops-v6-aaaa-whitelisting-implications-11] (31 pages) - Mobile Networks Considerations for IPv6 Deployment [draft-ietf-v6ops-v6-in-mobile-networks-05] (19 pages) - IPv6 Deployment in Internet Exchange Points (IXPs) [draft-ietf-v6ops-v6inixp-09] (11 pages) - Operational Neighbor Discovery Problems [draft-ietf-v6ops-v6nd-problems-05] (13 pages) - Issues with Dual Stack IPv6 on by Default [draft-ietf-v6ops-v6onbydefault-03] (14 pages) - Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks [draft-ietf-v6ops-vlan-usage-01] (13 pages) - Wireline Incremental IPv6 [draft-ietf-v6ops-wireline-incremental-ipv6-02] (27 pages) Requests for Comments: BCP0157: IPv6 Address Assignment to End Sites (10 pages) * Replaces DRAFT-NARTEN-IPV6-3177BIS-48BOUNDARY * Obsoletes RFC3177 RFC3574: Transition Scenarios for 3GPP Networks (11 pages) RFC3750: Unmanaged Networks IPv6 Transition Scenarios (19 pages) RFC3789: Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents (0 pages) RFC3790: Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards Track and Experimental Documents (56 pages) RFC3791: Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Track and Experimental Documents (17 pages) RFC3792: Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Track and Experimental Documents (0 pages) RFC3793: Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards Track and Experimental Documents (0 pages) RFC3794: Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents (0 pages) RFC3795: Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Track and Experimental Documents (55 pages) RFC3796: Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards Track and Experimental Documents (0 pages) RFC3904: Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks (18 pages) RFC3964: Security Considerations for 6to4 (41 pages) RFC4029: Scenarios and Analysis for Introducing IPv6 into ISP Networks (27 pages) RFC4038: Application Aspects of IPv6 Transition (30 pages) RFC4057: IPv6 Enterprise Network Scenarios (18 pages) RFC4192: Procedures for Renumbering an IPv6 Network without a Flag Day (25 pages) * Updates RFC2072 RFC4213: Basic Transition Mechanisms for IPv6 Hosts and Routers (29 pages) * Obsoletes RFC2893 RFC4215: Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks (22 pages) RFC4554: Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks (13 pages) RFC4779: ISP IPv6 Deployment Scenarios in Broadband Access Networks (79 pages) * Replaces DRAFT-ASADULLAH-V6OPS-BB-DEPLOYMENT-SCENARIOS RFC4852: IPv6 Enterprise Network Analysis - IP Layer 3 Focus (42 pages) RFC4864: Local Network Protection for IPv6 (46 pages) RFC4890: Recommendations for Filtering ICMPv6 Messages in Firewalls (36 pages) * Replaces DRAFT-IETF-V6OPS-ICMPV6-FILTERING-BCP RFC4891: Using IPsec to Secure IPv6-in-IPv4 Tunnels (22 pages) * Replaces DRAFT-TSCHOFENIG-V6OPS-SECURE-TUNNELS RFC4942: IPv6 Transition/Co-existence Security Considerations (40 pages) * Replaces DRAFT-SAVOLA-V6OPS-SECURITY-OVERVIEW RFC4943: IPv6 Neighbor Discovery On-Link Assumption Considered Harmful (11 pages) RFC4966: Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status (25 pages) * Replaces DRAFT-IETF-V6OPS-NATPT-TO-EXPRMNTL * Obsoletes RFC2766 RFC5156: Special-Use IPv6 Addresses (8 pages) RFC5157: IPv6 Implications for Network Scanning (13 pages) RFC5181: IPv6 Deployment Scenarios in 802.16 Networks (17 pages) * Replaces DRAFT-SHIN-V6OPS-802-16-DEPLOYMENT-SCENARIOS RFC5220: Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules (17 pages) * Replaces DRAFT-ARIFUMI-V6OPS-ADDR-SELECT-PS RFC5221: Requirements for Address Selection Mechanisms (9 pages) RFC5375: IPv6 Unicast Address Assignment Considerations (35 pages) * Replaces DRAFT-VANDEVELDE-V6OPS-ADDCON RFC5963: IPv6 Deployment in Internet Exchange Points (IXPs) (11 pages) RFC6036: Emerging Service Provider Scenarios for IPv6 Deployment (20 pages) * Replaces DRAFT-CARPENTER-V6OPS-ISP-SCENARIOS RFC6092: Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service (35 pages) RFC6104: Rogue IPv6 Router Advertisement Problem Statement (16 pages) * Replaces DRAFT-CHOWN-V6OPS-ROGUE-RA RFC6105: IPv6 Router Advertisement Guard (11 pages) RFC6169: Security Concerns with IP Tunneling (19 pages) * Replaces DRAFT-IETF-V6OPS-TEREDO-SECURITY-CONCERNS RFC6177: IPv6 Address Assignment to End Sites (10 pages) * Replaces DRAFT-NARTEN-IPV6-3177BIS-48BOUNDARY * Obsoletes RFC3177 RFC6204: Basic Requirements for IPv6 Customer Edge Routers (18 pages) * Replaces DRAFT-WBEEBEE-IPV6-CPE-ROUTER RFC6264: An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition (15 pages) * Replaces DRAFT-JIANG-V6OPS-INCREMENTAL-CGN RFC6312: Mobile Networks Considerations for IPv6 Deployment (19 pages) * Obsoletes RFC6312 * Obsoletes RFC6342 RFC6324: Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations (20 pages) * Replaces DRAFT-NAKIBLY-V6OPS-TUNNEL-LOOPS RFC6342: Mobile Networks Considerations for IPv6 Deployment (19 pages) * Obsoletes RFC6312 RFC6343: Advisory Guidelines for 6to4 Deployment (21 pages) * Replaces DRAFT-CARPENTER-V6OPS-6TO4-TEREDO-ADVISORY RFC6459: IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS) (35 pages) * Replaces DRAFT-KORHONEN-V6OPS-3GPP-EPS RFC6555: Happy Eyeballs: Success with Dual-Stack Hosts (17 pages) * Replaces DRAFT-WING-V6OPS-HAPPY-EYEBALLS-IPV6 RFC6583: Operational Neighbor Discovery Problems (13 pages) * Replaces DRAFT-GASHINSKY-V6OPS-V6ND-PROBLEMS RFC6589: Considerations for Transitioning Content to IPv6 (31 pages) * Replaces DRAFT-LIVINGOOD-DNS-WHITELISTING-IMPLICATIONS IPv6 Site Renumbering (6renum) ------------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Tim Chown Lee Howard Operations and Management Area Directors: 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: - IPv6 Enterprise Network Renumbering Scenarios and Guidelines [draft-ietf-6renum-enterprise-00] (16 pages) - IPv6 Site Renumbering Gap Analysis [draft-ietf-6renum-gap-analysis-01] (19 pages) No Requests for Comments MBONE Deployment (mboned) ------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Greg Shepherd Leonard Giuliano Operations and Management Area Directors: 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: - IPv4-Embedded IPv6 Multicast Address Format [draft-ietf-mboned-64-multicast-address-format-01] (12 pages) - Overview of the Internet Multicast Addressing Architecture [draft-ietf-mboned-addrarch-07] (16 pages) - Lightweight Multicast Address Discovery Problem Space [draft-ietf-mboned-addrdisc-problems-02] (11 pages) - Administratively Scoped IP Multicast [draft-ietf-mboned-admin-ip-space-05] (8 pages) - Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP) [draft-ietf-mboned-anycast-rp-08] (9 pages) - Automatic Multicast Tunneling [draft-ietf-mboned-auto-multicast-13] (84 pages) - Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address [draft-ietf-mboned-embeddedrp-07] (18 pages) - GLOP Addressing in 233/8 [draft-ietf-mboned-glop-addressing-02] (5 pages) - Extended Assignments in 233/8 [draft-ietf-mboned-glop-extensions-02] (5 pages) - GLOP Addressing in 233/8 [draft-ietf-mboned-glop-update-01] (6 pages) - IANA Guidelines for IPv4 Multicast Address Assignments [draft-ietf-mboned-iana-ipv4-mcast-guidelines-04] (9 pages) - Internet Multicast Gap Analysis from the MBONED Working Group for the IESG [draft-ietf-mboned-iesg-gap-analysis-00] (14 pages) - Some Issues for an Inter-domain Multicast Routing Protocol [draft-ietf-mboned-imrp-some-issues-03] (12 pages) - Introduction to IP Multicast Routing [draft-ietf-mboned-intro-multicast-03] (60 pages) - IP Multicast MIB [draft-ietf-mboned-ip-mcast-mib-07] (61 pages) - Requirements for IP multicast performance monitoring [draft-ietf-mboned-ip-multicast-pm-requirement-01] (15 pages) - IPv4 Multicast Best Current Practice [draft-ietf-mboned-ipv4-mcast-bcp-01] (12 pages) - IPv4 Multicast Unusable Group And Source Addresses [draft-ietf-mboned-ipv4-mcast-unusable-01] (7 pages) - Unicast-Prefix-Based IPv4 Multicast Addresses [draft-ietf-mboned-ipv4-uni-based-mcast-06] (6 pages) - IPv6 Multicast Deployment Issues [draft-ietf-mboned-ipv6-multicast-issues-02] (12 pages) - Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols [draft-ietf-mboned-lightweight-igmpv3-mldv2-06] (23 pages) - Guidelines for Rate Limits on the MBONE [draft-ietf-mboned-limit-rate-guide-00] (3 pages) - Using MSDP to create Logical RPs [draft-ietf-mboned-logical-rp-00] (7 pages) - Requirements for Multicast AAA coordinated between Content Provider(s) and Network Service Provider(s) [draft-ietf-mboned-maccnt-req-10] (18 pages) - Multicast Addresses for Documentation [draft-ietf-mboned-mcaddrdoc-03] (13 pages) - IP Multicast Applications: Challenges and Solutions [draft-ietf-mboned-mcast-apps-02] (28 pages) - Moving MCAST.NET into the ARPA infrastructure top level domain [draft-ietf-mboned-mcast-arpa-03] (9 pages) - Connecting Multicast Domains [draft-ietf-mboned-mcast-connect-00] (14 pages) - IP Multicast and Firewalls [draft-ietf-mboned-mcast-firewall-02] (7 pages) - Multicast Debugging Handbook [draft-ietf-mboned-mdh-05] (34 pages) - Multicast-Friendly Internet Exchange (MIX) [draft-ietf-mboned-mix-01] (10 pages) - Multicast Reachability Monitor (MRM) [draft-ietf-mboned-mrm-01] (22 pages) - Justification for and use of the Multicast Routing Monitor (MRM) Protocol [draft-ietf-mboned-mrm-use-00] (9 pages) - Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements [draft-ietf-mboned-mroutesec-04] (21 pages) - Multicast Source Discovery Protocol (MSDP) Deployment Scenarios [draft-ietf-mboned-msdp-deploy-06] (20 pages) - Multicast Source Discovery Protocol (MSDP) MIB [draft-ietf-mboned-msdp-mib-01] (34 pages) - Mtrace Version 2: Traceroute Facility for IP Multicast [draft-ietf-mboned-mtrace-v2-08] (41 pages) - AAA and Admission Control Framework for Multicasting [draft-ietf-mboned-multiaaa-framework-12] (22 pages) - Multicast-Scope Zone Announcement Protocol (MZAP) [draft-ietf-mboned-mzap-06] (29 pages) - Administratively Scoped IP Multicast [draft-ietf-mboned-oops-disregard-00] (6 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 pruning a necessity [draft-ietf-mboned-pruning-02] (3 pages) - Issues Related to Receiver Access Control in the Current Multicast Protocols [draft-ietf-mboned-rac-issues-03] (24 pages) - IANA Guidelines for IPv4 Multicast Address Assignments [draft-ietf-mboned-rfc3171-update-00] (9 pages) - IANA Guidelines for IPv4 Multicast Address Assignments [draft-ietf-mboned-rfc3171bis-08] (11 pages) - Overview of the Internet Multicast Routing Architecture [draft-ietf-mboned-routingarch-12] (24 pages) - Scoped Address Discovery Protocol (SADP) [draft-ietf-mboned-sadp-02] (14 pages) - Requirements for IP Multicast Session Announcement [draft-ietf-mboned-session-announcement-req-03] (14 pages) - The Use of SNTP as a Multicast Heartbeat [draft-ietf-mboned-sntp-heart-00] (8 pages) - Source-Specific Protocol Independent Multicast in 232/8 [draft-ietf-mboned-ssm232-09] (9 pages) - Multicast Ping Protocol [draft-ietf-mboned-ssmping-09] (24 pages) - Static Allocations in 233/8 [draft-ietf-mboned-static-allocation-00] (5 pages) - IPv4-IPv6 Multicast: Problem Statement and Use Cases [draft-ietf-mboned-v4v6-mcast-ps-00] (25 pages) Requests for Comments: BCP0023: Administratively Scoped IP Multicast (8 pages) BCP0051: IANA Guidelines for IPv4 Multicast Address Assignments (11 pages) * Updates RFC2780 * Obsoletes RFC3138 * Obsoletes RFC3171 BCP0053: GLOP Addressing in 233/8 (6 pages) * Obsoletes RFC2770 BCP0120: Source-Specific Protocol Independent Multicast in 232/8 (9 pages) BCP0121: Multicast Source Discovery Protocol (MSDP) Deployment Scenarios (20 pages) RFC2365: Administratively Scoped IP Multicast (8 pages) RFC2588: IP Multicast and Firewalls (7 pages) RFC2770: GLOP Addressing in 233/8 (5 pages) * Obsoletes RFC3180 RFC2776: Multicast-Scope Zone Announcement Protocol (MZAP) (29 pages) RFC3138: Extended Assignments in 233/8 (5 pages) * Obsoletes RFC5771 RFC3170: IP Multicast Applications: Challenges and Solutions (28 pages) RFC3171: IANA Guidelines for IPv4 Multicast Address Assignments (9 pages) * Obsoletes RFC5771 RFC3180: GLOP Addressing in 233/8 (6 pages) * Obsoletes RFC2770 RFC3446: Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP) (9 pages) RFC3956: Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address (18 pages) * Updates RFC3306 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) RFC4611: Multicast Source Discovery Protocol (MSDP) Deployment Scenarios (20 pages) RFC4624: Multicast Source Discovery Protocol (MSDP) MIB (34 pages) RFC5110: Overview of the Internet Multicast Routing Architecture (24 pages) * Replaces DRAFT-SAVOLA-MBONED-ROUTINGARCH RFC5132: IP Multicast MIB (61 pages) * Obsoletes RFC2932 RFC5771: IANA Guidelines for IPv4 Multicast Address Assignments (11 pages) * Updates RFC2780 * Obsoletes RFC3138 * Obsoletes RFC3171 RFC5790: Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols (23 pages) RFC6034: Unicast-Prefix-Based IPv4 Multicast Addresses (6 pages) RFC6308: Overview of the Internet Multicast Addressing Architecture (16 pages) * Obsoletes RFC2908 RFC6450: Multicast Ping Protocol (24 pages) NETCONF Data Modeling Language (netmod) --------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Juergen Schoenwaelder David Kessens Operations and Management Area Directors: Ronald Bonica Benoit Claise Operations and Management Area Advisor: Benoit Claise Mailing Lists: General Discussion: netmod@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netmod 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: - An Architecture for Network Management Using NETCONF and YANG [draft-ietf-netmod-arch-10] (34 pages) - Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content [draft-ietf-netmod-dsdl-map-10] (112 pages) - IANA Interface Type and Address Family YANG Modules [draft-ietf-netmod-iana-if-type-02] (48 pages) - A YANG Data Model for Interface Configuration [draft-ietf-netmod-interfaces-cfg-04] (24 pages) - A YANG Data Model for IP Configuration [draft-ietf-netmod-ip-cfg-03] (16 pages) - A YANG Data Model for Routing Configuration [draft-ietf-netmod-routing-cfg-02] (64 pages) - Translation of SMIv2 MIB Modules to YANG Modules [draft-ietf-netmod-smi-yang-05] (44 pages) - YANG Data Model for System Management [draft-ietf-netmod-system-mgmt-00] (40 pages) - YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) [draft-ietf-netmod-yang-13] (185 pages) - Common YANG Data Types [draft-ietf-netmod-yang-types-09] (31 pages) - Guidelines for Authors and Reviewers of YANG Data Model Documents [draft-ietf-netmod-yang-usage-11] (36 pages) Requests for Comments: RFC6020: YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) (185 pages) RFC6021: Common YANG Data Types (31 pages) * Replaces DRAFT-SCHOENW-NETMOD-YANG-TYPES RFC6087: Guidelines for Authors and Reviewers of YANG Data Model Documents (36 pages) * Replaces DRAFT-BIERMAN-NETMOD-YANG-USAGE RFC6110: Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content (112 pages) RFC6244: An Architecture for Network Management Using NETCONF and YANG (34 pages) * Replaces DRAFT-SHAFER-NETMOD-ARCH Network Configuration (netconf) ------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Bert Wijnen Mehmet Ersue Operations and Management Area Directors: Ronald Bonica Benoit Claise Operations and Management Area Advisor: Benoit Claise Tech Advisor: Tim Polk Mailing Lists: General Discussion: netconf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netconf 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: - Network Configuration Protocol (NETCONF) [draft-ietf-netconf-4741bis-10] (121 pages) - Network Configuration Protocol (NETCONF) Access Control Model [draft-ietf-netconf-access-control-07] (54 pages) - Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP) [draft-ietf-netconf-beep-10] (15 pages) - YANG Module for NETCONF Monitoring [draft-ietf-netconf-monitoring-15] (39 pages) - NETCONF Event Notifications [draft-ietf-netconf-notification-14] (49 pages) - Partial Lock Remote Procedure Call (RPC) for NETCONF [draft-ietf-netconf-partial-lock-11] (29 pages) - NETCONF Configuration Protocol [draft-ietf-netconf-prot-12] (105 pages) - Using the NETCONF Protocol over Secure Shell (SSH) [draft-ietf-netconf-rfc4742bis-08] (13 pages) - Using NETCONF over the Simple Object Access Protocol (SOAP) [draft-ietf-netconf-soap-08] (22 pages) - Using the NETCONF Configuration Protocol over Secure SHell (SSH) [draft-ietf-netconf-ssh-06] (11 pages) - Network Configuration Protocol (NETCONF) Base Notifications [draft-ietf-netconf-system-notifications-07] (17 pages) - NETCONF over Transport Layer Security (TLS) [draft-ietf-netconf-tls-07] (9 pages) - With-defaults Capability for NETCONF [draft-ietf-netconf-with-defaults-14] (32 pages) Requests for Comments: RFC4741: NETCONF Configuration Protocol (105 pages) * Obsoletes RFC6241 RFC4742: Using the NETCONF Configuration Protocol over Secure SHell (SSH) (11 pages) * Obsoletes RFC6242 RFC4743: Using NETCONF over the Simple Object Access Protocol (SOAP) (22 pages) RFC4744: Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP) (15 pages) RFC5277: NETCONF Event Notifications (49 pages) RFC5539: NETCONF over Transport Layer Security (TLS) (9 pages) * Replaces DRAFT-BADRA-TLS-NETCONF RFC5717: Partial Lock Remote Procedure Call (RPC) for NETCONF (29 pages) * Replaces DRAFT-LENGYEL-NGO-PARTIAL-LOCK RFC6022: YANG Module for NETCONF Monitoring (39 pages) * Replaces DRAFT-SCOTT-NETCONF-MONITORING RFC6241: Network Configuration Protocol (NETCONF) (121 pages) * Obsoletes RFC4741 RFC6242: Using the NETCONF Protocol over Secure Shell (SSH) (13 pages) * Obsoletes RFC4742 RFC6243: With-defaults Capability for NETCONF (32 pages) RFC6470: Network Configuration Protocol (NETCONF) Base Notifications (17 pages) RFC6536: Network Configuration Protocol (NETCONF) Access Control Model (54 pages) Operational Security Capabilities for IP Network Infrastructure (opsec) ----------------------------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Warren Kumari Gunter Van de Velde KK Chittimaneni Operations and Management Area Directors: 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/ 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: - Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF) [draft-ietf-opsec-blackhole-urpf-04] (18 pages) - Operational Security Current Practices in Internet Service Provider Environments [draft-ietf-opsec-current-practices-07] (43 pages) - Security Best Practices Efforts and Documents [draft-ietf-opsec-efforts-18] (41 pages) - Filtering and Rate Limiting Capabilities for IP Network Infrastructure [draft-ietf-opsec-filter-caps-09] (30 pages) - Framework for Operational Security Capabilities for IP Network Infrastructure [draft-ietf-opsec-framework-05] (29 pages) - Recommendations for filtering ICMP messages [draft-ietf-opsec-icmp-filtering-03] (48 pages) - Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols [draft-ietf-opsec-igp-crypto-requirements-04] (19 pages) - Service Provider Infrastructure Security [draft-ietf-opsec-infrastructure-security-01] (17 pages) - Security Assessment of the Internet Protocol Version 4 [draft-ietf-opsec-ip-security-07] (78 pages) - Logging Capabilities for IP Network Infrastructure [draft-ietf-opsec-logging-caps-04] (35 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) - Protecting the Router Control Plane [draft-ietf-opsec-protect-control-plane-06] (24 pages) - Routing Control Plane Security Capabilities [draft-ietf-opsec-routing-capabilities-03] (20 pages) - Issues with Existing Cryptographic Protection Methods for Routing Protocols [draft-ietf-opsec-routing-protocols-crypto-issues-07] (20 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 (20 pages) RFC6094: Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols (19 pages) RFC6192: Protecting the Router Control Plane (24 pages) * Replaces DRAFT-DUGAL-OPSEC-PROTECT-CONTROL-PLANE RFC6274: Security Assessment of the Internet Protocol Version 4 (78 pages) Operations and Management Area Working Group (opsawg) ----------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Scott O. Bradner Chris Liljenstolpe Melinda Shore Operations and Management Area Directors: Ronald Bonica Benoit Claise Operations and Management Area Advisor: Ronald Bonica 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: - Problem Statement for the Automated Configuration of Large IP Networks [draft-ietf-opsawg-automated-network-configuration-03] (23 pages) - A Template for Internet Drafts Containing Data Models [draft-ietf-opsawg-data-model-doc-template-00] (24 pages) - CGN Deployment with BGP/MPLS IP VPNs [draft-ietf-opsawg-lsn-deployment-00] (18 pages) - An Overview of the IETF Network Management Standards [draft-ietf-opsawg-management-stds-07] (102 pages) - Textual Conventions for the Representation of Floating-Point Numbers [draft-ietf-opsawg-mib-floats-02] (8 pages) - Guidelines for the Use of the "OAM" Acronym in the IETF [draft-ietf-opsawg-mpls-tp-oam-def-10] (9 pages) - An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms [draft-ietf-opsawg-oam-overview-06] (28 pages) - Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions [draft-ietf-opsawg-operations-and-management-09] (36 pages) - Expressing SNMP SMI Datatypes in XML Schema Definition Language [draft-ietf-opsawg-smi-datatypes-in-xsd-06] (19 pages) - Simple Network Management Protocol (SNMP) Context EngineID Discovery [draft-ietf-opsawg-snmp-engineid-discovery-03] (10 pages) - Survey of IETF Network Management Standards [draft-ietf-opsawg-survey-management-00] (21 pages) - Alarms in Syslog [draft-ietf-opsawg-syslog-alarm-02] (13 pages) - Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications [draft-ietf-opsawg-syslog-msg-mib-06] (23 pages) - Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages [draft-ietf-opsawg-syslog-snmp-05] (15 pages) Requests for Comments: BCP0161: Guidelines for the Use of the "OAM" Acronym in the IETF (9 pages) * Replaces DRAFT-ANDERSSON-MPLS-TP-OAM-DEF RFC5343: Simple Network Management Protocol (SNMP) Context EngineID Discovery (10 pages) * Updates RFC3411 RFC5674: Alarms in Syslog (13 pages) RFC5675: Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages (15 pages) RFC5676: Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications (23 pages) RFC5706: Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions (36 pages) RFC5935: Expressing SNMP SMI Datatypes in XML Schema Definition Language (19 pages) RFC6291: Guidelines for the Use of the "OAM" Acronym in the IETF (9 pages) * Replaces DRAFT-ANDERSSON-MPLS-TP-OAM-DEF RFC6340: Textual Conventions for the Representation of Floating-Point Numbers (8 pages) * Replaces DRAFT-PRESUHN-FLOATS RADIUS EXTensions (radext) -------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Jouni Korhonen Mauricio Sanchez Operations and Management Area Directors: Ronald Bonica Benoit Claise Operations and Management Area Advisor: Benoit Claise 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: - Chargeable User Identity [draft-ietf-radext-chargeable-user-id-06] (11 pages) - Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS) [draft-ietf-radext-crypto-agility-requirements-07] (12 pages) - RADIUS Delegated-IPv6-Prefix Attribute [draft-ietf-radext-delegated-prefix-05] (9 pages) - RADIUS Design Guidelines [draft-ietf-radext-design-19] (38 pages) - RADIUS Extension for Digest Authentication [draft-ietf-radext-digest-auth-09] (37 pages) - DTLS as a Transport Layer for RADIUS [draft-ietf-radext-dtls-01] (18 pages) - NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS [draft-ietf-radext-dynamic-discovery-03] (9 pages) - RADIUS Dynamic Authorization Client MIB [draft-ietf-radext-dynauth-client-mib-06] (30 pages) - RADIUS Dynamic Authorization Server MIB [draft-ietf-radext-dynauth-server-mib-06] (28 pages) - Extended Remote Authentication Dial In User Service (RADIUS) Attributes [draft-ietf-radext-extended-attributes-09] (13 pages) - RADIUS Filter Rule Attribute [draft-ietf-radext-filter-08] (10 pages) - RADIUS Attributes for Filtering and Redirection [draft-ietf-radext-filter-rules-03] (30 pages) - Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes [draft-ietf-radext-fixes-08] (28 pages) - VLAN, Priority, and Filtering Attributes [draft-ietf-radext-ieee802-01] (32 pages) - RADIUS Attributes for IEEE 802 Networks [draft-ietf-radext-ieee802ext-01] (22 pages) - RADIUS attributes for IPv6 Access Networks [draft-ietf-radext-ipv6-access-07] (14 pages) - Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management [draft-ietf-radext-management-authorization-07] (25 pages) - Remote Authentication Dial In User Service (RADIUS) Protocol Extensions [draft-ietf-radext-radius-extensions-05] (64 pages) - Transport Layer Security (TLS) encryption for RADIUS [draft-ietf-radext-radsec-12] (23 pages) - The Network Access Identifier [draft-ietf-radext-rfc2486bis-06] (17 pages) - RADIUS Authentication Client MIB for IPv6 [draft-ietf-radext-rfc2618bis-04] (24 pages) - RADIUS Authentication Server MIB for IPv6 [draft-ietf-radext-rfc2619bis-04] (26 pages) - RADIUS Accounting Client MIB for IPv6 [draft-ietf-radext-rfc2620bis-04] (23 pages) - RADIUS Accounting Server MIB for IPv6 [draft-ietf-radext-rfc2621bis-04] (25 pages) - Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) [draft-ietf-radext-rfc3576bis-13] (29 pages) - RADIUS Extension for Digest Authentication [draft-ietf-radext-rfc4590bis-02] (34 pages) - Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol [draft-ietf-radext-status-server-09] (25 pages) - RADIUS Over TCP [draft-ietf-radext-tcp-transport-09] (18 pages) - New Tunnel-Type Values [draft-ietf-radext-tunnel-type-00] (6 pages) - RADIUS Attributes for Virtual LAN and Priority Support [draft-ietf-radext-vlan-06] (15 pages) Requests for Comments: BCP0158: RADIUS Design Guidelines (38 pages) RFC4282: The Network Access Identifier (17 pages) * Obsoletes RFC2486 RFC4372: Chargeable User Identity (11 pages) RFC4590: RADIUS Extension for Digest Authentication (37 pages) * Obsoletes RFC5090 RFC4668: RADIUS Authentication Client MIB for IPv6 (24 pages) * Replaces DRAFT-NELSON-RFC2618BIS * Obsoletes RFC2618 RFC4669: RADIUS Authentication Server MIB for IPv6 (26 pages) * Replaces DRAFT-NELSON-RFC2619BIS * Obsoletes RFC2619 RFC4670: RADIUS Accounting Client MIB for IPv6 (23 pages) * Replaces DRAFT-NELSON-RFC2620BIS * Obsoletes RFC2620 RFC4671: RADIUS Accounting Server MIB for IPv6 (25 pages) * Replaces DRAFT-NELSON-RFC2621BIS * Obsoletes RFC2621 RFC4672: RADIUS Dynamic Authorization Client MIB (30 pages) RFC4673: RADIUS Dynamic Authorization Server MIB (28 pages) RFC4675: RADIUS Attributes for Virtual LAN and Priority Support (15 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) * Replaces DRAFT-ABOBA-RADEXT-FIXES * Updates RFC2865 * Updates RFC2866 * Updates RFC2869 * Updates RFC3579 RFC5090: RADIUS Extension for Digest Authentication (34 pages) * Obsoletes RFC4590 RFC5176: Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) (29 pages) * Replaces DRAFT-CHIBA-RADEXT-RFC3576BIS * Obsoletes RFC3576 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 (25 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: Roni Even Magnus Westerlund 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/ 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 Done - Submit Guidelines for the use of Variable Bit Rate Audio with Secure RTP as Informational (or possibly BCP) Done - Submit Explicit Congestion Notification (ECN) for RTP over UDP for Proposed Standard Done - Submit RTCP indication for retransmission suppression as Proposed Standard Apr 2012 - Submit Monitoring Architecture for RTP for Informational Apr 2012 - Submit Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP) for Proposed Standard Oct 2012 - Submit in band keying mechanism for SRTP draft for Proposed Standard Oct 2012 - Submit an Overview of RTP Security Solutions as Informational Nov 2012 - Submit Specification for Inter-destination Media Playout Synchronization in RTP to IESG for publication as Proposed Standard Nov 2012 - Submit RTP Clock Source Signaling as Proposed Standard Dec 2012 - Submit Real-Time Transport Control Protocol (RTCP) in Overlay Multicast for Proposed Standard Dec 2012 - Submit SRTP Cryptographic Transform(s) on the ARIA algorithm and corresponding key-management profiles for Security Descriptions, MIKEY and DTLS-SRTP for publication as proposed standard Internet-Drafts: - Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows [draft-ietf-avt-app-rtp-keepalive-10] (11 pages) - Explicit Congestion Notification (ECN) for RTP over UDP [draft-ietf-avt-ecn-for-rtp-03] (44 pages) - Forward-Shifted RTP Redundancy Payload Support [draft-ietf-avt-forward-shifted-red-08] (13 pages) - Port Mapping Between Unicast and Multicast RTP Sessions [draft-ietf-avt-ports-for-ucast-mcast-rtp-11] (35 pages) - AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) [draft-ietf-avt-srtp-aes-gcm-02] (19 pages) - Encrypted Key Transport for Secure RTP [draft-ietf-avt-srtp-ekt-03] (53 pages) - Why RTP Does Not Mandate a Single Security Mechanism [draft-ietf-avt-srtp-not-mandatory-08] (11 pages) - Explicit Congestion Notification (ECN) for RTP over UDP [draft-ietf-avtcore-ecn-for-rtp-08] (57 pages) - RTCP Extension for Third-party Loss Report [draft-ietf-avtcore-feedback-supression-rtp-17] (19 pages) - RTCP for inter-destination media synchronization [draft-ietf-avtcore-idms-03] (21 pages) - Monitoring Architecture for RTP [draft-ietf-avtcore-monarch-13] (29 pages) - Port Mapping between Unicast and Multicast RTP Sessions [draft-ietf-avtcore-ports-for-ucast-mcast-rtp-02] (37 pages) - Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP) [draft-ietf-avtcore-srtp-encrypted-header-ext-01] (13 pages) - Guidelines for the Use of Variable Bit Rate Audio with Secure RTP [draft-ietf-avtcore-srtp-vbr-audio-04] (7 pages) - RTP Congestion Control: Circuit Breakers for Unicast Sessions [draft-perkins-avtcore-rtp-circuit-breakers-00] (14 pages) Requests for Comments: RFC6263: Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows (11 pages) * Replaces DRAFT-MARJOU-BEHAVE-APP-RTP-KEEPALIVE RFC6284: Port Mapping between Unicast and Multicast RTP Sessions (37 pages) * Replaces DRAFT-IETF-AVT-PORTS-FOR-UCAST-MCAST-RTP RFC6354: Forward-Shifted RTP Redundancy Payload Support (13 pages) * Replaces DRAFT-XIE-AVT-FORWARD-SHIFTED-RED * Updates RFC2198 * Updates RFC4102 RFC6562: Guidelines for the Use of Variable Bit Rate Audio with Secure RTP (7 pages) * Replaces DRAFT-PERKINS-AVT-SRTP-VBR-AUDIO Audio/Video Transport Extensions (avtext) ----------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Keith Drage Magnus Westerlund 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/ 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 Done - 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 Client-to-Mixer Audio Level Indication [draft-ietf-avtext-client-to-mixer-audio-level-06] (11 pages) - A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication [draft-ietf-avtext-mixer-to-client-audio-level-06] (17 pages) - Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) [draft-ietf-avtext-multicast-acq-rtcp-xr-06] (21 pages) - Support for Multiple Clock Rates in an RTP Session [draft-ietf-avtext-multiple-clock-rates-05] (11 pages) - Considerations for Deploying the Rapid Acquisition of Multicast RTP Sessions (RAMS) Method [draft-ietf-avtext-rams-scenarios-05] (12 pages) - Content Splicing for RTP Sessions [draft-ietf-avtext-splicing-for-rtp-07] (16 pages) Requests for Comments: RFC6332: Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) (21 pages) * Replaces DRAFT-IETF-AVT-MULTICAST-ACQ-RTCP-XR RFC6464: A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication (11 pages) * Replaces DRAFT-LENNOX-AVT-RTP-AUDIO-LEVEL-EXTHDR RFC6465: A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication (17 pages) * Replaces DRAFT-IVOV-AVT-SLIC Audio/Video Transport Payloads (payload) ---------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Ali Begen Roni Even 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/ 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 Done - Submit RTP Payload Format for MPEG-4 Audio/Visual Streams for Proposed Standard Done - Submit RTP Payload Format for DV (IEC 61834) Video for Proposed Standard Apr 2011 - Submit RTP Payload Format for MPEG2-TS preamble for Proposed Standard Apr 2011 - Submit RTP Payload Format for the iSAC codec for Proposed Standard Jun 2012 - Submit RTP profile for the carriage of SMPTE 336M data for Proposed Standard Jun 2012 - Submit RTP Payload Format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) for Proposed Standard Aug 2012 - Submit RTP Payload Format for Bluetooth's SBC audio codec for Proposed Standard Sep 2012 - Submit How to Write an RTP Payload Format for Informational Sep 2012 - Submit RTP Payload Format for VP8 Video for Proposed Standard Sep 2012 - Submit RTP Payload Format for EVBR/G.718 for Proposed Standard Dec 2012 - Submit RTP Payload Format for Opus Speech and Audio Codec as proposed standard Mar 2013 - Submit RTP Payload Format for MVC Video for Proposed Standard Internet-Drafts: - RTP Payload Format for MPEG-4 Audio/Visual Streams [draft-ietf-avt-rfc3016bis-02] (32 pages) - RTP Payload Format for DV (IEC 61834) Video [draft-ietf-avt-rfc3189bis-04] (19 pages) - RTP Payload Format for MIDI [draft-ietf-avt-rfc4695-bis-10] (171 pages) - RTP payload format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) [draft-ietf-avt-rtp-evrc-nw-06] (32 pages) - RTP Payload Format for G.718 Speech/Audio [draft-ietf-avt-rtp-g718-05] (27 pages) - RTP Payload Format for IP-MR Speech Codec [draft-ietf-avt-rtp-ipmr-15] (20 pages) - RTP Payload Format for the iSAC Codec [draft-ietf-avt-rtp-isac-01] (10 pages) - RTP Payload Format for SMPTE 336M Encoded Data [draft-ietf-avt-rtp-klv-02] (12 pages) - RTP Payload Format for MVC Video [draft-ietf-avt-rtp-mvc-01] (25 pages) - RTP Payload Format for Bluetooth's SBC audio codec [draft-ietf-avt-rtp-sbc-01] (23 pages) - RTP Payload Format for Scalable Video Coding [draft-ietf-avt-rtp-svc-27] (105 pages) - RTP Payload Format for MPEG-4 Audio/Visual Streams [draft-ietf-payload-rfc3016bis-03] (33 pages) - RTP Payload Format for DV (IEC 61834) Video [draft-ietf-payload-rfc3189bis-03] (20 pages) - RTP Payload Format for MIDI [draft-ietf-payload-rfc4695-bis-02] (181 pages) - RTP Payload Format for G.718 Speech/Audio [draft-ietf-payload-rtp-g718-02] (27 pages) - How to Write an RTP Payload Format [draft-ietf-payload-rtp-howto-01] (57 pages) - RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data [draft-ietf-payload-rtp-klv-04] (13 pages) - RTP Payload Format for MVC Video [draft-ietf-payload-rtp-mvc-01] (27 pages) - RTP Payload Format for Bluetooth's SBC Audio Codec [draft-ietf-payload-rtp-sbc-02] (24 pages) - RTP Payload Format for VP8 Video [draft-ietf-payload-vp8-04] (28 pages) Requests for Comments: RFC6190: RTP Payload Format for Scalable Video Coding (105 pages) * Replaces DRAFT-WENGER-AVT-RTP-SVC * Replaces DRAFT-HANNUKSELA-AVT-RTP-SVC RFC6262: RTP Payload Format for IP-MR Speech Codec (20 pages) RFC6295: RTP Payload Format for MIDI (181 pages) * Replaces DRAFT-IETF-AVT-RFC4695-BIS * Obsoletes RFC4695 RFC6416: RTP Payload Format for MPEG-4 Audio/Visual Streams (33 pages) * Replaces DRAFT-IETF-AVT-RFC3016BIS * Obsoletes RFC3016 RFC6469: RTP Payload Format for DV (IEC 61834) Video (20 pages) * Obsoletes RFC3189 RFC6597: RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data (13 pages) * Replaces DRAFT-IETF-AVT-RTP-KLV Authority-to-Citizen Alert (atoca) ---------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Scott O. 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: - Session Initiation Protocol (SIP) Event Package for the Common Alerting Protocol (CAP) [draft-ietf-atoca-cap-00] (22 pages) - Requirements, Terminology and Framework for Exigent Communications [draft-ietf-atoca-requirements-03] (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 BLISS working group is rechartered to adjust its scope to reflect changes in working group interest and RAI processes since its original chartering. BLISS was chartered prior to the creation of DISPATCH. The charter called for the WG to document how to realize four initial building blocks in an interoperable way with existing standards, and to describe the use of those building blocks to implement specific call features. Any extensions to the protocols beyond the creation of event packages or the addition of SIP URI parameters was set out of scope for this working group. Working group interest in all but two of those building blocks has diminished. The current drafts on those two propose extensions that under the original charter would need to be developed in other working groups. Given the update to the SIP change process (RFC5727) and the subsequent restructuring of the RAI area, these constraints are being revised as detailed below. The BLISS working group shall be closed after completing the following two proposed standards: - call completion with queuing as proposed in draft-ietf-bliss-call-completion - shared appearances as proposed in draft-ietf-bliss-shared-appearances The goal to produce a problem statement and a common template for describing primitives is abandoned. The group will continue to work within the constraints of the creation of event packages and SIP URI parameters, with the addition of the ability to - exercise the already standardized extension points of SIP header fields. Currently, the documents propose to extend the SIP Alert-Info header field (RFC3261) to carry an appearance identifier, and the SIP Call-Info header field (RFC3261) to carry a call completion indicator. - extend the SIP Dialog event package (RFC4235) to carry appearance related state, The working group will coordinate review of those extensions with the SIPCORE working group. Describing the security properties (particularly any privacy considerations) of these deliverables remains of special importance. Upon completion of these two work items, the working group will conclude. Future proposals should be directed to the DISPATCH working group. Goals and Milestones: Mar 2012 - Submit Shared Appearances to the IESG for publication as Proposed Standard Jul 2012 - Submit Call Completion to the IESG for publication as Proposed Standard Sep 2012 - Bliss concludes Internet-Drafts: - An Analysis of Automatic Call Handling (ACH) Implementation Issues in the Session Initiation Protocol (SIP) [draft-ietf-bliss-ach-analysis-06] (25 pages) - Call Completion for Session Initiation Protocol (SIP) [draft-ietf-bliss-call-completion-14] (33 pages) - Implementing Call Park and Retrieve using the Session Initiation Protocol (SIP) [draft-ietf-bliss-call-park-extension-01] (19 pages) - Basic Level of Interoperability for Session Initiation Protocol (SIP) Services (BLISS) Problem Statement [draft-ietf-bliss-problem-statement-04] (20 pages) - Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR) [draft-ietf-bliss-shared-appearances-10] (70 pages) No Requests for Comments Binary Floor Control Protocol Bis (bfcpbis) -------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Charles Eckel 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: bfcpbis@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/bfcpbis Archive: http://www.ietf.org/mail-archive/web/bfcpbis/ Description of Working Group: The BFCPBIS working group is chartered to specify a revision of BFCP (RFC 4582) to support using both TCP and UDP as transports. The current version of BFCP only supports TCP, which when both endpoints are behind NATs or firewalls, has a lower success rate than using the ICE techniques with a UDP based transport for BFCP. The need for video endpoints to work in these types of environments is driving a strong need to support a UDP based transport as well as TCP. This WG will create a revision of RFC 4582 which adds optional support for UDP to BFCP. The security when using UDP will be based on DTLS. The updated protocol will use an existing approach (e.g., stop and wait with a single outstanding transaction) to provide a reliable, congestion safe, and TCP friendly transport. In addition to providing a way for dealing with the reliable delivery of client-initiated transactions, the updated protocol will also be able to deliver server-initiated transactions reliably when needed. The WG will research the size of messages used and decide if fragmenting a request or response over multiple UDP packets is required. The new protocol will be backwards compatible with RFC 4582 when used in TCP mode. The BFCPBIS WG will coordinate closely with the MMUSIC WG to create a revision of RFC 4583 specifying how BFCP is signaled in SDP so that it supports UDP as well as TCP transports. This WG would ask the MMUSIC WG to add a milestone to create a revisions of RFC 4583 to address signaling the use of UDP in SDP. The WG will coordinate with International Multimedia Telecommunications Consortium (IMTC) and other industry fora. Goals and Milestones: Jun 2012 - Draft revision of RFC 4582 to IESG Jun 2012 - Draft revision of RFC 4583 to IESG Internet-Drafts: - The Binary Floor Control Protocol (BFCP) [draft-ietf-bfcpbis-rfc4582bis-02] (85 pages) - Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams [draft-ietf-bfcpbis-rfc4583bis-00] (15 pages) No Requests for Comments Call Control UUI Service for SIP (cuss) --------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Vijay K. Gurbani Enrico Marocco Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo Mailing Lists: General Discussion: cuss@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/cuss Archive: http://www.ietf.org/mail-archive/web/cuss/ Description of Working Group: The Call control UUI Service for SIP (CUSS) working group is chartered to define a Session Initiation Protocol (SIP) mechanism for transporting call-control related user-to-user information (UUI) for applications using SIP to establish media sessions. The information transported is essentially opaque to SIP, but is tagged with the application that generated it and the encoding method. One important application of this mechanism is interworking with the ISDN User to User Information Service. This application, defined by ITU-T Q.931, is extensively deployed in the PSTN today supporting such applications as contact centers, call centers, and automatic call distributors (ACDs). A major barrier to the movement of these applications to SIP is the lack of a standard mechanism to transport this information in SIP. For interworking with ISDN, minimal information about the content of the UUI is available to the PSTN-SIP gateways. In this special case, the application tag will indicate ISDN UUI Service 1 interworking. Call control UUI is a small piece of application information conveyed between user agents during call control operations. As a result, the information must be conveyed with the INVITE transaction. A goal is to avoid a dependency on multipart MIME support. The mechanism must interwork with the existing ISDN service but should also be extensible for use by other applications and non-ISDN protocols. Even though interworking with the PSTN is an important requirement, call control UUI can be exchanged between native SIP clients that do not have any ISUP support. Therefore, existing SIP-T encapsulation-based approaches defined in RFC3372 do not meet the requirements to transport this type of information. Mechanisms based on the SIP INFO method, RFC2976, will not be considered by the working group since the UUI contents carry information that must be conveyed during session setup at the user agent - the information must be conveyed with the INVITE transaction. The information must be passed with the session setup request (INVITE), responses to that INVITE, or session termination requests. As a result, it is not possible to use INFO in these cases. The working group will define guidelines for other applications to utilize the mechanism and the information that each application must specify to utilize the mechanism. New applications of the mechanism will require a standards-track document. The mechanism developed in this working group is applicable in the following situations: 1. The information is generated and consumed by an application during session setup using SIP, but the application is not necessarily even SIP aware. 2. The behavior of SIP entities that support it is not significantly changed (as discussed in Section 4 of RFC 5727). 3. User Agent Clients (UAC) and User Agent Servers (UAS) are the generator and consumer of the UUI data. Proxies may route based on the application tag. 4. Intermediary elements or proxies can remove or insert UUI information This mechanism is not applicable in the following situations: 1. The behavior of SIP entities that support it is significantly changed (as discussed in Section 4 of RFC 5727). 2. The information is generated and consumed at the SIP layer by SIP elements. 3. SIP elements besides the UAC and UAS might be interested in consuming (beyond adding or removing) the information. 4. There are specific privacy issues involved with the information being transported (e.g., geolocation or emergency-related information). The group will produce: - A problem statement and requirements document for implementing a SIP call control UUI mechanism. - A specification of the SIP extension to best meet those requirements. - An application usage specification for the ISDN UUI Service. Goals and Milestones: Aug 2011 - Problem statement and requirements document to IESG (Informational) Oct 2011 - SIP call control UUI specification to IESG (PS) Nov 2011 - ISDN UUI Service application usage specification to IESG (PS) Internet-Drafts: - A Mechanism for Transporting User to User Call Control Information in SIP [draft-ietf-cuss-sip-uui-06] (18 pages) - Interworking ISDN Call Control User Information with SIP [draft-ietf-cuss-sip-uui-isdn-04] (19 pages) - Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP [draft-ietf-cuss-sip-uui-reqs-09] (12 pages) Requests for Comments: RFC6567: Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP (12 pages) * Replaces DRAFT-JOHNSTON-CUSS-SIP-UUI-REQS ControLling mUltiple streams for tElepresence (clue) ---------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Mary Barnes Paul Kyzivat Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo Mailing Lists: General Discussion: clue@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/clue Archive: http://www.ietf.org/mail-archive/web/clue/ Description of Working Group: In the context of this WG, the term telepresence is used in a general manner to describe systems that provide high definition, high quality audio/video enabling a "being-there" experience. One example is an immersive telepresence system using specially designed and special purpose rooms with multiple displays permitting life size image reproduction using multiple cameras, encoders, decoders, microphones and loudspeakers. Current telepresence systems are based on open standards such as RTP, SIP, H.264, the H.323 suite. However, they cannot easily interoperate with each other without operator assistance and expensive additional equipment which translates from one vendor to another. A major factor limiting the interoperability of telepresence systems is the lack of a standardized way to describe and negotiate the use of the multiple streams of audio and video comprising the media flows. The WG will create specifications for SIP-based conferencing systems to enable communication of information about media streams so that a sending system, receiving system, or intermediate system can make reasonable decisions about transmitting, selecting, and rendering media streams. This enables systems to make choices that optimize user experience. This working group is chartered to specify the following information about media streams from one entity to another entity: * Spatial relationships of cameras, displays, microphones, and loudspeakers - relative to each other and to likely positions of participants * Viewpoint, field of view/capture for camera/microphone/display/loudspeaker - so that senders and intermediate devices can understand how best to compose streams for receivers, and the receiver will know the characteristics of its received streams * Usage of the stream, for example whether the stream is presentation, or document camera output * Aspect ratio of cameras and displays * Which sources a receiver wants to receive. For example, it might want the source for the left camera, or might want the source chosen by VAD (Voice Activity Detection) Information between sources and sinks about media stream capabilities will be exchanged. The working group will define the semantics, syntax, and transport mechanism for communicating the necessary information. It will consider whether existing protocols for signaling, messaging and transport are adequate or need to be extended. Any extensions to IETF protocols will be done in appropriate WGs, for example extensions to SDP in MMUSIC. The scope of the work includes describing relatively static relations between entities (participants and devices). It also includes handling more dynamic relationships, such as specifying the audio and video streams for defined speakers. Specifying the location of the current speakers relative to display microphones needs to be provided dynamically as speakers move. As part of the receiver telling the sender what it wants dynamically, explicit receiver notification to the sender of the desired video stream and video pause will be considered. The scope includes both systems that provide a fully immersive experience, and systems that interwork with them and therefore need to understand the same multiple stream semantics. The focus of this work is on multiple RTP audio and video streams. Other media types may be considered, however development of methodologies for them is not within the scope of this work. Interoperation with SIP and related standards for audio and video is required. However, backwards compatibility with existing non-standards compliant telepresence systems is not required. This working group is not currently chartered to work on issues of continuous conference control including: far end camera control, floor control, conference roster. The working group may identify interoperability obstacles in existing open standards. If so, the WG will develop requirements to be communicated to other IETF WGs or Standards Forums, or recharter as appropriate. Reuse of existing protocols and backwards compatibility with SIP-compliant audio/video endpoints are important factors for the working group to consider. The work will closely coordinate with the appropriate areas (e.g., OPS and SEC), and working groups including AVT, MMUSIC, MEDIACTRL, XCON, and SIPCORE. Goals and Milestones: Jul 2011 - Submit informational draft to IESG on use cases Jul 2011 - Submit informational draft to IESG on framework and requirements Nov 2011 - Submit standards track specification(s) to IESG to support framework and requirements Internet-Drafts: - Framework for Telepresence Multi-Streams [draft-ietf-clue-framework-04] (35 pages) - Requirements for Telepresence Multi-Streams [draft-ietf-clue-telepresence-requirements-01] (12 pages) - Use Cases for Telepresence Multi-streams [draft-ietf-clue-telepresence-use-cases-02] (16 pages) No Requests for Comments Data for Reachability of Inter/tra-NetworK SIP (drinks) ------------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Sumanth Channabasappa Alexander Mayrhofer Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo Mailing Lists: General Discussion: drinks@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/drinks Archive: http://www.ietf.org/mail-archive/web/drinks/ Description of Working Group: The IETF has been working on various aspects of SIP-enabled Multimedia administrative domains among SIP Service Providers (SSP's). SSP's are entities that provide session services utilizing SIP signaling to their customers. In addition, the IETF has done significant work on data exchanges among various network elements. The DRINKS working group is chartered with a scope that is orthogonal to SPEERMINT and ENUM. The protocol work of DRINKS will be designed to build from the work of SPEERMINT and ENUM to identify and define the data structures and data exchange protocol(s) among SIP based Multimedia administrative domains. The ENUM working group is specifically chartered to develop protocols that involve the translation of E.164 numbers to URIs. While the SPEERMINT working group has been chartered to develop requirements and best current practices among real-time application SSPs and to describe how such services may best interconnect across administrative boundaries. These administrative domains may be of any practical size and could be any type of SSP, such as recognized telephony carriers, enterprises, end-user groups, or Federations. Data exchanges among these administrative domains may be bi-lateral or multi-lateral in nature, and could include bulk updates and/or more granular real-time updates. Administrative domains may exchange data through the use of an external registry to aggregate data from multiple administrative domains or multiple data providers into a single view. The DRINKS WG will provide details of how Session Establishment Data (SED) is collected, what comprises SED, how SED should be used to properly identify an optimal path to a destination SIP user agent (UA),either internally or externally to the SSP. In addition DRINKS will insure that the SED and the SIP session data is securely exchanged between the peering functions. Typical SED data might include: + Routes - Destination SIP/SIPS/TEL URI Egress and Ingress Routes - Relevant route names, identifiers, and services - Attributes affecting route selection - PSTN database information + Targets - Individual, ranges, or groups of user-agent identifiers - Target aggregation entities (e.g. service areas) and target-to-aggregate associations + Treatment Profiles - Priority - Location Potential SED Data types not in scope will be session rating or other billing or pricing information between SSP's The working group will draw upon expert advice and on-going consultation from the ENUM and SPEERMINT working groups, and also the XML Directorate. The working group will consider the reuse of elements of RFC 4114. The final work product(s) from this working group will utilize and be based on XML documents and XML document exchanges. Goals and Milestones: Done - Request publication of Use Cases and Protocol Requirements document Apr 2012 - Request publication of SPPP over SOAP Document Apr 2012 - Request publication of Framework Document Internet-Drafts: - Consolidated Provisioning Problem Statement [draft-ietf-drinks-cons-rqts-00] (12 pages) - Session Peering Provisioning Framework (SPPF) [draft-ietf-drinks-spp-framework-01] (59 pages) - Session Peering Provisioning (SPP) Protocol over SOAP [draft-ietf-drinks-spp-protocol-over-soap-01] (91 pages) - SPPP Over SOAP and HTTP [draft-ietf-drinks-sppp-over-soap-07] (87 pages) - Session Peering Provisioning Protocol Data Model [draft-ietf-drinks-spprov-12] (59 pages) - Data for Reachability of Inter-/Intra-NetworK SIP (DRINKS) Use Cases and Protocol Requirements [draft-ietf-drinks-usecases-requirements-06] (24 pages) Requests for Comments: RFC6461: Data for Reachability of Inter-/Intra-NetworK SIP (DRINKS) Use Cases and Protocol Requirements (24 pages) Dispatch (dispatch) ------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Mary Barnes Cullen Jennings Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo Mailing Lists: General Discussion: dispatch@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dispatch Archive: http://www.ietf.org/mail-archive/web/dispatch/ Description of Working Group: The Dispatch working group is chartered to consider proposals for new work in the RAI area and identify, or help create, an appropriate venue for the work. Options for handling new work include: - Directing the work to an existing WG. - Developing a proposal for a BOF. - Developing a charter and establishing consensus for a new WG or Exploratory Group. This option will primarily be used with fairly mature and well-defined efforts. - Rejecting and deferring work. A major objective of the DISPATCH WG is to provide timely, clear dispositions of new efforts. Where there is consensus to take on new work, the WG will strive to quickly find a home for it. Reconsideration of proposals which have failed to gather consensus will be prioritized behind proposals for new work which have not yet been considered. In general, requests for reconsideration should only be made once a proposal has been significantly revised. Guiding principles will include: 1. Providing a clear problem statement for proposed new work. 2. Prioritizing new efforts so that RAI does not take on more work than it can effectively complete. 3. Looking for commonalities among ongoing development efforts. Such commonalities may indicate the need to develop more general, reusable components. 4. Protecting the architectural integrity of RAI protocols and ensuring that work has general applicability. If the group decides that a particular topic needs to be addressed by a new or existing WG, the normal IETF chartering process will be followed, including, for instance, IETF-wide review of the proposed changes. Proposal for large work efforts SHOULD lead to a BOF where the topic can be discussed in front of the entire IETF community. Prior experience in RAI, particularly in SIPPING, indicates that the activities described here are significantly hindered when trying to complete the identified protocol work items in the same venue. The DISPATCH working group will not direct protocol work to itself. Goals and Milestones: Internet-Drafts: No Requests for Comments Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Marc Linsner Richard Barnes Roger Marshall Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: General Discussion: ecrit@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ecrit Archive: http://www.ietf.org/mail-archive/web/ecrit/ Description of Working Group: In a number of areas, the public switched telephone network (PSTN) has been configured to recognize an explicitly specified number (commonly one that is short and easily memorized) as a call for emergency services. These numbers (e.g. 911, 112) relate to an emergency service context and depend on a broad, regional configuration of service contact methods and a geographically-constrained context of service delivery. These calls are intended to be delivered to special call centers equipped to manage emergency response. Successful delivery of an emergency service call within those systems requires both an association of the physical location of the originator with an appropriate emergency service center and call routing to deliver the call to the center. Calls placed using Internet technologies do not use the same systems to achieve those goals, and the common use of overlay networks and tunnels (either as VPNs or for mobility) makes meeting them more challenging. There are, however, Internet technologies available to describe location and to manage call routing. This working group will describe when these may be appropriate and how they may be used. Explicitly outside the scope of this group is the question of pre-emption or prioritization of emergency services traffic. This group is considering emergency services calls which might be made by any user of the Internet, as opposed to government or military services that may impose very different authentication and routing requirements. The group will show how the availability of location data and call routing information at different steps in session setup would enable communication between a user and a relevant emergency response center. Though the term "call routing" is used in this document, it should be understood that some of the mechanisms which will be described might be used to enable other types of media streams. Video and text messaging, for example, might be used to request emergency services. While this group anticipates a close working relationship with groups such as NENA and ETSI EMTEL, any solution presented must be useful regardless of jurisdiction, and it must be possible to use without a single, central authority. Further, it must be possible for multiple delegations within a jurisdiction to be handled independently, as call routing for specific emergency types may be independent. This working group cares about privacy and security concerns, and will address them within its documents. Goals and Milestones: Done - Informational RFC containing terminology definitions and the requirements Done - An Informational document describing the threats and security considerations Done - A Standards Track RFC describing how to identify a session set-up request is to an emergency response center Done - A Standards Track RFC describing how to route an emergency call based on location information Done - An Informational document describing the Mapping Protocol Architecture Done - Submit 'Location Hiding: Problem Statement and Requirements' to the IESG for consideration as an Informational RFC. Done - Submit 'Framework for Emergency Calling using Internet Multimedia' to the IESG for consideration as an Informational RFC. Done - Submit 'Best Current Practice for Communications Services in support of Emergency Calling' to the IESG for consideration as a BCP document Done - Submit 'LoST Extension for returning Boundary Information for Services' to the IESG for consideration as an Experimental RFC Oct 2010 - Submit 'Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements' to the IESG for consideration as an Experimental RFC Nov 2010 - Submit 'Using Imprecise Location for Emergency Call Routing' to the IESG for consideration as an Informational RFC Mar 2011 - Submit 'Additional Data related to a Call for Emergency Call Purposes' to the IESG for consideration as a Standards Track RFC Apr 2011 - Submit 'Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (SIP)' to the IESG for consideration as an Experimental RFC Dec 2011 - Submit 'Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices' to the IESG for consideration as a Standards Track RFC Jan 2012 - Submit 'Trustworthy Location Information' to the IESG for consideration as an Informational RFC Mar 2012 - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the IESG for consideration as an Informational RFC Internet-Drafts: - Additional Data related to an Emergency Call [draft-ietf-ecrit-additional-data-03] (46 pages) - Data-Only Emergency Calls [draft-ietf-ecrit-data-only-ea-03] (23 pages) - Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP) [draft-ietf-ecrit-dhc-lost-discovery-03] (8 pages) - Framework for Emergency Calling Using Internet Multimedia [draft-ietf-ecrit-framework-13] (37 pages) - IANA Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications [draft-ietf-ecrit-local-emergency-rph-namespace-04] (8 pages) - Location Hiding: Problem Statement and Requirements [draft-ietf-ecrit-location-hiding-req-04] (11 pages) - LoST: A Location-to-Service Translation Protocol [draft-ietf-ecrit-lost-10] (79 pages) - Location-to-Service Translation (LoST) Service List Boundary Extension [draft-ietf-ecrit-lost-servicelistboundary-05] (16 pages) - Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements [draft-ietf-ecrit-lost-sync-17] (29 pages) - Location-to-URL Mapping Architecture and Framework [draft-ietf-ecrit-mapping-arch-04] (18 pages) - Best Current Practice for Communications Services in support of Emergency Calling [draft-ietf-ecrit-phonebcp-20] (26 pages) - Public Safety Answering Point (PSAP) Callback [draft-ietf-ecrit-psap-callback-04] (23 pages) - Requirements for Emergency Context Resolution with Internet Technologies [draft-ietf-ecrit-requirements-13] (32 pages) - Using Imprecise Location for Emergency Context Resolution [draft-ietf-ecrit-rough-loc-04] (18 pages) - Security Threats and Requirements for Emergency Call Marking and Mapping [draft-ietf-ecrit-security-threats-05] (18 pages) - A Uniform Resource Name (URN) for Emergency and Other Well-Known Services [draft-ietf-ecrit-service-urn-07] (15 pages) - Specifying Holes in Location-to-Service Translation (LoST) Service Boundaries [draft-ietf-ecrit-specifying-holes-03] (17 pages) - Trustworthy Location Information [draft-ietf-ecrit-trustworthy-location-03] (21 pages) - Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices [draft-ietf-ecrit-unauthenticated-access-04] (26 pages) Requests for Comments: RFC5012: Requirements for Emergency Context Resolution with Internet Technologies (32 pages) RFC5031: A Uniform Resource Name (URN) for Emergency and Other Well-Known Services (15 pages) * Replaces DRAFT-IETF-SIPPING-SOS RFC5069: Security Threats and Requirements for Emergency Call Marking and Mapping (18 pages) * Replaces DRAFT-TAYLOR-ECRIT-SECURITY-THREATS RFC5222: LoST: A Location-to-Service Translation Protocol (79 pages) * Replaces DRAFT-HARDIE-ECRIT-LOST RFC5223: Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP) (8 pages) * Replaces DRAFT-POLK-ECRIT-DHC-LOST-DISCOVERY RFC5582: Location-to-URL Mapping Architecture and Framework (18 pages) RFC5964: Specifying Holes in Location-to-Service Translation (LoST) Service Boundaries (17 pages) * Replaces DRAFT-WINTERBOTTOM-ECRIT-SPECIFYING-HOLES RFC6197: Location-to-Service Translation (LoST) Service List Boundary Extension (16 pages) * Replaces DRAFT-WOLF-ECRIT-LOST-SERVICELISTBOUNDARY RFC6443: Framework for Emergency Calling Using Internet Multimedia (37 pages) * Replaces DRAFT-ROSEN-ECRIT-FRAMEWORK RFC6444: Location Hiding: Problem Statement and Requirements (11 pages) * Replaces DRAFT-SCHULZRINNE-ECRIT-LOCATION-HIDING-REQ Extensible Messaging and Presence Protocol (xmpp) ------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Joe Hildebrand Ben Campbell Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: General Discussion: xmpp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/xmpp Archive: http://www.ietf.org/mail-archive/web/xmpp/ Description of Working Group: The Extensible Messaging and Presence Protocol (XMPP) is an technology for the near-real-time exchange of messages and presence notifications, where data is exchanged over Extensible Markup Language (XML) streams. The original XMPP working group published RFCs 3920-3923. Implementation and deployment experience since that time has resulted in errata, clarifications, and suggestions for improvement to the core XMPP specifications (RFCs 3920 and 3921). Some technologies on which XMPP depends (e.g., Transport Layer Security and the Simple Authentication and Security Layer) have undergone modifications of their own, which XMPP needs to track. Finally, the group needs to define a sustainable solution to internationalization of XMPP addresses, since the approach taken in RFC 3920 (based on stringprep profiles) is limited to Unicode 3.2 characters. Both draft-saintandre-rfc3920bis-* and draft-saintandre-rfc3921bis-* reflect community input so far regarding these modifications, but the group needs to complete this work, especially with regard to internationalization. Because of the scope of changes involved, it is envisioned that these specifications will be cycled at Proposed Standard. Although RFC 3923 defines an end-to-end signing and encryption technology for use by XMPP systems, to date it has not been implemented. A goal of the group is to develop an implementable method for end-to-end encryption, preferably based on well known and widely deployed security technologies. XMPP uses TLS for encryption and the Simple Authentication and Security Layer (SASL) for authentication. In the case of a server-to-server stream, XMPP is deployed using TLS and the SASL EXTERNAL mechanism, where each peer presents an X.509 certificate. This model introduces scaling challenges in multi-domain deployments because RFC 3920 requires that a stream cannot be reused for more than one domain, thus necessitating multiple TCP connections. The group will work to overcome these challenges by defining an optional mechanism for using a single connection with multiple identities. It is anticipated that most of the work will consist of defining and providing requirements to the TLS and SASL working groups. Many of the core and extended features of XMPP have also been implemented in technologies based on the Session Initiation Protocol (SIP). To ensure interworking between XMPP systems and SIP systems, a number of Internet-Drafts (draft-saintandre-sip-xmpp-*) have been produced. The group will define a framework within which this work could be completed. In completing its work, the group will strive to retain backwards compatibility with RFCs 3920 and 3921. However, changes that are not backwards compatible might be accepted if the group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. Goals and Milestones: Done - Decide upon a direction for server-to-server connection reuse. Done - Deliver rfc3920bis and rfc3921bis to the IESG. Done - Decide upon a direction for end-to-end encryption. Mar 2012 - Define a solution for server-to-server connection reuse. Aug 2012 - Define a solution for end-to-end encryption. Sep 2012 - Define a solution for internationalization of XMPP addresses (Update of RFC 6122) Internet-Drafts: - Extensible Messaging and Presence Protocol (XMPP): Core [draft-ietf-xmpp-3920bis-22] (213 pages) - Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence [draft-ietf-xmpp-3921bis-20] (116 pages) - Extensible Messaging and Presence Protocol (XMPP): Address Format [draft-ietf-xmpp-6122bis-02] (20 pages) - Extensible Messaging and Presence Protocol (XMPP): Address Format [draft-ietf-xmpp-address-09] (23 pages) - Domain Name Assertions [draft-ietf-xmpp-dna-01] (18 pages) - Requirements for End-to-End Encryption in the Extensible Messaging and Presence Protocol (XMPP) [draft-ietf-xmpp-e2e-requirements-01] (10 pages) Requests for Comments: RFC6120: Extensible Messaging and Presence Protocol (XMPP): Core (213 pages) * Obsoletes RFC3920 RFC6121: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence (116 pages) * Obsoletes RFC3921 RFC6122: Extensible Messaging and Presence Protocol (XMPP): Address Format (23 pages) * Replaces DRAFT-SAINTANDRE-XMPP-ADDRESS * Updates RFC3920 Geographic Location/Privacy (geopriv) ------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Alissa Cooper Richard Barnes Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Robert Sparks Tech Advisor: Lisa Dusseault Mailing Lists: General Discussion: geopriv@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/geopriv Archive: http://www.ietf.org/mail-archive/web/geopriv/ Description of Working Group: The IETF has recognized that many applications are emerging that require geographic and civic location information about resources and entities, and that the representation and transmission of that information has significant privacy and security implications. We have created a suite of protocols that allow such applications to represent and transmit such location objects and to allow users to express policies on how these representations are exposed and used. The IETF has also begun working on creating applications that use these capabilities, for emergency services, general real-time communication, and other usages. The GEOPRIV working group is chartered to continue to develop and refine representations of location in Internet protocols, and to analyze the authorization, integrity, and privacy requirements that must be met when these representations of location are created, stored, and used. The group will create and refine mechanisms for the transmission of these representations that address the requirements that have been identified. The working group will work with other IETF working groups and other standards development organizations that are building applications that use location information to ensure that the requirements are well understood and met, and that no additional security or privacy issues related to location are left unaddressed as these location information is incorporated into other protocols. It remains a goal of the GEOPRIV working group to deliver specifications of broad applicability that will become mandatory to implement for IETF protocols that are location aware. This working group will not develop location-determining technology. However, the IETF acknowledges that information used in the location- determination process will in some cases need to be carried over the Internet. Where necessary, this working group will develop protocols or protocol extensions to encode location-determination data structures defined elsewhere. This working group will not develop technologies to directly address any particular regulatory requirements (e.g. 9-1-1). The group will continue to coordinate with any other IETF entities that are working on those problems to ensure the technologies created here meet the needs of those entities, and that the authorization, integrity, and privacy requirements on the mechanisms provided by these technologies continue to be met. Goals and Milestones: Done - Discuss initial geopriv scenarios and application requirements i-d's Done - Discuss initial geographic location privacy and security requirements i-d. Done - Initial i-d on geographic information protocol design, including privacy and security techniques. Done - Review charter and initial i-ds with AD, and have IESG consider rechartering if necessary. Done - Submit geopriv scenarios and application requirements to IESG for publicaiton as Informational RFCs Done - Submit security/privacy requirements I-D to IESG for publication as Informational RFC. Done - Submit PIDF-LO basic geopriv object draft as a PS Done - Initial Common Rules base object draft Done - Initial Common Ruels GEOPRIV object draft Done - Submit DHCP Civil draft as a PS Done - Resubmit Conveying Location Objects in RADIUS and Diameter to the IESG for publication as PS Done - Submit Additional Civic PIDF-LO types (updating 4119) to the IESG for publication as PS Done - Submit Layer 7 Location Conveyance Protocol Problem Statement and Requirements to the IESG for publication as Informational Done - Submit Requirements for Location by Reference Protocols to the IESG for publication as Informational Done - Submit PIDF-LO Usage Clarifications and Recommendations (updating 4119) to the IESG for publication as PS Done - Submit minimal HTTP based protocol satisfying baseline requirements specified in the Layer 7 Location Conveyance Protocol Problem Statement and Requirements to the IESG for publication as PS Done - Submit a LIS Discovery Mechanism to the IESG for publication as a PS Done - Submit Recommendations for Retransmission in SIP Location Conveyance to the IESG for publication as Informational Done - Submit recommendations for representing civic addresses in PIDF-LO to the IESG for publication as BCP Done - Submit an draft for DHCP geodetic location to the IESG for publication as PS to obsolete 3825 Done - Submit an Architecture for Location and Location Privacy to the IESG for publication as Informational Done - Submit a Document Format for Filtering and Reporting PIDF-LO Location Notifications to the IESG for publication as PS Done - Submit a URI scheme for directly expressing geodetic location to the IESG for publication as PS Jan 2011 - Submit a DHCP Option for a Location Uniform Resource Identifier (URI) to the IESG for publication as PS Mar 2011 - Resubmit Geolocation Policy to the IESG for publication as PS Mar 2011 - Submit civic address registry values for street name and house number prefixes to the IESG for publication as Informational Mar 2011 - Submit a Location Dereferencing Protocol for HTTP-Enabled Location Delivery (HELD) to the IESG for publication as PS. Jun 2011 - Submit recommendations for LIS discovery conducted by hosts behind residential gateways as Informational Jun 2011 - Submit a draft that defines civic address parameters to allow the expression of a location relative to a reference point to the IESG for publication as PS. Jun 2011 - Submit a method that can be used to provide location-related measurement data to a Location Information Server (LIS) within a request for location information to the IESG for publication as PS. Jun 2011 - Submit a policy control mechanism for location configuration as Proposed Standard Dec 2012 - Submit recommendations for civic address extensions as PS Internet-Drafts: - Threat Analysis of the GEOPRIV Protocol [draft-danley-geopriv-threat-analysis-00] (18 pages) - An Architecture for Location and Location Privacy in Internet Applications [draft-ietf-geopriv-arch-03] (41 pages) - Binary to Decimal Conversion for Location Configuration Information [draft-ietf-geopriv-binary-lci-01] (8 pages) - Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition [draft-ietf-geopriv-civic-address-recommendations-03] (35 pages) - Common Policy: A Document Format for Expressing Privacy Preferences [draft-ietf-geopriv-common-policy-11] (43 pages) - A Location Dereferencing Protocol Using HELD [draft-ietf-geopriv-deref-protocol-05] (23 pages) - Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information [draft-ietf-geopriv-dhcp-civil-09] (23 pages) - Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI) [draft-ietf-geopriv-dhcp-lbyr-uri-option-14] (13 pages) - Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information [draft-ietf-geopriv-dhcp-lci-option-03] (14 pages) - DHC Location Object within GEOPRIV [draft-ietf-geopriv-dhcp-lo-option-01] (12 pages) - A Uniform Resource Identifier for Geographic Locations ('geo' URI) [draft-ietf-geopriv-geo-uri-07] (24 pages) - Use of Device Identity in HTTP-Enabled Location Delivery (HELD) [draft-ietf-geopriv-held-identity-extensions-06] (30 pages) - Using Device-provided Location-Related Measurements in Location Configuration Protocols [draft-ietf-geopriv-held-measurements-04] (74 pages) - HTTP-Enabled Location Delivery (HELD) [draft-ietf-geopriv-http-location-delivery-16] (47 pages) - GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements [draft-ietf-geopriv-l7-lcp-ps-10] (26 pages) - Requirements for a Location-by-Reference Mechanism [draft-ietf-geopriv-lbyr-requirements-09] (26 pages) - Discovering the Local Location Information Server (LIS) [draft-ietf-geopriv-lis-discovery-15] (18 pages) - Filtering Location Notifications in the Session Initiation Protocol (SIP) [draft-ietf-geopriv-loc-filters-11] (25 pages) - Specifying Civic Address Extensions in PIDF-LO [draft-ietf-geopriv-local-civic-03] (19 pages) - Location Types Registry [draft-ietf-geopriv-location-types-registry-06] (18 pages) - GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations [draft-ietf-geopriv-pdif-lo-profile-14] (35 pages) - A Presence-based GEOPRIV Location Object Format [draft-ietf-geopriv-pidf-lo-03] (24 pages) - Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information [draft-ietf-geopriv-policy-25] (48 pages) - Location Configuration Extensions for Policy Management [draft-ietf-geopriv-policy-uri-04] (18 pages) - Prefix elements for Road and House Numbers in PIDF-LO [draft-ietf-geopriv-prefix-00] (4 pages) - A Presence Architecture for the Distribution of GEOPRIV Location Objects [draft-ietf-geopriv-pres-02] (9 pages) - Carrying Location Objects in RADIUS and Diameter [draft-ietf-geopriv-radius-lo-24] (61 pages) - Relative Location Representation [draft-ietf-geopriv-relative-location-02] (36 pages) - Geopriv Requirements [draft-ietf-geopriv-reqs-04] (27 pages) - Location Information Server (LIS) Discovery using IP address and Reverse DNS [draft-ietf-geopriv-res-gw-lis-discovery-03] (19 pages) - Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO) [draft-ietf-geopriv-revised-civic-lo-07] (19 pages) - Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information [draft-ietf-geopriv-rfc3825bis-17] (35 pages) - Implications of 'retransmission-allowed' for SIP Location Conveyance [draft-ietf-geopriv-sip-lo-retransmission-02] (13 pages) - Threat Analysis of the Geopriv Protocol [draft-ietf-geopriv-threat-analysis-01] (18 pages) Requests for Comments: BCP0154: Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition (35 pages) * Updates RFC4776 BCP0160: An Architecture for Location and Location Privacy in Internet Applications (41 pages) * Replaces DRAFT-BARNES-GEOPRIV-LO-SEC * Updates RFC3693 * Updates RFC3694 RFC3693: Geopriv Requirements (27 pages) * Updates RFC6280 RFC3694: Threat Analysis of the Geopriv Protocol (18 pages) * Updates RFC6280 RFC3825: Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information (14 pages) * Obsoletes RFC6225 RFC4079: A Presence Architecture for the Distribution of GEOPRIV Location Objects (9 pages) RFC4119: A Presence-based GEOPRIV Location Object Format (24 pages) * Updates RFC5139 * Updates RFC5491 RFC4589: Location Types Registry (18 pages) RFC4676: Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information (23 pages) * Obsoletes RFC4776 RFC4745: Common Policy: A Document Format for Expressing Privacy Preferences (43 pages) RFC4776: Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information (None pages) * Obsoletes RFC4676 * Updates RFC5774 RFC5139: Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO) (19 pages) * Updates RFC4119 RFC5491: GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations (35 pages) * Updates RFC4119 RFC5580: Carrying Location Objects in RADIUS and Diameter (61 pages) RFC5606: Implications of 'retransmission-allowed' for SIP Location Conveyance (13 pages) RFC5687: GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements (26 pages) * Replaces DRAFT-TSCHOFENIG-GEOPRIV-L7-LCP-PS RFC5774: Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition (35 pages) * Updates RFC4776 RFC5808: Requirements for a Location-by-Reference Mechanism (26 pages) * Replaces DRAFT-MARSHALL-GEOPRIV-LBYR-REQUIREMENTS RFC5870: A Uniform Resource Identifier for Geographic Locations ('geo' URI) (24 pages) RFC5985: HTTP-Enabled Location Delivery (HELD) (47 pages) RFC5986: Discovering the Local Location Information Server (LIS) (18 pages) * Replaces DRAFT-THOMSON-GEOPRIV-LIS-DISCOVERY RFC6155: Use of Device Identity in HTTP-Enabled Location Delivery (HELD) (30 pages) * Replaces DRAFT-WINTERBOTTOM-GEOPRIV-HELD-IDENTITY-EXTENSIONS RFC6225: Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information (35 pages) * Obsoletes RFC3825 RFC6280: An Architecture for Location and Location Privacy in Internet Applications (41 pages) * Replaces DRAFT-BARNES-GEOPRIV-LO-SEC * Updates RFC3693 * Updates RFC3694 RFC6447: Filtering Location Notifications in the Session Initiation Protocol (SIP) (25 pages) * Replaces DRAFT-MAHY-GEOPRIV-LOC-FILTERS INtermediary-safe SIP session ID (insipid) ------------------------------------------ Charter Last Modified: 2012-02-23 Current Status: Active Chairs: Keith Drage Gonzalo Salgueiro Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo Mailing Lists: General Discussion: insipid@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/insipid Archive: http://www.ietf.org/mail-archive/web/insipid/ Description of Working Group: An end-to-end session identifier in SIP-based multimedia communication networks refers to the ability for endpoints, intermediate devices, and management and monitoring system to identify and correlate SIP messages and dialogs of the same higher-level end-to-end "communication session" across multiple SIP devices, hops, and administrative domains. Unfortunately, there are a number of factors that contribute to the fact that the current dialog identifiers defined in SIP are not suitable for end-to-end session identification. Perhaps the most important factor worth describing is that in real-world deployments of Back-to-Back User Agents (B2BUAs) devices like Session Border Controllers (SBC) often change the call identifiers (e.g., the From-tag and To-tag that are used in conjunction with the Call-ID header to make the dialog-id) as the session signaling passes through. An end-to-end session identifier should allow the possibility to identify the communication session from the point of origin, passing through any number of intermediaries, to the ultimate point of termination. It should have the same aim as the From-tag, To-tag and Call-ID conjunction, but should not be mangled by intermediaries. A SIP end-to-end session identifier has been considered as possible solution of different use cases like troubleshooting, billing, session tracking, session recording, media and signaling correlation, and so forth. Some of these requirements come from other working groups within the RAI area (e.g., SIPRec). Moreover, other standards organizations have identified the need for SIP and H.323 to carry the same "session ID" value so that it is possible to identify a call end-to end even when performing inter working between protocols. This group will focus on a document that will specify a SIP identifier that has the same aim as the From-tag, To-tag and Call-ID conjunction, but is less likely to be mangled by intermediaries. In doing this work, the group will pay attention to the privacy implications of a "session ID", for example considering the possibility to make it intractable for nodes to correlate "session IDs" generated by the same user for different sessions. Goals and Milestones: Dec 2012 - Specification of the new identifier sent to the IESG (PS) Internet-Drafts: No Requests for Comments Internet Wideband Audio Codec (codec) ------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Cullen Jennings Jonathan Rosenberg Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Robert Sparks Tech Advisor: Stephan Wenger Mailing Lists: General Discussion: codec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/codec Archive: http://www.ietf.org/mail-archive/web/codec/ Description of Working Group: Problem Statement According to reports from developers of Internet audio applications and operators of Internet audio services, there are no standardized, high-quality audio codecs that meet all of the following three conditions: 1. Are optimized for use in interactive Internet applications. 2. Are published by a recognized standards development organization (SDO) and therefore subject to clear change control. 3. Can be widely implemented and easily distributed among application developers, service operators, and end users. There exist codecs that provide high quality encoding of audio information, but that are not optimized for the actual conditions of the Internet; according to reports, this mismatch between design and deployment has hindered adoption of such codecs in interactive Internet applications. There exist codecs that can be widely implemented and easily distributed, but that are not standardized through any SDO; according to reports, this lack of standardization and clear change control has hindered adoption of such codecs in interactive Internet applications. There exist codecs that are standardized, but that cannot be widely implemented and easily distributed; according to reports, the presence of various usage restrictions (e.g., in the form of requirements to pay royalty fees, obtain a license, enter into a business agreement, or meet other special conditions imposed by a patent holder) has hindered adoptions of such codecs in interactive Internet applications. According to application developers and service operators, an audio codec that meets all three of these would: (1) enable protocol designers to more easily specify a mandatory-to-implement codec in their protocols and thus improve interoperability; (2) enable developers to more easily easily build innovative, interactive applications for the Internet; (3) enable service operators to more easily deploy affordable, high-quality audio services on the Internet; and (4) enable end users of Internet applications and services to enjoy an improved user experience. Objectives The goal of this working group is to ensure the existence of a single high-quality audio codec that is optimized for use over the Internet and that can be widely implemented and easily distributed among application developers, service operators, and end users. At present it appears that ensuring the existence of such a codec will require a development effort within the working group, however if a candidate codec is presented that achieves the goal then the working group should seriously consider stopping its development work. The core technical considerations for such a codec include, but are not necessarily limited to, the following: 1. Designing for use in interactive applications (examples include, but are not limited to, point-to-point voice calls, multi-party voice conferencing, telepresence, teleoperation, in-game voice chat, and live music performance) 2. Addressing the real transport conditions of the Internet as identified and prioritized by the working group 3. Ensuring interoperability and clean integration with the Real-time Transport Protocol (RTP), including secure transport via SRTP 4. Ensuring interoperability with Internet signaling technologies such as Session Initiation Protocol (SIP), Session Description Protocol (SDP), and Extensible Messaging and Presence Protocol (XMPP); however, the result should not depend on the details of any particular signaling technology Optimizing for very low bit rates (typically below 2.4 kbps) and for non-interactive audio is out of scope because such work might necessitate specialized optimizations. Although a codec produced by this working group or another standards organization might be used as a mandatory-to-implement technology by designers of particular Internet protocols, it is explicitly not a goal of the working group to produce or select a codec that will be mandated for use across the entire IETF or Internet community nor would their be any expectation that this would be the only mandatory-to-implement codec. Based on the working group's analysis of the design space, the working group might determine that it needs to produce more than one codec, or a codec with multiple modes; however, it is not the goal of working group to produce more than one codec, and to reduce confusion in the marketplace the working group shall endeavor to produce as few codecs as possible. In completing its work, the working group should collaborate with other IETF working groups to complete particular tasks. These might include, but would not be limited to, the following: - Within the AVT WG, define the codec's payload format for use with the Real-time Transport Protocol (RTP). - Collaborate with working groups in the Transport Area to identify important aspects of packet transmission over the Internet. - Collaborate with working groups in the Transport Area to understand the degree of rate adaptation desirable, and to reflect that understanding in the design of a codec that can adjust its transmission in a way that minimizes disruption to the audio. - Collaborate with working groups in the RAI Area to ensure that information about and negotiation of the codec can be easily represented at the signaling layer. In accordance with the liaison agreement in place, the working group will continue to coordinate with the ITU-T (Study group 16), with the intent of submitting the completed codec RFC for co-publication by the ITU-T if the ITU-T finds that appropriate. The working group will communicate a detailed description of the requirements and goals to other SDOs including the ITU-T, 3GPP, and MPEG to help determine if existing codecs meet the requirements and goals. Information about codecs being standardized will be available to other SDOs in the form of internet drafts and the working group welcomes technical feedback from other SDOs and experts from other organizations. Suggested Codec Standardization Guidelines and Requirements for achieving the foregoing objectives are provisionally outlined in draft-valin-codec-guidelines and draft-valin-codec-requirements respectively; these documents will form the starting point for working toward consensus and, if accepted as work items of the working group, will be refined by the working group in accordance with the usual IETF procedures. A codec that can be widely implemented and easily distributed among application developers, service operators, and end users is preferred. Many existing codecs that might fulfill some or most of the technical attributes listed above are encumbered in various ways. For example, patent holders might require that those wishing to implement the codec in software, deploy the codec in a service, or distribute the codec in software or hardware need to request a license, enter into a business agreement, pay licensing fees or royalties, or attempt to adhere to other special conditions or restrictions. Because such encumbrances have made it difficult to widely implement and easily distribute high-quality audio codecs across the entire Internet community, the working group prefers unencumbered technologies in a way that is consistent with BCP 78 and BCP 79. In particular, the working group shall heed the preference stated in BCP 79: "In general, IETF working groups prefer technologies with no known IPR claims or, for technologies with claims against them, an offer of royalty-free licensing." Although this preference cannot guarantee that the working group will produce an unencumbered codec, the working group shall follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to redistribute and use. Deliverables 1. A set of Codec Standardization Guidelines that define the work processes of the working group. This document shall be Informational. 2. A set of technical Requirements. This document shall be Informational. 3. Specification of a codec that meets the agreed-upon requirements, in the form of an Internet-Draft that defines the codec algorithm along with source code for a reference implementation. The text description of the codec shall indicate which components of the encoder and decoder are mandatory, recommended, and optional. It is envisioned that this document shall be a Proposed Standard document. Goals and Milestones: Done - WGLC on Codec Standardization Guidelines Done - WGLC on Requirements, liaise to other SDOs Done - Requirements to IESG (Informational) Done - Liaise requirements RFC to other SDOs Done - WGLC on codec specification, liaise to other SDOs Aug 2011 - Codec Standardization Guidelines to IESG (Informational) Aug 2011 - WGLC #2 on Codec specification Sep 2011 - Submit codec specification to IESG (Standards Track) Oct 2012 - WGLC on Testing document Dec 2012 - Testing document to IESG Internet-Drafts: - Definition of the IETF Interactive Audio Codec [draft-ietf-codec-description-00] (12 pages) - Guidelines for Development of an Audio Codec within the IETF [draft-ietf-codec-guidelines-08] (21 pages) - Definition of the Harmony Audio Codec [draft-ietf-codec-harmony-00] (12 pages) - Definition of the Opus Audio Codec [draft-ietf-codec-opus-12] (326 pages) - Requirements for an Internet Audio Codec [draft-ietf-codec-requirements-05] (23 pages) - Summary of Opus listening test results [draft-ietf-codec-results-01] (31 pages) Requests for Comments: RFC6366: Requirements for an Internet Audio Codec (23 pages) * Replaces DRAFT-VALIN-CODEC-REQUIREMENTS RFC6569: Guidelines for Development of an Audio Codec within the IETF (21 pages) Media Server Control (mediactrl) -------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Dale R. Worley Eric Burger Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: General Discussion: mediactrl@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mediactrl Archive: http://www.ietf.org/mail-archive/web/mediactrl Description of Working Group: Real-time multi-media applications often need the services of media processing elements. It is true that modern endpoints are capable of media processing. However, the physics of some media processing applications dictate that it is much more efficient for the media processing to occur at a centralized location. By media processing, we mean media mixing, recording and playing media, and interacting with a user in the audio or video domains. The commercial market calls these media processing network elements "media servers." Some services achieve significant efficiencies when a central node performs media processing. Because of these efficiencies, media servers are widely used for conference mixing, multimedia messaging, content rendering, and speech, voice, key press, and other audio and video input and output user interface modalities. Given the wide acceptance of the media server, we need a standard way to control them. Since the media server is a centralized component, the work group will not investigate distributed media processing algorithms or control protocols. A media server contains media processing components that are able to manipulate RTP streams. Typical processing includes mixing multiple streams, transcoding a stream (e.g., from G.711 to MS-GSM), storing or retrieving a stream (e.g., from RTP to HTTP), detecting tones (e.g., DTMF), converting text to speech, and performing speech recognition. Note that an MRCPv2 server may offer the low-level processing for the last two services, where the media server is a client to the MRCPv2 server. Also note it is common to call the package of detecting user input, recording media, and playing media "Interactive Voice Response," or IVR. Media services offered by the media server are addressed using SIP mechanisms, such as described in RFC 4240. Media servers commonly have a built-in VoiceXML interpreter. VoiceXML describes the elements of the user interaction, and is a proven model for separating application logic (which run on the clients of the media server) from the user interface (which the media server renders). Note this is a fundamentally different interaction model from MRCPv2, where media processing engines offer raw, low-level speech services. The work group will examine protocol extensions between media servers and their clients. However, modifying existing standard protocols, such as VoiceXML or SIP towards clients or MRCPv2 towards servers, is not in the work group's charter. The model of interest to this group is where the endpoint solely plays audio or video, transmits audio or video towards the server, and possibly transmits key press information towards the server. Alternate architectures, where the endpoint executes user interface commands, is outside the scope of the work group. For example, WIDEX/BEEP, with its distributed user interface description, is not in scope. The only model of user interface processing the work group will consider is where the media server performs all of the media processing. A caveat here is the media server, in interpreting a VoiceXML page, may make requests to a server for speech services. However, to the media server client and the media end point, the single point of signaling and media interaction is the media server. Any protocol developed by this group will meet the requirements for Internet deployment. This includes addressing Internet security, privacy, congestion control (or at least congestion safe), operational and manageability considerations, and scale. The protocol will not assume a private administrative domain. There is broad market acceptance of the stimulus/markup application design model for the application server - media server protocol interface. Thus this work group will focus on the use of SIP and XML for the protocol suite. The work product of this group includes the following: 1. A requirements document. This document will identify and enumerate requirements for a suite of media server control protocols. Given that one of the common media server clients is a conference application server, we will consider the application server - media server requirements developed by the XCON work group. Likewise, we will consider media server control requirements from other standards groups, such as 3GPP SA2 and CT1. 2. A framework document. This document will describe the different network elements, their interrelationship, and the broad set of message flows between them. 3. A protocol suite describing the embodiment of the framework document. There may be separate protocol PDU's for audio conference control, video conference control, interactive audio (voice) response, and interactive video (multimedia) response. The separation and negotiation of different PDU's is a working group topic. However, there will be one and only one (class) of PDU's defined by the work group. 4. Means for locating, and possibly establishing sessions to, media servers with appropriate resources at the request of clients. By appropriate, we mean the characteristics of a given media server required or desired for handling a given request. The expectation is such a means would build upon existing SIP, SNMP, and other protocol facilities. Such a means may or may not be an integral part of the item 3 deliverables above. This deliverable is an operational protocol that may rely on management protocols such as SNMP. We are neither creating a new management protocol nor a new provisioning protocol. Given the above-mentioned conferencing example, the work of this group is of interest to the XCON work group, as this protocol will describe the "Protocol used between the conference controller and the mixer (s)." Thus we expect to work closely with XCON. The protocol suite also is a possible embodiment of the ISC/Mr interface from the 3GPP IMS architecture. Thus we expect to gather requirements from, 3GPP, notably SA2, CT1, and CT4. ATIS and ETSI TISPAN have considered a functional element known as a media resource broker. The media resource broker provides the functionality described by deliverable #4, above. Thus we expect to gather requirements from ATIS and ETSI TISPAN. The Java Community Process has chartered work on a Java Media Server Control (JMSC) API, known as JSR 309. We expect to gather requirements from JCP, as well. Because of the vast experience with conferencing protocols and payloads, we expect considerable interaction with AVT and MMUSIC. If the work group requires extensions to SIP, the work group will forward those extensions to the SIP work group for consideration and refinement. Goals and Milestones: Done - Requirements Document WGLC Done - Framework Document WGLC Done - Requirements Document to IESG (Informational) Done - Framework Document to IESG (Informational) Done - IVR Control Protocol WGLC Done - IVR Control Protocol to IESG (Standards Track) Done - Mixer Control Protocol WGLC Dec 2009 - Mixer Control Protocol to IESG (Standards Track) Dec 2009 - Broker Protocol WGLC Jan 2010 - Media Control Call Flows WGLC Feb 2010 - Broker Protocol to IESG (Standards Track) Feb 2010 - Media Control Call Flows to IESG (Informational) Internet-Drafts: - IANA Registry for MEDIACTRL Interactive Voice Response Control Package [draft-ietf-mediactrl-6231-iana-00] (7 pages) - An Architectural Framework for Media Server Control [draft-ietf-mediactrl-architecture-04] (33 pages) - Media Control Channel Framework (CFW) Call Flow Examples [draft-ietf-mediactrl-call-flows-08] (171 pages) - An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework [draft-ietf-mediactrl-ivr-control-package-11] (160 pages) - A Mixer Control Package for the Media Control Channel Framework [draft-ietf-mediactrl-mixer-control-package-14] (105 pages) - Media Resource Brokering [draft-ietf-mediactrl-mrb-12] (138 pages) - Media Server Control Protocol Requirements [draft-ietf-mediactrl-requirements-04] (10 pages) - Media Control Channel Framework [draft-ietf-mediactrl-sip-control-framework-12] (55 pages) - SIP Interface to VoiceXML Media Services [draft-ietf-mediactrl-vxml-04] (47 pages) Requests for Comments: RFC5167: Media Server Control Protocol Requirements (10 pages) * Replaces DRAFT-DOLLY-MEDIACTRL-REQUIREMENTS RFC5552: SIP Interface to VoiceXML Media Services (47 pages) RFC5567: An Architectural Framework for Media Server Control (33 pages) RFC6230: Media Control Channel Framework (55 pages) RFC6231: An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework (160 pages) * Updates RFC6623 RFC6505: A Mixer Control Package for the Media Control Channel Framework (105 pages) RFC6623: IANA Registry for MEDIACTRL Interactive Voice Response Control Package (7 pages) * Updates RFC6231 Metric Blocks for use with RTCP's Extended Report Framework (xrblock) --------------------------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Charles Eckel Shida Schubert Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo Mailing Lists: General Discussion: xrblock@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/xrblock Archive: http://www.ietf.org/mail-archive/web/xrblock/ Description of Working Group: RFC3611, "RTP Control Protocol Extended Reports (RTCP XR)" established a framework to allow new information to be conveyed in RTCP, supplementing the original report blocks defined in RFC 3550, "RTP: A Transport Protocol for Real-Time Applications". The XRBLOCK working group is chartered to work within this framework, evaluating proposals for report block definitions containing new metrics. The group will follow the guidelines established in RFC5968, "Guidelines for Extending the RTP Control Protocol (RTCP)" and RTP Monitoring Architecture being developed in the AVTCORE working group. The group will consider the guidelines for performance metric development currently being discussed in the PMOL working group. Goals and Milestones: Feb 2012 - Submit RTCP XR Report Block for Measurement Identity Reporting to IESG Apr 2012 - Submit RTCP XR Report Block for Delay metric Reporting to IESG Apr 2012 - Submit RTCP XR Report Block for Packet Delay Variation Metric Reporting to IESG Jun 2012 - Submit RTCP XR Report Block for Discard metric Reporting to IESG Jun 2012 - Submit RTCP XR Report Block for Burst/Gap Discard metric Reporting to IESG Jun 2012 - Submit RTCP XR Report Block for Burst/Gap Loss metric Reporting to IESG Aug 2012 - Submit RTCP XR Report Block for Run Length Encodings of Discarded Packets to IESG Oct 2012 - Submit RTCP XR Report Block for QoE Metrics Reporting to IESG Oct 2012 - Submit RTCP XR Report Block for Concealed Seconds metric Reporting to IESG Dec 2012 - Submit RTCP XR Report Block for Jitter Buffer Metric Reporting to IESG Dec 2012 - Submit RTCP XR Report Block for Loss Concealment metric Reporting to IESG Internet-Drafts: - RTCP XR Report Block for Burst/Gap Discard metric Reporting [draft-ietf-xrblock-rtcp-xr-burst-gap-discard-03] (16 pages) - RTCP XR Report Block for Burst/Gap Loss metric Reporting [draft-ietf-xrblock-rtcp-xr-burst-gap-loss-01] (17 pages) - RTCP XR Report Block for Delay metric Reporting [draft-ietf-xrblock-rtcp-xr-delay-05] (15 pages) - RTCP XR Report Block for Discard metric Reporting [draft-ietf-xrblock-rtcp-xr-discard-02] (13 pages) - Real-time Transport Control Protocol (RTCP) Extension Report (XR) for Run Length Encoding of Discarded Packets [draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-03] (11 pages) - RTCP XR Report Block for Jitter Buffer Metric Reporting [draft-ietf-xrblock-rtcp-xr-jb-00] (13 pages) - Measurement Identity and information Reporting using SDES item and XR Block [draft-ietf-xrblock-rtcp-xr-meas-identity-06] (15 pages) - RTCP XR Report Block for Packet Delay Variation Metric Reporting [draft-ietf-xrblock-rtcp-xr-pdv-02] (17 pages) - RTCP XR Blocks for QoE Metric Reporting [draft-ietf-xrblock-rtcp-xr-qoe-01] (16 pages) No Requests for Comments Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Flemming Andreasen Miguel Angel Garcia Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo Mailing Lists: General Discussion: mmusic@ietf.org To Subscribe: mmusic-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/mmusic/ Description of Working Group: The Multiparty MUltimedia SessIon Control (MMUSIC) Working Group was chartered to develop protocols to support Internet teleconferencing and multimedia communications. These protocols are now reasonably mature, and many have received widespread deployments. The group has revised some of these protocols in the light of implementation experience and additional demands that have arisen from other WGs (such as AVT, SIP, and SIPPING). It is focused on using and negotiating mechanisms such STUN and TURN in order to enable media sessions to traverse Network Address Translators NATs, and on new means to exchange SDP capabilities. Multimedia communications protocols use a common platform to express media and session descriptions: the Session Description Protocol, SDP. The many uses of SDP have led to (requests for) numerous extensions and have led to recognition of several flaws in the protocol design, some of which were addressed in the revision of SDP. In spite of these, it is widely deployed. The current aims of the working group include the following: - To support the establishment of multi-party multimedia sessions across NATs, MMUSIC will define an Internet Connectivity Establishment protocol (ICE). This will define several SDP extensions to work with NATs for media sessions carried over both UDP and TCP. - Various extensions to SDP will be pursued to remedy the most urgent of SDP's shortcomings. These will be limited and include adding support for limited but generic capability negotiations in SDP, defining the means to select QoS mechanisms to use for a particular media stream, enabling file transfer via the SDP Offer/Answer model, and support for media loopback. With the exception of these specific items, only extensions within the existing SDP framework will be done (e.g. registering new codecs and defining parameters for them, extending SDP to include new address families). - to maintain and revise the specification of the Real Time Streaming Protocol (RTSP), including fixes and clarifications based on implementation experience. The revised RTSP specification will be re-issued as a Proposed Standard RFC. We will also document how RTSP can be used in the presence of NAT boxes. The MMUSIC work items will be pursued in close coordination with other IETF WGs including AVT, SIP, SIPPING, SIMPLE, XCON, and BEHAVE, as well as others where appropriate such as NSIS. Goals and Milestones: Done - Conduct WG Last Call for SAP Internet-Draft Done - Submit a revised Internet Multimedia Conferencing Architecture I-D. Done - Submit a revised SIP I-D. Done - Submit SDP to the IESG for consideration as a Proposed Standard. Done - Submit SAP Internet-Draft to IESG for publication as an Experimental Protocol. Done - Conduct WG Last Call for RTSP Internet-Draft. Done - Submit Internet-Draft on Internet Multimedia Conferencing Architecture. Done - Submit RTSP to IESG for consideration as a Proposed Standard. Done - Conduct WG Last Call for SIP Internet-Draft. Done - Submit SIP Internet-Draft to IESG for consideration as a Proposed Standard. Done - Conduct WG Last Call for SAP Security Internet-Draft. Done - Conduct second WG Last Call for SAP. Done - Submit SAP Internet-Draft to IESG for consideration as a Proposed Standard. Done - Submit SAP Security Internet-Draft to IESG for consideration as a Proposed Standard. Done - Submit IPv6 Extensions to SDP for Proposed Standard Done - Submit SIP's offer/answer use of SDP for Proposed Standard Done - Submit SDP4NAT for Proposed Standard (Informational?) Done - Submit SDP source filter extensions for Proposed Standard Done - Submit draft on SDPng motivations, comparisons with current SDP capabilities. Request charter review on SDPng work from IAB and IESG. Done - Submit SDP security extension for Proposed Standard Done - Submit IMG requirements and framework for Informational Done - Submit revised SDP spec for Proposed (or Draft) Standard Done - Submit SDP Offer/Answer examples for Informational Done - Review work on IMGs and update charter accordingly Done - Submit SDP connection-oriented media draft for Proposed Standard Done - Submit SDPng transition scenarios for Informational Done - Submit ICE draft for Proposed Standard Done - Submit updated SDP Offer/Answer examples draft for Informational Done - Submit SDP Offer/Answer exchange for enabling file transfer as a Proposed Standard Done - Submit QoS Mechanism Selection in SDP as a Proposed Standard Done - Submit SDP Capability Negotiations to Proposed Standard Done - Submit Source-Specific Media Attributes in SDP as Proposed Standard Done - Submit Connectivity Preconditions for SDP Media Streams as Proposed Standard Done - Signaling media decoding dependency in SDP Done - Submit revised RFC for Grouping of Media Lines in SDP Done - Submit an update to the FEC Grouping Semantics in SDP as Proposed Standard Done - Submit ICE Options Registry as a Proposed Standard Done - Submit SDP Image Attribute as Proposed Standard Done - Submit ICE-TCP draft as a Proposed Standard Done - Submit IANA registration of 'image' media type in SDP as Proposed Standard May 2012 - Submit SDP extensions for Media Loopback for Proposed Standard May 2012 - Submit SDP extensions for Media Capability Negotiations as Proposed Standard Jun 2012 - Submit SDP extensions for audio media streams over Circuit- Switched bearers as Proposed Standard Jun 2012 - Submit revised RTSP spec for Proposed or Draft Standard (as appropriate) Jun 2012 - Submit SCTP-Based Media Transport in SDP as Proposed Standard Jun 2012 - Submit SDP extensions for Media Titles and Media Bandwidth Capability Negotiations as Proposed Standard Jul 2012 - Submit revised SDP specification to IETF for Proposed Standard Jul 2012 - Submit Offer/Answer Examples as Informational Aug 2012 - Submit RTSP NAT considerations draft as a Proposed Standard Aug 2012 - Submit SDP extensions to classify traffic as Proposed Standard Sep 2012 - Submit Considerations for using SDP offer/answer with middleboxes for BCP Sep 2012 - Submit SDP extension to signal parallax information as Proposed Standard Sep 2012 - Submit SDP extension to signal stereoscopic 3D video as Proposed Standard Nov 2012 - Submit SDP extensions to negotiate multiplexed media streams as Proposed Standard Internet-Drafts: - Managing Shared Ephemeral Teleconferencing State: Policy and Mechanism [draft-ietf-mmusic-agree-00] (29 pages) - The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework [draft-ietf-mmusic-anat-02] (8 pages) - Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) [draft-ietf-mmusic-comedia-tls-06] (19 pages) - The Internet Multimedia Conferencing Architecture [draft-ietf-mmusic-confarch-03] (28 pages) - Connection-Establishment Preconditions in the Session Initiation Protocol (SIP) [draft-ietf-mmusic-connection-precon-01] (8 pages) - Connectivity Preconditions for Session Description Protocol (SDP) Media Streams [draft-ietf-mmusic-connectivity-precon-07] (18 pages) - Signaling Media Decoding Dependency in the Session Description Protocol (SDP) [draft-ietf-mmusic-decoding-dependency-08] (18 pages) - Forward Error Correction Grouping Semantics in Session Description Protocol [draft-ietf-mmusic-fec-grouping-05] (7 pages) - Grouping of Media Lines in the Session Description Protocol (SDP) [draft-ietf-mmusic-fid-06] (18 pages) - A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer [draft-ietf-mmusic-file-transfer-mech-11] (49 pages) - Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols [draft-ietf-mmusic-ice-19] (119 pages) - IANA Registry for Interactive Connectivity Establishment (ICE) Options [draft-ietf-mmusic-ice-options-registry-02] (5 pages) - TCP Candidates with Interactive Connectivity Establishment (ICE) [draft-ietf-mmusic-ice-tcp-16] (30 pages) - Negotiation of Generic Image Attributes in the Session Description Protocol (SDP) [draft-ietf-mmusic-image-attributes-11] (26 pages) - A Framework for the Usage of Internet Media Guides (IMGs) [draft-ietf-mmusic-img-framework-09] (23 pages) - Requirements for Internet Media Guides (IMGs) [draft-ietf-mmusic-img-req-08] (23 pages) - Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) [draft-ietf-mmusic-kmgmt-ext-15] (28 pages) - An Mbus Profile for Call Control [draft-ietf-mmusic-mbus-call-control-00] (37 pages) - The Message Bus: Guidelines for Application Profile Writers [draft-ietf-mmusic-mbus-guidelines-00] (49 pages) - Requirements for Local Conference Control [draft-ietf-mmusic-mbus-req-00] (10 pages) - A Message Bus for Local Coordination [draft-ietf-mmusic-mbus-transport-06] (46 pages) - An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback [draft-ietf-mmusic-media-loopback-18] (34 pages) - Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path [draft-ietf-mmusic-media-path-middleboxes-04] (22 pages) - Short term NAT requirements for UDP based peer-to-peer applications [draft-ietf-mmusic-natreq4udp-00] (6 pages) - Session Description Protocol (SDP) Offer/Answer Examples [draft-ietf-mmusic-offer-answer-examples-06] (25 pages) - SDP attribute to signal parallax [draft-ietf-mmusic-parallax-attribute-00] (15 pages) - Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP) [draft-ietf-mmusic-qos-identification-03] (10 pages) - Mapping of Media Streams to Resource Reservation Flows [draft-ietf-mmusic-reservation-flows-01] (7 pages) - Real Time Streaming Protocol 2.0 (RTSP) [draft-ietf-mmusic-rfc2326bis-29] (300 pages) - The Session Description Protocol (SDP) Grouping Framework [draft-ietf-mmusic-rfc3388bis-04] (22 pages) - SDP: Session Description Protocol [draft-ietf-mmusic-rfc4566bis-05] (49 pages) - Forward Error Correction Grouping Semantics in the Session Description Protocol [draft-ietf-mmusic-rfc4756bis-10] (14 pages) - Real Time Streaming Protocol (RTSP) [draft-ietf-mmusic-rtsp-08] (98 pages) - RTSP Announce Method [draft-ietf-mmusic-rtsp-announce-01] (0 pages) - A Network Address Translator (NAT) Traversal mechanism for media controlled by Real-Time Streaming Protocol (RTSP) [draft-ietf-mmusic-rtsp-nat-12] (30 pages) - The Evaluation of Different Network Addres Translator (NAT) Traversal Techniques for Media Controlled by Real-time Streaming Protocol (RTSP) [draft-ietf-mmusic-rtsp-nat-evaluation-05] (38 pages) - SAP: Session Announcement Protocol [draft-ietf-mmusic-sap-00] (14 pages) - SAP Security Using Public Key Algorithms [draft-ietf-mmusic-sap-sec-04] (18 pages) - Session Announcement Protocol [draft-ietf-mmusic-sap-v2-06] (15 pages) - Simple Conference Control Protocol [draft-ietf-mmusic-sccp-01] (24 pages) - Simple Conference Invitation Protocol [draft-ietf-mmusic-scip-00] (18 pages) - Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP) [draft-ietf-mmusic-sctp-sdp-01] (10 pages) - Session Description Protocol (SDP) Security Descriptions for Media Streams [draft-ietf-mmusic-sdescriptions-12] (37 pages) - SDP: Session Description Protocol [draft-ietf-mmusic-sdp-06] (42 pages) - Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections [draft-ietf-mmusic-sdp-atm-05] (101 pages) - Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams [draft-ietf-mmusic-sdp-bfcp-03] (14 pages) - Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers [draft-ietf-mmusic-sdp-bundle-negotiation-00] (11 pages) - A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-bwparam-06] (21 pages) - Session Description Protocol (SDP) Capability Negotiation [draft-ietf-mmusic-sdp-capability-negotiation-13] (89 pages) - SDP Capability Negotiation: Requirements and Review of Existing Work [draft-ietf-mmusic-sdp-capability-negotiation-reqts-01] (23 pages) - TCP-Based Media Transport in the Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-comedia-10] (15 pages) - Session Description Protocol (SDP) Extension For Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN) [draft-ietf-mmusic-sdp-cs-11] (35 pages) - Describing session directories in SDP [draft-ietf-mmusic-sdp-directory-type-02] (0 pages) - Session Description Protocol (SDP) Indicators for Datagram Transport Layer Security (DTLS) [draft-ietf-mmusic-sdp-dtls-00] (8 pages) - Implementation Status Of SDP [draft-ietf-mmusic-sdp-implem-00] (18 pages) - Support for IPv6 in Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-ipv6-03] (5 pages) - SDP Media Capabilities Negotiation [draft-ietf-mmusic-sdp-media-capabilities-13] (57 pages) - The Session Description Protocol (SDP) Content Attribute [draft-ietf-mmusic-sdp-media-content-06] (12 pages) - The Session Description Protocol (SDP) Label Attribute [draft-ietf-mmusic-sdp-media-label-01] (7 pages) - Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-misc-cap-00] (17 pages) - Miscellanoues Capabilities Negotiation in the Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-miscellaneous-caps-00] (19 pages) - SDP: Session Description Protocol [draft-ietf-mmusic-sdp-new-26] (49 pages) - An Offer/Answer Model with Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-offer-answer-02] (25 pages) - Establishing QoS and Security Preconditions for SDP Sessions [draft-ietf-mmusic-sdp-qos-00] (13 pages) - Source-Specific Media Attributes in the Session Description Protocol (SDP) [draft-ietf-mmusic-sdp-source-attributes-02] (19 pages) - Session Description Protocol (SDP) Source Filters [draft-ietf-mmusic-sdp-srcfilter-10] (0 pages) - SDP Extensions for Fax over IP Using T.38 [draft-ietf-mmusic-sdp-t38-00] (4 pages) - TCP-Based Media Transport in SDP [draft-ietf-mmusic-sdp-tcpmedia-00] (9 pages) - Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP) [draft-ietf-mmusic-sdp4nat-05] (7 pages) - Session Description and Capability Negotiation [draft-ietf-mmusic-sdpng-08] (61 pages) - Requirements for Session Description and Capability Negotiation [draft-ietf-mmusic-sdpng-req-01] (24 pages) - SDPng Transition [draft-ietf-mmusic-sdpng-trans-04] (15 pages) - Security Preconditions for Session Description Protocol (SDP) Media Streams [draft-ietf-mmusic-securityprecondition-04] (16 pages) - Signal 3D format [draft-ietf-mmusic-signal-3d-format-00] (27 pages) - SIP: Session Initiation Protocol [draft-ietf-mmusic-sip-12] (149 pages) - Reliability of Provisional Responses in SIP [draft-ietf-mmusic-sip-100rel-01] (12 pages) - SIP Caller Preferences and Callee Capabilities [draft-ietf-mmusic-sip-caller-00] (16 pages) - SIP Call Control Services [draft-ietf-mmusic-sip-cc-01] (34 pages) - The SIP INFO Method [draft-ietf-mmusic-sip-info-method-01] (6 pages) - The SIP ISUP/MIME type [draft-ietf-mmusic-sip-isup-mime-00] (4 pages) - The multipart/sip-id media type [draft-ietf-mmusic-sip-multipart-00] (4 pages) - SIP Security Using Public Key Algorithms [draft-ietf-mmusic-sip-sec-00] (24 pages) - SIP Session Timer [draft-ietf-mmusic-sip-session-timer-02] (12 pages) - SIP URL Scheme [draft-ietf-mmusic-sip-url-00] (3 pages) - A real-time stream control protocol (RTSP') [draft-ietf-mmusic-stream-00] (25 pages) - The Session Description Protocol (SDP) 'trafficclass' Attribute [draft-ietf-mmusic-traffic-class-for-sdp-01] (21 pages) Requests for Comments: RFC2326: Real Time Streaming Protocol (RTSP) (98 pages) RFC2327: SDP: Session Description Protocol (42 pages) * Obsoletes RFC4566 * Updates RFC3266 RFC2543: SIP: Session Initiation Protocol (149 pages) * Obsoletes RFC3261 * Obsoletes RFC3262 * Obsoletes RFC3263 * Obsoletes RFC3264 * Obsoletes RFC3265 RFC2974: Session Announcement Protocol (15 pages) RFC3108: Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections (101 pages) RFC3259: A Message Bus for Local Coordination (46 pages) RFC3264: An Offer/Answer Model with Session Description Protocol (SDP) (25 pages) * Obsoletes RFC2543 * Updates RFC6157 RFC3266: Support for IPv6 in Session Description Protocol (SDP) (5 pages) * Updates RFC2327 * Obsoletes RFC4566 RFC3388: Grouping of Media Lines in the Session Description Protocol (SDP) (18 pages) * Obsoletes RFC5888 RFC3524: Mapping of Media Streams to Resource Reservation Flows (7 pages) RFC3605: Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP) (7 pages) RFC3890: A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP) (21 pages) * Replaces DRAFT-WESTERLUND-MMUSIC-SDP-BWPARAM RFC4091: The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework (8 pages) * Obsoletes RFC5245 RFC4145: TCP-Based Media Transport in the Session Description Protocol (SDP) (15 pages) * Updates RFC4572 RFC4317: Session Description Protocol (SDP) Offer/Answer Examples (25 pages) RFC4435: A Framework for the Usage of Internet Media Guides (IMGs) (23 pages) RFC4473: Requirements for Internet Media Guides (IMGs) (23 pages) RFC4566: SDP: Session Description Protocol (49 pages) * Obsoletes RFC2327 * Obsoletes RFC3266 RFC4567: Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) (28 pages) RFC4568: Session Description Protocol (SDP) Security Descriptions for Media Streams (37 pages) RFC4570: Session Description Protocol (SDP) Source Filters (0 pages) RFC4572: Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) (19 pages) * Updates RFC4145 RFC4574: The Session Description Protocol (SDP) Label Attribute (7 pages) RFC4583: Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams (14 pages) RFC4756: Forward Error Correction Grouping Semantics in Session Description Protocol (7 pages) * Obsoletes RFC5956 RFC4796: The Session Description Protocol (SDP) Content Attribute (12 pages) RFC5027: Security Preconditions for Session Description Protocol (SDP) Media Streams (16 pages) * Replaces DRAFT-ANDREASEN-MMUSIC-SECURITYPRECONDITION * Updates RFC3312 RFC5245: Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols (119 pages) * Obsoletes RFC4091 * Obsoletes RFC4092 * Updates RFC6336 RFC5432: Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP) (10 pages) RFC5547: A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer (49 pages) * Replaces DRAFT-GARCIA-MMUSIC-FILE-TRANSFER-MECH RFC5576: Source-Specific Media Attributes in the Session Description Protocol (SDP) (19 pages) * Replaces DRAFT-LENNOX-MMUSIC-SDP-SOURCE-ATTRIBUTES RFC5583: Signaling Media Decoding Dependency in the Session Description Protocol (SDP) (18 pages) RFC5888: The Session Description Protocol (SDP) Grouping Framework (22 pages) * Obsoletes RFC3388 RFC5898: Connectivity Preconditions for Session Description Protocol (SDP) Media Streams (18 pages) RFC5939: Session Description Protocol (SDP) Capability Negotiation (89 pages) * Replaces DRAFT-ANDREASEN-MMUSIC-SDP-CAPABILITY-NEGOTIATION RFC5956: Forward Error Correction Grouping Semantics in the Session Description Protocol (14 pages) * Replaces DRAFT-BEGEN-MMUSIC-RFC4756BIS * Obsoletes RFC4756 RFC6236: Negotiation of Generic Image Attributes in the Session Description Protocol (SDP) (26 pages) * Replaces DRAFT-JOHANSSON-MMUSIC-IMAGE-ATTRIBUTES RFC6336: IANA Registry for Interactive Connectivity Establishment (ICE) Options (5 pages) * Replaces DRAFT-WESTERLUND-MMUSIC-ICE-OPTIONS-REGISTRY * Updates RFC5245 RFC6544: TCP Candidates with Interactive Connectivity Establishment (ICE) (30 pages) Peer-to-Peer Session Initiation Protocol (p2psip) ------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chair: Brian Rosen Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo Mailing Lists: General Discussion: p2psip@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/p2psip Archive: http://www.ietf.org/mail-archive/web/p2psip Description of Working Group: The Peer-to-Peer (P2P) Session Initiation Protocol working group (P2PSIP WG) is chartered to develop protocols and mechanisms for the use of the Session Initiation Protocol (SIP) in settings where the service of establishing and managing sessions is principally handled by a collection of intelligent endpoints, rather than centralized servers as in SIP as currently deployed. A number of cases where such an architecture is desirable have been documented. The work focuses on collections of nodes called "P2PSIP peers" and "P2PSIP clients". P2PSIP peers manifest a distributed namespace in which overlay users are identified and provides mechanisms for locating users or resources within the P2PSIP overlay. P2PSIP clients differ from P2PSIP peers primarily in that they do not store information in the overlay, but only use it to locate users and resources. P2PSIP clients and peers use the resolution services of the peers as an alternative to the SIP discovery process of RFC 3263. In this way, P2PSIP offers an alternative mechanism for determining the correct destination for SIP requests. The working group's initial charter scope will be to produce protocols to enable this alternate mechanism for RFC 3263 functionality. Session management, messaging, and presence functions are performed using conventional SIP. This group's primary tasks are to produce: 1. An overview document explaining concepts, terminology, rationale, and illustrative use cases for the remaining work. 2. A proposed standard defining a P2PSIP Peer Protocol. This protocol is used between P2PSIP overlay peers, some of which may be behind NATs. This protocol will define how the P2PSIP peers collectively provide for user and resource location in a SIP environment with no or minimal centralized servers. This protocol may or may not be syntactically based on SIP, a decision to be made by the WG. The group will identify and require one base P2P algorithm (likely a particular Distributed Hash Table (DHT) algorithm), while allowing for additional optional algorithms in the future. 3. Optionally, a proposed standard defining a P2PSIP Client Protocol for use by P2PSIP clients, some of which may be behind NATs. This protocol will define how the P2PSIP clients query and/or modify, the resource location information of the overlay. While clearly a logical subset of the P2PSIP Protocol, the WG will determine if the P2PSIP Client Protocol is a syntactic subset of the P2PSIP Peer Protocol, and whether the P2PSIP Client Protocol builds on the SIP protocol. 4. A usage document. This document will address how the protocols defined above, along with existing IETF protocols, can be used to produce systems to locate a P2PSIP peer or client, identify appropriate resources to facilitate communications (for example media relays), and establish communications between the users of these P2PSIP peers or clients, without relying on centralized servers. Additionally, the document will explain how P2PSIP and conventional SIP entities can interoperate. The initial work will assume the existence of some enrollment process that provides a unique user name, credentials, and an initial set of bootstrap nodes if that is required by the protocols. Developing a non-centralized enrollment process is not in scope. The work planned for the P2PSIP working group is distinct from, but requires close participation with other IETF WGs, particularly SIP, SIPPING, SIMPLE, BEHAVE and MMUSIC. The group cannot modify the baseline SIP behavior, define a new version of SIP, or attempt to produce a parallel protocol for session establishment. If the group determines that any capabilities requiring an extension to SIP are needed, the group will seek to define such extensions within the SIP working group using the SIP change process (RFC 3427). Similarly, existing tools developed in the BEHAVE and MMUSIC groups will be used for NAT traversal, with extensions or changes desired to support P2PSIP presented to the BEHAVE or MMUSIC working groups. The working group will assume that NATs and firewalls exist in the Internet, and will ensure that the protocols produced work in their presence as much as possible. Similarly, the WG will avoid making protocol design decisions that would preclude the creation of anonymous communications systems using techniques such as onion routing to conceal the IP addresses of P2PSIP peers. P2P networks pose unique security and privacy problems because an adversarial relationship may exist between nodes. Attackers can mount both integrity attacks on the stored data and denial of service attacks on the system as a whole. The WG will not attempt a solution to these issues for P2P networks in general. In order to simplify this problem, the WG will assume that all participants in the system are issued unique identities and credentials through some mechanism not in the scope of this working group, such as a centralized server, and that the data stored in the network will be authenticated by the storing entity in order to address the integrity issue and to some extent alleviate the DoS issue. Because signaling dialogs may be routed through intermediate P2PSIP peers which may be untrusted by the originating SIP UA, the WG will address the issue of establishing authenticated signaling dialogs through such untrusted relays. P2P systems also have privacy issues because the nodes that store data objects and route requests are unrelated to the clients which want to communicate. In the design of the P2PSIP protocol, the WG will assess these privacy issues and determine to what extent they need to be alleviated. The protocol document will contain a complete description of the privacy properties of P2PSIP. The following topics are excluded from the Working Group's scope: 1. Issues specific to applications other than locating users and resources for SIP-based communications and presence. 2. Solving "research" type questions related to P2PSIP or P2P in general. The WG will instead forward such work to the IRTF P2PRG or other RG as appropriate. Examples include fully distributed schemes for assuring unique user identities and the development of P2P-based replacements for DNS. 3. Locating resources based on something other than URIs. In other words, arbitrary search of attributes is out of scope, but locating resources based on their URIs is in scope. Using URIs need not imply using the DNS or having a record in the DNS for the URI. 4. Multicast and dynamic DNS based approaches as the core lookup mechanism for locating users and resources. Approaches based on these technologies may be reasonable ways to solve similar problems but that is not the focus of this WG. These techniques may be in-scope for locating bootstrap peers/servers or for interoperation with conventional SIP. Goals and Milestones: Done - WGLC of P2PSIP Peer Protocol document Apr 2011 - Submit P2PSIP Peer Protocol document to the IESG (PS) May 2011 - WGLC of P2PSIP Diagnostics document Jun 2011 - WGLC of P2PSIP Concepts document Jun 2011 - WGLC of P2PSIP SIP Usage document Jul 2011 - Submit P2PSIP Diagnostics document to the IESG (PS) Aug 2011 - WGLC of P2PSIP Self-Tuning document Aug 2011 - WGLC of P2PSIP Service Discovery document Aug 2011 - Submit P2PSIP SIP Usage document to the IESG (PS) Aug 2011 - Submit P2PSIP Concepts document to the IESG (Informational) Sep 2011 - WGLC of P2PSIP Direct Response Draft Sep 2011 - WGLC of P2PSIP Relay Response Draft Oct 2011 - Submit P2PSIP Self-Tuning document to the IESG (PS) Oct 2011 - Submit P2PSIP Service Discovery document to the IESG (PS) Internet-Drafts: - REsource LOcation And Discovery (RELOAD) Base Protocol [draft-ietf-p2psip-base-21] (166 pages) - Concepts and Terminology for Peer to Peer SIP [draft-ietf-p2psip-concepts-04] (20 pages) - P2PSIP Overlay Diagnostics [draft-ietf-p2psip-diagnostics-08] (29 pages) - An extension to RELOAD to support Direct Response Routing [draft-ietf-p2psip-drr-01] (18 pages) - REsource LOcation And Discovery (RELOAD) [draft-ietf-p2psip-reload-00] (130 pages) - An extension to RELOAD to support Relay Peer Routing [draft-ietf-p2psip-rpr-01] (15 pages) - A Self-tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD) [draft-ietf-p2psip-self-tuning-05] (21 pages) - Service Discovery Usage for REsource LOcation And Discovery (RELOAD) [draft-ietf-p2psip-service-discovery-05] (15 pages) - A SIP Usage for RELOAD [draft-ietf-p2psip-sip-07] (13 pages) No Requests for Comments Real-Time Communication in WEB-browsers (rtcweb) ------------------------------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Cullen Jennings Ted Hardie Magnus Westerlund Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo Mailing Lists: General Discussion: rtcweb@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/rtcweb Archive: http://www.ietf.org/mail-archive/web/rtcweb/ Description of Working Group: There are a number of proprietary implementations that provide direct interactive rich communication using audio, video, collaboration, games, etc. between two peers' web-browsers. These are not interoperable, as they require non-standard extensions or plugins to work. There is a desire to standardize the basis for such communication so that interoperable communication can be established between any compatible browsers. The goal is to enable innovation on top of a set of basic components. One core component is to enable real-time media like audio and video, a second is to enable data transfer directly between clients. This work will be done in collaboration with the W3C. The IETF WG will produce architecture and requirements for selection and profiling of the on the wire protocols. The architecture needs to be coordinated with W3C. The IETF WG work will identify state information and events that need to be exposed in the APIs as input to W3C. The W3C will be responsible for defining APIs to ensure that application developers can control the components. We will reach out to the developer community for consultation and early feedback on implementation. The security and privacy goals and requirements will be developed by the WG. The security model needs to be coordinated with the W3C. The work will also consider where support for extensibility is needed. RTP functionalities, media formats, security algorithms are example of things that commonly need extensions, additions or replacement, and thus some support for negotiation between clients is required. The WG will perform the following work: 1. Define the communication model in detail, including how session management is to occur within the model. 2. Define a security model that describes the security and privacy goals and specifies the security protocol mechanisms necessary to achieve those goals. 3. Define the solution - protocols and API requirements - for firewall and NAT traversal. 4. Define which media functions and extensions shall be supported in the client and their usage for real-time media, including media adaptation to ensure congestion safe usage. 5. Define what functionalities in the solution, such as media codecs, security algorithms, etc., can be extended and how the extensibility mechanisms works. 6. Define a set of media formats that must or should be supported by a client to improve interoperability. 7. Define how non media data is transported between clients in a secure and congestion safe way. 8. Provide W3C input for the APIs that comes from the communication model and the selected components and protocols that are part of the solution. 9. The group will consider options for interworking with legacy VoIP equipment. This work will be done primarily by using already defined protocols or functionalities. If there is identification of missing protocols or functionalities, such work can be requested to be done in another working group with a suitable charter or by requests for chartering it in this WG or another WG. The following topics will be out of scope for the initial phase of the WG: RTSP, RSVP, NSIS, Location services, Resource Priority, and IM & Presence specific features. The products of the working group will support security and keying as required by BCP 61 and be defined for IPv4, IPv6, and dual stack deployments. The Working Group will consider the possibility of defining a browser component that implements an existing session negotiation and management protocol. The working group will follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to use in web browsers. Goals and Milestones: Oct 2011 - Send Use Cases (draft-ietf-rtcweb-use-cases-and-requirements), Overview (draft-ietf-rtcweb-overview), Security and Privacy Documents (I-D) to W3C Dec 2011 - Send Use Cases (draft-ietf-rtcweb-use-cases-and-requirements) document to IESG for publication as Informational Apr 2012 - Send W3C input on what requirements the current solution has on API(s) May 2012 - Send Overview (draft-ietf-rtcweb-overview), Security and Privacy Model documents to IESG for publication as Informational May 2012 - Send Signalling and Negotiation, and NAT Traversal to IESG for publication as Proposed Standard Jun 2012 - Send Media Transport, Media Processing, and Codecs to IESG for publication as Proposed Standard Jun 2012 - Send Datagram Transport for non-media data to IESG for publication as Proposed Standard Internet-Drafts: - Overview: Real Time Protocols for Brower-based Applications [draft-alvestrand-rtcweb-overview-01] (14 pages) - Web Real-Time Communication Use-cases and Requirements [draft-holmberg-rtcweb-ucreqs-01] (11 pages) - RTCWeb Datagram Connection [draft-ietf-rtcweb-data-channel-00] (12 pages) - Javascript Session Establishment Protocol [draft-ietf-rtcweb-jsep-00] (27 pages) - Overview: Real Time Protocols for Brower-based Applications [draft-ietf-rtcweb-overview-03] (20 pages) - Web Real-Time Communication (WebRTC): Media Transport and Use of RTP [draft-ietf-rtcweb-rtp-usage-02] (27 pages) - Security Considerations for RTC-Web [draft-ietf-rtcweb-security-02] (21 pages) - RTCWEB Security Architecture [draft-ietf-rtcweb-security-arch-01] (20 pages) - Web Real-Time Communication Use-cases and Requirements [draft-ietf-rtcweb-use-cases-and-requirements-07] (24 pages) No Requests for Comments SIP Common Log Format (sipclf) ------------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chair: Peter Musgrave Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Robert Sparks Tech Advisor: Chris Lonvick Mailing Lists: General Discussion: sip-clf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sip-clf Archive: http://www.ietf.org/mail-archive/web/sip-clf/ Description of Working Group: The SIP Common Log Format (SIPCLF) working group is chartered to define a standard logging format for systems processing SIP messages. Well-known web servers such as Apache and web proxies like Squid support event logging using a common log format. The logs produced using these de-facto standard formats are invaluable to system administrators for trouble-shooting a server and tool writers to craft tools that mine the log files to produce reports and trends and to search for a certain message or messages, a transaction or a related set of transactions. Furthermore, these log records can also be used to train anomaly detection systems and feed events into a security event management system. The Session Initiation Protocol does not have a common log format. Diverse elements provide distinct log formats making it complex to produce tools to analyze them. The SIPCLF working group will produce a format suitable for logging from any SIP element. The working group will take into account * the need to search, merge, and summarize the log records from one or more possibly diverse elements. * the need to correlate messages from multiple elements related to a given request (that may fork) or a given dialog. The format will take SIP's extensibility into consideration, providing a way to represent SIP message components that are defined in the future. The format will anticipate being used both for off-line analysis and on-line real-time processing applications. The working group will consider the need for efficient creation of records and the need for efficient processing of the records. The working group will identify the fields to appear in a log record and provide one or more formats for encoding those fields. The working group is not pre-constrained to producing either a bit-field oriented or text-oriented format, and may choose to provide both. If the group chooses to specify both, it must be possible to mechanically translate between the formats without loss of information. Specifying the mechanics of exchanging, transporting, and storing SIP Common Log Format records is explicitly out of scope. However, the working group will document as part of the definition of the log record format: * operational guidance considering log file management addressing size, rollover, aggregation and filtering. * guidance for correlating SIP CLF records with events reported via other log mechanisms such as syslog or SNMP notifications. * security guidance for storage, access, and transporting SIP CLF log records, addressing information privacy The group will generate: - A problem statement enunciating the motivation, and use cases for a SIP Common Log Format. This analysis will identify the required minimal information that must appear in any record. - A specification of the SIP Common Log Format record Goals and Milestones: Dec 2009 - Problem statement, motivation, and use cases WGLC Jan 2010 - Problem statement, motivation, and use cases to IESG (Informational) Mar 2010 - SIP Common Log Format specification WGLC Apr 2010 - SIP Common Log Format specification to IESG (PS) Internet-Drafts: - Format for the Session Initiation Protocol (SIP) Common Log Format (CLF) [draft-ietf-sipclf-format-06] (28 pages) - The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Data Model [draft-ietf-sipclf-problem-statement-11] (37 pages) No Requests for Comments SIP Overload Control (soc) -------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Salvatore Loreto Volker Hilt Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: General Discussion: sip-overload@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sip-overload Archive: http://www.ietf.org/mail-archive/web/sip-overload/ Description of Working Group: As with any network element, a Session Initiation Protocol (SIP) server can suffer from overload when the number of SIP messages it receives exceeds the number of messages it can process. Overload is said to occur when a SIP server does not have sufficient resources to complete the processing of all incoming SIP messages within the required time. These resources can include CPU, memory, network bandwidth, input/ output, or disk resources. Overload can pose a serious problem for a network of SIP servers. During periods of overload, a network of SIP servers can be significantly degraded with regard to "goodput" (effective application throughput, not counting the overhead of retransmission and redundant data). In fact, overload may lead to a situation in which the goodput drops down to zero or a small fraction of the original processing capacity. The objective of a SIP overload control mechanism is to enable SIP servers to operate close to their capacity limit during times of overload. The SIP protocol provides a limited mechanism for overload control through its 503 (Service Unavailable) response code and the Retry-After header. However, this mechanism cannot fully prevent overload of a SIP server and it cannot prevent congestion collapse. In fact, its on/off behavior may cause traffic to oscillate and shift between SIP servers and thereby worsen an overload condition. A detailed discussion of the SIP overload problem, the problems with the 503 (Service Unavailable) response code and the Retry-After header and the requirements for a SIP overload control mechanism can be found in RFC5390. The objective of the working group is to develop mechanisms for SIP overload control. The problem domain of SIP overload control can be split into overload control between a user agent and a SIP server and overload control between SIP servers. Any specification developed by the working group needs to clearly specify its scope. A specification also needs to clearly state any limitations, in performance or otherwise, the specified overload control mechanism may have. In particular, the working group shall carefully define the deployment considerations for the effective operation of the specified mechanisms and discuss, for example, when a mechanism requires coordinated deployment and operation (if all servers need to deploy the same mechanism, certain configuration values need to be identical on all servers, etc), when a mechanism can become less effective or ineffective under some conditions, or especially if there are cases when a mechanism can reduce goodput compared to no overload protection. The intent of these considerations is to allow potential deployers to make the best use of these mechanism in their particular networks. The working group will consider two complementary approaches for handling overload situations: - The first mechanism aims at preventing overload in SIP servers by adjusting the incoming load to a level that is acceptable for this server. This mechanism uses implicit and/or explicit feedback to determine when an overload condition occurs in a SIP server and a reduction in load is required. - The second mechanism aims at preventing overload in SIP servers by distributing load control filters to SIP servers that throttle calls based on their source or destination domain, telephone number prefix or for a specific user. Such filters can be used, for example, to throttle calls to a hotline during a ticket-giveaway event. The working group will develop the following deliverables: 1. A document describing key design considerations for a SIP overload control mechanism. 2. A specification for an SIP overload control mechanism based on implicit/explicit feedback. 3. A specification for a SIP load filtering mechanism. Goals and Milestones: Done - Design Considerations to IESG for publication as Informational Nov 2011 - Specification for a SIP overload control mechanism based on implicit/explicit feedback to IESG for publication as Proposed Standard Feb 2012 - Specification for a SIP load filtering mechaism to IESG for publication as Proposed Standard Internet-Drafts: - A Session Initiation Protocol (SIP) Load Control Event Package [draft-ietf-soc-load-control-event-package-03] (35 pages) - Session Initiation Protocol (SIP) Overload Control [draft-ietf-soc-overload-control-08] (35 pages) - Design Considerations for Session Initiation Protocol (SIP) Overload Control [draft-ietf-soc-overload-design-08] (25 pages) - Session Initiation Protocol (SIP) Rate Control [draft-ietf-soc-overload-rate-control-01] (12 pages) Requests for Comments: RFC6357: Design Considerations for Session Initiation Protocol (SIP) Overload Control (25 pages) * Replaces DRAFT-HILT-SOC-OVERLOAD-DESIGN SIP Recording (siprec) ---------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Brian Rosen Andrew Hutton Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo Tech Advisor: Peter Saint-Andre Mailing Lists: General Discussion: siprec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/siprec Archive: http://www.ietf.org/mail-archive/web/siprec/ Description of Working Group: The Session Recording Protocol (SIPREC) working group is chartered to define a SIP-based protocol for controlling a session (media) recorder. Session recording is a critical requirement in many business communications environments such as call centers and financial trading floors. In some of these environments, all calls must be recorded for regulatory and compliance reasons. In others, calls may be recorded for quality control, business analytics, or consumer protection. Recording is typically done by sending a copy of the media to the recording devices. The working group will determine requirements and produce a specification for a protocol that will manage delivery of media from an end-point that originates media, or that has access to it, to a recording device. PBX and recording vendors today implement proprietary, incompatible mechanisms to facilitate recording. A standard protocol will reduce the complexity and cost of providing such recording services. The Session Recording problem presents certain unique requirements that are not addressed in the current SIP protocol specification. These include requirements such as the need for a distinction between the session that is being recorded versus the session that has been established for recording. Privacy and security of conversations are significant concerns. The working group will make sure that any protocol specified addresses these concerns and includes mechanisms to alert users to the fact that a session they are participating in is being recorded. The working group must take care that the session recording requirements and protocol does not conflict with the IETF statement on wiretapping contained in RFC 2804. The SIPREC Working Group will thoroughly identify use cases, provide example system architectures and deployment scenarios, and define requirements. The scope of the activity includes: * Recorder Control * Session metadata content and format * Security mechanisms, including transport and media encryption * Privacy concerns, including end-user notification * Negotiation of recording media streams The group will define these issues and rationalize with IETF standards and practices. This includes encryption, NAT traversal, operations and manageability, SIP-enabled firewalls, authorization, and security. The group will produce: * Updated Requirements, Use Cases, Architecture draft * Specification for Session Recording Protocol Goals and Milestones: Done - Use Cases and Requirements to IESG as Informational RFC Feb 2012 - Architecture to IESG as Informational RFC May 2012 - Submit Metadata model and format to IESG as Proposed Standard RFC Jun 2012 - Submit protocol draft to IESG as Proposed Standard RFC Internet-Drafts: - An Architecture for Media Recording using the Session Initiation Protocol [draft-ietf-siprec-architecture-04] (16 pages) - Session Initiation Protocol (SIP) Recording Metadata [draft-ietf-siprec-metadata-06] (48 pages) - Session Recording Protocol [draft-ietf-siprec-protocol-04] (34 pages) - Use Cases and Requirements for SIP-Based Media Recording (SIPREC) [draft-ietf-siprec-req-12] (16 pages) Requests for Comments: RFC6341: Use Cases and Requirements for SIP-Based Media Recording (SIPREC) (16 pages) * Replaces DRAFT-REHOR-SIPREC-REQ SIP for Instant Messaging and Presence Leveraging Extensions (simple) --------------------------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Hisham Khartabil Ben Campbell Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Robert Sparks Tech Advisor: Jon Peterson Mailing Lists: General Discussion: simple@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/simple Archive: http://www.ietf.org/mail-archive/web/simple/ Description of Working Group: This working group focuses on the application of the Session Initiation Protocol (SIP, RFC 3261) to the suite of services collectively known as instant messaging and presence (IMP). The IETF has committed to producing an interoperable standard for these services compliant to the requirements for IM outlined in RFC 2779 (including the security and privacy requirements there) and in the Common Profile for Instant Messaging (CPIM) specification, developed within the IMPP working group. As the most common services for which SIP is used share quite a bit in common with IMP, the adaptation of SIP to IMP seems a natural choice given the widespread support for (and relative maturity of) the SIP standard. This group has completed the majority of its primary goals and will focus on the remaining tasks documented here and concluding. Any proposed new work will require a recharter. The primary remaining work of this group will be to complete: 1. The MSRP proposed standard mechanism for transporting sessions of messages initiated using the SIP, compliant to the requirments of RFC 2779, CPIM and BCP 41. 2. The XCAP framework for representing and carrying configuration and policy information in SIMPLE systems. 3. A mechanism for representing partial changes (patches) to XML documents and extensions to the SIMPLE publication and notification mechanisms to convey these partial changes. 4. A mechanism for initiating and managing Instant Message group chat. 5. An annotated overview of the SIMPLE protocol definition documents. Any SIP extensions proposed in the course of this development will, after a last call process, be transferred to the SIP WG for consideration as formal SIP extensions. Any mechanisms created for managing Instant Message group chat are intended to provide a bridge to the conferencing protocols that will be defined in XCON. They will be limited in scope to address only simple Instant Message chat with nicknames and will not attempt to address complex conferencing concepts such as sidebars. Their design must anticipate operating in conjunction with the conferencing protocols XCON is working towards. The working group will work within the framework for presence and IM described in RFC 2778. The extensions it defines must also be compliant with the SIP processes for extensions. The group cannot modify baseline SIP behavior or define a new version of SIP for IM and presence. If the group determines that any capabilities requiring an extension to SIP are needed, the group will seek to define such extensions within the SIP working group, and then use them here. Goals and Milestones: Done - Submission of event package for presence to IESG for publication as Proposed Standard Done - Submission of watcher information drafts to IESG for publication as Proposed Standards Done - Submission of proposed event list mechanism to the SIP working group Done - Submission of requirements for event publishing to the IESG for publication as Proposed Standard Done - Submission of proposed mechanism for event publishing to the SIP working group Done - Submission of SIMPLE PIDF profile to IESG for publication as Proposed Standard Done - Submission of base XCAP draft to IESG for publication as Proposed Standard Done - Submission of Partial Notification mechanism to IESG for publication as a Proposed Standard Done - Submission of indication of instant message preparation using SIP to IESG for publication as a Proposed Standard Done - Submission of XCAP usage for manipulation of presence document content Done - Submission of XCAP usage for setting presence authorization to IESG for publication as Proposed Standard Done - Submission of Filtering mechanisms to IESG for publication as a Proposed Standard Done - Submission of instant messaging session draft to IESG for publication as a Proposed Standard Done - Submission of instant messaging session relay drafts to IESG for publication as Proposed Standards Done - Submission of proposed mechanisms meeting the advanced messaging requirements to the IESG or appropriate working group Done - Submission of XCAP event package to IESG or appropriate working group targeting publication as Proposed Standard Done - Submission of an Instant Message Disposition Notification mechanism to the IESG for publication as a Proposed Standard Done - Submission of additional connection models for MSRP to IESG for Proposed Standard Oct 2010 - Submission of proposed mechanisms for initiating and managing Instant Message group chat to the IESG for publication as Proposed Standard Nov 2010 - Submission of SIMPLE protocol annotated overview draft to IESG for publication as Informational Mar 2011 - Conclusion of SIMPLE Internet-Drafts: - Multi-party Chat Using the Message Session Relay Protocol (MSRP) [draft-ietf-simple-chat-14] (37 pages) - CIPID: Contact Information for the Presence Information Data Format [draft-ietf-simple-cipid-07] (12 pages) - An Extensible Markup Language (XML) Representation for Expressing Policy Capabilities [draft-ietf-simple-common-policy-caps-01] (14 pages) - CPIM Mapping of SIMPLE Presence and Instant Messaging [draft-ietf-simple-cpim-mapping-01] (13 pages) - Requirements for Manipulation of Data Elements in Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) Systems [draft-ietf-simple-data-req-03] (16 pages) - Functional Description of Event Notification Filtering [draft-ietf-simple-event-filter-funct-05] (31 pages) - A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists [draft-ietf-simple-event-list-07] (48 pages) - An Extensible Markup Language (XML)-Based Format for Event Notification Filtering [draft-ietf-simple-filter-format-05] (25 pages) - Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals [draft-ietf-simple-future-05] (15 pages) - SIP Extensions for Instant Messaging [draft-ietf-simple-im-01] (23 pages) - SDP Extensions for SIP Instant Message Sessions [draft-ietf-simple-im-sdp-00] (7 pages) - SIP Instant Message Sessions [draft-ietf-simple-im-session-00] (12 pages) - Instant Message Disposition Notification (IMDN) [draft-ietf-simple-imdn-10] (39 pages) - Presence Interdomain Scaling Analysis for SIP/SIMPLE [draft-ietf-simple-interdomain-scaling-analysis-08] (62 pages) - Models for Intra-Domain Presence and Instant Messaging (IM) Bridging [draft-ietf-simple-intradomain-federation-05] (49 pages) - Indication of Message Composition for Instant Messaging [draft-ietf-simple-iscomposing-03] (14 pages) - The Message Session Relay Protocol (MSRP) [draft-ietf-simple-message-sessions-19] (62 pages) - Advanced Instant Messaging Requirements for the Session Initiation Protocol (SIP) [draft-ietf-simple-messaging-requirements-00] (11 pages) - An Alternative Connection Model for the Message Session Relay Protocol (MSRP) [draft-ietf-simple-msrp-acm-10] (10 pages) - Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP) [draft-ietf-simple-msrp-cema-05] (21 pages) - Relay Extensions for the Message Sessions Relay Protocol (MSRP) [draft-ietf-simple-msrp-relays-10] (37 pages) - Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP) [draft-ietf-simple-msrp-sessmatch-13] (14 pages) - Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information [draft-ietf-simple-partial-notify-10] (16 pages) - Presence Information Data Format (PIDF) Extension for Partial Presence [draft-ietf-simple-partial-pidf-format-10] (17 pages) - Publication of Partial Presence Information [draft-ietf-simple-partial-publish-07] (16 pages) - Requirements for Presence Specific Event Notification Filtering [draft-ietf-simple-pres-filter-reqs-03] (13 pages) - An Extensible Markup Language (XML) Representation for Expressing Presence Policy Capabilities [draft-ietf-simple-pres-policy-caps-01] (10 pages) - Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF) [draft-ietf-simple-prescaps-ext-10] (30 pages) - A Presence Event Package for the Session Initiation Protocol (SIP) [draft-ietf-simple-presence-10] (27 pages) - A Data Model for Presence [draft-ietf-simple-presence-data-model-07] (35 pages) - Presence Authorization Rules [draft-ietf-simple-presence-rules-10] (30 pages) - A SIP Event Package for List Presence [draft-ietf-simple-presencelist-package-00] (17 pages) - Requirements for Efficient Delivery of Presence Information [draft-ietf-simple-presinfo-deliv-reg-01] (9 pages) - Session Initiation Protocol (SIP) Extension for Presence Publication [draft-ietf-simple-publish-01] (30 pages) - SIMPLE Presence Publication Requirements [draft-ietf-simple-publish-reqs-00] (11 pages) - RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) [draft-ietf-simple-rpid-10] (40 pages) - RPIDS -- Rich Presence Information Data Format for Presence Based on the Session Initiation Protocol (SIP) [draft-ietf-simple-rpids-01] (19 pages) - SIMPLE made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence using the Session Initiation Protocol (SIP) [draft-ietf-simple-simple-07] (15 pages) - Optimizing Federated Presence with View Sharing [draft-ietf-simple-view-sharing-02] (32 pages) - Requirements for Filtering of Watcher Information [draft-ietf-simple-winfo-filter-reqs-01] (10 pages) - An Extensible Markup Language (XML) Based Format for Watcher Information [draft-ietf-simple-winfo-format-04] (14 pages) - A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP) [draft-ietf-simple-winfo-package-05] (20 pages) - The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) [draft-ietf-simple-xcap-12] (72 pages) - Extensible Markup Language (XML) Configuration Access Protocol (XCAP)Usages for Setting Presence Authorization [draft-ietf-simple-xcap-auth-usage-01] (24 pages) - An Extensible Markup Language (XML) Document Format for Indicating a Change in XML Configuration Access Protocol (XCAP) Resources [draft-ietf-simple-xcap-diff-14] (26 pages) - Extensible Markup Language (XML) Formats for Representing Resource Lists [draft-ietf-simple-xcap-list-usage-05] (32 pages) - An Extensible Markup Language (XML) Document Format for Indicating Changes in XML Configuration Access Protocol (XCAP) Resources [draft-ietf-simple-xcap-package-03] (15 pages) - An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents [draft-ietf-simple-xcap-pidf-manipulation-usage-02] (11 pages) - An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors [draft-ietf-simple-xml-patch-ops-04] (42 pages) Requests for Comments: RFC3856: A Presence Event Package for the Session Initiation Protocol (SIP) (27 pages) RFC3857: A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP) (20 pages) RFC3858: An Extensible Markup Language (XML) Based Format for Watcher Information (14 pages) RFC3994: Indication of Message Composition for Instant Messaging (14 pages) RFC4479: A Data Model for Presence (35 pages) RFC4480: RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) (40 pages) * Replaces DRAFT-IETF-SIMPLE-RPIDS RFC4481: Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals (15 pages) RFC4482: CIPID: Contact Information for the Presence Information Data Format (12 pages) RFC4660: Functional Description of Event Notification Filtering (31 pages) RFC4661: An Extensible Markup Language (XML)-Based Format for Event Notification Filtering (25 pages) RFC4662: A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists (48 pages) * Replaces DRAFT-IETF-SIMPLE-PRESENCELIST-PACKAGE RFC4825: The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) (72 pages) RFC4826: Extensible Markup Language (XML) Formats for Representing Resource Lists (32 pages) RFC4827: An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents (11 pages) RFC4975: The Message Session Relay Protocol (MSRP) (62 pages) RFC4976: Relay Extensions for the Message Sessions Relay Protocol (MSRP) (37 pages) RFC5025: Presence Authorization Rules (30 pages) * Replaces DRAFT-IETF-SIMPLE-XCAP-AUTH-USAGE RFC5196: Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF) (30 pages) RFC5261: An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors (42 pages) RFC5262: Presence Information Data Format (PIDF) Extension for Partial Presence (17 pages) RFC5263: Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information (16 pages) RFC5264: Publication of Partial Presence Information (16 pages) RFC5438: Instant Message Disposition Notification (IMDN) (39 pages) * Replaces DRAFT-BURGER-SIMPLE-IMDN RFC5874: An Extensible Markup Language (XML) Document Format for Indicating a Change in XML Configuration Access Protocol (XCAP) Resources (26 pages) * Replaces DRAFT-IETF-SIMPLE-XCAP-PACKAGE RFC6135: An Alternative Connection Model for the Message Session Relay Protocol (MSRP) (10 pages) * Replaces DRAFT-BLAU-SIMPLE-MSRP-ACM Session Initiation Protocol Core (sipcore) ------------------------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Adam Roach Paul Kyzivat Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: General Discussion: sipcore@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sipcore Archive: http://www.ietf.org/mail-archive/web/sipcore/ Description of Working Group: The Session Initiation Protocol Core (SIPCore) working group is chartered to maintain and continue the development of the core SIP specifications, currently defined as proposed standard RFCs 3261, 3262, 3263, 3264, and 3265. The SIPCore working group will concentrate on specifications that update or replace the core SIP specifications. In this context, "update" means replacing or modifying protocol elements in the above listed RFCs in ways that would affect most or all implementations of those RFCs alone. Extensions to SIP that add new functionality that would not be required of all implementations will be done outside of this WG. The process and requirements for such extensions are documented in RFC 5727, "Change Process for the Session Initiation Protocol". Throughout its work, the group will strive to maintain the basic model and architecture defined by SIP. In particular: 1. Services and features are provided end-to-end whenever possible. 2. Reuse of existing Internet protocols and architectures and integrating with other Internet applications is crucial. The primary source of change requirements will be a) interoperability problems that stem from ambiguous, or under-defined specification, and b) requirements from other working groups in the RAI Area. Although in general the WG will not work on extensions to SIP, it may take on some previous work items from the SIP working group to allow for a smooth transition. The adoption of new items requires explicit agreement from the AD or rechartering. Goals and Milestones: Done - INFO package framework to IESG (PS) Done - Termination of early dialog prior to final response to IESG (PS) Done - Invite Transaction Handling Correction to IESG (PS) Done - Extension for use in etags in conditional notification to IESG (PS) Done - SIP Events throttling mechanism to IESG (PS) Done - Presence Scaling Requirements to IESG as Info Done - Mechanism for indicating support for keep-alives (PS) Done - Example security flows to IESG (Informational) Done - Location Conveyance with SIP to IESG (PS) Done - Error corrections and clarifications to RFC3265 to IESG (PS) May 2012 - WGLC on requirements for a mechanism to indicate proxy capabilities to both endpoints and other proxies in the path of a REGISTER transaction or a dialog-forming transaction. Jul 2012 - Delivering request-URI and parameters to UAS via proxy to IESG (PS) Dec 2012 - Mechanism to indicate proxy capabilities to both endpoints and other intermediaries in the path of a REGISTER transaction or dialog-forming transaction to IESG (PS) Apr 2013 - WebSockets transport definition for SIP to the IESG (proposed standard) Internet-Drafts: - Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog [draft-ietf-sipcore-199-06] (17 pages) - Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control [draft-ietf-sipcore-event-rate-control-09] (25 pages) - Session Initiation Protocol (SIP) INFO Method and Package Framework [draft-ietf-sipcore-info-events-10] (39 pages) - Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests [draft-ietf-sipcore-invfix-01] (20 pages) - Indication of Support for Keep-Alive [draft-ietf-sipcore-keep-12] (19 pages) - Location Conveyance for the Session Initiation Protocol [draft-ietf-sipcore-location-conveyance-09] (32 pages) - Scaling Requirements for Presence in SIP/SIMPLE [draft-ietf-sipcore-presence-scaling-requirements-02] (9 pages) - Indication of features supported by proxy [draft-ietf-sipcore-proxy-feature-02] (18 pages) - Requirements for indication of features supported by a SIP proxy [draft-ietf-sipcore-proxy-feature-reqs-03] (9 pages) - Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP) [draft-ietf-sipcore-reinvite-08] (25 pages) - SIP-Specific Event Notification [draft-ietf-sipcore-rfc3265bis-09] (53 pages) - An Extension to the Session Initiation Protocol (SIP) for Request History Information [draft-ietf-sipcore-rfc4244bis-08] (67 pages) - Example Call Flows Using Session Initiation Protocol (SIP) Security Mechanisms [draft-ietf-sipcore-sec-flows-09] (76 pages) - The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP) [draft-ietf-sipcore-sip-websocket-00] (21 pages) - An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification [draft-ietf-sipcore-subnot-etags-04] (25 pages) Requests for Comments: RFC5839: An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification (25 pages) * Replaces DRAFT-IETF-SIP-SUBNOT-ETAGS RFC6026: Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests (20 pages) * Replaces DRAFT-SPARKS-SIPCORE-INVFIX * Updates RFC3261 RFC6086: Session Initiation Protocol (SIP) INFO Method and Package Framework (39 pages) * Replaces DRAFT-IETF-SIP-INFO-EVENTS * Obsoletes RFC2976 RFC6141: Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP) (25 pages) * Replaces DRAFT-CAMARILLO-SIPCORE-REINVITE * Updates RFC3261 RFC6216: Example Call Flows Using Session Initiation Protocol (SIP) Security Mechanisms (76 pages) * Replaces DRAFT-IETF-SIP-SEC-FLOWS RFC6223: Indication of Support for Keep-Alive (19 pages) * Replaces DRAFT-HOLMBERG-SIPCORE-KEEP RFC6228: Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog (17 pages) * Replaces DRAFT-IETF-SIP-199 RFC6442: Location Conveyance for the Session Initiation Protocol (32 pages) * Replaces DRAFT-IETF-SIP-LOCATION-CONVEYANCE RFC6446: Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control (25 pages) * Replaces DRAFT-NIEMI-SIPPING-EVENT-THROTTLE * Updates RFC3265 Sip ALerting for User Devices (salud) ------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chair: Dale R. Worley Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo Mailing Lists: General Discussion: salud@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/salud Archive: http://www.ietf.org/mail-archive/web/salud/ Description of Working Group: The SALUD (Sip ALerting for User Devices) working group is chartered to define a new URN namespace that allows SIP to convey a particular alert indication using a name instead of a referenced URI. The Alert-Info URN namespace addresses issues encountered in current systems that use the Alert-Info header field. It is expected that this group will collaborate with the Applications area on the definition of the URN namespace. RFC 3261 allows a user agent server to provide a specific ringing tone, which can be played to the calling user, as a reference (e.g., an HTTP URI) in the Alert-Info header. In some situations, the calling user may not be able to understand the meaning of the ringing tone being played. For example, a user from a given country may not be familiar with the tone used to indicate call waiting in another country. Similarly, a hearing impaired person may prefer to get a visual call waiting indication instead of a call waiting tone. RFC 3261 also allows a user agent client to provide a reference to a specific alerting tone, which can be played to the called user (e.g., tones for emergency announcements sent over PBX systems or over the local telephone network). As in the previous examples, in some situations, the calling user may not be able to understand the meaning of the alerting tone being played. These issues can be resolved with a mechanism for user agents to exchange this type of alerting information in a semantic way. In this way, different user agents can use different renderings for the same semantics. For example, a user agent client instructed to inform its user about a call waiting service being provided can use the personalized tones that were previously configured by the user. Traditionally, SIP has used status codes to encode session state information (e.g., 180 Ringing). Status codes are used by SIP entities in an automatic fashion. The information this working group is concerned with is related to rendering and may not represent the state of the session. Additionally, the exchange of this information does not affect the way SIP entities process the session. That is why status codes are not an appropriate vehicle to encode this type of information. This working group will work on encoding this information in URNs. In addition to defining URNs that are associated to particular events (e.g., a call waiting service is being applied), this working group will also define URNs that describe the characteristics of the alerting to be applied (e.g., play a short tone followed by a long tone). There are a variety of non-interoperable URI conventions and proprietary Alert-Info header field parameters to provide this type of information today. A standardized set of Alert-Info URNs will increase SIP interoperability for this header field by replacing proprietary conventions. The group will produce a specification that: * describes the problem statement. * describes requirements and use cases. * defines an Alert-Info URN-scheme which allows to resolve the interoperability problems described in the use cases. * defines the specific Alert-Info URNs identifiers for some of the use cases above. The Alert-Info URN namespace must be open, so that additional Alert-Info URNs can be defined later if necessary. Goals and Milestones: Aug 2012 - Alert-Info URN specification to IESG (PS) Internet-Drafts: - Alert-Info URNs for the Session Initiation Protocol (SIP) [draft-ietf-salud-alert-info-urns-06] (37 pages) No Requests for Comments Speech Services Control (speechsc) ---------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Eric Burger David Oran Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: General Discussion: speechsc@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/speechsc Archive: http://www.ietf.org/mail-archive/web/speechsc/ Description of Working Group: Many multimedia applications can benefit from having Automated Speech Recognition (ASR), Text to Speech (TTS), and Speaker Verification (SV) processing available as a distributed, network resource. To date, there are a number of proprietary ASR, TTS, and SV API's, as well as two IETF drafts, that address this problem. However, there are serious deficiencies to the existing drafts relating to this problem. In particular, they mix the semantics of existing protocols yet are close enough to other protocols as to be confusing to the implementer. The speechsc Work Group will develop protocols to support distributed media processing of audio streams. The focus of this working group is to develop protocols to support ASR, TTS, and SV. The working group will only focus on the secure distributed control of these servers. The working group will develop an informational RFC detailing the architecture and requirements for distributed speechsc control. In addition, the requirements document will describe the use cases driving these requirements. The working group will then examine existing media-related protocols, especially RTSP, for suitability as a protocol for carriage of speechsc server control. The working group will then propose extensions to existing protocols or the development of new protocols, as appropriate, to meet the requirements specified in the informational RFC. The protocol will assume RTP carriage of media. Assuming session-oriented media transport, the protocol will use SDP to describe the session. The working group will not be investigating distributed speech recognition (DSR), as exemplified by the ETSI Aurora project. The working group will not be recreating functionality available in other protocols, such as SIP or SDP. The working group will offer changes to existing protocols, with the possible exception of RTSP, to the appropriate IETF work group for consideration. This working group will explore modifications to RTSP, if required. It is expected that we will coordinate our work in the IETF with the W3C Mutlimodal Interaction Work Group; the ITU-T Study Group 16 Working Party 3/16 on SG 16 Question 15/16; the 3GPP TSG SA WG1; and the ETSI Aurora STQ. Once the current set of milestones is completed, the speechsc charter may be expanded, with IESG approval, to cover additional uses of the technology, such as the orchestration of multiple ASR/TTS/SV servers, the accommodation of additional types of servers such as simultaneous translation servers, etc. Goals and Milestones: Done - Requirements ID submitted to IESG for publication (informational) Done - Submit Internet Draft(s) Analyzing Existing Protocols (informational) Done - Submit Internet Draft Describing New Protocol (if required) (standards track) Done - Submit Drafts to IESG for publication Oct 2006 - Submit MRCPv2 specification to IESG Internet-Drafts: - Media Resource Control Protocol Version 2 (MRCPv2) [draft-ietf-speechsc-mrcpv2-27] (225 pages) - SPEECHSC Protocol Evaluation [draft-ietf-speechsc-protocol-eval-02] (28 pages) - Requirements for Distributed Control of Automatic Speech Recognition (ASR), Speaker Identification/Speaker Verification (SI/SV), and Text-to-Speech (TTS) Resources [draft-ietf-speechsc-reqts-07] (20 pages) Requests for Comments: RFC4313: Requirements for Distributed Control of Automatic Speech Recognition (ASR), Speaker Identification/Speaker Verification (SI/SV), and Text-to-Speech (TTS) Resources (20 pages) Verification Involving PSTN Reachability (vipr) ----------------------------------------------- Charter Last Modified: 2012-02-10 Current Status: Active Chairs: Jon Peterson Daryl Malas Real-time Applications and Infrastructure Area Directors: Gonzalo Camarillo Robert Sparks Real-time Applications and Infrastructure Area Advisor: Robert Sparks Mailing Lists: General Discussion: vipr@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/vipr Archive: http://www.ietf.org/mail-archive/web/vipr/ Description of Working Group: There are two globally deployed address spaces for communications used by more than a billion people daily - phone numbers and DNS rooted address such as web servers and email addresses. The inter-domain signaling design of SIP is primarily designed for email style addresses yet a large percentage of SIP deployments mostly use phone numbers for identifying users, thus DNS lookups are not sufficient. The goal of this working group is to enable inter-domain communications over the Internet, using protocols such as SIP, while still allowing people to use phone numbers to identify the person with whom they wish to communicate. The VIPR WG will develop a peer to peer based approach to finding domains that claim to be responsible for a given phone number to mitigate the involvement of centralized entities to avoid some of the issues encountered by past attempts to support SIP inter-domain communications. Validation protocols will be developed to ensure a reasonable likelihood that a given domain actually is responsible for the phone number. In this context, "responsible" means an administrative domain, which is at least one of the domains, to which a PSTN call to this phone number would be routed. Once the domain responsible for the phone number is found, existing protocols, such as SIP, can be used for inter-domain communications. Some validation protocols may be based on knowledge gathered around a PSTN call; for example, the ability to prove a call was received over the PSTN based on start and stop times. Other validation schemes, such as examining fingerprints or watermarking of PSTN media to show that a domain received a particular PSTN phone call, may also be considered by the working group. This validation will be accomplished using publicly available open interfaces to the PSTN, so the validation can be performed by any domain wishing to participate. The WG will select and standardize at least one validation scheme. The validation mechanism requires a domain to gather and maintain information related to PSTN calls. This information is used by call agents such as phones, SBCs and IP PBXs to route calls. The WG will also develop mechanisms to detect in a timely manner that a given domain is no longer responsible for a phone number. The WG will define a client-server protocol between these call agents and the entity within a domain that maintains the information. To help mitigate SPAM issues when using SIP between domains, the WG will define a mechanism to enable one domain to check that incoming SIP messages are coming from a validated phone number. A phone number is considered validated if it is coming from a domain to which the calling domain had previously successfully placed a PSTN call. The working group will define new SIP headers and option tags, as necessary, to enable this. The essential characteristic of VIPR is establishing authentication by PSTN reachability when it is not possible to use a direct reference to ENUM databases or other direct assertions of PSTN number ownership. Elements such as public ENUM easily coexist with VIPR but no direct interaction with ENUM will be required. The solution set defined by this WG will be incrementally deployable using only existing interfaces to the PSTN. No changes will be required to existing PSTN capabilities, no new database access is needed nor is any new support from PSTN service providers required. The WG will produce the following deliverables: 1) A document describing the requirements, problem statement and architectural approach to support SIP inter-domain communications. 2) A document describing the use of the p2psip protocol (RELOAD) as applied to this problem space. 3) A document defining a scheme for validating the phone numbers using publicly available open interfaces to the PSTN. 4) A document defining client-server protocol between call agents and the entity within a domain that gathers and maintains information related to PSTN calls. 5) A document describing a mechanism to mitigate SPAM issues. The working group will carefully coordinate with the security area, O&M area, as well as the appropriate RAI WGs such as sipcore and p2psip. Goals and Milestones: Sep 2011 - Submit Requirements, Problem statement, and architecture overview for publication as Informational Dec 2011 - Submit Peer to peer base protocol specification for publication as Proposed Standard Dec 2011 - Submit PSTN based number validation techniques for publication as Proposed Standard Apr 2012 - Submit Specification of authorization tokens to mitigate SPAM for publication as Proposed Standard Apr 2012 - Submit Protocol for call agents to exchange call and routing information for publication as Proposed Standard Internet-Drafts: No Requests for Comments Bidirectional Forwarding Detection (bfd) ---------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: David Ward Jeffrey Haas Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Adrian Farrel Tech Advisor: Dave Katz Mailing Lists: General Discussion: rtg-bfd@ietf.org To Subscribe: rtg-bfd-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/rtg-bfd/ Description of Working Group: The BFD Working Group is chartered to standardize and support the bidirectional forwarding detection protocol (BFD) and its extensions. A core goal of the working group is to standardize BFD in the context of IP routing, or protocols such as MPLS that are based on IP routing, in a way that will encourage multiple, inter-operable vendor implementations. The Working Group will also provide advice and guidance on BFD to other working groups or standards bodies as requested. BFD is a protocol intended to detect faults in the bidirectional path between two forwarding engines, including physical interfaces, subinterfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. An additional goal is to provide a single mechanism that can be used for liveness detection over any media, at any protocol layer, with a wide range of detection times and overhead, to avoid a proliferation of different methods. Important characteristics of BFD include: - Simple, fixed-field encoding to facilitate implementations in hardware. - Independence of the data protocol being forwarded between two systems. BFD packets are carried as the payload of whatever encapsulating protocol is appropriate for the medium and network. - Path independence: BFD can provide failure detection on any kind of path between systems, including direct physical links, virtual circuits, tunnels, MPLS LSPs, multihop routed paths, and unidirectional links (so long as there is some return path, of course). - Ability to be bootstrapped by any other protocol that automatically forms peer, neighbor or adjacency relationships to seed BFD endpoint discovery. The working group is chartered to complete the following work items: 1. Develop the MIB module for BFD and submit it to the IESG for publication as a Proposed Standard. 2a. Provide a generic keying-based cryptographic authentication mechanism for the BFD protocol. This mechanism will support authentication through a key identifier for the BFD session's Security Association rather than specifying new authentication extensions. 2b. Provide extensions to the BFD MIB in support of the generic keying-based cryptographic authentication mechanism. 2c. Specify cryptographic authentication procedures for the BFD protocol using HMAC-SHA-256 (possibly truncated to a smaller integrity check value) using the generic keying-based cryptographic authentication mechanism. 3. Provide an extension to the BFD core protocol in support of point-to-multipoint links and networks. 4. Provide a mechanism for bootstrapping BFD on dynamically configured edge devices using DHCPv4 and DHCPv6. 5. Assist in the standardization of the BFD protocol for MPLS-TP. The preferred solution will be interoperable with the current BFD specification. 6. Assist with the standardization of the BFD protocol for Trill. Goals and Milestones: Done - Submit the base protocol specification to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for single-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for MPLS LSPs to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for multi-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Sep 2011 - Submit the BFD MIB to the IESG to be considered as a Proposed Standard Dec 2011 - Submit the generic keying based cryptographic authentication mechanism to the IESG to be considered as a Proposed Standard Dec 2011 - Submit a BFD MIB extension in support of the generic keying document to the IESG to be considered as a Proposed Standard Dec 2011 - Submit the cryptographic authentication procedures for BFD to the IESG to be considered as a Proposed Standard Mar 2012 - Submit the the document on BFD point-to-multipoint support to the IESG to be considered as a Proposed Standard Jun 2012 - Submit the bootstrapping mechanism for BFD using DHCP to the IESG to be considered as a Proposed Standard Internet-Drafts: - Bidirectional Forwarding Detection (BFD) [draft-ietf-bfd-base-11] (51 pages) - Generic Application of Bidirectional Forwarding Detection (BFD) [draft-ietf-bfd-generic-05] (18 pages) - BFD Generic Cryptographic Authentication [draft-ietf-bfd-generic-crypto-auth-01] (12 pages) - Authenticating BFD using HMAC-SHA-2 procedures [draft-ietf-bfd-hmac-sha-00] (10 pages) - BFD Management Information Base [draft-ietf-bfd-mib-10] (35 pages) - Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs) [draft-ietf-bfd-mpls-07] (13 pages) - Bidirectional Forwarding Detection (BFD) for Multihop Paths [draft-ietf-bfd-multihop-09] (7 pages) - BFD for Multipoint Networks [draft-ietf-bfd-multipoint-00] (29 pages) - Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management [draft-ietf-bfd-tc-mib-00] (9 pages) - Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop) [draft-ietf-bfd-v4v6-1hop-11] (8 pages) - BFD for Multipoint Networks [draft-katz-ward-bfd-multipoint-02] (29 pages) Requests for Comments: RFC5880: Bidirectional Forwarding Detection (BFD) (51 pages) RFC5881: Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop) (8 pages) RFC5882: Generic Application of Bidirectional Forwarding Detection (BFD) (18 pages) RFC5883: Bidirectional Forwarding Detection (BFD) for Multihop Paths (7 pages) RFC5884: Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs) (13 pages) * Updates RFC1122 Common Control and Measurement Plane (ccamp) -------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Lou Berger Deborah Brungard Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Adrian Farrel Secretaries: Daniel King <> Daniele Ceccarelli <> Mailing Lists: General Discussion: ccamp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ccamp Archive: http://www.ietf.org/mail-archive/web/ccamp/ Description of Working Group: Organizational Overview The CCAMP working group coordinates the work within the IETF defining a common control plane and a separate common measurement plane for physical path and core tunneling technologies of Internet and telecom service providers (ISPs and SPs), e.g. O-O and O-E-O optical switches, TDM Switches, Ethernet Switches, ATM and Frame Relay switches, IP encapsulation tunneling technologies, and MPLS in cooperation with the MPLS WG. In this context, measurement refers to the acquisition and distribution of attributes relevant to the setting up of tunnels and paths. CCAMP WG work scope includes: - Definition of protocol-independent metrics and parameters (measurement attributes) for describing links and paths that are required for routing and signaling. These will be developed in conjunction with requests and requirements from other WGs to ensure overall usefulness. - Definition of and extensions to protocols for link and path attribute measurement. This includes the Link Management Protocol (LMP). - Functional specification of extensions for GMPLS-related routing (OSPF, ISIS) and signaling (RSVP-TE) protocols required for path establishment and maintenance. Protocol formats and procedures that embody these extensions will be done jointly with the WGs supervising those protocols. - Definition of the mechanisms required to determine the route and properties of an established path (tunnel tracing). - Definition of management objects (e.g., as part of MIB modules) and control of OAM techniques relevant to the protocols and extensions specified within the WG. - Work on traffic-engineering GMPLS mechanisms and protocol extensions to support source-controlled and explicitly-routed data paths for data planes that are already approved by a Standards Development Organization (SDO). Note that the specification or modification of data planes is out of scope of this working group. Example data planes include Wavelength Switched Optical Networks (WSON), Optical Transport Networks (OTN), Ethernet, and the MPLS data plane. - Work on GMPLS mechanisms and protocol extensions to support the transport profile of MPLS (MPLS-TP) in cooperation with the MPLS, L2VPN, and PWE3 Working Group and in coordination with the requirements expressed jointly by the IETF and ITU-T. CCAMP WG currently works on the following tasks: - Define how the properties of network resources gathered by a measurement protocol (or by other means e.g. configured) can be distributed in existing routing protocols, such as OSPF and IS-IS. CCAMP will work with the WGs that supervise these protocols. The specifics of distribution within IS-IS are being addressed in the ISIS WG. Current work activities are focused in the areas of WSON and OTN. - Define signaling and routing mechanisms and extensions to allow path and tunnel setup and maintenance across multiple domains, where a domain may be an IGP area, an Autonomous System, or any other region of topological visibility. To this end, work cooperatively with the PCE and MPLS WGs. - Define abstract link and path properties needed for link and path protection. Specify signaling mechanisms for path protection, diverse routing and fast path restoration. Ensure that multi-layer path protection and restoration functions are achievable using the defined signaling, routing, and measurement protocols, either separately or in combination. - Identify signaling and routing requirements for supporting protocol extensions in support of data plane technologies (e.g., WSON, OTN, MPLS-TP, and Ethernet) and network architectures (e.g. ITU-T's Automatically Switched Optical Network (ASON)) not currently met by protocols defined in CCAMP; based on these, define mechanisms to address these requirements. This activity will build on documents produced by the WG, including Informational, Standards Track and Experimental documents. - Produce extensions to the CCAMP WG protocols and RFCs necessary to create an MPLS Transport Profile (MPLS TP). The work on the MPLS TP will be coordinated between the MPLS, L2VPN, PWE3, and CCAMP working groups that are jointly chartered to do MPLS TP work. In doing this work, the WG will work closely with at least the following other WGs: MPLS, L2VPN, PWE3, ISIS, OSPF, IDR, and PCE. The WG will also cooperate with the ITU-T and the IEEE 802.1. Goals and Milestones: Done - Post strawman WG goals and charter Done - Identify and document a limited set of candidate solutions for signalling and for measurement. Among candidate control solutions to be considered are the existing GMPLS drafts. Done - Build appropriate design teams Done - Submit WG document defining path setup portions of common control plane protocol Done - Submit WG document defining common measurement plane protocol Done - Submit LMP MIB to IESG Done - Submit GMPLS MIBs to IESG Done - Submit protection & restoration documents to IESG Done - Submit ASON signaling requirements doc to IESG Done - Produce CCAMP WG document for multi-area/AS signaling and routing Done - Produce CCAMP WG document for generic tunnel tracing protocol Done - Submit ASON routing requirements doc to IESG Done - Submit revised charter and milestones to IESG for IESG consideration of more detailed deliverables and determination of usefulness of continuation of WG Done - First version WG I-D for Advertising TE Node Capabilities in ISIS and OSPF Done - First version WG I-D for Automatic discovery of MPLS-TE mesh membership Done - Submit ASON Routing evaluation I-D for IESG review Done - Cross-WG review of I-D for Advertising TE Node Capabilities in ISIS and OSPF Done - First version WG I-D MPLS to GMPLS migration strategies Done - Submit RSVP-TE extensions for inter-domain signaling I-D for IESG review Done - Submit Per-domain path computation signaling I-D for IESG review Done - First version of WG I-D for ASON Routing solutions Done - First version WG I-D Requirements for Multi-Layer and Multi-Region Networks Done - First version WG I-D for Evaluation of existing protocols for MLN/MRN Done - Submit GMPLS signaling in support of Call Management I-D for IESG review Done - Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF for IESG review Done - First version WG I-D for Protocol solutions for MLN/MRN Done - First version of WG I-D for OSPF-TE/GMPLS MIB module Done - First version WG Informational I-D for Analysis of inter-domain issues for disjoint and protected paths Done - Submit GMPLS/ASON lexicography I-D for IESG review Done - Submit LSP Stitching I-D for IESG review Done - First version WG I-D MPLS-GMPLS interworking requirements and solutions Done - Submit I-D for Automatic discovery of MPLS-TE mesh membership for IESG review Done - First version WG I-D GMPLS OAM Requirements Done - Submit GMPLS routing and signaling interoperability advice I-D for IESG review Done - Submit MPLS to GMPLS migration strategies I-D for IESG review Done - Submit Requirements for Multi-Layer and Multi-Region Networks I-D for IESG review Done - Submit MPLS-GMPLS interworking requirements and solutions I-D for IESG review Done - Submit Evaluation of existing protocols for MLN/MRN for IESG review Done - Submit Informational I-D for Analysis of inter-domain issues for disjoint and protected paths for IESG review Done - First version WG I-Ds for GMPLS source-controlled and explicitly-routed Ethernet networks Done - Submit Protocol solutions for MLN/MRN I-D for IESG review Done - First version of WSON routing related Working Group drafts Done - Submit Ethernet related drafts for IESG review Done - Submit hierarchy bis for IESG review Done - First version of LMP Negotiation Working Group draft Done - First version of G.709 enhancements framework Working Group drafts Done - First version of Working Group draft providing Control Plane Framework for MPLS-TP Apr 2010 - First versions of impairments related solutions Working Group drafts Apr 2010 - Submit TE MIB module IESG review Done - Submit VCAT/LCAS with GMPLS for IESG review Done - Submit Lambda labels draft for IESG review Done - Submit WSON framework draft for IESG review Done - Submit WSON impairment framework draft for IESG review May 2010 - Submit OAM configuration framework for IESG review Done - First version of OAM configuration solutions Working Group draft Done - First version of G.709 enhancements solutions Working Group drafts Aug 2010 - First version of LMP for G.709 enhancements Working Group drafts Done - First version of Working Group draft defining RSVP-TE extensions for MPLS-TP Dec 2010 - Submit WSON routing related for IESG review Dec 2010 - Submit impairments related solutions for IESG review Dec 2010 - Submit G.709 enhancements framework for IESG review Done - Submit Control Plane Framework for MPLS-TP for IESG review Done - Submit RSVP-TE extensions for MPLS-TP for IESG review Apr 2011 - Submit G.709 enhancements solutions for IESG review Apr 2011 - Submit LMP Negotiation for IESG review Apr 2011 - Submit last OAM configuration solutions for IESG review Aug 2011 - Submit LMP for G.709 enhancements for IESG review Nov 2011 - Recharter or close Working Group Internet-Drafts: - Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks [draft-ceccarelli-ccamp-gmpls-ospf-g709-07] (29 pages) - RSVP Association Object Extensions [draft-ietf-ccamp-assoc-ext-03] (16 pages) - Usage of The RSVP Association Object [draft-ietf-ccamp-assoc-info-03] (11 pages) - GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) [draft-ietf-ccamp-asymm-bw-bidir-lsps-02] (15 pages) - GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) [draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-03] (15 pages) - Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects [draft-ietf-ccamp-attribute-bnf-02] (8 pages) - Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership [draft-ietf-ccamp-automesh-04] (16 pages) - Data Channel Status Confirmation Extensions for the Link Management Protocol [draft-ietf-ccamp-confirm-data-channel-status-09] (16 pages) - Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE [draft-ietf-ccamp-crankback-06] (35 pages) - Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS/ MPLS-TE Networks [draft-ietf-ccamp-dpm-05] (33 pages) - Service Provider Requirements for Ethernet control with GMPLS [draft-ietf-ccamp-ethernet-gmpls-provider-reqs-02] (20 pages) - Ethernet Traffic Parameters [draft-ietf-ccamp-ethernet-traffic-parameters-10] (14 pages) - General Network Element Constraint Encoding for GMPLS Controlled Networks [draft-ietf-ccamp-general-constraint-encode-07] (28 pages) - Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks [draft-ietf-ccamp-gmpls-addressing-08] (22 pages) - GMPLS - Communication of Alarm Information [draft-ietf-ccamp-gmpls-alarm-spec-06] (20 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Architecture [draft-ietf-ccamp-gmpls-architecture-07] (58 pages) - A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture [draft-ietf-ccamp-gmpls-ason-lexicography-06] (18 pages) - Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON) [draft-ietf-ccamp-gmpls-ason-reqts-07] (14 pages) - Evaluation of Existing Routing Protocols against Automatic Switched Optical Network (ASON) Routing Requirements [draft-ietf-ccamp-gmpls-ason-routing-eval-03] (0 pages) - OSPFv2 Routing Protocols Extensions for Automatically Switched Optical Network (ASON) Routing [draft-ietf-ccamp-gmpls-ason-routing-ospf-09] (29 pages) - Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON) [draft-ietf-ccamp-gmpls-ason-routing-reqts-05] (19 pages) - Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions [draft-ietf-ccamp-gmpls-dcsc-channel-ext-04] (11 pages) - GMPLS Signaling Procedure for Egress Control [draft-ietf-ccamp-gmpls-egress-control-03] (6 pages) - Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching [draft-ietf-ccamp-gmpls-ether-svcs-04] (16 pages) - Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework [draft-ietf-ccamp-gmpls-ethernet-arch-09] (21 pages) - Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE) [draft-ietf-ccamp-gmpls-ethernet-pbb-te-06] (21 pages) - Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers [draft-ietf-ccamp-gmpls-g-694-lambda-labels-11] (16 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control [draft-ietf-ccamp-gmpls-g709-09] (22 pages) - Framework for GMPLS and PCE Control of G.709 Optical Transport Networks [draft-ietf-ccamp-gmpls-g709-framework-06] (29 pages) - OSPF-TE Extensions for General Network Element Constraints [draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02] (14 pages) - Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base [draft-ietf-ccamp-gmpls-lsr-mib-15] (42 pages) - Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 User Network Interface (UNI) [draft-ietf-ccamp-gmpls-mef-uni-03] (10 pages) - Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN) [draft-ietf-ccamp-gmpls-mln-eval-06] (23 pages) - Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) [draft-ietf-ccamp-gmpls-mln-extensions-12] (24 pages) - Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) [draft-ietf-ccamp-gmpls-mln-reqs-11] (27 pages) - OAM Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Networks [draft-ietf-ccamp-gmpls-oam-requirements-00] (13 pages) - Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks [draft-ietf-ccamp-gmpls-ospf-g709v3-02] (31 pages) - Traffic Engineering Database Management Information Base in support of GMPLS [draft-ietf-ccamp-gmpls-ospf-mib-01] (22 pages) - Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model [draft-ietf-ccamp-gmpls-overlay-05] (12 pages) - Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) [draft-ietf-ccamp-gmpls-recovery-analysis-05] (42 pages) - RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery [draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04] (36 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification [draft-ietf-ccamp-gmpls-recovery-functional-04] (20 pages) - Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) [draft-ietf-ccamp-gmpls-recovery-terminology-06] (20 pages) - Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) [draft-ietf-ccamp-gmpls-routing-09] (25 pages) - Generalized MPLS (GMPLS) RSVP-TE Signalling in support of Automatically Switched Optical Network (ASON) [draft-ietf-ccamp-gmpls-rsvp-te-ason-04] (40 pages) - Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls [draft-ietf-ccamp-gmpls-rsvp-te-call-04] (30 pages) - GMPLS Segment Recovery [draft-ietf-ccamp-gmpls-segment-recovery-03] (25 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control [draft-ietf-ccamp-gmpls-signaling-g709v3-02] (29 pages) - Generalized MPLS Signaling - Implementation Survey [draft-ietf-ccamp-gmpls-signaling-survey-03] (101 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control [draft-ietf-ccamp-gmpls-sonet-sdh-08] (21 pages) - Generalized Multiprotocol Label Switching Extensions to Control Non-Standard SONET and SDH Features [draft-ietf-ccamp-gmpls-sonet-sdh-extensions-03] (14 pages) - Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management [draft-ietf-ccamp-gmpls-tc-mib-11] (9 pages) - Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base [draft-ietf-ccamp-gmpls-te-mib-16] (59 pages) - Traffic Engineering Database Management Information Base in support of MPLS-TE/GMPLS [draft-ietf-ccamp-gmpls-ted-mib-13] (32 pages) - Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS) [draft-ietf-ccamp-gmpls-vcat-lcas-13] (22 pages) - Description of the Resource Reservation Protocol - Traffic-Engineered (RSVP-TE) Graceful Restart Procedures [draft-ietf-ccamp-gr-description-04] (19 pages) - A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering [draft-ietf-ccamp-inter-domain-framework-06] (21 pages) - A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs) [draft-ietf-ccamp-inter-domain-pd-path-comp-06] (23 pages) - Analysis of Inter-Domain Label Switched Path (LSP) Recovery [draft-ietf-ccamp-inter-domain-recovery-analysis-05] (25 pages) - Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions [draft-ietf-ccamp-inter-domain-rsvp-te-07] (22 pages) - ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering [draft-ietf-ccamp-isis-interas-te-extension-04] (20 pages) - Link Management Protocol (LMP) [draft-ietf-ccamp-lmp-10] (77 pages) - Link Management Protocol Behavior Negotiation and Configuration Modifications [draft-ietf-ccamp-lmp-behavior-negotiation-05] (11 pages) - Link Management Protocol (LMP) Management Information Base (MIB) [draft-ietf-ccamp-lmp-mib-10] (83 pages) - Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages [draft-ietf-ccamp-lmp-test-sonet-sdh-04] (15 pages) - Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems [draft-ietf-ccamp-lmp-wdm-03] (16 pages) - Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP) [draft-ietf-ccamp-loose-path-reopt-02] (14 pages) - Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks [draft-ietf-ccamp-lsp-dppm-11] (52 pages) - Procedures for Dynamically Signaled Hierarchical Label Switched Paths [draft-ietf-ccamp-lsp-hierarchy-bis-08] (29 pages) - Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE) [draft-ietf-ccamp-lsp-stitching-06] (19 pages) - Framework for MPLS-TE to GMPLS Migration [draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05] (19 pages) - Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks [draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04] (13 pages) - Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks [draft-ietf-ccamp-mpls-graceful-shutdown-13] (10 pages) - MPLS Transport Profile (MPLS-TP) Control Plane Framework [draft-ietf-ccamp-mpls-tp-cp-framework-06] (55 pages) - RSVP-TE Extensions for Associated Bidirectional LSPs [draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03] (13 pages) - GMPLS RSVP-TE extensions for OAM Configuration [draft-ietf-ccamp-oam-configuration-fwk-07] (24 pages) - TITLE: Optical Link Interface Requirements [draft-ietf-ccamp-oli-reqts-00] (13 pages) - OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) [draft-ietf-ccamp-ospf-gmpls-extensions-12] (12 pages) - OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering [draft-ietf-ccamp-ospf-interas-te-extension-06] (19 pages) - Information model for G.709 Optical Transport Networks (OTN) [draft-ietf-ccamp-otn-g709-info-model-03] (24 pages) - Resource Reservation Protocol (RSVP) Extensions for Path Key Support [draft-ietf-ccamp-path-key-ero-04] (14 pages) - Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network [draft-ietf-ccamp-pc-and-sc-reqs-06] (11 pages) - RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network [draft-ietf-ccamp-pc-spc-rsvpte-ext-07] (22 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control [draft-ietf-ccamp-rfc3946bis-01] (24 pages) - Link Management Protocol (LMP) Management Information Base (MIB) [draft-ietf-ccamp-rfc4327bis-01] (81 pages) - Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) [draft-ietf-ccamp-rfc4420bis-03] (22 pages) - Updates to ASON Routing for OSPFv2 Protocols (RFC 5787bis) [draft-ietf-ccamp-rfc5787bis-03] (29 pages) - Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement [draft-ietf-ccamp-rsvp-node-id-based-hello-03] (7 pages) - RSVP Resource Sharing Remote Identification Association [draft-ietf-ccamp-rsvp-resource-sharing-02] (11 pages) - Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart [draft-ietf-ccamp-rsvp-restart-ext-09] (24 pages) - GMPLS RSVP-TE Extensions for Ethernet OAM Configuration [draft-ietf-ccamp-rsvp-te-eth-oam-ext-07] (20 pages) - Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) [draft-ietf-ccamp-rsvp-te-exclude-route-06] (26 pages) - Configuration of Pro-Active Operations, Administration, and Maintenance (OAM) Functions for MPLS-based Transport Networks using RSVP-TE [draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-08] (22 pages) - GMPLS RSVP-TE Extensions for SONET/SDH and OTN OAM Configuration [draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-04] (22 pages) - Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks [draft-ietf-ccamp-rwa-info-14] (27 pages) - Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks [draft-ietf-ccamp-rwa-wson-encode-14] (37 pages) - Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs) [draft-ietf-ccamp-rwa-wson-framework-12] (53 pages) - Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks [draft-ietf-ccamp-sdhsonet-control-05] (31 pages) - IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities [draft-ietf-ccamp-te-node-cap-05] (13 pages) - Tracing Requirements for Generic Tunnels [draft-ietf-ccamp-tracereq-05] (9 pages) - A Transport Network View of the Link Management Protocol (LMP) [draft-ietf-ccamp-transport-lmp-02] (17 pages) - Generic Tunnel Tracing Protocol (GTTP) Specification [draft-ietf-ccamp-tunproto-01] (36 pages) - Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) [draft-ietf-ccamp-wavelength-switched-framework-01] (37 pages) - A Framework for the Control of Wavelength Switched Optical Networks (WSONs) with Impairments [draft-ietf-ccamp-wson-impairments-10] (31 pages) - GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks [draft-ietf-ccamp-wson-signal-compatibility-ospf-08] (12 pages) - Signaling Extensions for Wavelength Switched Optical Networks [draft-ietf-ccamp-wson-signaling-03] (16 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions [draft-ietf-mpls-generalized-cr-ldp-07] (24 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions [draft-ietf-mpls-generalized-rsvp-te-09] (42 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description [draft-ietf-mpls-generalized-signaling-09] (34 pages) - Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control [draft-zhang-ccamp-gmpls-evolving-g709-09] (24 pages) Requests for Comments: RFC3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description (34 pages) * Updates RFC4201 * Updates RFC4328 * Updates RFC4872 * Updates RFC6002 * Updates RFC6003 * Updates RFC6205 RFC3472: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions (24 pages) * Updates RFC3468 * Updates RFC4201 RFC3473: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions (42 pages) * Updates RFC4003 * Updates RFC4201 * Updates RFC4420 * Updates RFC4783 * Updates RFC4874 * Updates RFC4873 * Updates RFC4974 * Updates RFC5063 * Updates RFC5151 * Updates RFC5420 * Updates RFC6002 * Updates RFC6003 RFC3609: Tracing Requirements for Generic Tunnels (9 pages) RFC3945: Generalized Multi-Protocol Label Switching (GMPLS) Architecture (58 pages) * Updates RFC6002 RFC3946: Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control (21 pages) * Obsoletes RFC4606 RFC4003: GMPLS Signaling Procedure for Egress Control (6 pages) * Updates RFC3473 RFC4139: Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON) (14 pages) * Replaces DRAFT-PAPADIMITRIOU-CCAMP-GMPLS-ASON-REQTS RFC4202: Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) (25 pages) * Updates RFC6001 * Updates RFC6002 RFC4203: OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) (12 pages) * Updates RFC3630 * Updates RFC6001 * Updates RFC6002 RFC4204: Link Management Protocol (LMP) (77 pages) RFC4207: Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages (15 pages) RFC4208: Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model (12 pages) RFC4209: Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems (16 pages) RFC4257: Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks (31 pages) RFC4258: Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON) (19 pages) * Replaces DRAFT-ALANQAR-CCAMP-GMPLS-ASON-ROUTING-REQTS RFC4327: Link Management Protocol (LMP) Management Information Base (MIB) (83 pages) * Obsoletes RFC4631 RFC4328: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control (22 pages) * Updates RFC3471 RFC4394: A Transport Network View of the Link Management Protocol (LMP) (17 pages) * Replaces DRAFT-ABOULMAGD-CCAMP-TRANSPORT-LMP RFC4397: A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture (18 pages) RFC4426: Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification (20 pages) RFC4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) (20 pages) RFC4428: Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) (42 pages) * Replaces DRAFT-PAPADIMITRIOU-CCAMP-GMPLS-RECOVERY-ANALYSIS RFC4558: Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement (7 pages) * Replaces DRAFT-ALI-CCAMP-RSVP-NODE-ID-BASED-HELLO RFC4606: Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control (24 pages) * Replaces DRAFT-PAPADIMITRIOU-CCAMP-RFC3946BIS * Obsoletes RFC3946 * Updates RFC6344 RFC4631: Link Management Protocol (LMP) Management Information Base (MIB) (81 pages) * Obsoletes RFC4327 RFC4652: Evaluation of Existing Routing Protocols against Automatic Switched Optical Network (ASON) Routing Requirements (0 pages) * Replaces DRAFT-DIMITRI-CCAMP-GMPLS-ASON-ROUTING-EVAL RFC4726: A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering (21 pages) * Replaces DRAFT-FARREL-CCAMP-INTER-DOMAIN-FRAMEWORK RFC4736: Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP) (14 pages) * Replaces DRAFT-VASSEUR-CCAMP-LOOSE-PATH-REOPT RFC4783: GMPLS - Communication of Alarm Information (20 pages) * Replaces DRAFT-BERGER-CCAMP-GMPLS-ALARM-SPEC * Updates RFC3473 RFC4801: Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management (9 pages) RFC4802: Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base (59 pages) RFC4803: Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base (42 pages) RFC4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery (36 pages) * Updates RFC3471 * Updates RFC4873 RFC4873: GMPLS Segment Recovery (25 pages) * Replaces DRAFT-BERGER-CCAMP-GMPLS-SEGMENT-RECOVERY * Updates RFC3473 * Updates RFC4872 RFC4874: Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) (26 pages) * Updates RFC3209 * Updates RFC3473 * Updates RFC6001 RFC4920: Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE (35 pages) RFC4972: Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership (16 pages) RFC4974: Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls (30 pages) * Replaces DRAFT-PAPADIMITRIOU-CCAMP-GMPLS-RSVP-TE-CALL * Updates RFC3473 * Updates RFC6001 RFC4990: Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks (22 pages) * Replaces DRAFT-SHIOMOTO-CCAMP-GMPLS-ADDRESSING RFC5063: Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart (24 pages) * Replaces DRAFT-ARUNS-CCAMP-RSVP-RESTART-EXT * Updates RFC2961 * Updates RFC3473 RFC5073: IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities (13 pages) * Replaces DRAFT-VASSEUR-CCAMP-TE-NODE-CAP RFC5145: Framework for MPLS-TE to GMPLS Migration (19 pages) * Replaces DRAFT-SHIOMOTO-CCAMP-MPLS-GMPLS-INTERWORK-FMWK RFC5146: Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks (13 pages) * Replaces DRAFT-KUMAKI-CCAMP-MPLS-GMPLS-INTERWORK-REQTS RFC5150: Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE) (19 pages) * Replaces DRAFT-AYYANGAR-CCAMP-LSP-STITCHING RFC5151: Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions (22 pages) * Replaces DRAFT-AYYANGAR-CCAMP-INTER-DOMAIN-RSVP-TE * Updates RFC3209 * Updates RFC3473 RFC5152: A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs) (23 pages) * Replaces DRAFT-VASSEUR-CCAMP-INTER-DOMAIN-PATH-COMP * Replaces DRAFT-VASSEUR-CCAMP-INTER-DOMAIN-PD-PATH-COMP RFC5212: Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) (27 pages) RFC5298: Analysis of Inter-Domain Label Switched Path (LSP) Recovery (25 pages) * Replaces DRAFT-TAKEDA-CCAMP-INTER-DOMAIN-RECOVERY-ANALYSIS RFC5316: ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering (20 pages) * Replaces DRAFT-CHEN-CCAMP-ISIS-INTERAS-TE-EXTENSION RFC5339: Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN) (23 pages) RFC5392: OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering (19 pages) * Replaces DRAFT-CHEN-CCAMP-OSPF-INTERAS-TE-EXTENSION RFC5420: Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) (22 pages) * Updates RFC3209 * Updates RFC3473 * Obsoletes RFC4420 * Updates RFC6510 RFC5467: GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) (15 pages) * Replaces DRAFT-BERGER-CCAMP-ASYMM-BW-BIDIR-LSPS * Obsoletes RFC6387 RFC5493: Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network (11 pages) * Replaces DRAFT-CAVIGLIA-CCAMP-PC-AND-SC-REQS RFC5495: Description of the Resource Reservation Protocol - Traffic-Engineered (RSVP-TE) Graceful Restart Procedures (19 pages) * Replaces DRAFT-LI-CCAMP-GR-DESCRIPTION RFC5553: Resource Reservation Protocol (RSVP) Extensions for Path Key Support (14 pages) * Replaces DRAFT-BRADFORD-CCAMP-PATH-KEY-ERO RFC5787: OSPFv2 Routing Protocols Extensions for Automatically Switched Optical Network (ASON) Routing (29 pages) * Replaces DRAFT-DIMITRI-CCAMP-GMPLS-ASON-ROUTING-OSPF RFC5814: Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks (52 pages) * Replaces DRAFT-XIE-CCAMP-LSP-DPPM RFC5817: Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks (10 pages) * Replaces DRAFT-ALI-CCAMP-MPLS-GRACEFUL-SHUTDOWN RFC5818: Data Channel Status Confirmation Extensions for the Link Management Protocol (16 pages) * Replaces DRAFT-LI-CCAMP-CONFIRM-DATA-CHANNEL-STATUS RFC5828: Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework (21 pages) RFC5852: RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network (22 pages) RFC6001: Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) (24 pages) * Updates RFC4202 * Updates RFC4203 * Updates RFC4206 * Updates RFC4874 * Updates RFC4974 * Updates RFC5307 RFC6002: Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions (11 pages) * Updates RFC3471 * Updates RFC3473 * Updates RFC3945 * Updates RFC4202 * Updates RFC4203 * Updates RFC5307 RFC6003: Ethernet Traffic Parameters (14 pages) * Updates RFC3471 * Updates RFC3473 RFC6004: Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching (16 pages) * Replaces DRAFT-BERGER-CCAMP-GMPLS-ETHER-SVCS RFC6005: Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 User Network Interface (UNI) (10 pages) * Replaces DRAFT-BERGER-CCAMP-GMPLS-MEF-UNI RFC6060: Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE) (21 pages) RFC6107: Procedures for Dynamically Signaled Hierarchical Label Switched Paths (29 pages) * Replaces DRAFT-SHIOMOTO-CCAMP-LSP-HIERARCHY-BIS * Updates RFC3477 * Updates RFC4206 RFC6163: Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs) (53 pages) * Replaces DRAFT-IETF-CCAMP-WAVELENGTH-SWITCHED-FRAMEWORK RFC6205: Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers (16 pages) * Updates RFC3471 RFC6344: Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS) (22 pages) * Replaces DRAFT-BERNSTEIN-CCAMP-GMPLS-VCAT-LCAS * Updates RFC4606 RFC6373: MPLS Transport Profile (MPLS-TP) Control Plane Framework (55 pages) * Replaces DRAFT-ABFB-MPLS-TP-CONTROL-PLANE-FRAMEWORK RFC6387: GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) (15 pages) * Replaces DRAFT-TAKACS-CCAMP-ASYMM-BW-BIDIR-LSPS-BIS * Obsoletes RFC5467 RFC6510: Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects (8 pages) * Replaces DRAFT-BERGER-CCAMP-ATTRIBUTE-BNF * Updates RFC4875 * Updates RFC5420 RFC6566: A Framework for the Control of Wavelength Switched Optical Networks (WSONs) with Impairments (31 pages) * Replaces DRAFT-BERNSTEIN-CCAMP-WSON-IMPAIRMENTS Forwarding and Control Element Separation (forces) -------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Patrick Droz Jamal Hadi Salim Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Adrian Farrel Mailing Lists: General Discussion: forces@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/forces Archive: http://www.ietf.org/mail-archive/web/forces/ Description of Working Group: The emergence of off-the-shelf network processor devices that implement the fast path or forwarding plane in network devices such as routers, along with the appearance of a new generation of third party signaling, routing, and other router control plane software, has created the need for standard mechanisms to allow these components to be combined into functional wholes. ForCES aims to define a framework and associated mechanisms for standardizing the exchange of information between the logically separate functionality of the control plane, including entities such as routing protocols, admission control, and signaling, and the forwarding plane, where per-packet activities such as packet forwarding, queuing, and header editing occur. By defining a set of standard mechanisms for control and forwarding separation, ForCES will enable rapid innovation in both the control and forwarding planes. A standard separation mechanism allows the control and forwarding planes to innovate in parallel while maintaining interoperability. The products of this working group will be: o A set of requirements for mechanisms to logically separate the control and data forwarding planes of an IP network element (NE) o An applicability statement for the ForCES model and protocol o Informational RFCs as necessary documenting current approaches to the functional model and controlled objects therein o An architectural framework defining the entities comprising a ForCES network element and identifying the interactions between them. o A description of the functional model of a Forwarding Element o A formal definition of the controlled objects in the functional model of a forwarding element. This includes IP forwarding, IntServ and DiffServ QoS. An existing specification language shall be used for this task. o Specification of IP-based protocol for transport of the controlled objects. When the control and forwarding devices are separated beyond a single hop, ForCES will make use of an existing RFC2914 compliant L4 protocol with adequate reliability, security and congestion control (e.g. TCP, SCTP) for transport purposes. The main focus area of the working group will be control and forwarding separation for IP forwarding devices where the control and forwarding elements are in close (same room/small number of hops) or very close (same box/one hop) proximity. Other scenarios will be considered but at not the main focus of the work. The functional model of the forwarding element will include QoS (DiffServ and IntServ) capabilities of modern networking devices such as routers. In order to minimize the effort to integrate forwarding elements and control elements, a mechanism for auto discovery and capability information exchange will form an integral part of the standardized interface. ForCES will coordinate with other standards bodies and working groups as appropriate. Examples of such bodies include IETF/GSMP, IETF/Megaco, the Network Processing Forum (NPF), the Multiservice Switching Forum (MSF), IEEE P1520, and SoftSwitch. ForCES will review relevant protocol efforts such as GSMP and Megaco and will extend or reuse them if appropriate. If protocol reuse is accepted as satisfactory for fulfilling the ForCES requirements then ForCES may recharter to adopt specific deliverables around the selected protocol. Goals and Milestones: Done - Submit requirements document to IESG Done - Submit framework document to IESG Done - Submit forwarding element functional model document to IESG Mar 2005 - Submit formal definition of controlled objects in functional model Done - Submit protocol selection/definition document to IESG Mar 2009 - Submit applicability statement to IESG Internet-Drafts: - ForCES Applicability Statement [draft-crouch-forces-applicability-01] (10 pages) - Forwarding and Control Element Separation (ForCES) Applicability Statement [draft-ietf-forces-applicability-09] (14 pages) - ForCES Intra-NE High Availability [draft-ietf-forces-ceha-03] (25 pages) - ForCES Intra-NE Topology Discovery [draft-ietf-forces-discovery-02] (17 pages) - ForCES Protocol Evaluation Draft [draft-ietf-forces-evaluation-00] (31 pages) - Forwarding and Control Element Separation (ForCES) Framework [draft-ietf-forces-framework-13] (40 pages) - ForCES Implementation Experience Draft [draft-ietf-forces-implementation-experience-00] (19 pages) - Implementation Report for Forwarding and Control Element Separation (ForCES) [draft-ietf-forces-implementation-report-02] (38 pages) - Interoperability Report for Forwarding and Control Element Separation (ForCES) [draft-ietf-forces-interop-03] (36 pages) - ForCES Interoperability Draft [draft-ietf-forces-interoperability-04] (34 pages) - ForCES Logical Function Block (LFB) Library [draft-ietf-forces-lfb-lib-08] (113 pages) - Forwarding and Control Element Separation (ForCES) MIB [draft-ietf-forces-mib-10] (20 pages) - Forwarding and Control Element Separation (ForCES) Forwarding Element Model [draft-ietf-forces-model-16] (132 pages) - Linux Netlink as an IP Services Protocol [draft-ietf-forces-netlink-04] (32 pages) - Forwarding and Control Element Separation (ForCES) Protocol Specification [draft-ietf-forces-protocol-22] (127 pages) - Requirements for Separation of IP Control and Forwarding [draft-ietf-forces-requirements-10] (16 pages) - SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol [draft-ietf-forces-sctptml-08] (29 pages) - TCP/IP based TML (Transport Mapping Layer) for ForCES protocol [draft-ietf-forces-tcptml-04] (27 pages) - ForCES Transport Mapping Layer (TML) Service Primitives [draft-ietf-forces-tmlsp-01] (25 pages) Requests for Comments: RFC3549: Linux Netlink as an IP Services Protocol (32 pages) RFC3654: Requirements for Separation of IP Control and Forwarding (16 pages) RFC3746: Forwarding and Control Element Separation (ForCES) Framework (40 pages) RFC5810: Forwarding and Control Element Separation (ForCES) Protocol Specification (127 pages) RFC5811: SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol (29 pages) RFC5812: Forwarding and Control Element Separation (ForCES) Forwarding Element Model (132 pages) * Replaces DRAFT-ANDERSON-FORCES-MODEL RFC5813: Forwarding and Control Element Separation (ForCES) MIB (20 pages) * Replaces DRAFT-HAAS-FORCES-MIB RFC6041: Forwarding and Control Element Separation (ForCES) Applicability Statement (14 pages) RFC6053: Implementation Report for Forwarding and Control Element Separation (ForCES) (38 pages) IS-IS for IP Internets (isis) ----------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Chris Hopps David Ward Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Stewart Bryant Mailing Lists: General Discussion: isis-wg@ietf.org To Subscribe: isis-wg-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/isis-wg/ Description of Working Group: IS-IS is an IGP specified and standarized by ISO and incorporating extensions to support IP. It has been deployed successfully in the Internet for several years years. The IS-IS Working Group is chartered to document current protocol implementation practices and improvements, as well as to propose further extensions to be used within the scope of IS-IS and IP routing. Short term, the WG is expected to deliver a set of documents describing common implementation practices and extensions necessary to scale the protocol. These specifications will encourage multiple, inter-operable vendor implementations. This working group will interact with other standards bodies that have responsibility for standardizing IS-IS. The status of the WG documents maintained by the WG chairs can be found at http://skat.usc.edu/~tli/Schedule.htm. Goals and Milestones: Done - Submit I-D on IS-IS Traffic Engineering Extensions Done - Submit I-D on IS-IS HMAC-MD5 Authentication Done - Submit I-D on Maintaining more than 255 adjacencies in IS-IS Done - Submit I-D on Optional Checksums on IIHs, CSNPs, and PSNPs in IS-IS Done - Submit I-D on IS-IS MIB Done - Submit IS-IS Traffic Engineering Extensions to IESG for publication as an Informational RFC Done - Submit IS-IS HMAC-MD5 Authentication to IESG for publication as an Informational RFC Done - Submit Maintaining more than 255 adjacencies in IS-IS to IESG for publication as an Informational RFC Done - Submit Optional Checksums on IIHs, CSNPs, and PSNPs in IS-IS to IESG for publication as an Informational RFC Done - Submit IPv6 to IESG for publication as an Informational RFC Done - Submit M-ISIS to IESG for publication as an Informational RFC Done - Submit 256+ Fragments to IESG for publication as an Informational RFC Done - Submit Administrative Tags to IESG for publication as an Informational RFC Done - Submit Interoperable IP Networks to IESG for publication as an Informational RFC Done - Submit Interoperable Networks to IESG for publication as an Informational RFC Done - Submit P2P over LAN to IESG for publication as an Informational RFC Done - Submit Gracefull Restart to IESG for publication as an Informational RFC Jun 2005 - Submit Experimental TLVs to IESG for publication as an Informational RFC Done - Submit Definition of an IS-IS Link Attribute sub-TLV to IESG for publication as Informational RFC Done - Submit A Policy Control Mechanism in IS-IS Using Administrative Tags to IESG for publication as Informational RFC Done - Submit IS-IS MIB to IESG for consideration as a Proposed Standard Done - Submit Multi Topology (MT) Routing in ISIS to IESG for publication as Informational RFC Done - Submit IS-IS extensions for advertising router information to IESG for publication as Informational RFC Done - Submit Routing IPv6 with IS-IS to IESG for publication as Proposed Standard Nov 2005 - Review WG's priorities and future potential Internet-Drafts: - Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies [draft-ietf-isis-3way-05] (9 pages) - A Policy Control Mechanism in IS-IS Using Administrative Tags [draft-ietf-isis-admin-tags-04] (9 pages) - Further Integration of IS-IS; Appletalk, IPX, and Other Protocols [draft-ietf-isis-atipx-00] (24 pages) - IS-IS Automatic Encapsulation [draft-ietf-isis-auto-encap-03] (24 pages) - IS-IS BFD-Enabled TLV [draft-ietf-isis-bfd-tlv-03] (8 pages) - Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information [draft-ietf-isis-caps-07] (8 pages) - Extensions to ISIS for support of Diff-Serv-aware MPLS Traffic Engineering [draft-ietf-isis-diff-te-00] (7 pages) - Domain-wide Prefix Distribution with Two-Level IS-IS [draft-ietf-isis-domain-wide-03] (10 pages) - Dynamic Hostname Exchange Mechanism for IS-IS [draft-ietf-isis-dyname-03] (4 pages) - TLV for Experimental Use [draft-ietf-isis-experimental-tlv-05] (0 pages) - Extended Ethernet Frame Size Support [draft-ietf-isis-ext-eth-01] (0 pages) - Extending the Number of Intermediate System to Intermediate System (IS-IS) Link State PDU (LSP) Fragments Beyond the 256 Limit [draft-ietf-isis-ext-lsp-frags-02] (13 pages) - Advertising Generic Information in IS-IS [draft-ietf-isis-genapp-04] (12 pages) - Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) [draft-ietf-isis-gmpls-extensions-19] (12 pages) - Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication [draft-ietf-isis-hmac-04] (6 pages) - IS-IS Generic Cryptographic Authentication [draft-ietf-isis-hmac-sha-07] (12 pages) - IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging [draft-ietf-isis-ieee-aq-05] (40 pages) - Point-to-Point Operation over LAN in Link State Routing Protocols [draft-ietf-isis-igp-p2p-over-lan-06] (10 pages) - Recommendations for Interoperable IP Networks using IS-IS [draft-ietf-isis-interoperable-01] (20 pages) - Recommendations for Interoperable IP Networks using Intermediate System to Intermediate System (IS-IS) [draft-ietf-isis-ip-interoperable-02] (12 pages) - Routing IPv6 with IS-IS [draft-ietf-isis-ipv6-07] (6 pages) - IPv6 Traffic Engineering in IS-IS [draft-ietf-isis-ipv6-te-08] (10 pages) - Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS) [draft-ietf-isis-iso-interoperable-02] (15 pages) - L1/L2 Optimal IS-IS Routing [draft-ietf-isis-l1l2-00] (7 pages) - Extensions to IS-IS for Layer-2 Systems [draft-ietf-isis-layer2-11] (11 pages) - Definition of an IS-IS Link Attribute Sub-TLV [draft-ietf-isis-link-attr-03] (6 pages) - IS-IS Multi-Instance [draft-ietf-isis-mi-06] (14 pages) - Integrated IS-IS Management Information Base [draft-ietf-isis-mib-04] (97 pages) - Multiple Levels of Hierarchy with IS-IS [draft-ietf-isis-multilevel-routing-00] (10 pages) - Routing over Nonbroadcast Multiaccess Links [draft-ietf-isis-nbma-00] (39 pages) - IS-IS Optimized Multipath (ISIS-OMP) [draft-ietf-isis-omp-01] (8 pages) - IS-IS Operational Enhancements for Network Maintenance Events [draft-ietf-isis-oper-enhance-00] (6 pages) - Experience with the Integrated ISIS Protocol [draft-ietf-isis-opexp-01] (25 pages) - TLV for Proprietary Use [draft-ietf-isis-proprietary-tlv-00] (5 pages) - Integrated ISIS Protocol Analysis [draft-ietf-isis-prot-anal-01] (20 pages) - Purge Originator Identification TLV for IS-IS [draft-ietf-isis-purge-tlv-05] (6 pages) - IS-IS Registry Extension for Purges [draft-ietf-isis-reg-purge-01] (5 pages) - Restart Signaling for Intermediate System to Intermediate System (IS-IS) [draft-ietf-isis-restart-05] (21 pages) - IS-IS Reverse Metric TLV for Network Maintenance Events [draft-ietf-isis-reverse-metric-00] (14 pages) - Dynamic Hostname Exchange Mechanism for IS-IS [draft-ietf-isis-rfc2763bis-00] (9 pages) - Domain-Wide Prefix Distribution with Two-Level IS-IS [draft-ietf-isis-rfc2966bis-03] (16 pages) - IS-IS Transient Blackhole Avoidance [draft-ietf-isis-rfc3277bis-00] (9 pages) - Three-Way Handshake for IS-IS Point-to-Point Adjacencies [draft-ietf-isis-rfc3373bis-01] (14 pages) - IS-IS Cryptographic Authentication [draft-ietf-isis-rfc3567bis-03] (11 pages) - Restart Signaling for IS-IS [draft-ietf-isis-rfc3847bis-00] (22 pages) - IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) [draft-ietf-isis-rfc4205bis-00] (12 pages) - Use of OSI IS-IS for Routing in TCP/IP and Multi-Protocol Environments [draft-ietf-isis-tcpip-01] (98 pages) - IS-IS Extensions for Traffic Engineering [draft-ietf-isis-te-bis-00] (21 pages) - Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE) [draft-ietf-isis-traffic-05] (13 pages) - Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance [draft-ietf-isis-transient-01] (6 pages) - Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS [draft-ietf-isis-trill-05] (30 pages) - Maintaining more than 255 adjacencies in IS-IS [draft-ietf-isis-wg-255adj-02] (6 pages) - Simplified Extension of Link State PDU (LSP) Space for IS-IS [draft-ietf-isis-wg-extlsp-05] (15 pages) - IS-IS Mesh Groups [draft-ietf-isis-wg-mesh-group-01] (9 pages) - Management Information Base for Intermediate System to Intermediate System (IS-IS) [draft-ietf-isis-wg-mib-26] (104 pages) - M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs) [draft-ietf-isis-wg-multi-topology-12] (13 pages) - IS-IS over IPv4 [draft-ietf-isis-wg-over-ip-02] (8 pages) - Optional Checksums in Intermediate System to Intermediate System (ISIS) [draft-ietf-isis-wg-snp-checksum-02] (5 pages) - Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System [draft-ietf-isis-wg-tlv-codepoints-00] (0 pages) - Extended Ethernet Frame Size Support [draft-kaplan-isis-ext-eth-02] (0 pages) Requests for Comments: RFC2763: Dynamic Hostname Exchange Mechanism for IS-IS (4 pages) * Obsoletes RFC5301 RFC2966: Domain-wide Prefix Distribution with Two-Level IS-IS (10 pages) * Obsoletes RFC5302 RFC2973: IS-IS Mesh Groups (9 pages) RFC3277: Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance (6 pages) RFC3358: Optional Checksums in Intermediate System to Intermediate System (ISIS) (5 pages) RFC3359: Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System (0 pages) RFC3373: Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies (9 pages) * Obsoletes RFC5303 RFC3567: Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication (6 pages) * Obsoletes RFC5304 RFC3719: Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS) (15 pages) RFC3784: Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE) (13 pages) * Obsoletes RFC5305 * Updates RFC4205 RFC3786: Extending the Number of Intermediate System to Intermediate System (IS-IS) Link State PDU (LSP) Fragments Beyond the 256 Limit (13 pages) * Obsoletes RFC5311 RFC3787: Recommendations for Interoperable IP Networks using Intermediate System to Intermediate System (IS-IS) (12 pages) RFC3847: Restart Signaling for Intermediate System to Intermediate System (IS-IS) (21 pages) * Obsoletes RFC5306 RFC4205: Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) (12 pages) * Updates RFC3784 * Obsoletes RFC5307 RFC4444: Management Information Base for Intermediate System to Intermediate System (IS-IS) (104 pages) RFC4971: Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information (8 pages) RFC5029: Definition of an IS-IS Link Attribute Sub-TLV (6 pages) RFC5120: M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs) (13 pages) RFC5130: A Policy Control Mechanism in IS-IS Using Administrative Tags (9 pages) RFC5301: Dynamic Hostname Exchange Mechanism for IS-IS (9 pages) * Obsoletes RFC2763 * Updates RFC6232 RFC5302: Domain-Wide Prefix Distribution with Two-Level IS-IS (16 pages) * Updates RFC1195 * Obsoletes RFC2966 RFC5303: Three-Way Handshake for IS-IS Point-to-Point Adjacencies (14 pages) * Obsoletes RFC3373 RFC5304: IS-IS Cryptographic Authentication (11 pages) * Updates RFC1195 * Obsoletes RFC3567 * Updates RFC6233 * Updates RFC6232 RFC5305: IS-IS Extensions for Traffic Engineering (21 pages) * Obsoletes RFC3784 * Updates RFC5307 RFC5306: Restart Signaling for IS-IS (22 pages) * Obsoletes RFC3847 RFC5307: IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) (12 pages) * Obsoletes RFC4205 * Updates RFC5305 * Updates RFC6001 * Updates RFC6002 RFC5308: Routing IPv6 with IS-IS (6 pages) RFC5309: Point-to-Point Operation over LAN in Link State Routing Protocols (10 pages) RFC5310: IS-IS Generic Cryptographic Authentication (12 pages) * Updates RFC6233 * Updates RFC6232 RFC5311: Simplified Extension of Link State PDU (LSP) Space for IS-IS (15 pages) * Obsoletes RFC3786 RFC6119: IPv6 Traffic Engineering in IS-IS (10 pages) RFC6165: Extensions to IS-IS for Layer-2 Systems (11 pages) RFC6213: IS-IS BFD-Enabled TLV (8 pages) RFC6232: Purge Originator Identification TLV for IS-IS (6 pages) * Updates RFC5301 * Updates RFC5304 * Updates RFC5310 RFC6233: IS-IS Registry Extension for Purges (5 pages) * Updates RFC3563 * Updates RFC5304 * Updates RFC5310 RFC6326: Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS (30 pages) * Replaces DRAFT-EASTLAKE-ISIS-TRILL RFC6329: IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging (40 pages) Inter-Domain Routing (idr) -------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Susan Hares John Scudder Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Stewart Bryant Tech Advisors: Sharon Chisholm Randall Atkinson Mailing Lists: General Discussion: idr@ietf.org To Subscribe: idr-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/idr/ Description of Working Group: The Inter-Domain Routing Working Group is chartered to standardize, develop, and support the Border Gateway Protocol Version 4 (BGP-4) [RFC 4271] capable of supporting policy based routing for TCP/IP internets. The main objective of the working group is to support the use of BGP-4 by IP version 4 and IP version 6 networks. The working group will also continue to work on improving the robustness and scalability of BGP. IDR will review extensions made to BGP in other working groups at least at WG document adoption and during working group last calls. The IDR working group will also provide advice and guidance on BGP to other working groups as requested. Work Items: The IDR working group will work on correctness, robustness and scalability of the BGP protocol, as well as clarity and accuracy of the BGP document set. The group will also work on extensions beyond these areas when specifically added to the charter. The current additional work items are: - Relax the definition of BGP identifiers to only require AS-wide uniqueness. This change must be made in a backward compatible way. - Specify a means to non-disruptively introduce new BGP Capabilities to an existing BGP session. - Upgrade of the base BGP specification to Full Standard - Define AS_PATH based Outbound Route Filtering. - MIB v2 for BGP-4 - Augment the BGP multiprotocol extensions to support the use of multiple concurrent sessions between a given pair of BGP speakers. Each session is used to transport routes related by some session- based attribute such as AFI/SAFI. This will provide an alternative to the MP-BGP approach of multiplexing all routes onto a single connection. - Support for four-octet AS Numbers in BGP. - Revisions to the BGP 'Minimum Route Advertisement Interval' deprecating the previously recommended values and allowing for withdrawals to be exempted from the MRAI. - Advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. Each path is identified by a path identifier in addition to the address prefix. - Revised error handling rules for optional transitive BGP attributes so that a BGP speaker is no longer required to reset the session over which a malformed attribute is received. Provide guidelines for authors of documents that define new optional transitive attributes, and re-assess procedures for existing optional transitive attributes - Specify Link Bandwidth Extended Community for use in unequal cost load balancing. - The definition of an "Accumulated IGP Metric" attribute for BGP to report the sum of the metric of each link along the path. This attribute is for use in a restricted environment where: - all ASes are subject to the administrative control - some form of tunneling is used to deliver a packet to its next BGP hop - where the path for a route leads outside the AS to which the BGP speaker adding the attribute belongs. - Advertisement of the best external route in BGP to assist with resolution of the next hop in the chosen data plane. Goals and Milestones: Done - Submit to BGP Capability Advertisement to the IESG Done - Submit BGP Security Vulnerabilities Analysis to IESG as an Informational Done - Submit BGP4 MIB to IESG as a Proposed Standard Done - Submit BGP4 document to IESG as a Draft Standard Done - Submit BGP Graceful Restart to IESG as a Proposed Standard Done - Submit Extended Communities draft to IESG as a Proposed Standard Done - Submit revised text on Multi-Protocol BGP (rfc2858bis) to IESG as a Draft Standard Done - Submit Subcodes for BGP Cease Notification Message to IESG as a Proposed Standard Done - Submit 4-byte AS ID to IESG as a Proposed Standard Done - Submit Outbound Route Filter, Prefix and ASpath ORF draft to IESG as a Proposed Standard Done - Prefix and ASpath ORF draft to IESG as a Proposed Standard Mar 2010 - Solicit work items for scalability improvements Aug 2010 - Submit AS-wide Unique BGP Identifier for BGP-4 to IESG as a Proposed Standard Aug 2010 - Submit Dynamic Capability for BGP-4 to IESG as a Proposed Standard Aug 2010 - Submit ASpath ORF draft to IESG as a Proposed Standard Aug 2010 - Submit MIB v2 for BGP-4 to IESG as a Proposed Standard Nov 2010 - Submit BGP Support for Four-octet AS Number Space (revised version) to IESG as a Proposed Standard Nov 2010 - Submit Revisions to the BGP 'Minimum Route Advertisement Interval' to IESG as a Proposed Standard Nov 2010 - Submit Advertisement of Multiple Paths in BGP to IESG as a Proposed Standard Nov 2010 - Submit BGP Link Bandwidth Extended Community to IESG as a Proposed Standard Nov 2010 - Submit Advertisement of the best external route in BGP to IESG as a Proposed Standard Dec 2010 - Submit Multisession BGP to IESG as a Proposed Standard Dec 2010 - Submit Error Handling for Optional Transitive BGP Attributes to IESG as a Proposed Standard Dec 2010 - Submit ASpath ORF to IESG as a Proposed Standard Dec 2010 - Revise WG charter Mar 2011 - Submit The Accumulated IGP Metric Attribute for BGP to IESG as a Proposed Standard Mar 2011 - Progress base BGP specification (RFC 4271) as Full Standard Internet-Drafts: - A BGP/IDRP Route Server alternative to a full mesh routing [draft-haskin-bgp-idrp-mesh-routing-00] (17 pages) - BGP Protocol Analysis [draft-ietf-bgp-analysis-00] (0 pages) - Application of the Border Gateway Protocol in the Internet [draft-ietf-bgp-application-03] (19 pages) - Border Gateway Protocol 3 (BGP-3) [draft-ietf-bgp-bgp3-00] (35 pages) - A Border Gateway Protocol 4 (BGP-4) [draft-ietf-bgp-bgp4-09] (58 pages) - BGP-4 Protocol Document Roadmap and Implementation Experience [draft-ietf-bgp-bgp4-implement-01] (5 pages) - Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol [draft-ietf-bgp-defaultroute-01] (2 pages) - Experience with the BGP Protocol [draft-ietf-bgp-experience-00] (9 pages) - Application of the Border Gateway Protocol and IDRP for IP in the Internet [draft-ietf-bgp-idrp-usage-00] (21 pages) - Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2 [draft-ietf-bgp-mibv4-05] (21 pages) - IP Multicast Communications Using BGP [draft-ietf-bgp-multicast-02] (10 pages) - Border Gateway Protocol NEXT-HOP-SNPA Attribute [draft-ietf-bgp-nexthop-01] (3 pages) - BGP OSPF Interaction [draft-ietf-bgp-ospfinteract-06] (15 pages) - Application of the Border Gateway Protocol in the Internet [draft-ietf-bgp-usage-01] (7 pages) - Advertisement of Multiple Paths in BGP [draft-ietf-idr-add-paths-06] (8 pages) - Best Practices for Advertisement of Multiple Paths in IBGP [draft-ietf-idr-add-paths-guidelines-02] (22 pages) - BGP Advisory Message [draft-ietf-idr-advisory-00] (7 pages) - A Framework for Inter-Domain Route Aggregation [draft-ietf-idr-aggregation-framework-04] (12 pages) - Route Aggregation Tutorial [draft-ietf-idr-aggregation-tutorial-01] (8 pages) - The Accumulated IGP Metric Attribute for BGP [draft-ietf-idr-aigp-07] (14 pages) - Using a Dedicated AS for Sites Homed to a Single Provider [draft-ietf-idr-as-dedicated-00] (6 pages) - Autonomous System (AS) Number Reservation for Documentation Use [draft-ietf-idr-as-documentation-reservation-00] (5 pages) - The AS_HOPCOUNT Path Attribute [draft-ietf-idr-as-hopcount-00] (16 pages) - The AS_PATHLIMIT Path Attribute [draft-ietf-idr-as-pathlimit-03] (16 pages) - Textual Representation of Autonomous System (AS) Numbers [draft-ietf-idr-as-representation-01] (4 pages) - Codification of AS 0 processing. [draft-ietf-idr-as0-04] (7 pages) - BGP Support for Four-octet AS Number Space [draft-ietf-idr-as4bytes-13] (10 pages) - Generic Subtype for BGP Four-octet AS specific extended community [draft-ietf-idr-as4octet-extcomm-generic-subtype-05] (6 pages) - Aspath Based Outbound Route Filter for BGP-4 [draft-ietf-idr-aspath-orf-09] (4 pages) - Guidelines for creation, selection, and registration of an Autonomous System (AS) [draft-ietf-idr-autosys-guide-03] (12 pages) - Avoid BGP Best Path Transitions from One External to Another [draft-ietf-idr-avoid-transition-05] (7 pages) - Advertisement of the best external route in BGP [draft-ietf-idr-best-external-05] (21 pages) - BGP-4 Protocol Analysis [draft-ietf-idr-bgp-analysis-07] (20 pages) - BGP Bestpath Selection Criteria Enhancement [draft-ietf-idr-bgp-bestpath-selection-criteria-05] (9 pages) - Autonomous System Confederations for BGP [draft-ietf-idr-bgp-confed-00] (7 pages) - Autonomous System Confederations for BGP [draft-ietf-idr-bgp-confed-rfc1965bis-01] (10 pages) - Destination Preference Attribute for BGP [draft-ietf-idr-bgp-dpa-05] (4 pages) - Enhanced Route Refresh Capability for BGP-4 [draft-ietf-idr-bgp-enhanced-route-refresh-01] (6 pages) - BGP Extended Communities Attribute [draft-ietf-idr-bgp-ext-communities-09] (12 pages) - Extended Message support for BGP [draft-ietf-idr-bgp-extended-messages-02] (5 pages) - Notification Message support for BGP Graceful Restart [draft-ietf-idr-bgp-gr-notification-00] (8 pages) - BGP Graceful Restart - Implementation Survey [draft-ietf-idr-bgp-gr-survey-01] (10 pages) - Autonomous-System-Wide Unique BGP Identifier for BGP-4 [draft-ietf-idr-bgp-identifier-14] (5 pages) - BGP-4 Implementation Report [draft-ietf-idr-bgp-implementation-02] (86 pages) - IPv6 Extensions for Route Target Distribution [draft-ietf-idr-bgp-ipv6-rt-constrain-01] (7 pages) - Issues in Revising BGP-4 (RFC1771 to RFC4271) [draft-ietf-idr-bgp-issues-06] (170 pages) - BGP AS Path Metrics [draft-ietf-idr-bgp-metrics-00] (8 pages) - BGP-4 MIB Implementation Survey [draft-ietf-idr-bgp-mibagent-survey-02] (37 pages) - Multisession BGP [draft-ietf-idr-bgp-multisession-06] (19 pages) - Carrying next-hop cost information in BGP [draft-ietf-idr-bgp-nh-cost-01] (10 pages) - BGP Optimal Route Reflection (BGP-ORR) [draft-ietf-idr-bgp-optimal-route-reflection-02] (19 pages) - Address-Prefix-Based Outbound Route Filter for BGP-4 [draft-ietf-idr-bgp-prefix-orf-05] (6 pages) - Route Refresh Capability for BGP-4 [draft-ietf-idr-bgp-route-refresh-01] (4 pages) - Protection of BGP Sessions via the TCP MD5 Signature Option [draft-ietf-idr-bgp-tcp-md5-00] (5 pages) - Protection of BGP Sessions via the TCP MD5 Signature Option [draft-ietf-idr-bgp-tcp-md5bad-01] (5 pages) - BGP Security Vulnerabilities Analysis [draft-ietf-idr-bgp-vuln-01] (24 pages) - A Border Gateway Protocol 4 (BGP-4) [draft-ietf-idr-bgp4-26] (100 pages) - BGP-4 Protocol Analysis [draft-ietf-idr-bgp4-analysis-00] (10 pages) - Capabilities Advertisement with BGP-4 [draft-ietf-idr-bgp4-cap-neg-05] (5 pages) - Experience with the BGP-4 protocol [draft-ietf-idr-bgp4-experience-00] (9 pages) - Experience with the BGP-4 Protocol [draft-ietf-idr-bgp4-experience-protocol-05] (23 pages) - Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing [draft-ietf-idr-bgp4-ipv6-01] (5 pages) - Definitions of Managed Objects for BGP-4 [draft-ietf-idr-bgp4-mib-15] (37 pages) - Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4), Second Version [draft-ietf-idr-bgp4-mibv2-13] (45 pages) - Definitions of Textual Conventions for the Management of the Fourth Version of Border Gateway Protocol (BGP-4) [draft-ietf-idr-bgp4-mibv2-tc-mib-03] (6 pages) - Multiprotocol Extensions for BGP-4 [draft-ietf-idr-bgp4-multiprotocol-01] (9 pages) - Multiprotocol Extensions for BGP-4 [draft-ietf-idr-bgp4-multiprotocol-v2-04] (11 pages) - Operational Experience with the BGP-4 protocol [draft-ietf-idr-bgp4-op-experience-02] (9 pages) - BGP-4 Requirement Satisfaction Report [draft-ietf-idr-bgp4-stdreport1-02] (3 pages) - BGP4/IDRP for IP---OSPF Interaction [draft-ietf-idr-bgp4ospf-interact-07] (19 pages) - Subcodes for BGP Cease Notification Message [draft-ietf-idr-cease-subcode-07] (6 pages) - BGP Communities Attribute [draft-ietf-idr-communities-00] (5 pages) - An Application of the BGP Community Attribute in Multi-home Routing [draft-ietf-idr-community-00] (10 pages) - An Application of the BGP Community Attribute in Multi-home Routing [draft-ietf-idr-community-usage-00] (10 pages) - BGP Custom Decision Process [draft-ietf-idr-custom-decision-00] (8 pages) - Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP [draft-ietf-idr-deprecate-as-sets-06] (6 pages) - Application of the BGP Destination Preference Attribute in Implementing Symmetric Routing [draft-ietf-idr-dpa-application-02] (8 pages) - Dynamic Capability for BGP-4 [draft-ietf-idr-dynamic-cap-14] (7 pages) - BGP Encapsulation SAFI and BGP Tunnel Encapsulation Attribute [draft-ietf-idr-encaps-safi-00] (13 pages) - Accelerated Routing Convergence for BGP Graceful Restart [draft-ietf-idr-enhanced-gr-00] (9 pages) - Revised Error Handling for BGP UPDATE Messages [draft-ietf-idr-error-handling-01] (10 pages) - Extended Optional Parameters Length for BGP OPEN Message [draft-ietf-idr-ext-opt-param-02] (5 pages) - Dissemination of Flow Specification Rules [draft-ietf-idr-flow-spec-09] (24 pages) - Dissemination of Flow Specification Rules for IPv6 [draft-ietf-idr-flow-spec-v6-03] (8 pages) - Subcodes for BGP Finite State Machine Error [draft-ietf-idr-fsm-subcode-03] (6 pages) - IDRP for IP v4 and v6 [draft-ietf-idr-idrp-v4v6-02] (20 pages) - Inter-Domain Routing Protocol, Version 2 [draft-ietf-idr-idrp2-00] (110 pages) - Internet Exchange Route Server [draft-ietf-idr-ix-bgp-route-server-00] (11 pages) - Automatic Route Target Filtering for legacy PEs [draft-ietf-idr-legacy-rtc-00] (11 pages) - BGP Link Bandwidth Extended Community [draft-ietf-idr-link-bandwidth-04] (5 pages) - Key Management Considerations for the TCP MD5 Signature Option [draft-ietf-idr-md5-keys-00] (7 pages) - Revisions to the BGP 'Minimum Route Advertisement Interval' [draft-ietf-idr-mrai-dep-04] (4 pages) - BGP OPERATIONAL Message [draft-ietf-idr-operational-message-00] (29 pages) - Revised Error Handling for BGP UPDATE Messages [draft-ietf-idr-optional-transitive-04] (10 pages) - Configuring IDRP Confederations [draft-ietf-idr-rdc-config-01] (5 pages) - Assigned BGP extended communities [draft-ietf-idr-reserved-extended-communities-02] (5 pages) - Graceful Restart Mechanism for BGP [draft-ietf-idr-restart-13] (11 pages) - Reclassification of RFC 1863 to Historic [draft-ietf-idr-rfc1863-historic-00] (4 pages) - Protection of BGP Sessions via the TCP MD5 Signature Option [draft-ietf-idr-rfc2385bis-01] (6 pages) - BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) [draft-ietf-idr-rfc2796bis-02] (12 pages) - Capabilities Advertisement with BGP-4 [draft-ietf-idr-rfc2842bis-01] (5 pages) - Multiprotocol Extensions for BGP-4 [draft-ietf-idr-rfc2858bis-10] (0 pages) - Autonomous System Confederations for BGP [draft-ietf-idr-rfc3065bis-06] (17 pages) - Capabilities Advertisement with BGP-4 [draft-ietf-idr-rfc3392bis-05] (7 pages) - Multiprotocol Extensions for BGP-4 [draft-ietf-idr-rfc4760bis-03] (13 pages) - BGP Support for Four-octet AS Number Space [draft-ietf-idr-rfc4893bis-06] (12 pages) - Extensions for Selective Updates in Inter Domain Routing [draft-ietf-idr-rifs-00] (9 pages) - BGP Route Flap Damping [draft-ietf-idr-route-damp-03] (36 pages) - Outbound Route Filtering Capability for BGP-4 [draft-ietf-idr-route-filter-17] (12 pages) - Border Gateway Protocol (BGP) Persistent Route Oscillation Condition [draft-ietf-idr-route-oscillation-00] (20 pages) - BGP Route Reflection An alternative to full mesh IBGP [draft-ietf-idr-route-reflect-02] (8 pages) - BGP Route Reflection - An Alternative to Full Mesh IBGP [draft-ietf-idr-route-reflect-v2-03] (10 pages) - Current Practice of Implementing Symmetric Routing and Load Sharing in the Multi-Provider Internet [draft-ietf-idr-symm-multi-prov-02] (13 pages) - Advertising an IPv4 NLRI with an IPv6 Next Hop [draft-ietf-idr-v4nlri-v6nh-01] (10 pages) - IDRP for SIP [draft-ietf-ipidrp-sip-01] (9 pages) - Border Gateway Protocol (BGP) [draft-ietf-iwg-bgp-00] (0 pages) - Definitions of Managed Objects for the Border Gateway Protocol: Version 3 [draft-ietf-iwg-bgp-mib-02] (13 pages) - Application of the Border Gateway Protocol in the Internet [draft-ietf-iwg-bgpapplication-00] (13 pages) - Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE) [draft-ooms-v6ops-bgp-tunnel-07] (14 pages) Requests for Comments: BCP0006: Guidelines for creation, selection, and registration of an Autonomous System (AS) (12 pages) BCP0172: Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP (6 pages) RFC1163: Border Gateway Protocol (BGP) (0 pages) * Obsoletes RFC1105 * Obsoletes RFC1267 RFC1164: Application of the Border Gateway Protocol in the Internet (13 pages) * Obsoletes RFC1268 RFC1265: BGP Protocol Analysis (0 pages) RFC1266: Experience with the BGP Protocol (9 pages) RFC1267: Border Gateway Protocol 3 (BGP-3) (35 pages) * Obsoletes RFC1163 RFC1268: Application of the Border Gateway Protocol in the Internet (7 pages) * Obsoletes RFC1164 * Obsoletes RFC1655 RFC1269: Definitions of Managed Objects for the Border Gateway Protocol: Version 3 (13 pages) * Obsoletes RFC4273 RFC1364: BGP OSPF Interaction (15 pages) * Obsoletes RFC1403 RFC1397: Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol (2 pages) RFC1654: A Border Gateway Protocol 4 (BGP-4) (58 pages) * Obsoletes RFC1771 RFC1655: Application of the Border Gateway Protocol in the Internet (19 pages) * Obsoletes RFC1268 * Obsoletes RFC1772 RFC1656: BGP-4 Protocol Document Roadmap and Implementation Experience (5 pages) * Obsoletes RFC1773 RFC1657: Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2 (21 pages) * Obsoletes RFC4273 RFC1745: BGP4/IDRP for IP---OSPF Interaction (19 pages) RFC1773: Experience with the BGP-4 protocol (9 pages) * Obsoletes RFC1656 RFC1774: BGP-4 Protocol Analysis (10 pages) RFC1863: A BGP/IDRP Route Server alternative to a full mesh routing (17 pages) * Obsoletes RFC4223 RFC1930: Guidelines for creation, selection, and registration of an Autonomous System (AS) (12 pages) RFC1965: Autonomous System Confederations for BGP (7 pages) * Obsoletes RFC3065 RFC1966: BGP Route Reflection An alternative to full mesh IBGP (8 pages) * Obsoletes RFC4456 * Updates RFC2796 RFC1997: BGP Communities Attribute (5 pages) RFC1998: An Application of the BGP Community Attribute in Multi-home Routing (10 pages) RFC2270: Using a Dedicated AS for Sites Homed to a Single Provider (6 pages) RFC2283: Multiprotocol Extensions for BGP-4 (9 pages) * Obsoletes RFC2858 RFC2385: Protection of BGP Sessions via the TCP MD5 Signature Option (5 pages) * Obsoletes RFC5925 RFC2439: BGP Route Flap Damping (36 pages) RFC2519: A Framework for Inter-Domain Route Aggregation (12 pages) RFC2545: Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing (5 pages) RFC2796: BGP Route Reflection - An Alternative to Full Mesh IBGP (10 pages) * Updates RFC1966 * Obsoletes RFC4456 RFC2842: Capabilities Advertisement with BGP-4 (5 pages) * Obsoletes RFC3392 RFC2858: Multiprotocol Extensions for BGP-4 (11 pages) * Obsoletes RFC2283 * Obsoletes RFC4760 RFC2918: Route Refresh Capability for BGP-4 (4 pages) RFC3065: Autonomous System Confederations for BGP (10 pages) * Obsoletes RFC1965 * Obsoletes RFC5065 RFC3345: Border Gateway Protocol (BGP) Persistent Route Oscillation Condition (20 pages) RFC3392: Capabilities Advertisement with BGP-4 (5 pages) * Obsoletes RFC2842 * Obsoletes RFC5492 RFC3562: Key Management Considerations for the TCP MD5 Signature Option (7 pages) RFC4223: Reclassification of RFC 1863 to Historic (4 pages) * Obsoletes RFC1863 RFC4271: A Border Gateway Protocol 4 (BGP-4) (100 pages) * Obsoletes RFC1771 * Updates RFC6286 * Updates RFC6608 RFC4272: BGP Security Vulnerabilities Analysis (24 pages) RFC4273: Definitions of Managed Objects for BGP-4 (37 pages) * Obsoletes RFC1269 * Obsoletes RFC1657 RFC4274: BGP-4 Protocol Analysis (20 pages) RFC4275: BGP-4 MIB Implementation Survey (37 pages) RFC4276: BGP-4 Implementation Report (86 pages) RFC4277: Experience with the BGP-4 Protocol (23 pages) RFC4360: BGP Extended Communities Attribute (12 pages) RFC4456: BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) (12 pages) * Obsoletes RFC1966 * Obsoletes RFC2796 RFC4486: Subcodes for BGP Cease Notification Message (6 pages) RFC4724: Graceful Restart Mechanism for BGP (11 pages) RFC4760: Multiprotocol Extensions for BGP-4 (0 pages) * Obsoletes RFC2858 RFC4798: Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE) (14 pages) RFC4893: BGP Support for Four-octet AS Number Space (10 pages) RFC5004: Avoid BGP Best Path Transitions from One External to Another (7 pages) RFC5065: Autonomous System Confederations for BGP (17 pages) * Obsoletes RFC3065 RFC5291: Outbound Route Filtering Capability for BGP-4 (12 pages) RFC5292: Address-Prefix-Based Outbound Route Filter for BGP-4 (6 pages) RFC5396: Textual Representation of Autonomous System (AS) Numbers (4 pages) RFC5398: Autonomous System (AS) Number Reservation for Documentation Use (5 pages) RFC5492: Capabilities Advertisement with BGP-4 (7 pages) * Obsoletes RFC3392 RFC5575: Dissemination of Flow Specification Rules (24 pages) * Replaces DRAFT-MARQUES-IDR-FLOW-SPEC RFC6286: Autonomous-System-Wide Unique BGP Identifier for BGP-4 (5 pages) * Updates RFC4271 RFC6472: Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP (6 pages) RFC6608: Subcodes for BGP Finite State Machine Error (6 pages) * Replaces DRAFT-DONG-IDR-FSM-SUBCODE * Updates RFC4271 Keying and Authentication for Routing Protocols (karp) ------------------------------------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Brian Weis Joel M. Halpern Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Stewart Bryant Tech Advisor: Tim Polk Mailing Lists: General Discussion: karp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/karp Archive: http://www.ietf.org/mail-archive/web/karp/ Description of Working Group: The KARP working group is tasked to work with the routing protocol working groups in order to improve the communication security of the packets on the wire used by the routing protocols. This working group is concerned with message authentication, packet integrity, and denial of service (DoS) protection. At present, this charter explicitly excludes confidentiality and non-repudiation concerns. Authenticating the routing peer sending a message, and message integrity protection, will be provided through the use of per-packet cryptographic message authentication. Peer authentication will protect against unrecognized peers, imposter peers, and some DoS attacks aimed at routers. Protecting against misbehavior of an otherwise allowed peer router is outside the scope of this working group. Many routing protocols (or groups of protocols) already have some method for accomplishing cryptographic message authentication. In many or most cases existing methods are vulnerable to known attack, and some employ cryptographic algorithms that have been deprecated. While much work has been done to update authentication of routing protocols, current status is not consistently up to date. It is important to review and update those mechanisms to use modern security practices. Ensuring algorithm agility within routing protocols is of particular importance. A goal of the working group is to add incremental security to existing mechanisms rather than replacing them. Better deployable solutions to which vendors and operators can migrate is more important than getting a perfect security solution. Although there are many candidate routing protocols to evaluate, KARP must by necessity begin with a restricted focus. The initial set of routing protocols in scope include BGP, OSPFv2, OSPFv3, PCE, PIM, LDP, RSVP-TE, ISIS, BFD, LMP, and MSDP. The working group must coordinate very closely with other working groups, such as: - Routing protocol working groups for any routing protocol being evaluated. This coordination will include cooperatively determining the current or already planned state of the security work in the protocol. It will also include ensuring that any proposed mechanisms are consistent with the architecture and use of the protocol. Also, any specific proposal accepted as a KARP document will be developed in cooperation with the concerned protocol working group. - Security area working groups for cryptographic advice, and/or key management protocol support. Cryptographic protocol support may be required in order to support certain KARP WG milestones. Coordination with an appropriate working group in the security area would be necessary in order to get the appropriate expertise in completing a milestone. This charter provides for preliminary work in this space, although it is expected that detailed work items will be added to the charter when the problem has been better analyzed. For example, this may include a key management protocol by which routing protcols automatically negotiate keying material and policy. More about the use of a key management protocol will be captured in a framework document described below. - OPSEC working group for advice on best practices to create and use integrity keys used with routing protocol message authentication. KARP will also coordinate with other Operations and Management area WGs and/or experts in order to identify operational impacts on existing routing protocols and to identify any management extensions that may be required. Routing protocols use a range of transport mechanisms and communication relationships. There are also differences in details among the various protocols. The working group will attempt to describe the security relevant characteristics of routings protocols, such as the use or non-use of TCP, or the frequent use of group communication versus purely pairwise communication. Using these characteristics, the working group will then provide suitable common frameworks that can be applied, and tailored, to improve the communication security of the routing protocols. In later phases, it is expected that the working group will investigate the suitably of defining conceptual structures and APIs, so as to enable further work to be more effective. Work Items: - Determine current threats to the routing protocol operation, and define general requirements for cryptographic authentication of routing protocols. A primary source for this document should be draft-lebovitz-karp-roadmap, although RFC 4393 may also be useful. - Identify deficiencies of each routing protocol in scope, and specify mechanisms that bring them in line with the general requirements. These are referred to as protocol gap analysis documents. - Define one or more frameworks describing the common elements for modern authentication in routing protocols. - Publish guidance on how to create a gap analysis for routing protocols. - Publish guidance on guidance to operators on how to create and use integrity keys used with routing protocol message authentication. - Specify automated key management needs for routing protocols. Goals and Milestones: Nov 2010 - Submit General Framework, General Requirements, and Priorities/Work-Plan documents to the IESG to be considered as Informational RFC Nov 2010 - Submit a framework document describing protocol groups and the common techniques and interfaces that apply to them to the IESG to be considered as Informational RFC Dec 2010 - ubmit a document describing best practices for creating and using protocol message authentication integrity keys as a BCP Apr 2011 - Submit specification document for OSPFv2 to the IESG to be considered as a Proposed Standard Apr 2011 - Submit specification document for BGP to the IESG to be considered as a Proposed Standard Jul 2011 - Submit specification document for OSPFv3 to the IESG to be considered as a Proposed Standard Jul 2011 - Submit specification document for LDP to the IESG to be considered as a Proposed Standard Oct 2011 - Submit specification document for PIM to the IESG to be considered as a Proposed Standard Oct 2011 - Submit specification document for RSVP-TE to the IESG to be considered as a Proposed Standard Nov 2011 - Specify automated key management needs for routing protocols using unicast techniques Jan 2012 - Submit specification document for ISIS to the IESG to be considered as a Proposed Standard Jan 2012 - Submit specification document for PCE to the IESG to be considered as a Proposed Standard Apr 2012 - Submit specification document for MSDP to the IESG to be considered as a Proposed Standard Apr 2012 - Specify automated key management needs for routing protocols using multicast techniques Apr 2012 - Submit specification document for BFD to the IESG to be considered as a Proposed Standard Jul 2012 - Submit specification document for LMP to the IESG to be considered as a Proposed Standard Internet-Drafts: - Database of Long-Lived Symmetric Cryptographic Keys [draft-ietf-karp-crypto-key-table-02] (10 pages) - Keying and Authentication for Routing Protocols (KARP) Design Guidelines [draft-ietf-karp-design-guide-10] (31 pages) - Framework for Cryptographic Authentication of Routing Protocol Packets on the Wire [draft-ietf-karp-framework-00] (25 pages) - Operations Model for Router Keying [draft-ietf-karp-ops-model-02] (23 pages) - Analysis of OSPF Security According to KARP Design Guide [draft-ietf-karp-ospf-analysis-03] (12 pages) - Analysis of BGP, LDP, PCEP, and MSDP Security According to KARP Design Guide [draft-ietf-karp-routing-tcp-analysis-01] (17 pages) - Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements [draft-ietf-karp-threats-reqs-05] (32 pages) Requests for Comments: RFC6518: Keying and Authentication for Routing Protocols (KARP) Design Guidelines (31 pages) Layer 2 Virtual Private Networks (l2vpn) ---------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Giles Heron Dr. Nabil N. Bitar Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Stewart Bryant Tech Advisor: Alex Zinin Mailing Lists: General Discussion: l2vpn@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/l2vpn Archive: http://www.ietf.org/mail-archive/web/l2vpn/ Description of Working Group: The L2VPN working group is responsible for defining and specifying a limited number of solutions for supporting provider-provisioned Layer-2 Virtual Private Networks (L2VPNs). It will also address requirements driven by cloud computing services and data centers as they apply to Layer-2 VPN services. Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as defined by the PWE3 WG or over IP or MPLS PSN tunnels. A L2VPN emulates a "native" service over a PSN that is adequately faithful to, but may not be entirely indistinguishable from the native service itself. Further, following in the "edge-to-edge" nature of the service, the L2VPN WG will not define any mechanisms which exert control over the underlying PSN. When necessary it may, however, recommend or require the use of existing PSN QoS and path control mechanisms between the PEs which provide the L2VPN connectivity. Layer-2 VPNs comprise the following: 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that emulates a switched Ethernet (V)LAN across a PSN. 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service that provides point-to-point connectivity for a variety of link layers, including Frame Relay, ATM, Ethernet, PPP, etc., across a PSN. 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service that provides point-to-multipoint connectivity for a variety of link layers across a PSN. 4. IP-only L2VPN, an IP-only service over a PSN. The WG will address two specific types of IP-only L2VPN: a) Point-to-point Layer-2 VPN. This service is similar to VPWS, but also supports heterogenous Attachment Circuits at either end of a single point-to-point service. b) Multipoint-to-multipoint Layer-2 VPN. This service is similar to VPLS, but learns IP and MAC address bindings from ARPs and broadcast/multicast IP packets. 5. Ethernet VPN (E-VPN) - An enhanced Layer-2 service that emulates an Ethernet (V)LAN across a PSN. E-VPN supports load-sharing across multiple connections from a Layer-2 site to an L2VPN service. E-VPN is primarily targeted to support large-scale L2VPNs with resiliency requirements not satisfied by other L2VPN solutions. 6. E-Tree, a Layer-2 service defined by the MEF, which provides connectivity between one or more root nodes and one or more leaf nodes, with the restriction that leaf nodes may only communicate with root node(s) (and not with each other). L2VPNs will make use of existing IETF specified mechanisms unless there are technical reasons why the existing mechanisms are insufficient or unnecessary. The L2VPN WG is responsible for specification of the discovery and membership of PEs participating in a Layer-2 VPN as well as the membership of CE devices for a specific instance of an L2VPN. The L2VPN WG will provide extensions of existing protocols that will be discussed in protocol-specific WGs. In particular, the L2VPN WG may define extensions to pseudowire management mechanisms for VPLS. Those extensions will be reviewed by the PWE3 WG to ensure they are aligned with the overall design/architecture of PWE3. The L2VPN WG will not define new encapsulations, control, or resiliency mechanisms specifically related to pseudowires. Furthermore, when the L2VPN solution is based on PWs, the L2VPN WG will not define protocol inter-working between an L2VPN and native service Layer-2 OAM or resiliency mechanisms. The L2VPN WG may define how to operate native service-layer control, OAM or resiliency mechanisms on top of an L2VPN. In addition, it may define native data plane and/or control plane interworking between an L2VPN and an associated native Layer-2 service. The L2VPN WG scope includes the following: 1. Discovery of PEs participating in a Layer-2 VPN and the associated topology required for connectivity of the VPLS, VPWS, VPMS or E-VPN service. 2. Signaling of information related to the discovery and membership of PEs within a L2VPN. These procedures must use PWE3 control and management procedures, or define requirements for extensions of PWE3 protocols to suit the needs of an L2VPN, when the L2VPN operates over PWs. Once those requirements have been reviewed by the L2VPN WG, they should be provided to the PWE3 WG to derive solutions. 3. MIBs for Layer-2 VPN solutions. 4. Specification of requirements, framework and solutions that facilitate Operations Administration and Management (OAM) of any type of L2VPN within the scope of the L2VPN Working Group. 5. Mechanisms to permit optimization of multicast data traffic within an L2VPN. 6. If transport does not involve PWs, mechanisms that support load-balancing/multi-pathing between PEs interconnecting a Layer-2 service using an L2VPN across the PSN. 7. requirements for the multi-homing of CEs to several VPLS or E-VPN PEs, inclusive of active/backup and active/ active (load-sharing) configurations. Based on these requirements define VPLS or E-VPN control plane solutions for achieving fast convergence after failure of an active path in the PSN or on the AC side. 8. Enhancements to increase the scalability of the Control Plane and Data Plane of L2VPN PE nodes, and of core nodes that provide transport services for L2VPN. 9. Requirements and solutions for Auto-Discovery and Signaling of Inter-AS L2VPNs, in addition to Inter-AS solutions for multicast-optimized L2VPNs. 10. Requirements and solutions for supporting "E-Tree" services using VPLS. Goals and Milestones: Done - Submit an I-D describing MIB for VPLS Done - Submit an I-D describing MIB for VPWS Done - Submit an I-D on OAM requirements for VPLS Done - Submit an I-D on OAM requirements for VPWS Done - Submit L2 requirements to IESG for publication as Informational RFC Done - Submit L2 framework to IESG for publication as Informational RFC Done - Identify VPLS and VPWS solutions for the WG Done - Submit VPLS solution documents to IESG Done - Submit VPWS solution documents to IESG Done - Submit Auto-Discovery and Signaling for Intra-AS and Inter-AS VPLS and VPWS Layer-2 VPNs Oct 2011 - Submit IP-only L2VPN solution documents to IESG Nov 2011 - Submit OAM solutions for VPWS to IESG Nov 2011 - Submit OAM solutions for VPLS to IESG Nov 2011 - Submit signaling solution for multicast-optimized VPLS to IESG Nov 2011 - Submit I-D on Virtual Private Multicast Service (VPMS) requirements to IESG Nov 2011 - Submit MIB for VPLS to IESG Nov 2011 - Submit MIB for VPWS to IESG Mar 2012 - Submit scalability solutions for VPLS Data-Plane to IESG Mar 2012 - Submit scalability solutions for VPLS Control-Plane to IESG Mar 2012 - Submit E-Tree requirements/framework to IESG Jul 2012 - Submit MIB for IP-only L2VPN to IESG Jul 2012 - Submit OAM solutions for IP-only L2VPN to IESG Jul 2012 - Submit Auto-Discovery solution for VPMS to IESG Jul 2012 - Submit VPLS service convergence improvement solutions to IESG Jul 2012 - Submit VPLS multi-homing solutions to IESG Jul 2012 - Submit E-Tree solution to IESG Jul 2012 - Submit E-VPN requirements/framework to IESG Nov 2012 - Submit E-Tree OAM to IESG Nov 2012 - Submit E-VPN solution to IESG Dec 2012 - Submit E-Tree MIB to IESG Mar 2013 - Submit E-VPN OAM to IESG Apr 2013 - Submit E-VPN MIB to IESG Internet-Drafts: - ARP Mediation for IP Interworking of Layer 2 VPN [draft-ietf-l2vpn-arp-mediation-19] (33 pages) - A Framework for E-Tree Service over MPLS Network [draft-ietf-l2vpn-etree-frwk-00] (29 pages) - Requirements for MEF E-Tree Support in VPLS [draft-ietf-l2vpn-etree-reqt-01] (14 pages) - BGP MPLS Based Ethernet VPN [draft-ietf-l2vpn-evpn-00] (39 pages) - Requirements for Ethernet VPN (E-VPN) [draft-ietf-l2vpn-evpn-req-00] (12 pages) - IP-Only LAN Service (IPLS) [draft-ietf-l2vpn-ipls-09] (30 pages) - Framework for Layer 2 Virtual Private Networks (L2VPNs) [draft-ietf-l2vpn-l2-framework-05] (45 pages) - Radius/L2TP Based VPLS [draft-ietf-l2vpn-l2tp-radius-vpls-00] (9 pages) - Extension to LDP-VPLS for Ethernet Broadcast and Multicast [draft-ietf-l2vpn-ldp-vpls-broadcast-exten-03] (20 pages) - Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework [draft-ietf-l2vpn-oam-req-frmk-11] (36 pages) - PBB E-VPN [draft-ietf-l2vpn-pbb-evpn-02] (27 pages) - VPLS Interoperability with Provider Backbone Bridges [draft-ietf-l2vpn-pbb-vpls-interop-02] (23 pages) - Extensions to VPLS PE model for Provider Backbone Bridging [draft-ietf-l2vpn-pbb-vpls-pe-model-04] (14 pages) - Using RADIUS for PE-Based VPN Discovery [draft-ietf-l2vpn-radius-pe-discovery-02] (18 pages) - Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks [draft-ietf-l2vpn-requirements-07] (26 pages) - Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs) [draft-ietf-l2vpn-signaling-08] (39 pages) - Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling [draft-ietf-l2vpn-vpls-bgp-08] (37 pages) - Virtual Private LAN Service (VPLS) Interoperability with Customer Edge (CE) Bridges [draft-ietf-l2vpn-vpls-bridge-interop-06] (19 pages) - Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling [draft-ietf-l2vpn-vpls-ldp-09] (27 pages) - VPLS Applicability [draft-ietf-l2vpn-vpls-ldp-applic-00] (20 pages) - LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS [draft-ietf-l2vpn-vpls-ldp-mac-opt-05] (18 pages) - MAC Flush Loop Detection in VPLS [draft-ietf-l2vpn-vpls-macflush-ld-01] (9 pages) - Multicast in VPLS [draft-ietf-l2vpn-vpls-mcast-10] (46 pages) - Requirements for Multicast Support in Virtual Private LAN Services [draft-ietf-l2vpn-vpls-mcast-reqts-07] (31 pages) - Virtual Private Lan Services (VPLS) Management Information Base [draft-ietf-l2vpn-vpls-mib-06] (45 pages) - BGP based Multi-homing in Virtual Private LAN Service [draft-ietf-l2vpn-vpls-multihoming-03] (26 pages) - VPLS Interoperability with Provider Backbone Bridges [draft-ietf-l2vpn-vpls-pbb-interop-00] (23 pages) - PIM Snooping over VPLS [draft-ietf-l2vpn-vpls-pim-snooping-01] (37 pages) - Requirements for Virtual Private LAN Services (VPLS) [draft-ietf-l2vpn-vpls-requirements-00] (16 pages) - Framework and Requirements for Virtual Private Multicast Service (VPMS) [draft-ietf-l2vpn-vpms-frmwk-requirements-04] (27 pages) - OAM Procedures for VPWS Interworking [draft-ietf-l2vpn-vpws-iw-oam-03] (12 pages) Requests for Comments: RFC4664: Framework for Layer 2 Virtual Private Networks (L2VPNs) (45 pages) RFC4665: Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks (26 pages) RFC4761: Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling (37 pages) * Updates RFC5462 RFC4762: Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling (27 pages) RFC5501: Requirements for Multicast Support in Virtual Private LAN Services (31 pages) RFC6074: Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs) (39 pages) RFC6136: Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework (36 pages) RFC6246: Virtual Private LAN Service (VPLS) Interoperability with Customer Edge (CE) Bridges (19 pages) * Replaces DRAFT-SAJASSI-L2VPN-VPLS-BRIDGE-INTEROP Layer 3 Virtual Private Networks (l3vpn) ---------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Martin Vigoureux Thomas Morin Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Stewart Bryant Secretary: Daniel King <> Mailing Lists: General Discussion: l3vpn@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/l3vpn Archive: http://www.ietf.org/mail-archive/web/l3vpn/ Description of Working Group: This working group is responsible for defining, specifying and extending BGP/MPLS IP VPNs solutions (based on RFC4364 and RFC4659) for supporting provider-provisioned Layer-3 (routed) Virtual Private Networks (L3VPNs). The WG will continue to extend and enhance RFC4364 and RFC4659 based solutions so that these solutions can be used to provide IPv4, IPv6, and MPLS services including multicast. The following VPN deployment scenarios will be considered by the WG: 1. Single service provider (SP)/single AS: VPN sites attached to the network of a single provider within the scope of a single AS. 2. Single SP/multiple AS'es: VPN sites attached to the network of a single provider consisting of multiple AS'es. 3. Cooperating SPs: VPN sites attached to networks of different providers that cooperate with each other to provide VPN service. As part of this effort the WG will work on the following tasks: 1. Additional requirements and framework for Layer 3 VPNs. 2. Solution documents, including applicability statements. 3. MIB definitions. 4. Security mechanisms. As a general rule, the WG will not create new protocols, but will extend existing protocols to provide the necessary L3VPN functionality. Protocol extensions that provide L3VPN functionality will be reviewed by both the L3VPN WG and by the WG responsible for the protocol being extended. The WG will continue to extend and enhance the Multicast over BGP/MPLS VPN solution. Goals and Milestones: Done - Submit L3 VPN Requirements Document to IESG for publication as Info Done - Submit Generic Requirements Document to IESG for publication as Info Done - Submit L3 VPN Framework Document to IESG for publication as Info Done - Submit VPN Security Analysis to IESG for publication as Info (draft-fang-ppvpn-security-framework-00) Done - Submit BGP/MPLS VPNs specification and AS to IESG for publication as PS (draft-ietf-ppvpn-rfc2547bis-03, draft-ietf-ppvpn-as2547-01) Done - Submit CE-based specification and AS to IESG for publication as PS (draft-ietf-ppvpn-ce-based-03, draft-declercq-ppvpn-ce-based-sol-00, draft-declercq-ppvpn-ce-based-as-01) Done - Submit Virtual Router specification and AS to IESG for publication as PS (draft-ietf-ppvpn-vpn-vr-03, draft-ietf-ppvpn-as-vr-01) Done - Submit BGP as an Auto-Discovery Mechanism for publication as PS (draft-ietf-ppvpn-bgpvpn-auto-05.txt) Done - Submit specification of using GRE for PE-PE encapsulation in BGP/MPLS VPNs to IESG for publication as PS (draft-ietf-ppvpn-gre-ip-2547-02) Done - Submit VPN MIB Textual Conventions to IESG for publication as PS (draft-ietf-ppvpn-tc-mib-02) Done - Submit MPLS/BGP VPN MIB to IESG for publication as PS (draft-ietf-ppvpn-mpls-vpn-mib-05) Done - Submit VR MIB to IESG for publication as PS (draft-ietf-ppvpn-vr-mib-04) Done - Submit specification of using IPSEC for PE-PE encapsulation in BGP/MPLS VPNs to IESG for publication as PS (draft-ietf-ppvpn-ipsec-2547-03) Done - Submit specification of OSPF as the PE/CE Protocol in BGP/MPLS VPNs for publication (draft-ietf-l3vpn-ospf-2547-xx.txt) Done - Submit specification of IPv6 over BGP/MPLS VPNs for publication Done - Submit specification of IPv4 multicast over BGP/MPLS VPNs for publication Done - Submit MVPNv6 using PIM & S-PMSIs specification to IESG as PS Done - Submit IPv6 MVPN infrastructure address encoding document to IESG for publication as PS Done - Submit specification for using Internal BGP as PE-CE protocol to IESG as PS May 2011 - Submit S-PMSI A-D route Wildcard selection specification to IESG as PS Nov 2011 - Submit MVPN Extranet specification to IESG as PS Internet-Drafts: - Applicability Statement for Provider Provisioned CE-based Virtual Private Networks using IPsec [draft-declercq-l3vpn-ce-based-as-00] (30 pages) - Multicast in MPLS/BGP IP VPNs [draft-ietf-l3vpn-2547bis-mcast-10] (89 pages) - BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs [draft-ietf-l3vpn-2547bis-mcast-bgp-08] (61 pages) - BGP ACCEPT_OWN Community Attribute [draft-ietf-l3vpn-acceptown-community-04] (9 pages) - Guidelines of Applicability Statements for PPVPNs [draft-ietf-l3vpn-applicability-guidelines-00] (10 pages) - Applicability Statement for Virtual Router-based Layer 3 PPVPN Approaches [draft-ietf-l3vpn-as-vr-02] (28 pages) - Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs) [draft-ietf-l3vpn-as2547-07] (32 pages) - 4-Octet AS Specific BGP Extended Community [draft-ietf-l3vpn-as4octet-ext-community-03] (5 pages) - CE-to-CE Member Verification for Layer 3 VPNs [draft-ietf-l3vpn-auth-00] (0 pages) - BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN [draft-ietf-l3vpn-bgp-ipv6-07] (18 pages) - Using BGP as an Auto-Discovery Mechanism for VR-based Layer-3 VPNs [draft-ietf-l3vpn-bgpvpn-auto-09] (12 pages) - An Architecture for Provider Provisioned CE-based Virtual Private Networks using IPsec [draft-ietf-l3vpn-ce-based-03] (26 pages) - Requirements for Supporting Customer Resource ReSerVation Protocol (RSVP) and RSVP Traffic Engineering (RSVP-TE) over a BGP/MPLS IP-VPN [draft-ietf-l3vpn-e2e-rsvp-te-reqts-05] (24 pages) - A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs) [draft-ietf-l3vpn-framework-00] (80 pages) - Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN) [draft-ietf-l3vpn-generic-reqts-03] (26 pages) - Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks [draft-ietf-l3vpn-gre-ip-2547-05] (14 pages) - Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) [draft-ietf-l3vpn-ibgp-08] (19 pages) - Architecture for the Use of PE-PE IPsec Tunnels in BGP/MPLS IP VPNs [draft-ietf-l3vpn-ipsec-2547-05] (18 pages) - CE-to-CE Member Verification for Layer 3 VPNs [draft-ietf-l3vpn-l3vpn-auth-01] (16 pages) - Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management [draft-ietf-l3vpn-mgt-fwk-08] (26 pages) - MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base [draft-ietf-l3vpn-mpls-vpn-mib-07] (42 pages) - MVPN: Using Bidirectional P-Tunnels [draft-ietf-l3vpn-mvpn-bidir-01] (16 pages) - Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution [draft-ietf-l3vpn-mvpn-considerations-06] (40 pages) - IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN [draft-ietf-l3vpn-mvpn-infra-addrs-05] (10 pages) - MPLS/BGP Layer 3 VPN Multicast Management Information Base [draft-ietf-l3vpn-mvpn-mib-00] (31 pages) - IPv6 Multicast VPN (MVPN) Support Using PIM Control Plane and Selective Provider Multicast Service Interface (S-PMSI) Join Messages [draft-ietf-l3vpn-mvpn-spmsi-joins-02] (8 pages) - Wildcards in Multicast VPN Auto-Discovery Routes [draft-ietf-l3vpn-mvpn-wildcards-02] (18 pages) - OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) [draft-ietf-l3vpn-ospf-2547-06] (26 pages) - OSPFv3 as a PE-CE routing protocol [draft-ietf-l3vpn-ospfv3-pece-11] (20 pages) - Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs) [draft-ietf-l3vpn-ppvpn-mcast-reqts-10] (45 pages) - Provider Provisioned Virtual Private Network (VPN) Terminology [draft-ietf-l3vpn-ppvpn-terminology-04] (26 pages) - Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs) [draft-ietf-l3vpn-requirements-02] (44 pages) - BGP/MPLS IP Virtual Private Networks (VPNs) [draft-ietf-l3vpn-rfc2547bis-03] (49 pages) - Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs) [draft-ietf-l3vpn-rt-constrain-02] (19 pages) - Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs) [draft-ietf-l3vpn-security-framework-03] (43 pages) - Definition of Textual Conventions for Virtual Private Network (VPN) Management [draft-ietf-l3vpn-tc-mib-06] (6 pages) - IPv6 Address Specific BGP Extended Community Attribute [draft-ietf-l3vpn-v6-ext-communities-02] (5 pages) - Virtual Hub-and-Spoke in BGP/MPLS VPNs [draft-ietf-l3vpn-virtual-hub-01] (22 pages) - Layer-3 VPN Import/Export Verification [draft-ietf-l3vpn-vpn-verification-00] (11 pages) - Network based IP VPN Architecture Using Virtual Routers [draft-ietf-l3vpn-vpn-vr-03] (24 pages) - Virtual Router Management Information Base Using SMIv2 [draft-ietf-l3vpn-vr-mib-04] (24 pages) - MPLS/BGP Layer 3 VPN Multicast Management Information Base [draft-zzhang-mvpn-mib-00] (30 pages) Requests for Comments: RFC3809: Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN) (26 pages) RFC4026: Provider Provisioned Virtual Private Network (VPN) Terminology (26 pages) RFC4031: Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs) (44 pages) RFC4110: A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs) (80 pages) RFC4111: Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs) (43 pages) RFC4176: Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management (26 pages) RFC4265: Definition of Textual Conventions for Virtual Private Network (VPN) Management (6 pages) * Replaces DRAFT-IETF-PPVPN-TC-MIB RFC4364: BGP/MPLS IP Virtual Private Networks (VPNs) (49 pages) * Obsoletes RFC2547 * Updates RFC4577 * Updates RFC4684 * Updates RFC5462 RFC4365: Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs) (32 pages) RFC4382: MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base (42 pages) RFC4577: OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) (26 pages) * Updates RFC4364 RFC4659: BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN (18 pages) RFC4684: Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs) (19 pages) * Updates RFC4364 RFC4797: Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks (14 pages) RFC4834: Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs) (45 pages) RFC5668: 4-Octet AS Specific BGP Extended Community (5 pages) RFC5701: IPv6 Address Specific BGP Extended Community Attribute (5 pages) RFC5824: Requirements for Supporting Customer Resource ReSerVation Protocol (RSVP) and RSVP Traffic Engineering (RSVP-TE) over a BGP/MPLS IP-VPN (24 pages) * Replaces DRAFT-KUMAKI-L3VPN-E2E-RSVP-TE-REQTS RFC6368: Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) (19 pages) * Replaces DRAFT-MARQUES-L3VPN-IBGP RFC6513: Multicast in MPLS/BGP IP VPNs (89 pages) RFC6514: BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs (61 pages) * Replaces DRAFT-RAGGARWA-L3VPN-2547BIS-MCAST-BGP * Updates RFC6515 RFC6515: IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN (10 pages) * Replaces DRAFT-ROSEN-L3VPN-MVPN-INFRA-ADDRS * Updates RFC6514 RFC6516: IPv6 Multicast VPN (MVPN) Support Using PIM Control Plane and Selective Provider Multicast Service Interface (S-PMSI) Join Messages (8 pages) * Replaces DRAFT-ROSEN-L3VPN-MVPN-SPMSI-JOINS RFC6517: Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution (40 pages) * Replaces DRAFT-MORIN-L3VPN-MVPN-CONSIDERATIONS Mobile Ad-hoc Networks (manet) ------------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Stan Ratliff Joseph P. Macker Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Adrian Farrel Secretary: Ulrich Herberg <> Mailing Lists: General Discussion: manet@ietf.org To Subscribe: manet-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/manet/ Description of Working Group: The purpose of the MANET working group is to standardize IP routing protocol functionality suitable for wireless routing application within both static and dynamic topologies with increased dynamics due to node motion or other factors. Approaches are intended to be relatively lightweight in nature, suitable for multiple hardware and wireless environments, and address scenarios where MANETs are deployed at the edges of an IP infrastructure. Hybrid mesh infrastructures (e.g., a mixture of fixed and mobile routers) should also be supported by MANET specifications and management features. Using mature components from previous work on experimental reactive and proactive protocols, the WG will develop two Standards track routing protocol specifications: - Reactive MANET Protocol (RMP) - Proactive MANET Protocol (PMP) If significant commonality between RMRP and PMRP protocol modules is observed, the WG may decide to go with a converged approach. Both IPv4 and IPv6 will be supported. Routing security requirements and issues will also be addressed. The MANET WG will also develop a scoped forwarding protocol that can efficiently flood data packets to all participating MANET nodes. The primary purpose of this mechanism is a simplified best effort multicast forwarding function. The use of this protocol is intended to be applied ONLY within MANET routing areas and the WG effort will be limited to routing layer design issues. The MANET WG will pay attention to the OSPF-MANET protocol work within the OSPF WG and IRTF work that is addressing research topics related to MANET environments. Goals and Milestones: Done - Post as an informational Internet-Drafts a discussion of mobile ad-hoc networking and issues. Done - Agenda bashing, discussion of charter and of mobile ad hoc networking draft. Done - Discuss proposed protocols and issues. Redefine charter. Done - Publish Informational RFC on manet design considerations Done - Review the WG Charter and update Done - Submit AODV specification to IESG for publication as Experimental RFC Done - Develop I-D for potential common manet encapsulation protocol approach Done - Submit initial I-D(s) of candidate proposed routing protocols and design frameworks Done - Promote implementation, revision, and testing of initial proposed I-D(s) Done - Explore basic performance and implementation issues of initial approaches Done - Explore proposed proactive protocol design commonalities Done - Submit DSR specification to IESG for publication as Experimental RFC Done - Submit OLSR specification to IESG for publication as Experimental RFC Done - Submit TBRPF specification to IESG for publication as Experimental RFC Done - Develop a further focused problem statement and address an approach for a common engineering work effort Done - Reevaluate the WG's potential based on the problem statement consensus Done - Submit initial ID of RMP for WG review Done - Submit initial ID of PMP for WG review Done - Submit inital ID of generalized MANET flooding approach Done - Revise WG documents and review Done - Document initial implementation progress and experience Revise documents based upon implementation experience Done - Submit initial WG ID on Neighborhood Discovery (NHDP) Done - Submit PacketBB to IESG Done - Submit initial WG ID on MIB for NHDP, DYMO, OLSRv2 Apr 2007 - Submit NHDP to IESG Apr 2007 - Submit DYMO to IESG Apr 2007 - Submit OLSRv2 to IESG Apr 2007 - Submit SMF to IESG Internet-Drafts: - The Adaptive Demand-Driven Multicast Routing Protocol for Mobile Ad Hoc Networks (ADMR) [draft-ietf-manet-admr-01] (63 pages) - Ad hoc Multicast Routing protocol utilizing Increasing id-numberS (AMRIS) Functional Specification [draft-ietf-manet-amris-spec-00] (23 pages) - Ad hoc On-Demand Distance Vector (AODV) Routing [draft-ietf-manet-aodv-13] (35 pages) - MANET Routing Protocol Applicability Statement [draft-ietf-manet-appl-00] (3 pages) - IP Flooding in Ad hoc Mobile Networks [draft-ietf-manet-bcast-00] (0 pages) - Cluster Based Routing Protocol(CBRP) Functional Specification [draft-ietf-manet-cbrp-spec-01] (27 pages) - Core Extraction Distributed Ad hoc Routing (CEDAR) Specification [draft-ietf-manet-cedar-spec-00] (29 pages) - Differential Destination Multicast (DDM) Specification [draft-ietf-manet-ddm-00] (21 pages) - Dynamic Link Exchange Protocol (DLEP) [draft-ietf-manet-dlep-02] (52 pages) - The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4 [draft-ietf-manet-dsr-10] (112 pages) - Flow State in the Dynamic Source Routing Protocol for Mobile Ad Hoc Networks [draft-ietf-manet-dsrflow-00] (30 pages) - Dynamic MANET On-demand (AODVv2) Routing [draft-ietf-manet-dymo-22] (35 pages) - Definition of Managed Objects for the DYMO Manet Routing Protocol [draft-ietf-manet-dymo-mib-04] (41 pages) - Fisheye State Routing Protocol (FSR) for Ad Hoc Networks [draft-ietf-manet-fsr-03] (17 pages) - IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols [draft-ietf-manet-iana-07] (7 pages) - An Internet MANET Encapsulation Protocol (IMEP) Specification [draft-ietf-manet-imep-spec-01] (37 pages) - INSIGNIA [draft-ietf-manet-insignia-01] (22 pages) - Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations [draft-ietf-manet-issues-02] (11 pages) - Jitter Considerations in Mobile Ad Hoc Networks (MANETs) [draft-ietf-manet-jitter-04] (18 pages) - Landmark Routing Protocol (LANMAR) for Large Scale Ad Hoc Networks [draft-ietf-manet-lanmar-05] (21 pages) - Long-lived Ad Hoc Routing based on the Concept of Associativity [draft-ietf-manet-longlived-adhoc-routing-00] (18 pages) - Multicast Ad hoc On-Demand Distance Vector (MAODV) Routing [draft-ietf-manet-maodv-00] (24 pages) - Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) [draft-ietf-manet-nhdp-15] (87 pages) - Definition of Managed Objects for the Neighborhood Discovery Protocol [draft-ietf-manet-nhdp-mib-13] (63 pages) - Using Integrity Check Values and Timestamps in NHDP [draft-ietf-manet-nhdp-sec-01] (11 pages) - Security Threats for NHDP [draft-ietf-manet-nhdp-sec-threats-00] (15 pages) - On-Demand Multicast Routing Protocol (ODMRP) for Ad-Hoc Networks [draft-ietf-manet-odmrp-04] (29 pages) - Optimized Link State Routing Protocol (OLSR) [draft-ietf-manet-olsr-11] (77 pages) - The Optimized Link State Routing Protocol version 2 [draft-ietf-manet-olsrv2-14] (106 pages) - Definition of Managed Objects for the Optimized Link State Routing Protocol version 2 [draft-ietf-manet-olsrv2-mib-04] (68 pages) - Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format [draft-ietf-manet-packetbb-17] (60 pages) - Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs) [draft-ietf-manet-packetbb-sec-09] (20 pages) - Relative Distance Micro-discovery Ad Hoc Routing (RDMAR) Protocol [draft-ietf-manet-rdmar-00] (15 pages) - Definition of Managed Objects for Performance Reporting [draft-ietf-manet-report-mib-02] (26 pages) - A Simple Protocol for Multicast and Broadcast in Mobile Ad Hoc Networks [draft-ietf-manet-simple-mbcast-01] (11 pages) - Simplified Multicast Forwarding [draft-ietf-manet-smf-14] (53 pages) - Definition of Managed Objects for the Manet Simplified Multicast Framework Relay Set Process [draft-ietf-manet-smf-mib-03] (55 pages) - SOURCE TREE ADAPTIVE ROUTING (STAR) PROTOCOL [draft-ietf-manet-star-00] (26 pages) - Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) [draft-ietf-manet-tbrpf-11] (47 pages) - Mobile Ad Hoc Networking Terminology [draft-ietf-manet-term-01] (9 pages) - Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs) [draft-ietf-manet-timetlv-08] (15 pages) - Temporally-Ordered Routing Algorithm (TORA) Version 1 Functional Specification [draft-ietf-manet-tora-spec-04] (23 pages) - The Bordercast Resolution Protocol (BRP) for Ad Hoc Networks [draft-ietf-manet-zone-brp-02] (13 pages) - The Intrazone Routing Protocol (IARP) for Ad Hoc Networks [draft-ietf-manet-zone-iarp-02] (11 pages) - The Interzone Routing Protocol (IERP) for Ad Hoc Networks [draft-ietf-manet-zone-ierp-02] (14 pages) - The Zone Routing Protocol (ZRP) for Ad Hoc Networks [draft-ietf-manet-zone-zrp-04] (11 pages) - AMRoute: Adhoc Multicast Routing Protocol [draft-talpade-manet-amroute-00] (24 pages) Requests for Comments: RFC2501: Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations (11 pages) RFC3561: Ad hoc On-Demand Distance Vector (AODV) Routing (35 pages) RFC3626: Optimized Link State Routing Protocol (OLSR) (77 pages) RFC3684: Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) (47 pages) RFC4728: The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4 (112 pages) RFC5148: Jitter Considerations in Mobile Ad Hoc Networks (MANETs) (18 pages) * Replaces DRAFT-CLAUSEN-MANET-JITTER RFC5444: Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format (60 pages) RFC5497: Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs) (15 pages) * Replaces DRAFT-CLAUSEN-MANET-TIMETLV RFC5498: IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols (7 pages) * Replaces DRAFT-CHAKERES-MANET-IANA RFC6130: Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) (87 pages) RFC6622: Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs) (20 pages) * Replaces DRAFT-HERBERG-MANET-PACKETBB-SEC Multiprotocol Label Switching (mpls) ------------------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Loa Andersson George Swallow Ross Callon Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Adrian Farrel Secretary: Martin Vigoureux <> Mailing Lists: General Discussion: mpls@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mpls Archive: http://www.ietf.org/mail-archive/web/mpls/ Description of Working Group: The MPLS working group is responsible for standardizing a base technology for using label switching and for the implementation of label-switched paths over various packet based link-level technologies, such as Packet-over-Sonet, Frame Relay, ATM, and LAN technologies (e.g. all forms of Ethernet, Token Ring, etc.). This includes procedures and protocols for the distribution of labels between routers and encapsulation. The working group is also responsible for specifying the necessary management objects (e.g. as part of MIB modules) and OAM techniques for the functionality specified in the base MPLS technology. The first generation of the MPLS standards are largely complete, and the current WG work items are: - Define requirements, mechanisms and protocol extensions for point-to-multipoint (P2MP) MPLS - Define requirements, mechanisms and protocol extensions for traffic engineered point-to-multipoint (P2MP) MPLS, including soft preemption - Define requirements and mechanisms for MPLS OAM - Define an overall OAM framework for MPLS applications - MPLS-specific aspects of traffic engineering for multi-areas/multi-AS in cooperation with the CCAMP WG - Determine (with CCAMP) what procedures are appropriate for evaluating proposals to extend the MPLS and GMPLS protocols, and document these - Document current implementation practices for MPLS load sharing - Include extensions to the MPLS WG protocols and RFCs necessary to create an MPLS Transport Profile (MPLS TP). The work on the MPLS TP will be coordinated between the working groups (eg, MPLS, CCAMP, PWE3, and L2PVN) that are chartered to do MPLS TP work. Goals and Milestones: Done - Submit documents from original MPLS effort to IESG Done - Framework for IP multicast over label-switched paths ready for advancement. Done - LDP fault tolerance specification ready for advancement to Proposed Standard. Done - Submit Definitions of Managed Objects for MultoiProtocol Label Switching, Label Distribution Protocol (LDP) to the IESG for publication as Proposed Standards Done - Specification for MPLS-specific recovery ready for advancement. Done - Submit Multiprotocol Label Switching (MPLS) Forward Equivalency Class-To-Next Hop Label Forwarding Entry Management Information Base to the IESG for publication as Proposed Standards Done - Submit Multiprotocol Label Switching (MPLS) Label Switching Router (LSR), Management Information Base to the IESG for publication as Proposed Standards Done - Submit Multiprotocol Label Switching (MPLS) Management Overview to the IESG for publication as Proposed Standards Done - Submit Definitions of Textual Conventions for Multiprotocol Label Switching (MPLS) Management to the IESG for publication as Proposed Standards Done - Submit Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base to the IESG for publication as Proposed Standards Done - Submit the Traffic Engineering Link MIB to the IESG for as a Proposed Standard Done - Submit a specification on Encapsulations to carry MPLS over IP and GRE to the IESG for as a Proposed Standard Done - Submit specification on LSP Ping to the IESG for publication as a Proposed Standard Done - Submit a document defining the scope, requirements, and issues to resolve for setup of P2MP TE LSPs (MPLS and GMPLS) Done - Submit an OAM Framework Document to the IESG for publication as an Informational RFC Done - Submit a BCP on MPLS load sharing to the IESG Done - Submit specification on LSR Self Test to the IESG for publication as a Proposed Standard Done - Submit document(s) specifying protocol extensions, enhancements and mechanisms for setup of P2MP TE LSPs Done - Submit point to multipoint TE MIB to IESG as proposed standard Done - Submit EXP field clarification document to IESG as proposed standard Done - Submit a specification on Soft Pre-emption of LSP Tunnels to the IESG for publication as a Proposed Standard Done - Submit LDP extensions for P2MP LSPs Done - Submit MPLS security framework for publication as an informational RFC Done - Submit requirements for point-to-multipoint extensions to LDP Internet-Drafts: - The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols [draft-andersson-mpls-sig-decision-03] (8 pages) - Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages [draft-ietf-mpls-3209-patherr-06] (7 pages) - Multiprotocol Label Switching Architecture [draft-ietf-mpls-arch-07] (62 pages) - MPLS using LDP and ATM VC Switching [draft-ietf-mpls-atm-04] (21 pages) - Graceful Restart Mechanism for BGP with MPLS [draft-ietf-mpls-bgp-mpls-restart-05] (11 pages) - Carrying Label Information in BGP-4 [draft-ietf-mpls-bgp4-mpls-05] (7 pages) - Link Bundling in MPLS Traffic Engineering (TE) [draft-ietf-mpls-bundle-06] (12 pages) - Link Bundling Management Information Base [draft-ietf-mpls-bundle-mib-04] (52 pages) - Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field [draft-ietf-mpls-cosfield-def-08] (18 pages) - Constraint-Based LSP Setup using LDP [draft-ietf-mpls-cr-ldp-06] (38 pages) - Applicability Statement for CR-LDP [draft-ietf-mpls-crldp-applic-01] (6 pages) - Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol) [draft-ietf-mpls-crldp-unnum-10] (8 pages) - LSP Modification Using CR-LDP [draft-ietf-mpls-crlsp-modify-03] (10 pages) - Multi-Protocol Label Switching (MPLS) Support of Differentiated Services [draft-ietf-mpls-diff-ext-09] (53 pages) - Extensions to RSVP-TE and CR-LDP for support of Diff-Serv-aware MPLS Traffic Engineering [draft-ietf-mpls-diff-te-ext-01] (12 pages) - Requirements for support of Diff-Serv-aware MPLS Traffic Engineering [draft-ietf-mpls-diff-te-reqts-00] (13 pages) - Avoiding Equal Cost Multipath Treatment in MPLS Networks [draft-ietf-mpls-ecmp-bcp-03] (9 pages) - A Proposal to Incorporate ECN in MPLS [draft-ietf-mpls-ecn-00] (9 pages) - The Use of Entropy Labels in MPLS Forwarding [draft-ietf-mpls-entropy-label-03] (23 pages) - Removing a Restriction on the use of MPLS Explicit NULL [draft-ietf-mpls-explicit-null-02] (7 pages) - Component Link Recording and Resource Control for TE Links [draft-ietf-mpls-explicit-resource-control-bundle-10] (13 pages) - Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute [draft-ietf-mpls-fastreroute-mib-21] (50 pages) - Use of Label Switching on Frame Relay Networks Specification [draft-ietf-mpls-fr-06] (24 pages) - A Framework for MPLS [draft-ietf-mpls-framework-05] (69 pages) - Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB) [draft-ietf-mpls-ftn-mib-09] (40 pages) - MPLS Generic Associated Channel (G-ACh) Advertisement Protocol [draft-ietf-mpls-gach-adv-00] (17 pages) - The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol [draft-ietf-mpls-git-uus-04] (25 pages) - PathErr Message Triggered MPLS and GMPLS LSP Reroutes [draft-ietf-mpls-gmpls-lsp-reroute-06] (12 pages) - MPLS/IP Header Compression [draft-ietf-mpls-hdr-comp-00] (14 pages) - MPLS/IP Header Compression over PPP [draft-ietf-mpls-hdr-comp-over-ppp-00] (10 pages) - Codepoint Registry for the Flags Field in the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Session Attribute Object [draft-ietf-mpls-iana-rsvp-session-flags-01] (5 pages) - ICMP Extensions for Multiprotocol Label Switching [draft-ietf-mpls-icmp-08] (9 pages) - LDP IGP Synchronization [draft-ietf-mpls-igp-sync-01] (8 pages) - Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE) [draft-ietf-mpls-in-ip-or-gre-08] (15 pages) - Detecting MPLS Data Plane Failures in Inter-AS and inter-provider Scenarios [draft-ietf-mpls-interas-lspping-00] (18 pages) - Label Edge Router Forwarding of IPv4 Option Packets [draft-ietf-mpls-ip-options-07] (10 pages) - MPLS Label Stack Encoding [draft-ietf-mpls-label-encaps-08] (22 pages) - Multiprotocol Label Switching (MPLS) Label-Controlled Asynchronous Transfer Mode (ATM) and Frame-Relay Management Interface Definition [draft-ietf-mpls-lc-if-mib-08] (22 pages) - LDP Specification [draft-ietf-mpls-ldp-11] (135 pages) - LDP Applicability [draft-ietf-mpls-ldp-applic-02] (6 pages) - LDP Capabilities [draft-ietf-mpls-ldp-capabilities-04] (14 pages) - LDP Downstream-on-Demand in Seamless MPLS [draft-ietf-mpls-ldp-dod-01] (33 pages) - LDP DoD Graceful Restart [draft-ietf-mpls-ldp-dod-restart-00] (18 pages) - Signaling LDP Label Advertisement Completion [draft-ietf-mpls-ldp-end-of-lib-04] (11 pages) - Experience with the Label Distribution Protocol (LDP) [draft-ietf-mpls-ldp-experience-00] (0 pages) - Fault Tolerance for the Label Distribution Protocol (LDP) [draft-ietf-mpls-ldp-ft-06] (53 pages) - The Generalized TTL Security Mechanism (GTSM) for Label Distribution Protocol (LDP) [draft-ietf-mpls-ldp-gtsm-06] (9 pages) - Label Distribution Protocol (LDP) Internet Assigned Numbers Authority (IANA) Considerations Update [draft-ietf-mpls-ldp-iana-01] (5 pages) - LDP IGP Synchronization [draft-ietf-mpls-ldp-igp-sync-04] (8 pages) - LDP IGP Synchronization for Broadcast Networks [draft-ietf-mpls-ldp-igp-sync-bcast-06] (11 pages) - LDP Extension for Inter-Area Label Switched Paths (LSPs) [draft-ietf-mpls-ldp-interarea-04] (12 pages) - LDP IP and PW Capability [draft-ietf-mpls-ldp-ip-pw-capability-01] (11 pages) - Updates to LDP for IPv6 [draft-ietf-mpls-ldp-ipv6-06] (17 pages) - Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP) [draft-ietf-mpls-ldp-mib-14] (132 pages) - Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol [draft-ietf-mpls-ldp-mtu-extensions-03] (10 pages) - LDP Extensions for Multi Topology Routing [draft-ietf-mpls-ldp-multi-topology-03] (18 pages) - LDP Extensions for Optical User Network Interface (O-UNI) Signaling [draft-ietf-mpls-ldp-optical-uni-01] (26 pages) - Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths [draft-ietf-mpls-ldp-p2mp-15] (39 pages) - Graceful Restart Mechanism for Label Distribution Protocol [draft-ietf-mpls-ldp-restart-06] (13 pages) - Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP) [draft-ietf-mpls-ldp-restart-applic-01] (14 pages) - LDP State Machine [draft-ietf-mpls-ldp-state-04] (78 pages) - The Label Distribution Protocol (LDP) Implementation Survey Results [draft-ietf-mpls-ldp-survey2002-00] (22 pages) - Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC) [draft-ietf-mpls-ldp-typed-wildcard-07] (11 pages) - MPLS Upstream Label Assignment for LDP [draft-ietf-mpls-ldp-upstream-10] (14 pages) - Link Management Protocol (LMP) [draft-ietf-mpls-lmp-02] (58 pages) - MPLS Loop Prevention Mechanism [draft-ietf-mpls-loop-prevention-03] (40 pages) - Packet Loss and Delay Measurement for MPLS Networks [draft-ietf-mpls-loss-delay-04] (52 pages) - Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE) [draft-ietf-mpls-lsp-hierarchy-08] (13 pages) - Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures [draft-ietf-mpls-lsp-ping-13] (51 pages) - Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels [draft-ietf-mpls-lsp-ping-enhanced-dsmap-11] (23 pages) - Configuration of Pro-Active Operations, Administration, and Maintenance (OAM) Functions for MPLS-based Transport Networks using LSP Ping [draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-04] (22 pages) - Definition of Time-to-Live TLV for LSP-Ping Mechanisms [draft-ietf-mpls-lsp-ping-ttl-tlv-02] (7 pages) - Multi Protocol Label Switching Label Distribution Protocol Query Message Description [draft-ietf-mpls-lsp-query-09] (19 pages) - Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB) [draft-ietf-mpls-lsr-mib-14] (57 pages) - Label Switching Router Self-Test [draft-ietf-mpls-lsr-self-test-07] (15 pages) - Connectivity Verification for Multicast Label Switched Paths [draft-ietf-mpls-mcast-cv-00] (13 pages) - Multiprotocol Label Switching (MPLS) Management Overview [draft-ietf-mpls-mgmt-overview-09] (29 pages) - Multipoint LDP in-band signaling for Point-to-Multipoint and Multipoint- to-Multipoint Label Switched Paths [draft-ietf-mpls-mldp-in-band-signaling-05] (14 pages) - Using Multipoint LDP When the Backbone Has No Route to the Root [draft-ietf-mpls-mldp-recurs-fec-04] (12 pages) - Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol [draft-ietf-mpls-mp-ldp-reqs-08] (20 pages) - Security Framework for MPLS and GMPLS Networks [draft-ietf-mpls-mpls-and-gmpls-security-framework-09] (63 pages) - Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment [draft-ietf-mpls-multicast-08] (29 pages) - MPLS Multicast Encapsulations [draft-ietf-mpls-multicast-encaps-10] (11 pages) - Definition of a Record Route Object (RRO) Node-Id Sub-Object [draft-ietf-mpls-nodeid-subobject-07] (8 pages) - A Link-Type sub-TLV to Convey the Number of Traffic Engineering Label Switched Paths Signalled with Zero Reserved Bandwidth across a Link [draft-ietf-mpls-number-0-bw-te-lsps-12] (10 pages) - A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM) [draft-ietf-mpls-oam-frmwk-05] (11 pages) - Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks [draft-ietf-mpls-oam-requirements-07] (16 pages) - Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3 [draft-ietf-mpls-over-l2tpv3-03] (12 pages) - Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping [draft-ietf-mpls-p2mp-lsp-ping-18] (29 pages) - Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks [draft-ietf-mpls-p2mp-oam-reqs-01] (12 pages) - Requirements for Point to Multipoint Traffic Engineered MPLS LSPs [draft-ietf-mpls-p2mp-requirement-04] (34 pages) - Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs) [draft-ietf-mpls-p2mp-sig-requirement-04] (28 pages) - P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels [draft-ietf-mpls-p2mp-te-bypass-02] (14 pages) - Point-to-Multipoint Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) module [draft-ietf-mpls-p2mp-te-mib-09] (62 pages) - Framework for Multi-Protocol Label Switching (MPLS)-based Recovery [draft-ietf-mpls-recovery-frmwrk-08] (34 pages) - Proxy LSP Ping [draft-ietf-mpls-remote-lsp-ping-03] (19 pages) - Return Path Specified LSP Ping [draft-ietf-mpls-return-path-specified-lsp-ping-04] (18 pages) - LDP Specification [draft-ietf-mpls-rfc3036bis-04] (138 pages) - Use of Label Switching With RSVP [draft-ietf-mpls-rsvp-00] (13 pages) - Fast Reroute Extensions to RSVP-TE for LSP Tunnels [draft-ietf-mpls-rsvp-lsp-fastreroute-07] (37 pages) - RSVP-TE: Extensions to RSVP for LSP Tunnels [draft-ietf-mpls-rsvp-lsp-tunnel-09] (64 pages) - Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths [draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09] (11 pages) - Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs) [draft-ietf-mpls-rsvp-te-p2mp-07] (55 pages) - Applicability Statement for Extensions to RSVP for LSP-Tunnels [draft-ietf-mpls-rsvp-tunnel-applicability-02] (8 pages) - Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) [draft-ietf-mpls-rsvp-unnum-08] (9 pages) - MPLS Upstream Label Assignment for RSVP-TE [draft-ietf-mpls-rsvp-upstream-05] (10 pages) - Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) [draft-ietf-mpls-rsvpte-attributes-05] (20 pages) - Inter-Area P2MP Segmented LSPs [draft-ietf-mpls-seamless-mcast-03] (37 pages) - Seamless MPLS Architecture [draft-ietf-mpls-seamless-mpls-01] (48 pages) - MPLS Traffic Engineering Soft Preemption [draft-ietf-mpls-soft-preemption-18] (14 pages) - Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management [draft-ietf-mpls-tc-mib-10] (23 pages) - Improving Topology Data Base Accuracy with Label Switched Path Feedback in Constraint Based Label Distribution Protocol [draft-ietf-mpls-te-feed-06] (13 pages) - Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) [draft-ietf-mpls-te-mib-14] (68 pages) - An Analysis of Scaling Issues in MPLS-TE Core Networks [draft-ietf-mpls-te-scaling-analysis-05] (41 pages) - Traffic Engineering Link Management Information Base [draft-ietf-mpls-telink-mib-07] (55 pages) - Definition of ACH TLV Structure [draft-ietf-mpls-tp-ach-tlv-02] (9 pages) - Proactive Connection Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile [draft-ietf-mpls-tp-bfd-cc-cv-00] (12 pages) - Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile [draft-ietf-mpls-tp-cc-cv-rdi-06] (22 pages) - Indication of Client Failure in MPLS-TP [draft-ietf-mpls-tp-csf-02] (12 pages) - MPLS Transport Profile Data Plane Architecture [draft-ietf-mpls-tp-data-plane-04] (15 pages) - MPLS-TP Next-Hop Ethernet Addressing [draft-ietf-mpls-tp-ethernet-addressing-00] (7 pages) - MPLS Fault Management Operations, Administration, and Maintenance (OAM) [draft-ietf-mpls-tp-fault-07] (17 pages) - A Framework for MPLS in Transport Networks [draft-ietf-mpls-tp-framework-12] (63 pages) - An In-Band Data Communication Network For the MPLS Transport Profile [draft-ietf-mpls-tp-gach-dcn-06] (8 pages) - MPLS Generic Associated Channel [draft-ietf-mpls-tp-gach-gal-06] (19 pages) - MPLS Transport Profile (MPLS-TP) Identifiers [draft-ietf-mpls-tp-identifiers-07] (17 pages) - MPLS-TP Identifiers Following ITU-T Conventions [draft-ietf-mpls-tp-itu-t-identifiers-03] (12 pages) - MPLS Transport Profile Lock Instruct and Loopback Functions [draft-ietf-mpls-tp-li-lb-08] (11 pages) - MPLS Transport Profile (MPLS-TP) Linear Protection [draft-ietf-mpls-tp-linear-protection-09] (42 pages) - Packet Loss and Delay Measurement for the MPLS Transport Profile [draft-ietf-mpls-tp-loss-delay-00] (30 pages) - A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks [draft-ietf-mpls-tp-loss-delay-profile-04] (6 pages) - LSP-Ping and BFD encapsulation over ACH [draft-ietf-mpls-tp-lsp-ping-bfd-procedures-01] (9 pages) - Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-based Management Overview [draft-ietf-mpls-tp-mib-management-overview-08] (26 pages) - Handling MPLS-TP OAM Packets Targeted at Internal MIPs [draft-ietf-mpls-tp-mip-mep-map-01] (15 pages) - Network Management Framework for MPLS-based Transport Networks [draft-ietf-mpls-tp-nm-framework-05] (19 pages) - Network Management Requirements for MPLS-based Transport Networks [draft-ietf-mpls-tp-nm-req-06] (25 pages) - An Overview of the OAM Tool Set for MPLS based Transport Networks [draft-ietf-mpls-tp-oam-analysis-09] (22 pages) - Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks [draft-ietf-mpls-tp-oam-framework-11] (65 pages) - Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks [draft-ietf-mpls-tp-oam-requirements-06] (17 pages) - MPLS On-Demand Connectivity Verification and Route Tracing [draft-ietf-mpls-tp-on-demand-cv-07] (22 pages) - IETF Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP) Document Process [draft-ietf-mpls-tp-process-05] (23 pages) - Requirements of an MPLS Transport Profile [draft-ietf-mpls-tp-requirements-10] (32 pages) - Applicability of MPLS-TP Linear Protection for Ring Topologies [draft-ietf-mpls-tp-ring-protection-02] (28 pages) - A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations. [draft-ietf-mpls-tp-rosetta-stone-05] (21 pages) - MPLS-TP Security Framework [draft-ietf-mpls-tp-security-framework-03] (25 pages) - MPLS Transport Profile (MPLS-TP) Survivability Framework [draft-ietf-mpls-tp-survive-fwk-06] (56 pages) - MPLS-TP Traffic Engineering (TE) Management Information Base (MIB) [draft-ietf-mpls-tp-te-mib-03] (47 pages) - Temporal and hitless path segment monitoring [draft-ietf-mpls-tp-temporal-hitless-psm-00] (15 pages) - MPLS Transport Profile User-to-Network and Network-to-Network Interfaces [draft-ietf-mpls-tp-uni-nni-03] (7 pages) - MPLS-TP Applicability; Use Cases and Design [draft-ietf-mpls-tp-use-cases-and-design-01] (21 pages) - Requirements for Traffic Engineering Over MPLS [draft-ietf-mpls-traffic-eng-01] (28 pages) - Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks [draft-ietf-mpls-ttl-04] (8 pages) - MPLS Upstream Label Assignment and Context-Specific Label Space [draft-ietf-mpls-upstream-label-07] (13 pages) - VCID Notification over ATM link for LDP [draft-ietf-mpls-vcid-atm-05] (16 pages) - MPLS Capability set [draft-loa-mpls-cap-set-01] (7 pages) - LDP IP and PW Capability [draft-raza-mpls-ldp-ip-pw-capability-01] (11 pages) - MPLS-TP Traffic Engineering (TE) Management Information Base (MIB) [draft-vkst-mpls-tp-te-mib-02] (39 pages) Requests for Comments: BCP0128: Avoiding Equal Cost Multipath Treatment in MPLS Networks (9 pages) RFC2702: Requirements for Traffic Engineering Over MPLS (28 pages) RFC3031: Multiprotocol Label Switching Architecture (62 pages) * Updates RFC6178 RFC3032: MPLS Label Stack Encoding (22 pages) * Updates RFC3443 * Updates RFC4182 * Updates RFC5332 * Updates RFC3270 * Updates RFC5129 * Updates RFC5462 * Updates RFC5586 RFC3033: The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol (25 pages) RFC3034: Use of Label Switching on Frame Relay Networks Specification (24 pages) RFC3035: MPLS using LDP and ATM VC Switching (21 pages) RFC3036: LDP Specification (135 pages) * Obsoletes RFC5036 RFC3037: LDP Applicability (6 pages) RFC3038: VCID Notification over ATM link for LDP (16 pages) RFC3063: MPLS Loop Prevention Mechanism (40 pages) RFC3107: Carrying Label Information in BGP-4 (7 pages) RFC3209: RSVP-TE: Extensions to RSVP for LSP Tunnels (64 pages) * Updates RFC3936 * Updates RFC4420 * Updates RFC4874 * Updates RFC5151 * Updates RFC5420 * Updates RFC5711 RFC3210: Applicability Statement for Extensions to RSVP for LSP-Tunnels (8 pages) * Replaces DRAFT-AWDUCHE-MPLS-RSVP-TUNNEL-APPLICABILITY RFC3212: Constraint-Based LSP Setup using LDP (38 pages) * Updates RFC3468 RFC3213: Applicability Statement for CR-LDP (6 pages) RFC3214: LSP Modification Using CR-LDP (10 pages) RFC3215: LDP State Machine (78 pages) RFC3270: Multi-Protocol Label Switching (MPLS) Support of Differentiated Services (53 pages) * Updates RFC3032 * Updates RFC5462 RFC3353: Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment (29 pages) RFC3443: Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks (8 pages) * Replaces DRAFT-AGARWAL-MPLS-TTL * Updates RFC3032 * Updates RFC5462 RFC3468: The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols (8 pages) * Updates RFC3212 * Updates RFC3472 * Updates RFC3475 * Updates RFC3476 RFC3469: Framework for Multi-Protocol Label Switching (MPLS)-based Recovery (34 pages) * Updates RFC5462 RFC3477: Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) (9 pages) * Updates RFC6107 RFC3478: Graceful Restart Mechanism for Label Distribution Protocol (13 pages) RFC3479: Fault Tolerance for the Label Distribution Protocol (LDP) (53 pages) RFC3480: Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol) (8 pages) RFC3612: Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP) (14 pages) RFC3811: Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management (23 pages) RFC3812: Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) (68 pages) RFC3813: Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB) (57 pages) RFC3814: Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB) (40 pages) RFC3815: Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP) (132 pages) RFC3988: Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol (10 pages) RFC4023: Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE) (15 pages) * Updates RFC5332 RFC4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels (37 pages) RFC4182: Removing a Restriction on the use of MPLS Explicit NULL (7 pages) * Updates RFC3032 * Updates RFC5462 RFC4201: Link Bundling in MPLS Traffic Engineering (TE) (12 pages) * Updates RFC3471 * Updates RFC3472 * Updates RFC3473 RFC4206: Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE) (13 pages) * Updates RFC6001 * Updates RFC6107 RFC4220: Traffic Engineering Link Management Information Base (55 pages) * Replaces DRAFT-IETF-MPLS-BUNDLE-MIB RFC4221: Multiprotocol Label Switching (MPLS) Management Overview (29 pages) RFC4368: Multiprotocol Label Switching (MPLS) Label-Controlled Asynchronous Transfer Mode (ATM) and Frame-Relay Management Interface Definition (22 pages) RFC4377: Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks (16 pages) RFC4378: A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM) (11 pages) * Replaces DRAFT-ALLAN-MPLS-OAM-FRMWK RFC4379: Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures (51 pages) * Updates RFC1122 * Updates RFC5462 * Updates RFC6424 * Updates RFC6425 * Updates RFC6426 RFC4420: Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) (20 pages) * Updates RFC3209 * Updates RFC3473 * Obsoletes RFC5420 RFC4461: Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs) (28 pages) RFC4561: Definition of a Record Route Object (RRO) Node-Id Sub-Object (8 pages) RFC4687: Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks (12 pages) * Replaces DRAFT-YASUKAWA-MPLS-P2MP-OAM-REQS RFC4781: Graceful Restart Mechanism for BGP with MPLS (11 pages) RFC4817: Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3 (12 pages) RFC4859: Codepoint Registry for the Flags Field in the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Session Attribute Object (5 pages) * Replaces DRAFT-FARREL-MPLS-IANA-RSVP-SESSION-FLAGS RFC4875: Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs) (55 pages) * Updates RFC6510 RFC4928: Avoiding Equal Cost Multipath Treatment in MPLS Networks (9 pages) RFC4950: ICMP Extensions for Multiprotocol Label Switching (9 pages) RFC5036: LDP Specification (138 pages) * Obsoletes RFC3036 RFC5037: Experience with the Label Distribution Protocol (LDP) (0 pages) RFC5038: The Label Distribution Protocol (LDP) Implementation Survey Results (22 pages) RFC5283: LDP Extension for Inter-Area Label Switched Paths (LSPs) (12 pages) * Replaces DRAFT-DECRAENE-MPLS-LDP-INTERAREA RFC5330: A Link-Type sub-TLV to Convey the Number of Traffic Engineering Label Switched Paths Signalled with Zero Reserved Bandwidth across a Link (10 pages) * Replaces DRAFT-VASSEUR-MPLS-NUMBER-0-BW-TE-LSPS RFC5331: MPLS Upstream Label Assignment and Context-Specific Label Space (13 pages) RFC5332: MPLS Multicast Encapsulations (11 pages) * Updates RFC3032 * Updates RFC4023 RFC5439: An Analysis of Scaling Issues in MPLS-TE Core Networks (41 pages) RFC5443: LDP IGP Synchronization (8 pages) * Replaces DRAFT-IETF-MPLS-IGP-SYNC * Updates RFC6138 RFC5462: Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field (18 pages) * Updates RFC3032 * Updates RFC3270 * Updates RFC3272 * Updates RFC3443 * Updates RFC3469 * Updates RFC3564 * Updates RFC3985 * Updates RFC4182 * Updates RFC4364 * Updates RFC4379 * Updates RFC4448 * Updates RFC4761 * Updates RFC5129 RFC5561: LDP Capabilities (14 pages) * Replaces DRAFT-THOMAS-MPLS-LDP-CAPABILITIES RFC5586: MPLS Generic Associated Channel (19 pages) * Replaces DRAFT-BOCCI-MPLS-TP-GACH-GAL * Updates RFC3032 * Updates RFC4385 * Updates RFC5085 * Updates RFC6423 RFC5654: Requirements of an MPLS Transport Profile (32 pages) * Replaces DRAFT-JENKINS-MPLS-MPLS-TP-REQUIREMENTS RFC5710: PathErr Message Triggered MPLS and GMPLS LSP Reroutes (12 pages) * Replaces DRAFT-BERGER-MPLS-GMPLS-LSP-REROUTE RFC5711: Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages (7 pages) * Replaces DRAFT-VASSEUR-MPLS-3209-PATHERR * Updates RFC3209 RFC5712: MPLS Traffic Engineering Soft Preemption (14 pages) RFC5718: An In-Band Data Communication Network For the MPLS Transport Profile (8 pages) * Replaces DRAFT-BELLER-MPLS-TP-GACH-DCN RFC5860: Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks (17 pages) * Replaces DRAFT-VIGOUREUX-MPLS-TP-OAM-REQUIREMENTS RFC5918: Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC) (11 pages) * Replaces DRAFT-THOMAS-MPLS-LDP-TYPED-WILDCARD RFC5919: Signaling LDP Label Advertisement Completion (11 pages) * Replaces DRAFT-ASATI-MPLS-LDP-END-OF-LIB RFC5920: Security Framework for MPLS and GMPLS Networks (63 pages) RFC5921: A Framework for MPLS in Transport Networks (63 pages) * Replaces DRAFT-BLB-MPLS-TP-FRAMEWORK * Updates RFC6215 RFC5950: Network Management Framework for MPLS-based Transport Networks (19 pages) * Replaces DRAFT-MANSFIELD-MPLS-TP-NM-FRAMEWORK RFC5951: Network Management Requirements for MPLS-based Transport Networks (25 pages) * Replaces DRAFT-GRAY-MPLS-TP-NM-REQ RFC5960: MPLS Transport Profile Data Plane Architecture (15 pages) * Replaces DRAFT-FBB-MPLS-TP-DATA-PLANE RFC6138: LDP IGP Synchronization for Broadcast Networks (11 pages) * Replaces DRAFT-LU-LDP-IGP-SYNC-BCAST * Updates RFC5443 RFC6178: Label Edge Router Forwarding of IPv4 Option Packets (10 pages) * Replaces DRAFT-DASMITH-MPLS-IP-OPTIONS * Updates RFC3031 RFC6215: MPLS Transport Profile User-to-Network and Network-to-Network Interfaces (7 pages) * Replaces DRAFT-BFL-MPLS-TP-UNI-NNI * Updates RFC5921 RFC6348: Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol (20 pages) * Replaces DRAFT-LEROUX-MPLS-MP-LDP-REQS RFC6370: MPLS Transport Profile (MPLS-TP) Identifiers (17 pages) * Replaces DRAFT-SWALLOW-MPLS-TP-IDENTIFIERS RFC6371: Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks (65 pages) * Replaces DRAFT-BUSI-MPLS-TP-OAM-FRAMEWORK * Updates RFC6435 RFC6372: MPLS Transport Profile (MPLS-TP) Survivability Framework (56 pages) * Replaces DRAFT-SPRECHER-MPLS-TP-SURVIVE-FWK RFC6374: Packet Loss and Delay Measurement for MPLS Networks (52 pages) * Replaces DRAFT-FROST-MPLS-LOSS-DELAY RFC6375: A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks (6 pages) * Replaces DRAFT-IETF-MPLS-TP-LOSS-DELAY RFC6378: MPLS Transport Profile (MPLS-TP) Linear Protection (42 pages) * Replaces DRAFT-WEINGARTEN-MPLS-TP-LINEAR-PROTECTION RFC6388: Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths (39 pages) * Replaces DRAFT-MINEI-MPLS-LDP-P2MP * Replaces DRAFT-MINEI-WIJNANDS-MPLS-LDP-P2MP RFC6389: MPLS Upstream Label Assignment for LDP (14 pages) * Replaces DRAFT-RAGGARWA-MPLS-LDP-UPSTREAM RFC6424: Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels (23 pages) * Replaces DRAFT-NITINB-LSP-PING-OVER-MPLS-TUNNEL * Updates RFC4379 RFC6425: Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping (29 pages) * Replaces DRAFT-YASUKAWA-MPLS-P2MP-LSP-PING * Updates RFC4379 RFC6426: MPLS On-Demand Connectivity Verification and Route Tracing (22 pages) * Replaces DRAFT-NITINB-MPLS-TP-ON-DEMAND-CV * Updates RFC4379 RFC6427: MPLS Fault Management Operations, Administration, and Maintenance (OAM) (17 pages) * Replaces DRAFT-BOUTROS-MPLS-TP-FAULT * Replaces DRAFT-SFV-MPLS-TP-FAULT RFC6428: Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile (22 pages) * Replaces DRAFT-IETF-MPLS-TP-BFD-CC-CV RFC6435: MPLS Transport Profile Lock Instruct and Loopback Functions (11 pages) * Replaces DRAFT-BOUTROS-MPLS-TP-LI-LB * Updates RFC6371 RFC6445: Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute (50 pages) * Replaces DRAFT-CETIN-MPLS-FASTREROUTE-MIB RFC6511: Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths (11 pages) * Replaces DRAFT-ALI-MPLS-RSVP-TE-NO-PHP-OOB-MAPPING RFC6512: Using Multipoint LDP When the Backbone Has No Route to the Root (12 pages) * Replaces DRAFT-WIJNANDS-MPLS-MLDP-RECURS-FEC Network Virtualization Overlays (nvo3) -------------------------------------- Charter Last Modified: 2012-02-23 Current Status: Active Chairs: Matthew Bocci Benson Schliesser Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Stewart Bryant Tech Advisor: Ronald Bonica Mailing Lists: General Discussion: nvo3@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/nvo3 Archive: http://www.ietf.org/mail-archive/web/nvo3/ Description of Working Group: Support for multi-tenancy has become a core requirement of data centers (DCs), especially in the context of data centers supporting virtualized hosts known as virtual machines (VMs). Three key requirements needed to support multi-tenancy are: o Traffic isolation, so that a tenant's traffic is not visible to any other tenant, and o Address independence, so that one tenant's addressing scheme does not collide with other tenant's addressing schemes or with addresses used within the data center itself. o Support the placement and migration of VMs anywhere within the data center, without being limited by DC network constraints such as the IP subnet boundaries of the underlying DC network. An NVO3 solution (known here as a Data Center Virtual Private Network (DCVPN)) is a VPN that is viable across a scaling range of a few thousand VMs to several million VMs running on greater than one hundred thousand physical servers. It thus has good scaling properties from relatively small networks to networks with several million DCVPN endpoints and hundreds of thousands of DCVPNs within a single administrative domain. A DCVPN also supports VM migration between physical servers in a sub-second timeframe. Note that although this charter uses the term VM throughout, NVO3 must also support connectivity to traditional hosts e.g. hosts that do not have hypervisors. NVO3 will consider approaches to multi-tenancy that reside at the network layer rather than using traditional isolation mechanisms that rely on the underlying layer 2 technology (e.g., VLANs). The NVO3 WG will determine which types of connectivity services are needed by typical DC deployments (for example, IP and/or Ethernet). NVO3 will document the problem statement, the applicability, and an architectural framework for DCVPNs within a data center environment. Within this framework, functional blocks will be defined to allow the dynamic attachment / detachment of VMs to their DCVPN, and the interconnection of elements of the DCVPNs over the underlying physical network. This will support the delivery of packets to the destination VM within the scaling and migration limits described above. Based on this framework, the NVO3 WG will develop requirements for both control plane protocol(s) and data plane encapsulation format(s), and perform a gap analysis of existing candidate mechanisms. In addition to functional and architectural requirements, the NVO3 WG will develop management, operational, maintenance, troubleshooting, security and OAM protocol requirements. The NVO3 WG will investigate the interconnection of the DCVPNs and their tenants with non-NVO3 IP network(s) to determine if any specific work is needed. The NVO3 WG will write the following informational RFCs, which must have completed Working Group Last Call before rechartering can be considered: Problem Statement Framework document Control plane requirements document Data plane requirements document Operational Requirements Gap Analysis Driven by the requirements and consistent with the gap analysis, the NVO3 WG may request being rechartered to document solutions consisting of one or more data plane encapsulations and control plane protocols as applicable. Any documented solutions will use existing IETF protocols if suitable. Otherwise, the NVO3 WG may propose the development of new IETF protocols, or the writing of an applicability statement for non-IETF protocols. If the WG anticipates the adoption of the technologies of another SDO, such as the IEEE, as part of the solution, it will liaise with that SDO to ensure the compatibility of the approach. Goals and Milestones: Dec 2012 - Problem Statement submitted for IESG review Dec 2012 - Framework document submitted for IESG review Dec 2012 - Data plane requirements submitted for IESG review Dec 2012 - Operational Requirements submitted for IESG review Mar 2013 - Control plane requirements submitted for IESG review Mar 2013 - Gap Analysis submitted for IESG review Apr 2013 - Recharter or close Working Group Internet-Drafts: No Requests for Comments Open Shortest Path First IGP (ospf) ----------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Abhay Roy Acee Lindem Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Stewart Bryant Mailing Lists: General Discussion: ospf@ietf.org To Subscribe: ospf-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/ospf/ Description of Working Group: The OSPF Working develops and documents extensions and bug fixes to the OSPF protocol, as well as documenting OSPF usage scenarios. The specific protocol work items area listed in the Goals and Milestones section below. Additional work items will require rechartering. Goals and Milestones: Done - Develop multiple implementations, and test against each other. Done - Design the routing protocol, and write its specification. Done - Obtain performance data for the protocol. Done - Make changes to the specification (if necessary) and publish the protocol as a Draft Standard RFC. Done - Gather operational experience with the OSPF protocol and submit the document as an Informational RFC. Done - Submit OSPF for IPv6 to IESG for consideration as a Standard. Done - Update the OSPF NSSA option specified in RFC 1587 and submit to IESG for consideration as a Proposed Standard Done - Develop Traffic Engineering extensions for OSPFv2 and submit it to the IESG as a Proposed Standard Done - Submit to IESG a document which updates RFC 1793 allowing detection of demand circuit neighbors whose OSPF process has exited. Done - Submit to IESG a BCP advocating that OSPF LSA refreshes be spread out over time Done - Develop a hitless restart mechanism for OSPF and submit it to the IESG as a Proposed Standard. Done - Document Alternative ABR implementations and submit ti IESG as an Informational RFC Done - Extend the hitless restart mechanism to OSPFv3 and submit it to the IESG as a Proposed Standard Done - Submit to IESG a BCP advocating that OSPF Hellos be given preference over other OSPF control traffic. Done - Update OSPFv2 MIB and submit to IESG as a Standard, replacing RFC 1850 Done - Specify IPSEC usage with OSPFv3 and submit to IESG for consideration as a Proposed Standard Done - Extend OSPF Demand Circuits to detect inactive neighbors and submit to IESG for consideration as a Proposed Standard Done - Provide mechanisms to prevent looping in RFC 2547 OSPF networks and submit to IESG for consideration as a Proposed Standard Done - Develop OSPFv2 Multiple Topology Routing (MTR) specification and submit to IESG for consideration as a Proposed Standard Done - Develop OSPF Capabilities Advertisement specification and submit to IESG for consideration as a Proposed Standard Done - Document IANA Considerations for OSPFv2 and OSPFv3 for consideration as a BCP Mar 2008 - Develop OSPF for IPv6 MIB and submit to IESG for consideration as a Proposed Standard Mar 2008 - Reissue RFC 2370 with corrections and clarifications and submit to IESG for consideration as a Proposed Standard Mar 2008 - Reissue RFC 2740 with corrections and clarifications and submit to IESG for consideration as a Proposed Standard Mar 2008 - Develop mechanisms for support of multi-area adjacencies on a single link and submit to IESG for consideration as a Proposed Standard Mar 2008 - Advance Link Local Signaling (LLS) from experimental status and submit to IESG for consideration as a Proposed Standard Jul 2008 - Develop Traffic Engineering extensions for OSPFv3 and submit it to the IESG as a Proposed Standard Jul 2008 - Develop multiple instance OSPFv3 protocol mechanisms to support multiple address families and topologies Jul 2008 - Develop multiple OSPFv3 protocol alternatives to reduce flooding overhead and adjacencies in a MANET environment and submit to the IESG as experimental RFCs Jul 2008 - Develop a OSPFv2 Multiple Topology Routing (MTR) MIB specification and submit to IESG for consideration as a Proposed Standard Nov 2008 - Develop stronger authentication mechanisms for OSPFv2 and submit to IESG as a Proposed Standard Mar 2009 - Develop a single instance OSPFv3 Multiple Topology Routing (MTR) specification and submit to IESG for consideration as a Proposed Standard Internet-Drafts: - QoS Routing Mechanisms and OSPF Extensions [draft-guerin-qos-routing-ospf-05] (47 pages) - Multicast Extensions to OSPF [draft-ietf-mospf-mospf-01] (102 pages) - Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs) [draft-ietf-ospf-2547-dnbit-04] (8 pages) - Type 5 to Type 7 Translation [draft-ietf-ospf-5to7-01] (10 pages) - Alternative Implementations of OSPF Area Border Routers [draft-ietf-ospf-abr-alt-05] (10 pages) - OSPF ABR Behavior [draft-ietf-ospf-abr-behavior-00] (15 pages) - Support of Address Families in OSPFv3 [draft-ietf-ospf-af-alt-10] (15 pages) - OSPF Protocol Analysis [draft-ietf-ospf-analysis-00] (0 pages) - The OSPF Address Resolution Advertisement Option [draft-ietf-ospf-ara-02] (40 pages) - OSPF over ATM and Proxy-PAR [draft-ietf-ospf-atm-03] (13 pages) - Supporting Authentication Trailer for OSPFv3 [draft-ietf-ospf-auth-trailer-ospfv3-11] (23 pages) - Extensions to OSPF for Advertising Optional Router Capabilities [draft-ietf-ospf-cap-11] (15 pages) - IP Forwarding Table MIB [draft-ietf-ospf-cidr-route-mib-05] (29 pages) - OSPF Database Exchange Summary List Optimization [draft-ietf-ospf-dbex-opt-02] (6 pages) - Detecting Inactive Neighbors over OSPF Demand Circuits (DC) [draft-ietf-ospf-dc-07] (5 pages) - Extending OSPF to Support Demand Circuits [draft-ietf-ospf-demand-01] (32 pages) - Techniques in OSPF-based Network [draft-ietf-ospf-deploy-00] (0 pages) - Extensions to OSPF for support of Diff-Serv-aware MPLS Traffic Engineering [draft-ietf-ospf-diff-te-00] (7 pages) - OSPFv2 Domain Of Interpretation (DOI) for ISAKMP [draft-ietf-ospf-doi-00] (11 pages) - Dynamic Hostname Exchange Mechanism for OSPF [draft-ietf-ospf-dynamic-hostname-05] (11 pages) - Experience with the OSPF Protocol [draft-ietf-ospf-experience-00] (0 pages) - The OSPF External Attributes LSA [draft-ietf-ospf-extattr-00] (18 pages) - OSPF Floodgates [draft-ietf-ospf-floodgates-01] (22 pages) - Graceful OSPF Restart Implementation Report [draft-ietf-ospf-graceful-impl-report-05] (6 pages) - Guidelines for Running OSPF Over Frame Relay Networks [draft-ietf-ospf-guidelines-frn-00] (6 pages) - Graceful OSPF Restart [draft-ietf-ospf-hitless-restart-08] (15 pages) - OSPFv2 HMAC-SHA Cryptographic Authentication [draft-ietf-ospf-hmac-sha-07] (15 pages) - OSPF Hybrid Broadcast and P2MP Interface Type [draft-ietf-ospf-hybrid-bcast-and-p2mp-02] (16 pages) - IANA Considerations for OSPF [draft-ietf-ospf-iana-03] (15 pages) - Routing for IPv4-embedded IPv6 Packets [draft-ietf-ospf-ipv4-embedded-ipv6-routing-02] (12 pages) - OSPF IPv6 Extensions [draft-ietf-ospf-ipv6-ext-00] (9 pages) - Flooding optimizations in link-state routing protocols [draft-ietf-ospf-isis-flood-opt-01] (12 pages) - OSPF Link-Local Signaling [draft-ietf-ospf-lls-08] (16 pages) - Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding [draft-ietf-ospf-manet-mdr-05] (63 pages) - OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks [draft-ietf-ospf-manet-mpr-04] (31 pages) - Extensions to OSPF to Support Mobile Ad Hoc Networking [draft-ietf-ospf-manet-or-03] (35 pages) - Use of OSPF-MDR in Single-Hop Broadcast Networks [draft-ietf-ospf-manet-single-hop-mdr-00] (6 pages) - OSPF Cryptographic Authentication [draft-ietf-ospf-md5-02] (12 pages) - OSPF Version 2 Management Information Base [draft-ietf-ospf-mib-05] (108 pages) - OSPF Version 2 Management Information Base [draft-ietf-ospf-mib-update-11] (111 pages) - OSPF Multiple Area Links [draft-ietf-ospf-mlinks-03] (19 pages) - Multi-Topology (MT) Routing in OSPF [draft-ietf-ospf-mt-09] (25 pages) - OSPF Version 2 MIB for Multi-Topology (MT) Routing [draft-ietf-ospf-mt-mib-04] (29 pages) - Multi-topology routing in OSPFv3 (MT-OSPFv3) [draft-ietf-ospf-mt-ospfv3-03] (26 pages) - OSPF Multi-Area Adjacency [draft-ietf-ospf-multi-area-adj-09] (15 pages) - OSPFv2 Multi-Instance Extensions [draft-ietf-ospf-multi-instance-09] (13 pages) - The OSPF NSSA Option [draft-ietf-ospf-nssa-option-00] (15 pages) - The OSPF Not-So-Stubby Area (NSSA) Option [draft-ietf-ospf-nssa-update-11] (30 pages) - OSPF Optimized Multipath (OSPF-OMP) [draft-ietf-ospf-omp-02] (38 pages) - OSPF Out-of-band LSDB resynchronization [draft-ietf-ospf-oob-resync-01] (7 pages) - The OSPF Opaque LSA Option [draft-ietf-ospf-opaque-05] (16 pages) - OSPF Version 2 [draft-ietf-ospf-ospf2-01] (0 pages) - OSPF Version 2 Management Information Base [draft-ietf-ospf-ospfmib-04] (0 pages) - Authentication/Confidentiality for OSPFv3 [draft-ietf-ospf-ospfv3-auth-08] (15 pages) - OSPFv3 Graceful Restart [draft-ietf-ospf-ospfv3-graceful-restart-08] (8 pages) - Management Information Base for OSPFv3 [draft-ietf-ospf-ospfv3-mib-16] (85 pages) - OSPF for IPv6 Standardization Report [draft-ietf-ospf-ospfv3-stdreport-00] (7 pages) - Traffic Engineering Extensions to OSPF Version 3 [draft-ietf-ospf-ospfv3-traffic-13] (17 pages) - OSPF for IPv6 [draft-ietf-ospf-ospfv3-update-23] (111 pages) - OSPF for IPv6 [draft-ietf-ospf-ospfv6-08] (93 pages) - OSPF Database Overflow [draft-ietf-ospf-overflow-00] (11 pages) - OSPF Point-to-MultiPoint Interface [draft-ietf-ospf-pmp-if-00] (6 pages) - Flooding over parallel point-to-point links [draft-ietf-ospf-ppp-flood-01] (8 pages) - Hiding Transit-only Networks in OSPF [draft-ietf-ospf-prefix-hiding-03] (12 pages) - Guidelines for Efficient LSA Refreshment in OSPF [draft-ietf-ospf-refresh-guide-01] (11 pages) - OSPF Restart Signaling [draft-ietf-ospf-restart-01] (4 pages) - The OSPF Opaque LSA Option [draft-ietf-ospf-rfc2370bis-05] (17 pages) - OSPF Stub Router Advertisement [draft-ietf-ospf-rfc3137bis-00] (6 pages) - Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance [draft-ietf-ospf-scalability-09] (14 pages) - Security Extension for OSPFv2 when using Manual Key Management [draft-ietf-ospf-security-extension-manual-keying-02] (11 pages) - OSPF Shortcut ABR Enhanced OSPF ABR Behavior [draft-ietf-ospf-shortcut-abr-02] (19 pages) - OSPF Standardization Report [draft-ietf-ospf-stdreport-03] (8 pages) - OSPF Stub Router Advertisement [draft-ietf-ospf-stub-adv-02] (4 pages) - Flooding Over a Subset Topology [draft-ietf-ospf-subset-flood-00] (13 pages) - OSPF Traffic Engineering (TE) Metric Extensions [draft-ietf-ospf-te-metric-extensions-00] (15 pages) - Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions [draft-ietf-ospf-te-node-addr-07] (9 pages) - OSPF Transport Instance Extensions [draft-ietf-ospf-transport-instance-08] (14 pages) - OSPF Version 2 Traps [draft-ietf-ospf-trapmib-02] (13 pages) - Proposed modifications to RFC 1247 [draft-ietf-ospf-v2update-00] (8 pages) - OSPF Version 2 [draft-ietf-ospf-vers2-02] (215 pages) - OSPF Version 2 [draft-ietf-ospf-version2-10] (220 pages) - Traffic Engineering (TE) Extensions to OSPF Version 2 [draft-katz-yeung-ospf-traffic-10] (15 pages) - OSPF Database Exchange Summary List Optimization [draft-ogier-ospf-dbex-opt-03] (6 pages) - OSPF Refresh and Flooding Reduction in Stable Topologies [draft-pillay-esnault-ospf-flooding-07] (5 pages) Requests for Comments: BCP0112: Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance (14 pages) BCP0130: IANA Considerations for OSPF (15 pages) RFC1245: OSPF Protocol Analysis (0 pages) RFC1246: Experience with the OSPF Protocol (0 pages) RFC1247: OSPF Version 2 (0 pages) * Obsoletes RFC1131 * Obsoletes RFC1583 * Updates RFC1349 RFC1252: OSPF Version 2 Management Information Base (0 pages) * Obsoletes RFC1248 * Obsoletes RFC1253 RFC1586: Guidelines for Running OSPF Over Frame Relay Networks (6 pages) RFC1587: The OSPF NSSA Option (15 pages) * Obsoletes RFC3101 RFC1765: OSPF Database Overflow (11 pages) RFC1793: Extending OSPF to Support Demand Circuits (32 pages) * Updates RFC3883 RFC1850: OSPF Version 2 Management Information Base (108 pages) * Obsoletes RFC1253 * Obsoletes RFC4750 RFC2096: IP Forwarding Table MIB (29 pages) * Obsoletes RFC1354 * Obsoletes RFC4292 RFC2178: OSPF Version 2 (220 pages) * Obsoletes RFC1583 * Obsoletes RFC2328 RFC2328: OSPF Version 2 (215 pages) * Obsoletes RFC2178 * Updates RFC5709 * Updates RFC6549 RFC2329: OSPF Standardization Report (8 pages) RFC2370: The OSPF Opaque LSA Option (16 pages) * Obsoletes RFC5250 * Updates RFC3630 RFC2676: QoS Routing Mechanisms and OSPF Extensions (47 pages) RFC2740: OSPF for IPv6 (93 pages) * Obsoletes RFC5340 RFC2844: OSPF over ATM and Proxy-PAR (13 pages) RFC3101: The OSPF Not-So-Stubby Area (NSSA) Option (30 pages) * Obsoletes RFC1587 RFC3137: OSPF Stub Router Advertisement (4 pages) RFC3509: Alternative Implementations of OSPF Area Border Routers (10 pages) RFC3623: Graceful OSPF Restart (15 pages) RFC3630: Traffic Engineering (TE) Extensions to OSPF Version 2 (15 pages) * Updates RFC2370 * Updates RFC4203 * Updates RFC5786 RFC3883: Detecting Inactive Neighbors over OSPF Demand Circuits (DC) (5 pages) * Updates RFC1793 RFC4136: OSPF Refresh and Flooding Reduction in Stable Topologies (5 pages) RFC4167: Graceful OSPF Restart Implementation Report (6 pages) RFC4222: Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance (14 pages) RFC4552: Authentication/Confidentiality for OSPFv3 (15 pages) RFC4576: Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs) (8 pages) RFC4750: OSPF Version 2 Management Information Base (111 pages) * Obsoletes RFC1850 RFC4915: Multi-Topology (MT) Routing in OSPF (25 pages) RFC4940: IANA Considerations for OSPF (15 pages) RFC4970: Extensions to OSPF for Advertising Optional Router Capabilities (15 pages) RFC5185: OSPF Multi-Area Adjacency (15 pages) RFC5187: OSPFv3 Graceful Restart (8 pages) RFC5243: OSPF Database Exchange Summary List Optimization (6 pages) RFC5250: The OSPF Opaque LSA Option (17 pages) * Replaces DRAFT-BERGER-OSPF-RFC2370BIS * Obsoletes RFC2370 RFC5329: Traffic Engineering Extensions to OSPF Version 3 (17 pages) RFC5340: OSPF for IPv6 (111 pages) * Obsoletes RFC2740 RFC5449: OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks (31 pages) RFC5613: OSPF Link-Local Signaling (16 pages) * Obsoletes RFC4813 RFC5614: Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding (63 pages) RFC5642: Dynamic Hostname Exchange Mechanism for OSPF (11 pages) RFC5643: Management Information Base for OSPFv3 (85 pages) RFC5709: OSPFv2 HMAC-SHA Cryptographic Authentication (15 pages) * Updates RFC2328 RFC5786: Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions (9 pages) * Updates RFC3630 RFC5820: Extensions to OSPF to Support Mobile Ad Hoc Networking (35 pages) RFC5838: Support of Address Families in OSPFv3 (15 pages) RFC6506: Supporting Authentication Trailer for OSPFv3 (23 pages) * Replaces DRAFT-BHATIA-MANRAL-AUTH-TRAILER-OSPFV3 RFC6549: OSPFv2 Multi-Instance Extensions (13 pages) * Updates RFC2328 STD0054: OSPF Version 2 (215 pages) * Obsoletes RFC2178 Path Computation Element (pce) ------------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: JP Vasseur Julien Meuric Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Adrian Farrel Secretary: Daniel King <> Mailing Lists: General Discussion: pce@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/pce Archive: http://www.ietf.org/mail-archive/web/pce/ Description of Working Group: The PCE Working Group is chartered to specify the required protocols so as to enable a Path Computation Element (PCE)-based architecture for the computation of paths for MPLS and GMPLS Point to Point and Point to Multi-point Traffic Engineered LSPs. In this architecture path computation does not necessarily occur on the head-end (ingress) LSR, but on some other path computation entity that may physically not be located on each head-end LSR. The PCE WG works on application of this model within a single domain or within a group of domains (where a domain is a layer, IGP area or Autonomous System with limited visibility from the head-end LSR). At this time, applying this model to large groups of domains such as the Internet is not thought to be possible, and the PCE WG will not spend energy on that topic. The WG specifies the PCE communication Protocol (PCEP) and needed extensions for communication between LSRs (termed Path Computation Clients - PCCs) and PCEs, and between cooperating PCEs. Security mechanisms such as authentication and confidentiality are included. The WG determines requirements for extensions to existing routing and signaling protocols in support of the PCE architecture and the signaling of inter-domain paths (e.g. RSVP-TE and its GMPLS variations). Any necessary extensions will be produced in collaboration with the Working Groups responsible for the protocols. The WG also works on the mechanisms to for multi-layer path computation and PCEP extensions for communication between several network layers. The WG defines the required PCEP extensions for Wavelength Switched Optical Networks (WSON) while keeping consistency with the GMPLS architecture specified in the CCAMP WG. Work Items: - PCEP extensions for MPLS and GMPLS Traffic Engineered LSP path computation models involving PCE(s). This includes the case of computing the paths of intra and inter-domain TE LSPs. Such path computation includes the generation of primary, protection and recovery paths, as well as computations for (local/global) reoptimization and load balancing. Both intra- and inter-domain applications are covered. - In cooperation with protocol specific Working Group (e.g., MPLS, CCAMP), development of LSP signaling (RSVP-TE) extensions required to support PCE-based path computation models. - Specification of PCEP extensions for communication in the various GMPLS-controlled networks, including WSON. - Definition of PCEP extensions for path computation in multi-layer networks. Goals and Milestones: Done - Submit first draft of PCE architecture document Done - Submit first draft of PCE discovery requirements and protocol extensions documents Done - Submit first draft of the PCE communication protocol requirements Done - Submit first draft of the definition of objective metrics Done - Submit first draft of the PCE communication protocol specification Done - Submit PCE architecture specification to the IESG to be considered as Informational RFC Done - Submit first draft of the MIB module for the PCE protocol Done - Submit PCE communication protocol requirements to the IESG to be considered as an Informational RFC Done - Submit PCE discovery protocol extensions specifications to the IESG to be considered as a Proposed Standard Done - Submit PCE communication protocol specification to the IESG to be considered as a Proposed Standard Done - Submit first draft of the PCE P2MP communication requirements Done - Submit first draft of the PCE P2MP PCEP protocol extensions Done - Submit PCE P2MP communication requirements to the IESG to be considered as an Informational RFC Done - Submit PCE P2MP PCEP protocol extensions to the IESG to be considered as an Proposed Standard RFC Done - Submit applicability and metrics documents to the IESG Oct 2011 - Submit WSON requirements to the IESG to be considered as an Informational RFC Dec 2011 - Submit extensions for hierarchical PCE path computation model as WG document Jan 2012 - Submit the PCEP MIB to the IESG to be considered as a Proposed Standard Jan 2012 - Submit P2MP MIB as a WG document Feb 2012 - Submit the discovery MIB to the IESG to be considered as a Proposed Standard Feb 2012 - Submit inter-layer extensions to the IESG to be considered as a Proposed Standard Mar 2012 - Submit inter-area/AS applicability statement to the IESG as an informational RFC Mar 2012 - Submit PCEP extensions for WSON as a WG document Apr 2012 - Submit the GMPLS requirements to the IESG to be considered as an Informational RFC Jun 2012 - Submit PCEP extensions for GMPLS to the IESG to be considered as a Proposed Standard Aug 2012 - Submit PCEP extensions for WSON to the IESG to be considered as a Proposed Standard Oct 2012 - Submit P2MP MIB to the IESG to be considered as a Proposed Standard Feb 2013 - Submit extensions for hierarchical model to the IESG to be considered as a Proposed Standard Mar 2013 - Evaluate WG progress, recharter or close Internet-Drafts: - A Path Computation Element (PCE)-Based Architecture [draft-ietf-pce-architecture-05] (37 pages) - A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths [draft-ietf-pce-brpc-09] (20 pages) - Path Computation Element (PCE) Communication Protocol Generic Requirements [draft-ietf-pce-comm-protocol-gen-reqs-07] (19 pages) - Definitions of Managed Objects for Path Computation Element Discovery [draft-ietf-pce-disc-mib-04] (24 pages) - IGP protocol extensions for Path Computation Element (PCE) Discovery [draft-ietf-pce-disco-proto-igp-02] (37 pages) - IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery [draft-ietf-pce-disco-proto-isis-08] (16 pages) - OSPF Protocol Extensions for Path Computation Element (PCE) Discovery [draft-ietf-pce-disco-proto-ospf-08] (19 pages) - Requirements for Path Computation Element (PCE) Discovery [draft-ietf-pce-discovery-reqs-05] (18 pages) - Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol [draft-ietf-pce-dste-02] (10 pages) - Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization [draft-ietf-pce-global-concurrent-optimization-10] (27 pages) - Document: [draft-ietf-pce-gmpls-aps-req-05] (14 pages) - PCEP extensions for GMPLS [draft-ietf-pce-gmpls-pcep-extensions-05] (41 pages) - The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS [draft-ietf-pce-hierarchy-fwk-02] (31 pages) - Applicability of the Path Computation Element to Inter-Area and Inter-AS MPLS and GMPLS Traffic Engineering [draft-ietf-pce-inter-area-as-applicability-02] (21 pages) - Extensions to the Path Computation Element communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering [draft-ietf-pce-inter-layer-ext-06] (18 pages) - Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering [draft-ietf-pce-inter-layer-frwk-10] (33 pages) - PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering [draft-ietf-pce-inter-layer-req-15] (13 pages) - Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP) [draft-ietf-pce-interas-pcecp-reqs-06] (14 pages) - Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts [draft-ietf-pce-manageability-requirements-11] (12 pages) - A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture [draft-ietf-pce-monitoring-09] (28 pages) - Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP) [draft-ietf-pce-of-06] (20 pages) - Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE) [draft-ietf-pce-p2mp-app-02] (15 pages) - Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE [draft-ietf-pce-p2mp-req-05] (11 pages) - Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism [draft-ietf-pce-path-key-06] (19 pages) - Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering [draft-ietf-pce-pcecp-interarea-reqs-05] (11 pages) - Path Computation Element (PCE) Communication Protocol (PCEP) [draft-ietf-pce-pcep-19] (89 pages) - PCE-based Computation Procedure To Compute Shortest Constrained P2MP Inter-domain Traffic Engineering Label Switched Paths [draft-ietf-pce-pcep-inter-domain-p2mp-procedures-02] (26 pages) - PCE communication protocol(PCEP) Management Information Base [draft-ietf-pce-pcep-mib-02] (25 pages) - Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths [draft-ietf-pce-pcep-p2mp-extensions-11] (31 pages) - Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations [draft-ietf-pce-pcep-svec-list-05] (17 pages) - Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions [draft-ietf-pce-pcep-xro-06] (17 pages) - Policy-Enabled Path Computation Framework [draft-ietf-pce-policy-enabled-path-comp-04] (36 pages) - PCEP Extensions for Stateful PCE [draft-ietf-pce-stateful-pce-00] (51 pages) - Definitions of Textual Conventions for Path Computation Element [draft-ietf-pce-tc-mib-05] (6 pages) - Conveying Vendor-Specific Constraints in the Path Computation Element Protocol [draft-ietf-pce-vendor-constraints-05] (13 pages) - PCC-PCE Communication Requirements for VPNs [draft-ietf-pce-vpn-req-02] (16 pages) - PCEP Requirements for WSON Routing and Wavelength Assignment [draft-ietf-pce-wson-routing-wavelength-07] (13 pages) Requests for Comments: RFC4655: A Path Computation Element (PCE)-Based Architecture (37 pages) * Replaces DRAFT-ASH-PCE-ARCHITECTURE RFC4657: Path Computation Element (PCE) Communication Protocol Generic Requirements (19 pages) * Replaces DRAFT-ASH-PCE-COMM-PROTOCOL-GEN-REQS RFC4674: Requirements for Path Computation Element (PCE) Discovery (18 pages) * Replaces DRAFT-LEROUX-PCE-DISCOVERY-REQS RFC4927: Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering (11 pages) RFC5088: OSPF Protocol Extensions for Path Computation Element (PCE) Discovery (19 pages) RFC5089: IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery (16 pages) * Replaces DRAFT-IETF-PCE-DISCO-PROTO-IGP RFC5376: Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP) (14 pages) * Replaces DRAFT-LEROUX-PCE-PCECP-INTERAREA-REQS RFC5394: Policy-Enabled Path Computation Framework (36 pages) * Replaces DRAFT-BRYSKIN-PCE-POLICY-ENABLED-PATH-COMP RFC5440: Path Computation Element (PCE) Communication Protocol (PCEP) (89 pages) * Replaces DRAFT-VASSEUR-PCE-PCEP RFC5441: A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths (20 pages) * Replaces DRAFT-VASSEUR-PCE-BRPC RFC5455: Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol (10 pages) * Replaces DRAFT-SIVABALAN-PCE-DSTE RFC5520: Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism (19 pages) * Replaces DRAFT-BRADFORD-PCE-PATH-KEY RFC5521: Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions (17 pages) * Replaces DRAFT-OKI-PCE-PCEP-XRO RFC5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP) (20 pages) * Replaces DRAFT-LEROUX-PCE-OF RFC5557: Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization (27 pages) * Replaces DRAFT-LEE-PCE-GLOBAL-CONCURRENT-OPTIMIZATION RFC5623: Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering (33 pages) * Replaces DRAFT-OKI-PCE-INTER-LAYER-FRWK RFC5671: Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE) (15 pages) * Replaces DRAFT-YASUKAWA-PCE-P2MP-APP RFC5862: Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE (11 pages) * Replaces DRAFT-YASUKAWA-PCE-P2MP-REQ RFC5886: A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture (28 pages) * Replaces DRAFT-VASSEUR-PCE-MONITORING RFC6006: Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths (31 pages) RFC6007: Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations (17 pages) RFC6123: Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts (12 pages) * Replaces DRAFT-FARREL-PCE-MANAGEABILITY-REQUIREMENTS RFC6457: PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering (13 pages) Protocol Independent Multicast (pim) ------------------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Stig Venaas Mike McBride Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Adrian Farrel Tech Advisor: Brian Haberman Mailing Lists: General Discussion: pim@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/pim/ Archive: http://www.ietf.org/mail-archive/web/pim/ Description of Working Group: The Protocol Independent Multicast (PIM) Working Group has completed the standardization of PIM with RFC 4601. The WG has determined there is additional work to be accomplished and is chartered to standardize extensions to RFC 4601 - Protocol Independent Multicast Version 2 - Sparse Mode. These PIM extensions will involve reliability, resiliency, scalability, management, and security. If L2VPN or L3VPN WGs determine that support for multicast in L2VPNs and/or L3VPNs requires extensions to PIM, then such extensions will be developed within the PIM WG. Additional work on the PIM-BIDIR and BSR drafts may also be necessary by the WG as these drafts progress through Standards Track. The working group has produced MIB modules for PIM in RFC 5060 and RFC 5240. The working group currently has no plans to do further work on management for PIM. If proposals are brought forward to update or extend the existing MIB modules or to develop YANG modules, the working group will be rechartered. The PIM WG will further enhance RFC4601 as an even more scalable, efficient and robust multicast routing protocol, which is capable of supporting thousands of groups, different types of multicast applications, and all major underlying layer-2 subnetwork technologies. We will accomplish these enhancements by submitting drafts, to the IESG, involving reliable pim, pim join attributes and pim authentication. The working group primarily works on extensions to PIM, but may take on work related to IGMP/MLD. There is a significant number of errata that need to be addressed in order to advance RFC4601 to Draft Standard. The PIM WG will correct the errata, as necessary, and update RFC4601. The working group will initiate a new re-chartering effort if it is determined that a Version 3 of PIM is required. Goals and Milestones: Done - Hold the first Working Group meeting and discuss the charter and the state of progress on the chartered items. Done - Update the PIM-DM version 2 Internet-draft. Go to WG last call. Submission to IESG for considerations as proposed standard. Done - Resubmit the latest PIM-SM version 2 specification to IESG for consideration as a proposed standard RFC Done - Submit PIM-SM Applicability Statements Done - Submit PIMv2 MIB to IESG for consideration as proposed standard. Done - Submit updated PIM-SM and PIM-DM internet-drafts, clarifying any inconsistencies or ambiguities in the previous drafts. Done - Submit PIM-SM version 2 and PIM-DM version 2 specifications to IESG for consideration as Draft Standards. Done - Submit PIMv2 MIB to IESG for consideration as draft standard. Done - Ratify new WG charter and milestones Done - Submit the BSR spec as a Proposed Standard to the IESG Done - Submit the BSR MIB as a Proposed Standard to the IESG Done - Submit a generic TLV PIM Join Attribute PS draft to the IESG Done - Submit RPF Vector (use of PIM Join Attribute) as PS to the IESG Done - Submit a way to authenticate PIM link local messages as PS to the IESG Done - Submit an Informational PIM last hop threats document to the IESG Aug 2011 - First WG version of udated RFC 4601 Aug 2011 - Submit a more reliable PIM solution (refresh reduction) to the IESG Nov 2011 - Submit a population count extension to PIM to the IESG Dec 2011 - Submit update of RFC 4601 to IESG for advancement to Draft Standard Internet-Drafts: - Anycast-RP Using Protocol Independent Multicast (PIM) [draft-ietf-pim-anycast-rp-07] (12 pages) - Bidirectional Protocol Independent Multicast (BIDIR-PIM) [draft-ietf-pim-bidir-09] (45 pages) - Protocol Independent Multicast (PIM) Bootstrap Router MIB [draft-ietf-pim-bsr-mib-06] (23 pages) - Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) [draft-ietf-pim-dm-new-v2-05] (55 pages) - Protocol Independent Multicast DR Load Balancing [draft-ietf-pim-drlb-01] (13 pages) - Protocol Independent Multicast ECMP Redirect [draft-ietf-pim-ecmp-03] (12 pages) - IGMP/MLD-Based Explicit Membership Tracking Function for Multicast Routers [draft-ietf-pim-explicit-tracking-01] (10 pages) - PIM Group-to-Rendezvous-Point Mapping [draft-ietf-pim-group-rp-mapping-10] (19 pages) - PIM Neighbor Hello GenId Option [draft-ietf-pim-hello-genid-01] (3 pages) - An Interface Identifier (ID) Hello Option for PIM [draft-ietf-pim-hello-intid-01] (11 pages) - Protocol Independent Multicast Routing in the Internet Protocol Version 6 (IPv6) [draft-ietf-pim-ipv6-04] (5 pages) - The Protocol Independent Multicast (PIM) Join Attribute Format [draft-ietf-pim-join-attributes-06] (12 pages) - Host Threats to Protocol Independent Multicast (PIM) [draft-ietf-pim-lasthop-threats-04] (13 pages) - Protocol Independent Multicast MIB [draft-ietf-pim-mib-v2-10] (93 pages) - PIM Multi-Topology ID (MT-ID) Join Attribute [draft-ietf-pim-mtid-10] (14 pages) - Population Count Extensions to PIM [draft-ietf-pim-pop-count-06] (20 pages) - A Reliable Transport Mechanism for PIM [draft-ietf-pim-port-09] (36 pages) - Protocol Independent Multicast - Sparse Mode (PIM-SM) IETF Proposed Standard Requirements Analysis [draft-ietf-pim-proposed-req-02] (9 pages) - Format for using PIM proxies [draft-ietf-pim-proxy-00] (7 pages) - State Refresh in PIM-DM [draft-ietf-pim-refresh-02] (10 pages) - A Registry for PIM Message Types [draft-ietf-pim-registry-04] (8 pages) - Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) [draft-ietf-pim-rfc4601bis-01] (132 pages) - The Reverse Path Forwarding (RPF) Vector TLV [draft-ietf-pim-rpf-vector-08] (9 pages) - Simple Key Management Protocol for PIM [draft-ietf-pim-simplekmp-02] (8 pages) - Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM) [draft-ietf-pim-sm-bsr-12] (45 pages) - Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages [draft-ietf-pim-sm-linklocal-10] (20 pages) - Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) [draft-ietf-pim-sm-v2-new-12] (148 pages) - Authenticating PIM version 2 messages [draft-ietf-pim-v2-auth-01] (4 pages) - Protocol Independent Multicast Version 2 Dense Mode Specification [draft-ietf-pim-v2-dm-03] (18 pages) - Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification [draft-ietf-pim-v2-sm-01] (65 pages) Requests for Comments: RFC3973: Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) (55 pages) RFC4601: Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) (148 pages) * Obsoletes RFC2362 * Updates RFC5059 * Updates RFC5796 * Updates RFC6226 RFC4602: Protocol Independent Multicast - Sparse Mode (PIM-SM) IETF Proposed Standard Requirements Analysis (9 pages) RFC4610: Anycast-RP Using Protocol Independent Multicast (PIM) (12 pages) * Replaces DRAFT-FARINACCI-PIM-ANYCAST-RP RFC5015: Bidirectional Protocol Independent Multicast (BIDIR-PIM) (45 pages) RFC5059: Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM) (45 pages) * Obsoletes RFC2362 * Updates RFC4601 RFC5060: Protocol Independent Multicast MIB (93 pages) RFC5240: Protocol Independent Multicast (PIM) Bootstrap Router MIB (23 pages) * Replaces DRAFT-MCWALTER-PIM-BSR-MIB RFC5294: Host Threats to Protocol Independent Multicast (PIM) (13 pages) * Replaces DRAFT-SAVOLA-PIM-LASTHOP-THREATS RFC5384: The Protocol Independent Multicast (PIM) Join Attribute Format (12 pages) RFC5496: The Reverse Path Forwarding (RPF) Vector TLV (9 pages) RFC5796: Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages (20 pages) * Replaces DRAFT-ATWOOD-PIM-SM-LINKLOCAL * Updates RFC4601 RFC6166: A Registry for PIM Message Types (8 pages) * Replaces DRAFT-VENAAS-PIM-REGISTRY RFC6226: PIM Group-to-Rendezvous-Point Mapping (19 pages) * Replaces DRAFT-JOSHI-PIM-GROUP-RP-MAPPING * Updates RFC4601 RFC6395: An Interface Identifier (ID) Hello Option for PIM (11 pages) * Replaces DRAFT-GULRAJANI-PIM-HELLO-INTID RFC6420: PIM Multi-Topology ID (MT-ID) Join Attribute (14 pages) * Replaces DRAFT-CAI-PIM-MTID RFC6559: A Reliable Transport Mechanism for PIM (36 pages) * Replaces DRAFT-FARINACCI-PIM-PORT Pseudowire Emulation Edge to Edge (pwe3) ---------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Matthew Bocci Andrew G. Malis Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Stewart Bryant Tech Advisor: David Black Secretary: David Sinicrope <> Mailing Lists: General Discussion: pwe3@ietf.org To Subscribe: pwe3-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/pwe3/ Description of Working Group: Network transport service providers and their users are seeking to rationalize their networks by migrating their existing services and platforms onto IP or MPLS enabled IP packet switched networks (PSN). This migration requires communications services that can emulate the essential properties of traditional communications links over a PSN. Some service providers wish to use MPLS technology to replace existing transport network infrastructure, relying upon pseudowire technology is an integral component of these network convergence architectures. Pseudowire Emulation Edge to Edge (PWE3) will specify the encapsulation, transport, control, management, interworking and security of services emulated over IETF-specified PSNs. A pseudowire emulates a point-to-point or point-to-multipoint link, and provides a single service which is perceived by its user as an unshared link or circuit of the chosen service. It is not intended that an emulated service will be indistinguishable from the service that is being emulated. The emulation need only be sufficient for the satisfactory operation of the service. Emulation necessarily involves a degree of cost-performance trade-off. In some cases it may be necessary to design more than one emulation mechanism in order to resolve these design conflicts. All emulated service definitions must include an applicability statement describing the faithfulness of the emulation. Switching, multiplexing, modification or other operation on the traditional service, unless required as part of the emulation, is out of the scope of the PWE3 WG. PWE3 will make use of existing IETF-specified mechanisms unless there are technical reasons why the existing mechanisms are insufficient or unnecessary. PWE3 operates "edge to edge" and will not exert control on the underlying PSN, other than to use any existing QoS or path control mechanism to provide the required connectivity between the endpoints of the PW. PWE3 will co-ordinate this with the AVT and TICTOC WGs. Where AVT or TICTOC require extensions to PWs to support time or frequency transfer this work will be undertaken by the PWE3 WG in co-ordination with the these WGs. A PW operating over a shared PSN does not necessarily have the same intrinsic security as a dedicated, purpose built, network. In some cases this is satisfactory, while in other cases it will be necessary to enhance the security of the PW to emulate the intrinsic security of the emulated service. PW specifications MUST include a description of how they are to be operated over a shared PSN with adequate security. PWE3 will work with the MPLS, L2VPN and other relevant WGs for definitions of common solutions for the secure operation of pseudowires. Whilst a service provider may traffic engineer their network in such a way that PW traffic will not cause significant congestion, a PW deployed by an end-user may cause congestion of the underlying PSN. Suitable congestion avoidance mechanisms are therefore needed to protect the Internet from the unconstrained deployment of PWs. Congestion avoidance may be more difficult with P2MP pseudowires than P2P pseudowires. The WG will consider both cases. PWE3 will work closely with the L2VPN WG to ensure a clear demarcation is defined for where PWE3 stops and L2VPN starts, in particular in defining point-multipoint (P2MP) PWs. PWE3 will work with MPLS and L2VPN to enhance the OAM suite for transport applications. PWE3 will coordinate very closely with any WG that is responsible for protocols which PWE3 intends to extend (e.g., the MPLS WG for LDP), as well as foster interaction with WGs that intend to extend PWE3 protocols. The IETF PWE3 WG is the design authority for pseudo-wire over IP/MPLS PSN technology. An entity or individual that wishes to propose extensions or changes to this technology must bring the corresponding proposals to the PWE3 WG that would treat them via a process similar to one described in RFC 4929 for the MPLS/GMPLS change process. WG Objectives: Specify the following PW types: Most of the initial specific PW types have been specified (e.g., Frame Realy, Ethernet, ATM). Investigation into and specification of a "generic PW" type and/or MPLS PW should be undertaken. PWE3 will specify a PW type for the special case where the access service payloads at both ends are known to consist entirely of IP packets. PWE3 will not specify mechanisms by which a PW connects two different access services unless the Network Layer protocol is IP or MPLS. Specify the control and management functions of chartered PW types, to include PW setup, configuration, maintenance and tear-down. The PWE3 WG will do this in its entirety for MPLS PSNs, and the L2TPEXT WG will develop the L2TP specifics for L2TPv3-based PWs. Specify Operations and Management (OAM) mechanisms for all PW types, suitable for operation over both IP/L2TPv3 and MPLS PSNs, and capable of providing the necessary interworking with the OAM mechanisms of the emulated service. Define requirements for and mechanisms to provide interconnection of PWs (to include inter-domain PWs). Define requirements for and mechanisms to provide protection and restoration of PWs. Publish document outlining PW-specific congestion avoidance and response guidelines. Publish document outlining PW-specific security considerations. Specify requirements and mechanisms for P2MP functionality for PWs. This work will be coordinated with the L2VPN and MPLS working groups. Publish requirements and specification for PW to take advantage of multiple PSN paths that exist between PEs. Publish requirements and specification for enhanced OAM. Include extensions to the PWE3 protocols and RFCs necessary to create an MPLS Transport Profile (MPLS-TP). The work on the MPLS TP needs to be coordinated between three primary working groups (MPLS, PWE3, L2VPN and CCAMP) that are chartered to do MPLS TP work. Goals and Milestones: Done - PWE3 WG started, organize editing teams. Done - Hold interim meeting, including discussion of priority of service-specific documents and consider pruning some deliverables Done - Accept drafts of service-specific documents as WG items Done - PW Requirements Document Last Call Done - TDM Circuit Documents Last Call Done - ATM Documents Last Call Done - Ethernet Documents Last Call Done - Fragmentation LC Done - TDM Requirements LC Done - SONET Documents Last Call Done - TDM Documents Last Call Done - Frame Relay Documents Last Call Done - FCS retention Last Call Done - Multi-Segment PW Requirements LC Done - VCCV LC Done - PWE3 Services MIBs LC Done - PPP/HDLC PW LC Done - Wildcard FEC LC Done - TDM Signaling LC Done - Multi-Segment Architecture LC Done - Basic Pseudowire MIBs LC Done - Fiber Channel Encap LC Done - PW OAM Mapping LC Done - PW Protection and Restoration Requirements LC Done - PW Protection and Restoration Architecture Done - Multipath PW LC Done - Generic Associated Channel Header LC Done - Multi-Segment PW LC Done - PW Protection and Restoration LC Jun 2011 - P2MP Requirements LC Jun 2011 - PW Status signalling in static/MPLS-TP Jun 2011 - Packet PW Requirements / solution Jul 2011 - Dynamic MS PW LC Sep 2011 - P2MP PW Signaling (rootinitiated) Sep 2011 - Congestion Considerations Sep 2011 - Signaling extensions for MPLS-TP OAM Sep 2011 - Multisegment PW MIB Sep 2011 - Security Considerations LC Sep 2011 - Enhanced PW OAM Dec 2011 - P2MP PW Signaling (leaf initiated) Internet-Drafts: - Stitching Procedures for Static PW in MPLS-TP Environment [draft-boutros-pwe3-mpls-tp-ms-pw-01] (11 pages) - Attachment Individual Identifier (AII) Types for Aggregation [draft-ietf-pwe3-aii-aggregate-02] (8 pages) - Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture [draft-ietf-pwe3-arch-07] (44 pages) - Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks [draft-ietf-pwe3-atm-encap-11] (40 pages) - Pseudowire Control Word Negotiation Mechanism Update [draft-ietf-pwe3-cbit-negotiation-03] (8 pages) - Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service [draft-ietf-pwe3-cell-transport-06] (5 pages) - Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP) MIB Using SMIv2 [draft-ietf-pwe3-cep-mib-16] (65 pages) - Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN) [draft-ietf-pwe3-cesopsn-07] (31 pages) - Pseudowire Congestion Control Framework [draft-ietf-pwe3-congestion-frmwk-02] (26 pages) - Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) [draft-ietf-pwe3-control-protocol-17] (35 pages) - Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN [draft-ietf-pwe3-cw-06] (12 pages) - Dynamic Placement of Multi Segment Pseudowires [draft-ietf-pwe3-dynamic-ms-pw-14] (22 pages) - Ethernet Pseudowire (PW) Management Information Base (MIB) [draft-ietf-pwe3-enet-mib-14] (23 pages) - Encapsulation Methods for Transport of Ethernet over MPLS Networks [draft-ietf-pwe3-ethernet-encap-11] (23 pages) - Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network [draft-ietf-pwe3-fat-pw-07] (20 pages) - Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks [draft-ietf-pwe3-fc-encap-16] (23 pages) - Reliable Fibre Channel Transport Over MPLS Networks [draft-ietf-pwe3-fc-flow-00] (30 pages) - Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention [draft-ietf-pwe3-fcs-retention-04] (8 pages) - Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly [draft-ietf-pwe3-fragmentation-10] (15 pages) - Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks [draft-ietf-pwe3-frame-relay-07] (21 pages) - Framework for Pseudo Wire Emulation Edge-to-Edge (PWE3) [draft-ietf-pwe3-framework-01] (24 pages) - Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks [draft-ietf-pwe3-hdlc-ppp-encap-mpls-09] (16 pages) - IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3) [draft-ietf-pwe3-iana-allocation-15] (10 pages) - Inter-Chassis Communication Protocol for L2VPN PE Redundancy [draft-ietf-pwe3-iccp-07] (78 pages) - LDP extensions for AII reachability [draft-ietf-pwe3-ldp-aii-reachability-04] (10 pages) - MPLS and Ethernet OAM Interworking [draft-ietf-pwe3-mpls-eth-oam-iwk-05] (20 pages) - Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP) [draft-ietf-pwe3-mpls-tp-gal-in-pw-01] (7 pages) - Stitching Procedures for Static PW in MPLS-TP Environment [draft-ietf-pwe3-mpls-tp-ms-pw-00] (11 pages) - Label Distribution Protocol Extensions for Proactive Operations, Administration and Maintenance Configuration of Dynamic MPLS Transport Profile PseudoWire [draft-ietf-pwe3-mpls-tp-oam-config-00] (28 pages) - Application of Ethernet Pseudowires to MPLS Transport Networks [draft-ietf-pwe3-mpls-transport-04] (13 pages) - An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge [draft-ietf-pwe3-ms-pw-arch-07] (25 pages) - Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3) [draft-ietf-pwe3-ms-pw-requirements-07] (30 pages) - Explicit Path Routing for Dynamic Multi-Segment Pseudowires [draft-ietf-pwe3-mspw-er-00] (12 pages) - Label Distribution Protocol Extensions for Proactive Operations, Administration and Maintenance Configuration of Dynamic MPLS Transport Profile PseudoWire [draft-ietf-pwe3-oam-config-00] (28 pages) - Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping [draft-ietf-pwe3-oam-msg-map-16] (40 pages) - Signaling Root-Initiated Point-to-Multipoint Pseudowire using LDP [draft-ietf-pwe3-p2mp-pw-04] (22 pages) - Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS PSNs [draft-ietf-pwe3-p2mp-pw-requirements-05] (20 pages) - Packet Pseudowire Encapsulation over an MPLS PSN [draft-ietf-pwe3-packet-pw-04] (15 pages) - Protocol Layering in PWE3 [draft-ietf-pwe3-protocol-layer-00] (33 pages) - Managed Objects for ATM over Packet Switched Networks (PSNs) [draft-ietf-pwe3-pw-atm-mib-06] (41 pages) - Pseudowire (PW) Management Information Base (MIB) [draft-ietf-pwe3-pw-mib-14] (68 pages) - Pseudowire (PW) over MPLS PSN Management Information Base (MIB) [draft-ietf-pwe3-pw-mpls-mib-14] (32 pages) - Definitions of Textual Conventions for Pseudowire (PW) Management [draft-ietf-pwe3-pw-tc-mib-15] (11 pages) - LDP Typed Wildcard FEC for PWid and Generalized PWid FEC Elements [draft-ietf-pwe3-pw-typed-wc-fec-03] (9 pages) - The Pseudowire (PW) & Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results [draft-ietf-pwe3-pw-vccv-impl-survey-results-00] (37 pages) - Pseudowire Redundancy [draft-ietf-pwe3-redundancy-08] (16 pages) - Pseudowire Preferential Forwarding Status Bit [draft-ietf-pwe3-redundancy-bit-07] (36 pages) - Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3) [draft-ietf-pwe3-requirements-08] (20 pages) - Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP) [draft-ietf-pwe3-satop-05] (22 pages) - Managed Objects for Structure-Agnostic TDM over Packet Network [draft-ietf-pwe3-satop-mib-03] (20 pages) - Segmented Pseudowire [draft-ietf-pwe3-segmented-pw-18] (45 pages) - Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP) [draft-ietf-pwe3-sonet-14] (55 pages) - TDM Service Specification for Pseudo-Wire Emulation Edge to Edge (PWE3) [draft-ietf-pwe3-sonet-vt-00] (36 pages) - Pseudowire Status for Static Pseudowires [draft-ietf-pwe3-static-pw-status-10] (14 pages) - MPLS LSP PW status refresh reduction for Static Pseudowires [draft-ietf-pwe3-status-reduction-00] (17 pages) - Control Protocol Extensions for the Setup of Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks [draft-ietf-pwe3-tdm-control-protocol-extensi-07] (16 pages) - Managed Objects for Time Division Multiplexing (TDM) over Packet Switched Networks (PSNs) [draft-ietf-pwe3-tdm-mib-11] (48 pages) - Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks [draft-ietf-pwe3-tdm-requirements-08] (25 pages) - Time Division Multiplexing over IP (TDMoIP) [draft-ietf-pwe3-tdmoip-06] (49 pages) - Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires [draft-ietf-pwe3-vccv-15] (32 pages) - Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV) [draft-ietf-pwe3-vccv-bfd-07] (14 pages) - A Unified Control Channel for Pseudowires [draft-ietf-pwe3-vccv-for-gal-01] (9 pages) - The Pseudowire (PW) & Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results [draft-ietf-pwe3-vccv-impl-survey-results-00] (37 pages) - Wildcard Pseudowire Type [draft-ietf-pwe3-wildcard-pw-type-02] (7 pages) - Definition of P2MP PW TLV for LSP-Ping Mechanisms [draft-jain-pwe3-p2mp-pw-lsp-ping-00] (8 pages) - Label Distribution Protocol Extensions for Proactive Operations, Administration and Maintenance Configuration of Dynamic MPLS Transport Profile PseudoWire [draft-zhang-mpls-tp-pw-oam-config-06] (28 pages) Requests for Comments: BCP0116: IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3) (10 pages) RFC3916: Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3) (20 pages) RFC3985: Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture (44 pages) * Updates RFC5462 RFC4197: Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks (25 pages) RFC4385: Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN (12 pages) * Updates RFC5586 RFC4446: IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3) (10 pages) RFC4447: Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) (35 pages) RFC4448: Encapsulation Methods for Transport of Ethernet over MPLS Networks (23 pages) * Updates RFC5462 RFC4553: Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP) (22 pages) RFC4618: Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks (16 pages) RFC4619: Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks (21 pages) RFC4623: Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly (15 pages) RFC4717: Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks (40 pages) RFC4720: Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention (8 pages) RFC4816: Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service (5 pages) * Replaces DRAFT-MALIS-PWE3-CELL-TRANSPORT RFC4842: Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP) (55 pages) * Obsoletes RFC5143 RFC4863: Wildcard Pseudowire Type (7 pages) RFC5003: Attachment Individual Identifier (AII) Types for Aggregation (8 pages) RFC5085: Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires (32 pages) * Updates RFC5586 RFC5086: Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN) (31 pages) RFC5087: Time Division Multiplexing over IP (TDMoIP) (49 pages) * Replaces DRAFT-ANAVI-TDMOIP RFC5254: Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3) (30 pages) RFC5287: Control Protocol Extensions for the Setup of Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks (16 pages) * Replaces DRAFT-VAINSHTEIN-PWE3-TDM-CONTROL-PROTOCOL-EXTENSI RFC5542: Definitions of Textual Conventions for Pseudowire (PW) Management (11 pages) RFC5601: Pseudowire (PW) Management Information Base (MIB) (68 pages) RFC5602: Pseudowire (PW) over MPLS PSN Management Information Base (MIB) (32 pages) RFC5603: Ethernet Pseudowire (PW) Management Information Base (MIB) (23 pages) RFC5604: Managed Objects for Time Division Multiplexing (TDM) over Packet Switched Networks (PSNs) (48 pages) RFC5605: Managed Objects for ATM over Packet Switched Networks (PSNs) (41 pages) RFC5659: An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge (25 pages) RFC5885: Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV) (14 pages) * Updates RFC6478 RFC5994: Application of Ethernet Pseudowires to MPLS Transport Networks (13 pages) * Replaces DRAFT-BRYANT-PWE3-MPLS-TRANSPORT RFC6073: Segmented Pseudowire (45 pages) RFC6240: Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP) MIB Using SMIv2 (65 pages) RFC6307: Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks (23 pages) RFC6310: Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping (40 pages) RFC6391: Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network (20 pages) RFC6423: Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP) (7 pages) * Replaces DRAFT-LM-PWE3-MPLS-TP-GAL-IN-PW * Updates RFC5586 RFC6478: Pseudowire Status for Static Pseudowires (14 pages) * Replaces DRAFT-MARTINI-PWE3-STATIC-PW-STATUS * Updates RFC5885 Routing Area Working Group (rtgwg) ---------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Alvaro Retana Alia Atlas Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Stewart Bryant Mailing Lists: General Discussion: rtgwg@ietf.org To Subscribe: rtgwg-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/rtgwg/ Description of Working Group: The Routing area receives occasional proposals for the development and publication of RFCs dealing with routing topics, but for which the required work does not yet rise to the level where a new working group is justified, yet the topic does not fit with an existing working group, and it is either not ready for a BOF or a single BOF would not provide the time to ensure a mature proposal. The RTGWG will serve as the forum for developing these types of proposals. The RTGWG also focuses on enhancements to hop-by-hop distributed routing (e.g. multicast, LDP-MPLS, unicast routing) related to fast-reroute and loop-free convergence. A specific goal of fast-reroute mechanisms is to provide up to complete coverage when the potential failure would not partition the network. All work in this area should be specifically evaluated by the WG in terms of practicality and applicability to deployed networks. The RTGWG mailing list will be used to discuss the proposals as they arise. The working group will meet if there are one or more active proposals that require discussion. The working group milestones will be updated as needed to reflect the proposals currently being worked on and the target dates for their completion. New milestones will be first reviewed by the IESG. The working group will be on-going as long as the ADs believe it serves a useful purpose. Goals and Milestones: Done - Submit draft on calculation of IGP routes over TE tunnels to IESG for publication as Informational RFC Done - Submit initial Internet Draft on IP Fast Reroute Framework Done - Submit initial Internet Draft on Basic IP Fast Reroute mechanism Done - Review various mechanisms for Advanced IP Fast Reroute Done - Select the Advanced IP Fast Reroute mechanism Done - Submit IP Fast Reroute Framework to IESG for publication as Informational RFC Done - Submit specification on Basic IP Fast Reroute mechanism to IESG for publication as Proposed Standard Done - Submit Framework for Loop-free Convergence to IESG for publication as Informational RFC Mar 2012 - Submit IP Fast Re-Route Using Not-via Addresses to IESG for publication as Informational Nov 2012 - Submit Composite-Link Requirements to IESG for publication as Informational Nov 2012 - Submit Ordered FIB architecture to IESG for publication as Informational Nov 2012 - Submit initial Internet Draft on Multicast IP Fast Reroute Architecture Nov 2012 - Submit Composite-Link Framework to IESG for publication as Informational Apr 2013 - Submit specification on Advanced IP Fast Reroute mechanism to IESG for publication as Proposed Standard Internet-Drafts: - Calculating IGP routes over Traffic Engineering tunnels [draft-hsmit-mpls-igp-spf-01] (6 pages) - Requirements for MPLS Over a Composite Link [draft-ietf-rtgwg-cl-requirement-05] (16 pages) - Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels [draft-ietf-rtgwg-igp-shortcut-01] (7 pages) - IP Fast Reroute Framework [draft-ietf-rtgwg-ipfrr-framework-13] (16 pages) - IP MIB for IP Fast-Reroute [draft-ietf-rtgwg-ipfrr-ip-mib-02] (19 pages) - IP Fast Reroute Using Not-via Addresses [draft-ietf-rtgwg-ipfrr-notvia-addresses-08] (28 pages) - Basic Specification for IP Fast Reroute: Loop-Free Alternates [draft-ietf-rtgwg-ipfrr-spec-base-12] (31 pages) - A Framework for Loop-Free Convergence [draft-ietf-rtgwg-lf-conv-frmwk-07] (23 pages) - LFA applicability in SP networks [draft-ietf-rtgwg-lfa-applicability-06] (34 pages) - Analysis and Minimization of Microloops in Link-state Routing Protocols [draft-ietf-rtgwg-microloop-analysis-01] (17 pages) - An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees [draft-ietf-rtgwg-mrt-frr-architecture-01] (25 pages) - Loop-free convergence using oFIB [draft-ietf-rtgwg-ordered-fib-05] (23 pages) - The Generalized TTL Security Mechanism (GTSM) [draft-ietf-rtgwg-rfc3682bis-10] (18 pages) Requests for Comments: RFC3906: Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels (7 pages) RFC5082: The Generalized TTL Security Mechanism (GTSM) (18 pages) * Obsoletes RFC3682 RFC5286: Basic Specification for IP Fast Reroute: Loop-Free Alternates (31 pages) RFC5714: IP Fast Reroute Framework (16 pages) RFC5715: A Framework for Loop-Free Convergence (23 pages) * Replaces DRAFT-BRYANT-SHAND-LF-CONV-FRMWK Routing Over Low power and Lossy networks (roll) ------------------------------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Michael Richardson JP Vasseur Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Adrian Farrel Tech Advisor: Rene Struik Secretary: Daniel King <> Mailing Lists: General Discussion: roll@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/roll Archive: http://www.ietf.org/mail-archive/web/roll/ Description of Working Group: Low power and Lossy networks (LLNs) are made up of many embedded devices with limited power, memory, and processing resources. They are interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low power PLC (Powerline Communication) links. LLNs are transitioning to an end-to-end IP-based solution to avoid the problem of non-interoperable networks interconnected by protocol translation gateways and proxies. Generally speaking, LLNs have at least five distinguishing characteristics: - LLNs operate with a hard, very small bound on state. - In most cases, LLN optimize for saving energy. - Typical traffic patterns are not simply unicast flows (e.g. in some cases most if not all traffic can be point to multipoint). - In most cases, LLNs will be employed over link layers with restricted frame-sizes, thus a routing protocol for LLNs should be specifically adapted for such link layers. - LLN routing protocols have to be very careful when trading off efficiency for generality; many LLN nodes do not have resources to waste. These specific properties cause LLNs to have specific routing requirements. Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have been evaluated by the working group and have in their current form been found to not satisfy all of these specific routing requirements. The Working Group is focused on routing issues for LLN. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (HVAC, lighting, access control, fire), connected homes, healthcare, environmental monitoring, urban sensor networks (e.g. Smart Grid), asset tracking. The Working Group focuses on routing solutions for a subset of these: industrial, connected home, building and urban sensor networks for which routing requirements have been specified. These application-specific routing requirement documents will be used for protocol design. The Working Group focuses only on IPv6 routing architectural framework for these application scenarios. The Framework will take into consideration various aspects including high reliability in the presence of time varying loss characteristics and connectivity while permitting low-power operation with very modest memory and CPU pressure in networks potentially comprising a very large number (several thousands) of nodes. The Working Group will pay particular attention to routing security and manageability (e.g., self routing configuration) issues. It will also need to consider the transport characteristic the routing protocol messages will experience. Mechanisms that protect an LLN from congestion collapse or that establish some degree of fairness between concurrent communication sessions are out of scope of the Working Group. It is expected that upper-layer applications utilizing LLNs define appropriate mechanisms. The solution must include unicast and multicast considerations. Work Items: - Specification of routing metrics used in path calculation. This includes static and dynamic link/node attributes required for routing in LLNs. - Provide an architectural framework for routing and path selection at Layer 3 (Routing for LLN Architecture) that addresses such issues as whether LLN routing require a distributed and/or centralized path computation models, whether additional hierarchy is necessary and how it is applied. Manageability will be considered with each approach, along with various trade-offs for maintaining low power operation, including the presence of non-trivial loss and networks with a very large number of nodes. - Produce a routing security framework for routing in LLNs. - Protocol work: The Working Group will consider specific routing requirements from the four application documents collectively, and specify either a new protocol or extend an existing routing protocol in cooperation with the relevant Working Group. If requirements from the four target application areas cannot be met with a single protocol, the WG may choose to specify or extend more than one protocol (this will require a recharter of the WG). - Documentation of applicability statement of ROLL routing protocols. Goals and Milestones: Done - Submit Routing requirements for Industrial applications to the IESG to be considered as an Informational RFC. Done - Submit Routing requirements for Connected Home networks applications to the IESG to be considered as an Informational RFC. Done - Submit Routing requirements for Building applications to the IESG to be considered as an Informational RFC. Done - Submit Routing requirements for Urban networks applications to the IESG to be considered as an Informational RFC. Done - Submit Security Framework to the IESG to be considered as an Informational RFC Done - Submit Routing metrics for LLNs document to the IESG to be considered as a Proposed Standard. Done - Submit first draft of ROLL routing protocol specification as Proposed Standard. Done - Submit the ROLL routing protocol specification to the IESG as Proposed Standard. Jun 2011 - Submit first draft of RPL applicability statement for Industrial applications to the IESG to be considered as an Informational RFC. Jun 2011 - Submit first draft of RPL applicability statement for Building Automation applications to the IESG to be considered as an Informational RFC. Jul 2011 - Submit first draft of RPL applicability statement for Home Automation applications to the IESG to be considered as an Informational RFC. Jul 2011 - Submit first draft of RPL applicability statement for Urban applications to the IESG to be considered as an Informational RFC. Oct 2011 - Submit RPL applicability statement for Industrial applications to the IESG to be considered as an Informational RFC. Oct 2011 - Submit RPL applicability statement for Building Automation applications to the IESG to be considered as an Informational RFC. Nov 2011 - Submit RPL applicability statement for Home Automation applications to the IESG to be considered as an Informational RFC. Nov 2011 - Submit RPL applicability statement for urban applications to the IESG to be considered as an Informational RFC. Dec 2012 - Evaluate WG progress, recharter or close. Internet-Drafts: - Applicability Statement for the Routing Protocol for Low Power and Lossy Networks (RPL) in AMI Networks [draft-ietf-roll-applicability-ami-06] (18 pages) - Building Automation Routing Requirements in Low-Power and Lossy Networks [draft-ietf-roll-building-routing-reqs-09] (26 pages) - Home Automation Routing Requirements in Low-Power and Lossy Networks [draft-ietf-roll-home-routing-reqs-11] (18 pages) - Industrial Routing Requirements in Low-Power and Lossy Networks [draft-ietf-roll-indus-routing-reqs-06] (26 pages) - The Minimum Rank with Hysteresis Objective Function [draft-ietf-roll-minrank-hysteresis-of-10] (13 pages) - Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL) [draft-ietf-roll-of0-20] (14 pages) - A Mechanism to Measure the Quality of a Point-to-point Route in a Low Power and Lossy Network [draft-ietf-roll-p2p-measurement-05] (20 pages) - Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks [draft-ietf-roll-p2p-rpl-12] (34 pages) - Overview of Existing Routing Protocols for Low Power and Lossy Networks [draft-ietf-roll-protocols-survey-07] (26 pages) - Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks [draft-ietf-roll-routing-metrics-19] (30 pages) - RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks [draft-ietf-roll-rpl-19] (163 pages) - A Security Framework for Routing over Low Power and Lossy Networks [draft-ietf-roll-security-framework-07] (49 pages) - Terminology in Low power And Lossy Networks [draft-ietf-roll-terminology-06] (8 pages) - The Trickle Algorithm [draft-ietf-roll-trickle-08] (13 pages) - Multicast Forwarding Using Trickle [draft-ietf-roll-trickle-mcast-00] (19 pages) - Routing Requirements for Urban Low-Power and Lossy Networks [draft-ietf-roll-urban-routing-reqs-05] (21 pages) Requests for Comments: RFC5548: Routing Requirements for Urban Low-Power and Lossy Networks (21 pages) * Replaces DRAFT-DOHLER-ROLL-URBAN-ROUTING-REQS RFC5673: Industrial Routing Requirements in Low-Power and Lossy Networks (26 pages) * Replaces DRAFT-PISTER-ROLL-INDUS-ROUTING-REQS RFC5826: Home Automation Routing Requirements in Low-Power and Lossy Networks (18 pages) * Replaces DRAFT-BRANDT-ROLL-HOME-ROUTING-REQS RFC5867: Building Automation Routing Requirements in Low-Power and Lossy Networks (26 pages) * Replaces DRAFT-MARTOCCI-ROLL-BUILDING-ROUTING-REQS RFC6206: The Trickle Algorithm (13 pages) RFC6550: RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks (163 pages) * Replaces DRAFT-DT-ROLL-RPL RFC6551: Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks (30 pages) * Replaces DRAFT-MJKIM-ROLL-ROUTING-METRICS RFC6552: Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL) (14 pages) Secure Inter-Domain Routing (sidr) ---------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Alexey Melnikov Dr. Sandra L. Murphy Chris Morrow Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Stewart Bryant Tech Advisor: Steven Bellovin Mailing Lists: General Discussion: sidr@ietf.org To Subscribe: sidr-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/sidr/ Description of Working Group: The purpose of the SIDR working group is to reduce vulnerabilities in the inter-domain routing system. The two vulnerabilities that will be addressed are: * Is an Autonomous System (AS) authorized to originate an IP prefix * Is the AS-Path represented in the route the same as the path through which the NLRI traveled The SIDR working group will take practical deployability into consideration. Building upon the already completed and implemented framework: * Resource Public Key Infrastructure (RPKI) * Distribution of RPKI data to routing devices and its use in operational networks * Document the use of certification objects within the secure routing architecture This working group will specify security enhancements for inter-domain routing protocols. Goals and Milestones: Done - Submit initial draft on inter-domain routing security within this architecture Done - Submit initial draft on certificate objects to be used within this architecture Done - Submit initial draft on securing origination of routing information Jan 2010 - I-D: draft-ietf-sidr-publication Jan 2010 - I-D: draft-ietf-sidr-keyroll Jan 2010 - I-D: draft-ietf-sidr-arch Jan 2010 - I-D: draft-ietf-sidr-cp Jan 2010 - I-D: draft-ietf-sidr-res-certs Jan 2010 - I-D: draft-ietf-sidr-roa-validation Jan 2010 - I-D: draft-ietf-sidr-signed-object Jan 2010 - I-D: draft-ietf-sidr-rpki-manifests Jan 2010 - I-D: draft-ietf-sidr-rpki-algs Jan 2010 - I-D: draft-ietf-sidr-rescerts-provisioning Jan 2010 - I-D: draft-ietf-sidr-ta Mar 2010 - I-D: draft-ietf-sidr-cps-irs Mar 2010 - I-D: draft-ietf-sidr-cps-isp Nov 2010 - I-D: draft-ietf-sidr-origin-ops Nov 2010 - I-D: draft-ietf-sidr-pfx-validate Nov 2010 - I-D: draft-ietf-sidr-repos-struct Nov 2010 - I-D: draft-ietf-sidr-roa-format Nov 2010 - I-D: draft-ietf-sidr-ltamgmt Dec 2010 - I-D: draft-rgaglian-sidr-algorithm-agility Jan 2011 - I-D: draft-ietf-sidr-ghostbusters Feb 2011 - I-D: draft-ietf-sidr-rpki-rtr Mar 2011 - I-D: Document the BGP protocol enhancements that meet the security requirements Mar 2011 - I-D: A requirements document that addresses these threats Mar 2011 - I-D: A document describing threats to the routing system Mar 2011 - I-D: An overview of the RPKI and BGP Protocol changes required for origin and path validation Mar 2011 - I-D: Operational deployment guidance for network operators May 2011 - I-D: draft-ietf-sidr-usecases May 2011 - Publication: draft-ietf-sidr-arch May 2011 - Publication: draft-ietf-sidr-cp May 2011 - Publication: draft-ietf-sidr-res-certs Jun 2011 - I-D: System and architecture design choices made in the protocol and RPKI Jun 2011 - Publication: draft-ietf-sidr-publication Jun 2011 - Publication: draft-ietf-sidr-repos-struct Jun 2011 - Publication: draft-ietf-sidr-roa-format Jun 2011 - Publication: draft-ietf-sidr-rpki-rtr Jun 2011 - Publication: draft-ietf-sidr-roa-validation Jun 2011 - Publication: draft-ietf-sidr-signed-object Jun 2011 - Publication: draft-ietf-sidr-rpki-manifests Jul 2011 - Publication: draft-ietf-sidr-origin-ops Jul 2011 - Publication: draft-ietf-sidr-rpki-algs Jul 2011 - Publication: draft-ietf-sidr-rescerts-provisioning Aug 2011 - Publication: draft-ietf-sidr-ta Oct 2011 - Publication: draft-rgaglian-sidr-algorithm-agility Oct 2011 - Publication: draft-ietf-sidr-ghostbusters Nov 2011 - Publication: draft-ietf-sidr-ltamgmt Dec 2011 - Publication: System and architecture design choices made in the protocol and RPKI Dec 2011 - Publication: draft-ietf-sidr-usecases Dec 2011 - Publication: draft-ietf-sidr-keyroll Jan 2012 - Publication: An overview of the RPKI and BGP Protocol changes required for origin and path validation Jan 2012 - Publication: Document the BGP protocol enhancements that meet the security requirements Jan 2012 - Publication: draft-ietf-sidr-pfx-validate Mar 2012 - Publication: draft-ietf-sidr-cps-irs Mar 2012 - Publication: draft-ietf-sidr-cps-isp Jun 2012 - Publication: A document describing threats to the routing system Jun 2012 - Publication: A requirements document that addresses these threats Jul 2012 - Publication: Operational deployment guidance for network operators Internet-Drafts: - Algorithm Agility Procedure for RPKI. [draft-ietf-sidr-algorithm-agility-05] (28 pages) - An Infrastructure to Support Secure Internet Routing [draft-ietf-sidr-arch-13] (24 pages) - BGP Algorithms, Key Formats, & Signature Formats [draft-ietf-sidr-bgpsec-algs-02] (7 pages) - BGPsec Operational Considerations [draft-ietf-sidr-bgpsec-ops-04] (8 pages) - An Overview of BGPSEC [draft-ietf-sidr-bgpsec-overview-02] (10 pages) - A Profile for BGPSEC Router Certificates, Certificate Revocation Lists, and Certification Requests [draft-ietf-sidr-bgpsec-pki-profiles-03] (11 pages) - BGPSEC Protocol Specification [draft-ietf-sidr-bgpsec-protocol-03] (31 pages) - Security Requirements for BGP Path Validation [draft-ietf-sidr-bgpsec-reqs-03] (9 pages) - Threat Model for BGP Path Security [draft-ietf-sidr-bgpsec-threats-02] (25 pages) - A Profile for Bogon Origin Attestations (BOAs) [draft-ietf-sidr-bogons-03] (14 pages) - Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI) [draft-ietf-sidr-cp-17] (43 pages) - Template for an Internet Registry's Certification Practice Statement (CPS) for the Resource PKI (RPKI) [draft-ietf-sidr-cps-irs-05] (42 pages) - Template for an Internet Service Provider's Certification Practice Statement (CPS) for the Resource PKI (RPKI) [draft-ietf-sidr-cps-isp-04] (43 pages) - The Resource Public Key Infrastructure (RPKI) Ghostbusters Record [draft-ietf-sidr-ghostbusters-16] (9 pages) - Resource Public Key Infrastructure (RPKI) Objects Issued by IANA [draft-ietf-sidr-iana-objects-03] (22 pages) - Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI) [draft-ietf-sidr-keyroll-08] (11 pages) - Local Trust Anchor Management for the Resource Public Key Infrastructure [draft-ietf-sidr-ltamgmt-04] (28 pages) - RPKI-Based Origin Validation Operation [draft-ietf-sidr-origin-ops-15] (10 pages) - BGP Prefix Origin Validation State Extended Community [draft-ietf-sidr-origin-validation-signaling-01] (7 pages) - BGP Prefix Origin Validation [draft-ietf-sidr-pfx-validate-05] (11 pages) - A Publication Protocol for the Resource Public Key Infrastructure (RPKI) [draft-ietf-sidr-publication-02] (19 pages) - A Profile for Resource Certificate Repository Structure [draft-ietf-sidr-repos-struct-09] (16 pages) - A Profile for X.509 PKIX Resource Certificates [draft-ietf-sidr-res-certs-22] (31 pages) - A Protocol for Provisioning Resource Certificates [draft-ietf-sidr-rescerts-provisioning-11] (32 pages) - A Profile for Route Origin Authorizations (ROAs) [draft-ietf-sidr-roa-format-12] (9 pages) - Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs) [draft-ietf-sidr-roa-validation-10] (10 pages) - The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI) [draft-ietf-sidr-rpki-algs-05] (6 pages) - Manifests for the Resource Public Key Infrastructure (RPKI) [draft-ietf-sidr-rpki-manifests-16] (19 pages) - The RPKI/Router Protocol [draft-ietf-sidr-rpki-rtr-26] (27 pages) - RPKI Router Implementation Report [draft-ietf-sidr-rpki-rtr-impl-00] (11 pages) - Definitions of Managed Objects for the RPKI-Router Protocol [draft-ietf-sidr-rpki-rtr-protocol-mib-00] (23 pages) - Securing RPSL Objects with RPKI Signatures [draft-ietf-sidr-rpsl-sig-05] (13 pages) - Router Keying for BGPsec [draft-ietf-sidr-rtr-keying-00] (7 pages) - Signed Object Template for the Resource Public Key Infrastructure (RPKI) [draft-ietf-sidr-signed-object-04] (13 pages) - Resource Public Key Infrastructure (RPKI) Trust Anchor Locator [draft-ietf-sidr-ta-07] (8 pages) - Use Cases and Interpretation of RPKI Objects for Issuers and Relying Parties [draft-ietf-sidr-usecases-04] (31 pages) - Router Keying for BGPsec [draft-ymbk-bgpsec-rtr-rekeying-00] (7 pages) - RPKI Router Implementation Report [draft-ymbk-rpki-rtr-impl-01] (11 pages) Requests for Comments: BCP0173: Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI) (43 pages) BCP0174: Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI) (11 pages) * Replaces DRAFT-HUSTON-SIDR-KEYROLL RFC6480: An Infrastructure to Support Secure Internet Routing (24 pages) RFC6481: A Profile for Resource Certificate Repository Structure (16 pages) * Replaces DRAFT-HUSTON-SIDR-REPOS-STRUCT RFC6482: A Profile for Route Origin Authorizations (ROAs) (9 pages) RFC6483: Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs) (10 pages) * Replaces DRAFT-HUSTON-SIDR-ROA-VALIDATION RFC6484: Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI) (43 pages) RFC6485: The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI) (6 pages) * Replaces DRAFT-HUSTON-SIDR-RPKI-ALGS RFC6486: Manifests for the Resource Public Key Infrastructure (RPKI) (19 pages) RFC6487: A Profile for X.509 PKIX Resource Certificates (31 pages) * Replaces DRAFT-HUSTON-SIDR-RES-CERTS RFC6488: Signed Object Template for the Resource Public Key Infrastructure (RPKI) (13 pages) * Replaces DRAFT-ACHI-RPKI-SIGNED-OBJECT RFC6489: Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI) (11 pages) * Replaces DRAFT-HUSTON-SIDR-KEYROLL RFC6490: Resource Public Key Infrastructure (RPKI) Trust Anchor Locator (8 pages) RFC6491: Resource Public Key Infrastructure (RPKI) Objects Issued by IANA (22 pages) RFC6492: A Protocol for Provisioning Resource Certificates (32 pages) RFC6493: The Resource Public Key Infrastructure (RPKI) Ghostbusters Record (9 pages) * Replaces DRAFT-YMBK-GHOSTBUSTERS Application Bridging for Federated Access Beyond web (abfab) ------------------------------------------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Leif Johansson Klaas Wierenga Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Stephen Farrell Mailing Lists: General Discussion: abfab@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/abfab Archive: http://www.ietf.org/mail-archive/web/abfab/ Description of Working Group: Problem Statement Federated identity facilitates the controlled sharing of information about principals, commonly across organisational boundaries. This avoids redundant registration of principals who operate in multiple domains, reducing administrative overheads and improving usability while addressing privacy-related concerns and regulatory and statutory requirements of some jurisdictions. A number of such mechanisms are in use for the Web. This working group will specify a federated identity mechanism for use by other Internet protocols not based on HTML/HTTP, such as for instance IMAP, XMPP, SSH and NFS. The design will combine existing protocols, specifically the Extensible Authentication Protocol (EAP - RFC 3748), Authentication, Authorization and Account Protocols (RADIUS - RFC 2865 and Diameter - RFC 3588), and the Security Assertion Markup Language (SAML). Specifically EAP will be used to authenticate the subject to a trusted party, AAA (RADIUS and Diameter) will be used to authenticate and convey information from that party to a relying party and SAML and SAML message formats are used to carry subject information that can be used for authorization and personalization by a relying party. Any change in the choices for these three technical roles is out of scope for this charter. Constraints ----------- Initially the working group will focus on using GSS-API (RFC2743) as a mechanism for integrating the developed solution for federated identity into application protocols but other technologies for application interface are in scope of the working group and may be adopted as deliverables subject to the normal IETF consensus and (re)charter process. In order to be usable in all current Internet protocols, GSS-API mechanism must provide the following features: mutual authentication, key confirmation, host-based service naming, per-message tokens ("security layers") and channel binding. Support for Pseudo Random Function (PRF) is desirable, and generally feasible whenever per-message tokens are supported. As a result, all of those features are required for GSS-API mechanisms produced by this WG. Note also that some of these requirements derive from SASL (RFC 4422) applications, which can use GSS- API mechanisms through GS2 (RFC5081). Other application integration strategies are very likely to mirror these constraints. In particular, host-based service naming, mutual authentication and support for channel binding are likely to be important for defense against phishing attacks. The working group will ensure that any solution developed has technical controls for privacy protection. Other than a change to its applicability statement and the development of EAP mechanisms, the working group may not change EAP, RADIUS or Diameter without establishing consensus with the appropriate community within the IETF. The working group will use the following documents as a starting point for its work: - draft-howlett-eap-gss-00, - draft-howlett-radius-saml-attr-00 - draft-hartman-gss-eap-naming-00 Concerns have been raised that additional work is required in keying AAA associations in a federated environment. The working group is chartered to explore these concerns and if needed, specify protocols that use existing AAA key management mechanisms to address these concerns. Coordination with other SDOs ---------------------------- The Working Group will work in conjunction with the IAB to establish appropriate liaison relationships with the OASIS Security Services Technical Committee (SSTC) and take care that any changes or profiling required in SAML can be properly coordinated across the different organizations. In particular coordination is required with respect to the SAML-RADIUS binding. Deliverables ------------ 1. Descriptions of applicable use cases (informational). 2. An architecture that describes how the components of the solution fit together to address the use cases and open issues that will require future changes to the architecture (informational). 3. A standards-track update to the EAP applicability statement in RFC 3748 describing the applicability of EAP to application authentication and placing appropriate requirements on this new EAP use case. 4. A standards-track solution for using EAP methods to provide authentication within the application. 5. A standards-track update to the EMSK root key applicability statement in RFC 5295. 6. A standards-track description of GSS names and name attributes required by the solution. 7. Descriptions of usability and user-interface concerns related to this work (informational). 8. A standards-track protocol for carrying SAML messages in RADIUS and Diameter. Goals and Milestones: Oct 2010 - Submit Internet draft describing applicable use cases as initial WG item. Oct 2010 - Submit Internet draft describing the architecture as initial WG item. Oct 2010 - Submit Internet draft that updates the EAP applicability statement as initial WG item. Oct 2010 - Submit Internet draft for using EAP methods to provide authentication within the application as initial WG item. Oct 2010 - Submit Internet draft that updates the EMSK root key applicability statement as initial WG item. Oct 2010 - Submit Internet draft that describes GSS names and name attributes as initial WG item. Oct 2010 - Submit Internet draft for usability and user-interface concerns as initial WG item. Oct 2010 - Submit Internet draft for SAML messages in Radius and Diameter as an initial WG item. Dec 2010 - Submit Internet draft describing applicable use cases to the IESG for consideration. Dec 2010 - Submit Internet draft describing the architecture to the IESG for consideration. May 2011 - Submit Internet draft that updates the EAP applicability statement to the IESG for consideration. May 2011 - Submit Internet draft for using EAP methods to provide authentication within the application to the IESG for consideration. Aug 2011 - Submit Internet draft that updates the EMSK root key applicability statement to the IESG for consideration. Aug 2011 - Submit Internet draft that describes GSS names and name attributes to the IESG for consideration. Aug 2011 - Submit Internet draft for usability and user-interface concerns to the IESG for consideration. Dec 2011 - Submit Internet draft for SAML messages in Radius and Diameter to the IESG for consideration. Internet-Drafts: - A RADIUS Attribute, Binding and Profiles for SAML [draft-ietf-abfab-aaa-saml-03] (15 pages) - Application Bridging for Federated Access Beyond Web (ABFAB) Architecture [draft-ietf-abfab-arch-01] (37 pages) - A GSS-API Mechanism for the Extensible Authentication Protocol [draft-ietf-abfab-gss-eap-06] (40 pages) - Name Attributes for the GSS-API EAP mechanism [draft-ietf-abfab-gss-eap-naming-02] (14 pages) - Application Bridging for Federated Access Beyond web (ABFAB) Use Cases [draft-ietf-abfab-usecases-02] (12 pages) No Requests for Comments Common Authentication Technology Next Generation (kitten) --------------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Tom Yu Shawn Emery Alexey Melnikov Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Stephen Farrell Mailing Lists: General Discussion: kitten@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/kitten Archive: http://www.ietf.org/mail-archive/web/kitten/ Description of Working Group: The Generic Security Services (GSS) API and Simple Authentication and Security Layer (SASL) provide various applications with a security framework for secure network communication. The purpose of the Common Authentication Technology Next Generation (Kitten) working group (WG) is to develop extensions/improvements to the GSS-API, shepherd specific GSS-API security mechanisms, and provide guidance for any new SASL- related submissions. This working is chartered to specify the following extensions and improvements (draft-yu-kitten-api-wishlist-00) to the GSS-API: * Provide new interfaces for credential management, which include the following: initializing credentials iterating credentials exporting/importing credentials * Specify interface for asynchronous calls. * Negotiable replay cache avoidance * Define interfaces for better error message reporting. * Provide a more programmer friendly GSS-API for application developers. This could include reducing the number of interface parameters, for example, by eliminating parameters which are commonly used with the default values. * Specify an option for exporting partially-established security contexts and possibly a utility function for exporting security contexts in an encrypted form, as well as a corresponding utility function to decrypt and import such security context tokens. This WG is also chartered to finalize proposed SASL mechanisms as GSS-API mechanisms (based on RFC 5801): * A SASL Mechanism for OpenID draft-ietf-kitten-sasl-openid * SASL Mechanisms for SAML: draft-ietf-kitten-sasl-saml draft-cantor-ietf-kitten-saml-ec The SAML mechanism drafts will include applicability statement text to highlight when each is appropriate for use. * A SASL Mechanism for OAuth draft-mills-kitten-sasl-oauth The transition from SASL to GSS-API mechanisms will allow a greater set of applications to utilize said mechanisms with SASL implementations that support the use of GSS-API mechanisms in SASL (RFC 5801). This WG should review proposals for new SASL and GSS-API mechanisms, but may take on work on such mechanisms only through a revision of this charter. The WG should also review non-mechanism proposals related to SASL and the GSS-API. However, work that adds SASL or GSS-API support in application protocols is out of scope and should be handled by the corresponding application's WG. Deliverables: * GSS-API: initializing credentials * GSS-API: iterating credentials * GSS-API: exporting/importing credentials * GSS-API: specification for asynchronous calls * GSS-API: interfaces/improvements for better error message reporting * GSS-API: programmer friendly interfaces * SASL: SASL mechanism for OpenID * SASL: SASL mechanisms for SAML * SASL: SASL mechanism for OAuth * GSS-API: publish draft-ietf-kitten-gssapi-extensions-iana Goals and Milestones: Jul 2011 - Submit SASL OpenID mechanism to the IESG as Proposed Standard Jul 2011 - Submit naming-exts to the IESG as Proposed Standard Jul 2011 - WGLC on gssapi-extensions-iana Aug 2011 - Submit SASL SAML mechanisms to the IESG as Proposed Standard Sep 2011 - Submit gssapi-extensions-iana to the IESG as Proposed Standard Internet-Drafts: - The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism [draft-ietf-kitten-2478bis-05] (30 pages) - Moving DIGEST-MD5 to Historic [draft-ietf-kitten-digest-to-historic-04] (7 pages) - Extended Generic Security Service Mechanism Inquiry APIs [draft-ietf-kitten-extended-mech-inquiry-06] (13 pages) - Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming [draft-ietf-kitten-gss-naming-05] (17 pages) - Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings [draft-ietf-kitten-gssapi-channel-bindings-07] (11 pages) - GSS_API V2: C# Bindings [draft-ietf-kitten-gssapi-csharp-bindings-00] (95 pages) - Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type [draft-ietf-kitten-gssapi-domain-based-names-06] (9 pages) - Namespace Considerations and Registries for GSS-API Extensions [draft-ietf-kitten-gssapi-extensions-iana-06] (10 pages) - GSS-API Naming Extensions [draft-ietf-kitten-gssapi-naming-exts-14] (18 pages) - A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API) [draft-ietf-kitten-gssapi-prf-07] (9 pages) - GSS-API V2: Java & C# Bindings [draft-ietf-kitten-gssapi-rfc2853-update-for-csharp-00] (10 pages) - Generic Security Service Application Program Interface (GSS-API) Extension for Storing Delegated Credentials [draft-ietf-kitten-gssapi-store-cred-04] (12 pages) - Guide to the GSS-APIv3 [draft-ietf-kitten-gssapi-v3-guide-to-01] (22 pages) - Generic Security Service Application Program Interface (GSS-API) Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism [draft-ietf-kitten-krb5-gssapi-domain-based-names-05] (6 pages) - A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism [draft-ietf-kitten-krb5-gssapi-prf-04] (6 pages) - Generic Security Service API Version 2: Java Bindings Update [draft-ietf-kitten-rfc2853bis-05] (95 pages) - A SASL and GSS-API Mechanism for OAuth [draft-ietf-kitten-sasl-oauth-00] (25 pages) - A SASL & GSS-API Mechanism for OpenID [draft-ietf-kitten-sasl-openid-08] (18 pages) - A Simple Authentication and Security Layer (SASL) and GSS-API Mechanism for the Security Assertion Markup Language (SAML) [draft-ietf-kitten-sasl-saml-09] (30 pages) - SAML Enhanced Client SASL and GSS-API Mechanisms [draft-ietf-kitten-sasl-saml-ec-01] (27 pages) - Stackable Generic Security Service Pseudo-Mechanisms [draft-ietf-kitten-stackable-pseudo-mechs-02] (17 pages) Requests for Comments: RFC4178: The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism (30 pages) * Obsoletes RFC2478 RFC4401: A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API) (9 pages) RFC4402: A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism (6 pages) RFC4768: Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming (17 pages) RFC5178: Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type (9 pages) RFC5179: Generic Security Service Application Program Interface (GSS-API) Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism (6 pages) RFC5554: Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings (11 pages) * Updates RFC2743 RFC5587: Extended Generic Security Service Mechanism Inquiry APIs (13 pages) RFC5588: Generic Security Service Application Program Interface (GSS-API) Extension for Storing Delegated Credentials (12 pages) RFC5653: Generic Security Service API Version 2: Java Bindings Update (95 pages) * Obsoletes RFC2853 RFC6331: Moving DIGEST-MD5 to Historic (7 pages) * Replaces DRAFT-IETF-SASL-DIGEST-TO-HISTORIC * Obsoletes RFC2831 RFC6595: A Simple Authentication and Security Layer (SASL) and GSS-API Mechanism for the Security Assertion Markup Language (SAML) (30 pages) DNS-based Authentication of Named Entities (dane) ------------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Ondrej Sury Warren Kumari Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Stephen Farrell Secretary: Matt Lepinski <> Mailing Lists: General Discussion: dane@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dane Archive: http://www.ietf.org/mail-archive/web/dane/ Description of Working Group: Objective: Specify mechanisms and techniques that allow Internet applications to establish cryptographically secured communications by using information distributed through DNSSEC for discovering and authenticating public keys which are associated with a service located at a domain name. Problem Statement: Entities on the Internet are usually identified using domain names and forming a cryptographically secured connection to the entity requires the entity to authenticate its name. For instance, in HTTPS, a server responding to a query for is expected to authenticate as "www.example.com". Security protocols such as TLS and IPsec accomplish this authentication by allowing an endpoint to prove ownership of a private key whose corresponding public key is somehow bound to the name being authenticated. As a pre-requisite for authentication, then, these protocols require a mechanism for bindings to be asserted between public keys and domain names. DNSSEC provides a mechanism for a zone operator to sign DNS information directly, using keys that are bound to the domain by the parent domain; relying parties can continue this chain up to any trust anchor that they accept. In this way, bindings of keys to domains are asserted not by external entities, but by the entities that operate the DNS. In addition, this technique inherently limits the scope of any given entity to the names in zones he controls. This working group will develop mechanisms for zone operators to present bindings between names within their control and public keys, in such a way that these bindings can be integrity-protected (and thus shown to be authentically from the zone operator) using DNSSEC and used as a basis for authentication in protocols that use domain names as identifiers. Possible starting points for these deliverables include draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, and draft-josefsson-keyassure-tls. The mechanisms developed by this group will address bindings between domain names and keys, allowing flexibility for all key-transport mechanisms supported by the application protocols addressed (e.g., both self-signed and CA-issued certificates for use in TLS). The solutions specified by this working group rely upon the security of the DNS to provide source authentication for public keys. The decision whether the chain of trust provided by DNSSEC is sufficient to trust the key, or whether additional mechanisms are required to determine the acceptability of a key, is left to the entity that uses the key material. In addition to the protections afforded by DNSSEC, the protocols and mechanisms designed by this working group require securing the "last hop" by operating a local DNS resolver or securing the connection to remote resolver - this WG will not specify new mechanisms to secure that hop, but will reference existing specifications or document existing methods in order to allow implementations to interoperate securely. Initial deliverables for this working group are limited to distribution of bindings between names within the zone operator's control and public keys. More general statements of policy for a domain are out of scope, and new tasks in this area may only be adopted through a re-chartering. The group may also create documents that describe how protocol entities can discover and validate these bindings in the execution of specific applications. This work would be done in coordination with the IETF Working Groups responsible for the protocols. Goals and Milestones: Apr 2011 - First WG draft of standards-track protocol for using DNS to associate hosts with keys for TLS and DTLS May 2011 - First WG draft of standards-track protocols for using DNS to associate hosts with IPsec Sep 2011 - Protocol for using DNS to associate domain names with keys for TLS and DTLS to IESG Sep 2011 - Protocols for using DNS to associate domain names with keys for IPsec to IESG Nov 2011 - Recharter Internet-Drafts: - The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA [draft-ietf-dane-protocol-20] (34 pages) - Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE) [draft-ietf-dane-use-cases-05] (12 pages) Requests for Comments: RFC6394: Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE) (12 pages) EAP Method Update (emu) ----------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Joseph A. Salowey Alan DeKok Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Sean Turner Mailing Lists: General Discussion: emu@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/emu Archive: http://www.ietf.org/mail-archive/web/emu/ Description of Working Group: The Extensible Authentication Protocol (EAP) [RFC 3748] is a network access authentication framework used in the PPP, 802.11, 802.16, VPN, PANA, and in some functions in 3G networks. EAP itself is a simple protocol and actual authentication happens in EAP methods. Over 40 different EAP methods exist. Most of these methods are proprietary methods, but some are documented in informational RFCs. In the past the lack of documented, open specifications has been a deployment and interoperability problem. There are currently only two EAP methods in the standards track that implement features such as key derivation that are required for many modern applications. Authentication types and credentials continue to evolve as do requirements for EAP methods. This group is chartered to work on the following types of mechanisms to meet requirements relevant to EAP methods in RFC 3748, RFC 4017, RFC 4962 and EAP Keying: - A mechanism based on strong shared secrets. This mechanism should strive to be simple and compact for implementation in resource constrained environments. - A document that defines EAP channel bindings and provides guidance for establishing EAP channel bindings within EAP methods. - Enable TLS-based EAP methods to support channel bindings. This item will not generate a new method; rather, it will focus on adding support for EAP channel bindings to the tunneled method (described below), and if possible, other TLS-based EAP methods. Potential mechanisms for adding channel binding support will be investigated, including tunneling of channel binding parameters, or a TLS extension, or other standard TLS mechanism - A mechanism to support extensible communication within a TLS protected tunnel. This mechanism will support meeting the requirements of an enhanced TLS mechanism, a password based authentication mechanism, and additional inner authentication mechanisms. It will also support channel bindings (as described above) in order to meet RFC 4962 requirements. - A mechanism that makes use of existing password databases such as AAA databases. This item will be based on the above tunnel method. Goals and Milestones: Done - Form design team to work on strong shared secret mechanism Done - Submit 2716bis I-D Done - Form password based mechanism design team Done - Submit first draft of shared secret mechanism I-D Done - Submit Strong Shared Secret Mechanism to IESG Done - Submit Tunnel/Password Method Requirements to IESG Nov 2010 - Call for Tunnel/Password Method Submissions Feb 2011 - Close Tunnel/Password Method Submissions and Begin Evaluation Jun 2011 - Channel Bindings Draft WGLC Jul 2011 - Tunnel/Password Method Selection Jul 2011 - Channel Bindings Draft to IESG Aug 2011 - Tunnel/Password Method WGLC Sep 2011 - Tunnel/Password Method to IESG Internet-Drafts: - Channel Binding Support for EAP Methods [draft-ietf-emu-chbind-15] (33 pages) - Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method [draft-ietf-emu-eap-gpsk-17] (39 pages) - Tunnel EAP Method (TEAP) Version 1 [draft-ietf-emu-eap-tunnel-method-02] (91 pages) - Requirements for a Tunnel Based EAP Method [draft-ietf-emu-eaptunnel-req-09] (25 pages) - The EAP-TLS Authentication Protocol [draft-simon-emu-rfc2716bis-13] (33 pages) Requests for Comments: RFC5216: The EAP-TLS Authentication Protocol (33 pages) * Obsoletes RFC2716 RFC5433: Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method (39 pages) * Replaces DRAFT-CLANCY-EMU-EAP-SHARED-SECRET Handover Keying (hokey) ----------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Glen Zorn Tina Tsou (Ting ZOU) Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Stephen Farrell Mailing Lists: General Discussion: hokey@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/hokey Archive: http://www.ietf.org/mail-archive/web/hokey/ Description of Working Group: A mobile device has to re-authenticate each time it changes its point of attachment to the network. When it goes through the full procedure of authentication it creates a series of ruptures, during which the medium cannot flow. This results in a poor user experience during handover. However, it is possible to shorten the time it takes to re-authenticate by reusing the key information developed during the initial authentication. The Handover Keying Working Group is concerned with developing procedures for key reuse and delivery, while respecting good security practice. The Handover Keying Working Group has already done work on this subject, but it has not yet developed the complete set of procedures, protocols, and changes needed for different security environment scenarios and situations. The solutions specified by the HOKEY WG fall into several categories, based on timing and mechanism. The authentication and key management may occur before handoff, when latency is much less critical. Alternatively, authentication and key management can occur as part of the handoff, where latency is critical. Solutions should reduce or eliminate the number of referrals to AAA servers, and solutions should avoid re-executing lengthy EAP method exchanges. This may be accomplished by providing new mechanisms for cryptographic keying material in combination with a protocol for the timely delivery of appropriate keys to the appropriate entities. Solutions are expected to include "handover keying," "low-latency re-authentication," and "pre-authentication" or "early authentication". All solution categories are useful, each supporting different scenarios. The HOKEY WG may provide multiple solutions, each addressing a different scenario. Solutions specified by the HOKEY WG must: 1) Be responsive to handover and re-authentication latency performance objectives within a mobile wireless access network. 2) Fulfill the requirements in RFC 4962 and RFC 5247. 3) Be independent of the access-technology. Any key hierarchy topology or protocol defined must be independent of EAP lower layers. The protocols may require additional support from the EAP lower layers that use it. 4) Accommodate inter-technology heterogeneous handover and roaming. 5) Not require changes to EAP methods. Any extensions defined to EAP must not cause changes to existing EAP methods. In specifying an access-technology-independent solution, media independent guidelines for SDOs may also be needed to explain how the keying material and signaling can be employed in a specific access technology. HOKEY WG Deliverables ===================== 1) A specification of Local Domain Name Discovery for ERP. Currently the use of DHCP mechanisms to request the local domain name is unspecified. There are other useful scenarios that need to be addressed. Lower layer announcement for local domain name is unspecified. Ambiguity with using initial full EAP exchange for re-authentication needs to be clarified. Additional re-authentication scenarios, for which there is interest, need to be addressed. 2) A specification of Early Authentication solutions. These include use of EAP to pre-establish authenticated keying material on a target authenticator prior to arrival of the peer. 3) A specification for a Hokey architecture Document. It includes deployment of ERP and EAP early authentication protocol in the mobile environment. There are various useful scenarios that need to be addressed. This specification and the revision of RFC5296 should be conducted in parallel. 4) Assistance to the 802.21a group in specifying the integration of EAP pre-authentication with IEEE 802.21a. The Hokey Working Group shall perform tasks that are complementary to and do not duplicate work being done in IEEE 802.21a. 6) A specification for NAS-Authenticator interaction. NAS interaction can be used to release resources in the old NAS and achieve faster initiation of authentication. Related work in external SDOs on authenticator/NAS interaction for re-authentication may be taken into consideration. 7) A revision of RFC 5296 to eliminate unnecessary references to the home server. 8) Assistance to the radext and dime Working Groups in developing AAA support for handoff keying. Goals and Milestones: Done - First draft with a problem statement on EAP re-authentication and key management Done - First draft on EMSK-based Keying Hierarchy Done - First draft on EAP Re-authentication and Handover Keying Hierarchy Done - First draft on EAP Re-authentication Protocol Done - First draft on Protocol and Keying Hierarchy for Visited Domain Handovers and Re-authentication Done - Submit EMSK-based Keying Hierarchy draft to IESG Done - First draft on Handover Key Distribution Protocol Done - Submit the problem statement draft to IESG Done - Submit EAP Re-authentication and Handover Keying Hierarchy draft to IESG Done - Submit EAP Re-authentication Protocol draft to IESG Done - Submit Protocol and Keying Hierarchy for Visited Domain Handovers and Re-authentication draft to IESG Done - First draft on EAP Pre-authentication Specification for inter-technology and inter-domain handoffs Done - First draft on Local Domain Name Discovery for ERP Nov 2009 - First draft on Early Authentication solutions Mar 2010 - First draft on Hokey architecture Mar 2010 - First draft on NAS-Authenticator Interaction Jul 2010 - First draft on revision of RFC 5296 Mar 2011 - Submit the Local Domain Name Discovery for ERP draft to IESG Mar 2011 - Submit the Early Authentication solutions draft to IESG Jul 2011 - Submit the NAS-Authenticator Interaction draft to IESG Nov 2011 - Submit the Hokey architecture draft to IESG Nov 2011 - Submit the revision of RFC 5296 to IESG Mar 2012 - Re-charter or shut down WG Internet-Drafts: - Handover Keying (HOKEY) Architecture Design [draft-ietf-hokey-arch-design-11] (20 pages) - Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK) [draft-ietf-hokey-emsk-hierarchy-07] (20 pages) - EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK) [draft-ietf-hokey-erp-aak-11] (20 pages) - EAP Extensions for EAP Re-authentication Protocol (ERP) [draft-ietf-hokey-erx-14] (43 pages) - Distribution of EAP-Based Keys for Handover and Re-Authentication [draft-ietf-hokey-key-mgm-13] (13 pages) - The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option [draft-ietf-hokey-ldn-discovery-10] (7 pages) - Extensible Authentication Protocol (EAP) Early Authentication Problem Statement [draft-ietf-hokey-preauth-ps-12] (21 pages) - Handover Key Management and Re-Authentication Problem Statement [draft-ietf-hokey-reauth-ps-09] (15 pages) - EAP Extensions for EAP Re-authentication Protocol (ERP) [draft-ietf-hokey-rfc5296bis-06] (43 pages) Requests for Comments: RFC5169: Handover Key Management and Re-Authentication Problem Statement (15 pages) * Replaces DRAFT-CLANCY-HOKEY-REAUTH-PS RFC5295: Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK) (20 pages) * Replaces DRAFT-SALOWEY-EAP-EMSK-DERIV RFC5296: EAP Extensions for EAP Re-authentication Protocol (ERP) (43 pages) RFC5749: Distribution of EAP-Based Keys for Handover and Re-Authentication (13 pages) RFC5836: Extensible Authentication Protocol (EAP) Early Authentication Problem Statement (21 pages) RFC6440: The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option (7 pages) * Replaces DRAFT-WU-HOKEY-LDN-DISCOVERY IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Paul E. Hoffman Yaron Sheffer Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Sean Turner Mailing Lists: General Discussion: ipsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: http://www.ietf.org/mail-archive/web/ipsec/ Description of Working Group: The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs), IKEv2 (RFC 4306, RFC 4718, and associated RFCs), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group continues the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions to IPsec, mostly to IKEv2. The working group also serves as a focus point for other IETF Working Groups who use IPsec in their own protocols. The current work items include: In an environment with many IPsec gateways and remote clients that share an established trust infrastructure (in a single administrative domain or across multiple domains), customers want to get on-demand point-to-point IPsec capability for efficiency. However, this cannot be feasibly accomplished only with today's IPsec and IKE due to problems with address lookup, reachability, policy configuration, and so on. The IPsecME Working Group will handle this large scale VPN problem by: * Creating a problem statement document including use cases, definitions and proper requirements for discovery and updates. This document would be solution-agnostic. * Publishing a common solution for the discovery and update problems that will satisfy the requirements in the problem statement document. The working group may standardize one of the vendor solutions, a combination, an superset of such a solution, or a new protocol. * Reviewing and help publish Informational documents describing current vendor proprietary solutions. This charter will expire in January 2014 (24 months from approval). If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Goals and Milestones: Done - WG last call on IPv6 configuration payloads Done - WG last call on IPsec roadmap Done - WG last call on session resumption Done - WG last call on redirect Done - WG last call on IKEv2bis Done - WG last call on ESP NULL traffic visibility Done - WG last call on HA requirements Done - WG last call on quick crash discovery Done - WG last call on EAP-only authentication Nov 2012 - IETF Last Call on large scale VPN use cases Jun 2013 - IETF Last Call on large scale VPN protocol Internet-Drafts: - Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol [draft-ietf-ipsecme-aes-ctr-ikev2-07] (10 pages) - An Extension for EAP-Only Authentication in IKEv2 [draft-ietf-ipsecme-eap-mutual-05] (16 pages) - Heuristics for Detecting ESP-NULL Packets [draft-ietf-ipsecme-esp-null-heuristics-07] (37 pages) - A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE) [draft-ietf-ipsecme-failure-detection-08] (24 pages) - IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-ikev2-ipv6-config-03] (36 pages) - Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-ikev2-redirect-13] (15 pages) - Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption [draft-ietf-ipsecme-ikev2-resumption-09] (29 pages) - Internet Key Exchange Protocol Version 2 (IKEv2) [draft-ietf-ipsecme-ikev2bis-11] (130 pages) - IPsec Cluster Problem Statement [draft-ietf-ipsecme-ipsec-ha-09] (13 pages) - Protocol Support for High Availability of IKEv2/IPsec [draft-ietf-ipsecme-ipsecha-protocol-06] (26 pages) - Point to Point VPNs Problem Statement [draft-ietf-ipsecme-p2p-vpn-problem-00] (13 pages) - IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap [draft-ietf-ipsecme-roadmap-10] (61 pages) - Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility [draft-ietf-ipsecme-traffic-visibility-12] (15 pages) Requests for Comments: RFC5685: Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2) (15 pages) * Replaces DRAFT-DEVARAPALLI-IPSEC-IKEV2-REDIRECT RFC5723: Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption (29 pages) * Replaces DRAFT-TSCHOFENIG-IPSECME-IKEV2-RESUMPTION RFC5739: IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2) (36 pages) * Replaces DRAFT-ERONEN-IPSEC-IKEV2-IPV6-CONFIG RFC5840: Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility (15 pages) * Replaces DRAFT-GREWAL-IPSEC-TRAFFIC-VISIBILITY RFC5879: Heuristics for Detecting ESP-NULL Packets (37 pages) * Replaces DRAFT-KIVINEN-IPSECME-ESP-NULL-HEURISTICS RFC5930: Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol (10 pages) * Replaces DRAFT-IPSECME-AES-CTR-IKEV2 RFC5996: Internet Key Exchange Protocol Version 2 (IKEv2) (130 pages) * Replaces DRAFT-HOFFMAN-IKEV2BIS * Obsoletes RFC4306 * Obsoletes RFC4718 * Updates RFC5998 RFC5998: An Extension for EAP-Only Authentication in IKEv2 (16 pages) * Replaces DRAFT-ERONEN-IPSEC-IKEV2-EAP-AUTH * Updates RFC5996 RFC6027: IPsec Cluster Problem Statement (13 pages) RFC6071: IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap (61 pages) * Obsoletes RFC2411 RFC6290: A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE) (24 pages) RFC6311: Protocol Support for High Availability of IKEv2/IPsec (26 pages) Javascript Object Signing and Encryption (jose) ----------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Jim Schaad Tony Hansen Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Sean Turner Mailing Lists: General Discussion: jose@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/jose Archive: http://www.ietf.org/mail-archive/web/jose/ Description of Working Group: Javascript Object Notation (JSON) is a text format for the serialization of structured data described in RFC 4627. The JSON format is often used for serializing and transmitting structured data over a network connection. With the increased usage of JSON in protocols in the IETF and elsewhere, there is now a desire to offer security services such as encryption, digital signatures, and message authentication codes (MACs) for data that is being carried in JSON format. Different proposals for providing such security services have already been defined and implemented. This Working Group's task is to standardize two security services, integrity protection (signature and MAC) and encryption, in order to increase interoperability of security features between protocols that use JSON. The Working Group will base its work on well-known message security primitives (e.g., CMS), and will solicit input from the rest of the IETF Security Area to be sure that the security functionality in the JSON format is correct. This group is chartered to work on four documents: 1) A Standards Track document specifying how to apply JSON-structured integrity protection to data, including (but not limited to) JSON data structures. "Integrity protection" includes public-key digital signatures as well as symmetric-key MACs. 2) A Standards Track document specifying how to apply a JSON-structured encryption to data, including (but not limited to) JSON data structures. 3) A Standards Track document specifying how to encode public keys as JSON-structured objects. 4) A Standards Track document specifying mandatory-to-implement algorithms for the other three documents. The working group may decide to address one or more of these goals in a single document, in which case the concrete milestones for signing/encryption below will both be satisfied by the single document. Goals and Milestones: Jan 2012 - Submit JSON object integrity document as a WG item. Jan 2012 - Submit JSON object encryption document as a WG item. Jan 2012 - Submit JSON key format document as a WG item. Jan 2012 - Submit JSON algorithm document as a WG item. Jun 2012 - Start Working Group Last Call on JSON object integrity document. Jun 2012 - Start Working Group Last Call on JSON object encryption document. Jun 2012 - Start Working Group Last Call on JSON key format document. Jun 2012 - Start Working Group Last Call on JSON algorithm document. Jul 2012 - Submit JSON object integrity document to IESG for consideration as Standards Track document. Jul 2012 - Submit JSON object encryption document to IESG for consideration as Standards Track document. Jul 2012 - Submit JSON key format document to IESG for consideration as Standards Track document. Jul 2012 - Submit JSON algorithm document to IESG for consideration as Standards Track document. Internet-Drafts: - JSON Web Algorithms (JWA) [draft-ietf-jose-json-web-algorithms-02] (26 pages) - JSON Web Encryption (JWE) [draft-ietf-jose-json-web-encryption-02] (24 pages) - JSON Web Key (JWK) [draft-ietf-jose-json-web-key-02] (8 pages) - JSON Web Signature (JWS) [draft-ietf-jose-json-web-signature-02] (30 pages) No Requests for Comments Kerberos (krb-wg) ----------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Jeffrey Hutzelman Larry Zhu Sam D. Hartman Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Stephen Farrell Mailing Lists: General Discussion: ietf-krb-wg@lists.anl.gov To Subscribe: https://lists.anl.gov/mailman/listinfo/ietf-krb-wg Archive: https://lists.anl.gov/pipermail/ietf-krb-wg/ Description of Working Group: Kerberos over the years has been ported to virtually every operating system. There are at least two open source versions, with numerous commercial versions based on these and other proprietary implementations. Kerberos evolution has continued in recent years, with the development of new crypto and preauthentication frameworks, support for initial authentication using public keys, improved support for protecting clients' long-term keys during initial authentication, support for anonymous and partially-anonymous authentication, and numerous extensions developed in and out of the IETF. However, wider deployment and advances in technology bring with them both new challenges and new opportunities, such as exploring support for new mechanisms for initial authentication, new cryptographic technologies, and better integration of Kerberos with other systems for authentication, authorization, and identity management. In addition, several key features remain undefined. The Kerberos Working Group will continue to improve the core Kerberos specification, develop extensions to address new needs and technologies related to the areas described above, and produce specifications for missing functionality. Specifically, the Working Group will: * Complete existing work, including: - DHCP Option (draft-sakane-dhc-dhcpv6-kdc-option-10.txt) - KDC Data Model (draft-ietf-krb-wg-kdc-model-09.txt) - One-Time Passwords (draft-ietf-krb-wg-otp-preauth-16.txt) - IAKERB (draft-ietf-krb-wg-iakerb-02.txt) - Single-DES Deprecation (draft-lha-des-die-die-die-05.txt) - IANA registry creation (draft-lha-krb-wg-some-numbers-to-iana) - Hash agility for GSS-KRB5 (draft-ietf-krb-wg-gss-cb-hash-agility-06.txt) - Hash agility for PKINIT (draft-ietf-krb-wg-pkinit-alg-agility-05.txt) - Referrals (draft-ietf-krb-wg-kerberos-referrals-12.txt) - Set/Change Password (draft-ietf-krb-wg-kerberos-set-passwd-08.txt) * Prepare and advance one or more standards-track specifications which update the Kerberos version 5 protocol to support non-ASCII principal and realm names, salt strings, and passwords, and localized error reporting. Maximizing backward compatibility is strongly desired. * Prepare and advance one or more standards-track specifications which update the Kerberos version 5 protocol in a backward-compatible way to support extending the unencrypted portion of a Kerberos ticket. * Prepare, review, and advance standards-track and informational specifications defining use of new cryptographic algorithms in the Kerberos protocol, on an ongoing basis. * Prepare, review, and advance standards-track and informational specifications defining use of new cryptographic algorithms in Kerberos using the RFC3961 framework. Cryptographic algorithms intended for standards track status must be of good quality, have broad international support, and fill a definite need. * Prepare, review, and advance standards-track and informational specifications defining new authorization data types for carrying supplemental information about the client to which a Kerberos ticket has been issued and/or restrictions on what the ticket can be used for. To enhance this ongoing authorization data work, a container format supporting the use cases of draft-sorce-krbwg-general-pac-01 may be standardized. * Prepare a standards-track protocol to solve the use cases addressed by draft-hotz-kx509-01 including new support for digital signatures. * Prepare and advance one or more standards-track specifications which define mechanisms for establishing keys and configuration information used during authentication between Kerberos realms. * Prepare and advance a standards-track specification defining a format for the transport of Kerberos credentials within other protocols. * Today Kerberos requires a replay cache to be used in AP exchanges in almost all cases. Replay caches are quite complex to implement correctly, particularly in clustered systems. High-performance replay caches are even more difficult to implement. The WG will pursue extensions to minimize the need for replay caching, optimize replay caching, and/or elide the need for replay caching. * Produce an LDAP schema for management of the KDC's database. Goals and Milestones: Done - First meeting Done - Submit the Kerberos Extensions document to the IESG for consideration as a Proposed standard. Done - Complete first draft of Pre-auth Framework Done - Complete first draft of Extensions Done - Submit K5-GSS-V2 document to IESG for consideration as a Proposed Standard Done - Last Call on OCSP for PKINIT Done - Consensus on direction for Change/Set password Done - PKINIT to IESG Done - Enctype Negotiation to IESG Done - Last Call on PKINIT ECC Done - TCP Extensibility to IESG Done - ECC for PKINIT to IESG Done - Naming Constraints to IESG Done - Anonymity to IESG Done - WGLC on preauth framework Done - WGLC on OTP Done - WGLC on data model Done - WGLC on cross-realm issues Done - WGLC on IAKERB Done - Anonymity back to IESG Done - WGLC on STARTTLS Done - WGLC on DHCPv6 Option Done - draft-ietf-krb-wg-clear-text-cred to IESG Aug 2011 - draft-ietf-krbwg-camellia-cts to IESG Done - draft-ietf-krb-wg-des-die-die-die to IESG Done - DHCP option for Kerberos to IESG Oct 2011 - Internationalized error support to IESG Oct 2011 - draft-ietf-krb-wg-pkinit-alg-agility to IESG Dec 2011 - Kerberos PAD authorization data to IESG Dec 2011 - Consider adopting kx509bis in response to use cases in draft-hotz-kx509-01 Internet-Drafts: - Initial and Pass Through Authentication Using Kerberos V5 and GSS-API (IAKERB) [draft-ietf-cat-iakerb-09] (13 pages) - Public Key Cryptography for Cross-Realm Authentication in Kerberos [draft-ietf-cat-kerberos-pk-cross-08] (5 pages) - Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) [draft-ietf-cat-kerberos-pk-init-34] (42 pages) - Public Key Utilizing Tickets for Application Servers (PKTAPP) [draft-ietf-cat-kerberos-pk-tapp-04] (5 pages) - The Kerberos Network Authentication Service (V5) [draft-ietf-cat-kerberos-revisions-10] (103 pages) - Kerberos Set/Change Password: Version 2 [draft-ietf-cat-kerberos-set-passwd-06] (13 pages) - The Kerberos Version 5 GSSAPI Mechanism, Version 2 [draft-ietf-cat-krb5gss-mech2-03] (23 pages) - Anonymity Support for Kerberos [draft-ietf-krb-wg-anon-12] (16 pages) - Camellia Encryption for Kerberos 5 [draft-ietf-krb-wg-camellia-cts-01] (12 pages) - Container Authenticated by Multiple MACs [draft-ietf-krb-wg-cammac-01] (7 pages) - The Unencrypted Form of Kerberos 5 KRB-CRED Message [draft-ietf-krb-wg-clear-text-cred-03] (5 pages) - Problem Statement on the Cross-Realm Operation of Kerberos [draft-ietf-krb-wg-cross-problem-statement-06] (14 pages) - Encryption and Checksum Specifications for Kerberos 5 [draft-ietf-krb-wg-crypto-07] (51 pages) - Deprecate DES, RC4-HMAC-EXP, and other weak cryptographic algorithms in Kerberos [draft-ietf-krb-wg-des-die-die-die-04] (7 pages) - A Generalized PAC for Kerberos V5 [draft-ietf-krb-wg-general-pac-01] (17 pages) - Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Channel Binding Hash Agility [draft-ietf-krb-wg-gss-cb-hash-agility-10] (11 pages) - General Kerberos Cryptosystem Support for the Kerberos 5 GSSAPI Mechanism [draft-ietf-krb-wg-gss-crypto-00] (10 pages) - The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2 [draft-ietf-krb-wg-gssapi-cfx-07] (17 pages) - Passwordless Initial Authentication to Kerberos by Hardware Preauthentication [draft-ietf-krb-wg-hw-auth-04] (7 pages) - Initial and Pass Through Authentication Using Kerberos V5 and the GSS- API (IAKERB) [draft-ietf-krb-wg-iakerb-02] (10 pages) - Informational: Kerberos GeneralString to be Interpreted as ASCII Only [draft-ietf-krb-wg-info-ascii-gen-string-00] (0 pages) - An information model for Kerberos version 5 [draft-ietf-krb-wg-kdc-model-11] (18 pages) - The Kerberos Network Authentication Service (V5) [draft-ietf-krb-wg-kerberos-clarifications-07] (135 pages) - Kerberos Principal Name Canonicalization and KDC-Generated Cross-Realm Referrals [draft-ietf-krb-wg-kerberos-referrals-14] (20 pages) - Integrating Single-use Authentication Mechanisms with Kerberos [draft-ietf-krb-wg-kerberos-sam-03] (16 pages) - Kerberos Set/Change Key/Password Protocol Version 2 [draft-ietf-krb-wg-kerberos-set-passwd-08] (41 pages) - Distributing Kerberos KDC and Realm Information with DNS [draft-ietf-krb-wg-krb-dns-locate-03] (7 pages) - Additional Kerberos Naming Constraints [draft-ietf-krb-wg-naming-07] (8 pages) - Online Certificate Status Protocol (OCSP) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) [draft-ietf-krb-wg-ocsp-for-pkinit-06] (7 pages) - One-Time Password (OTP) Pre-Authentication [draft-ietf-krb-wg-otp-preauth-21] (43 pages) - POSIX Authorization Data [draft-ietf-krb-wg-pad-01] (16 pages) - PKINIT Algorithm Agility [draft-ietf-krb-wg-pkinit-alg-agility-06] (17 pages) - A Generalized Framework for Kerberos Pre-Authentication [draft-ietf-krb-wg-preauth-framework-17] (52 pages) - The Kerberos Network Authentication Service (Version 5) [draft-ietf-krb-wg-rfc1510ter-04] (114 pages) - Unkeyed SHA-1 Checksum Specification for Kerberos 5 [draft-ietf-krb-wg-sha1-00] (4 pages) - Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges over TCP [draft-ietf-krb-wg-tcp-expansion-02] (7 pages) - Kerberos ticket extensions [draft-ietf-krb-wg-ticket-extensions-00] (17 pages) - Preparation of Internationalized Strings Profile for Kerberos UTF-8 Strings [draft-ietf-krb-wg-utf8-profile-01] (0 pages) - Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol [draft-josefsson-kerberos5-starttls-09] (13 pages) - Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges Over TCP [draft-josefsson-krb-tcp-expansion-02] (7 pages) - Deprecate DES support for Kerberos [draft-lha-des-die-die-die-05] (10 pages) - Kerberos number registry to IANA [draft-lha-krb-wg-some-numbers-to-iana-00] (15 pages) - Advanced Encryption Standard (AES) Encryption for Kerberos 5 [draft-raeburn-krb-rijndael-krb-07] (15 pages) - Kerberos Options for DHCPv6 [draft-sakane-dhc-dhcpv6-kdc-option-14] (17 pages) - Kerberos KDC LDAP Schema [draft-skibbie-krb-kdc-ldap-schema-02] (0 pages) - Keys Extension for the Kerberos KDC LDAP Schema [draft-skibbie-krb-kdckeys-ldap-schema-00] (0 pages) - Kerberos Cryptosystem Negotiation Extension [draft-zhu-kerb-enctype-nego-04] (7 pages) - Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) [draft-zhu-pkinit-ecc-04] (11 pages) Requests for Comments: RFC3961: Encryption and Checksum Specifications for Kerberos 5 (51 pages) RFC3962: Advanced Encryption Standard (AES) Encryption for Kerberos 5 (15 pages) RFC4120: The Kerberos Network Authentication Service (V5) (135 pages) * Obsoletes RFC1510 * Updates RFC4537 * Updates RFC5021 * Updates RFC5896 * Updates RFC6111 * Updates RFC6112 * Updates RFC6113 RFC4121: The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2 (17 pages) * Updates RFC1964 * Updates RFC6112 * Updates RFC6542 RFC4537: Kerberos Cryptosystem Negotiation Extension (7 pages) * Updates RFC4120 RFC4556: Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) (42 pages) * Updates RFC6112 RFC4557: Online Certificate Status Protocol (OCSP) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) (7 pages) RFC5021: Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges over TCP (7 pages) * Updates RFC4120 RFC5349: Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) (11 pages) RFC5868: Problem Statement on the Cross-Realm Operation of Kerberos (14 pages) RFC6111: Additional Kerberos Naming Constraints (8 pages) * Updates RFC4120 RFC6112: Anonymity Support for Kerberos (16 pages) * Updates RFC4120 * Updates RFC4121 * Updates RFC4556 RFC6113: A Generalized Framework for Kerberos Pre-Authentication (52 pages) * Updates RFC4120 RFC6251: Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol (13 pages) RFC6448: The Unencrypted Form of Kerberos 5 KRB-CRED Message (5 pages) RFC6542: Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Channel Binding Hash Agility (11 pages) * Updates RFC4121 RFC6560: One-Time Password (OTP) Pre-Authentication (43 pages) * Replaces DRAFT-RICHARDS-OTP-KERBEROS Managed Incident Lightweight Exchange (mile) -------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Kathleen Moriarty Brian Trammell Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Sean Turner Mailing Lists: General Discussion: mile@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mile Archive: http://www.ietf.org/mail-archive/web/mile/ Description of Working Group: The Managed Incident Lightweight Exchange (MILE) working group will develop standards and extensions for the purpose of improving incident information sharing and handling capabilities based on the work developed in the IETF Extended INCident Handling (INCH) working group. The Incident Object Description Exchange Format (IODEF) in RFC5070 and Real-time Inter-network Defense (RID) in RFC6045 were developed in the INCH working group by international Computer Security Incident Response Teams (CSIRTs) and industry to meet the needs of a global community interested in sharing, handling, and exchanging incident information. The extensions and guidance created by the MILE working group assists with the daily operations of CSIRTs at an organization, service provider, law enforcement, and at the country level. The application of IODEF and RID to interdomain incident information cooperative exchange and sharing has recently expanded and the need for extensions has become more important. Efforts continue to deploy IODEF and RID, as well as to extend them to support specific use cases covering reporting and mitigation of current threats such as anti-phishing extensions. An incident could be a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), a system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack, etc. When an incident is detected, the response may include simply filing a report, notification to the source of the incident, a request to a third party for resolution/mitigation, or a request to locate the source. IODEF defines a data representation that provides a standard format for sharing information commonly exchanged about computer security incidents. RID enables the secure exchange of incident related information in an IODEF format providing options for security, privacy, and policy setting. MILE leverages collaboration and sharing experiences with the work developed in the INCH working group which includes the data model detailed in the IODEF, existing extensions to the IODEF for Anti-phishing (RFC5901), and RID (RFC6045, RFC6046) for the secure exchange of information. MILE will also leverage the experience gained in using IODEF and RID in operational contexts. Related work, drafted outside of INCH will also be reviewed and includes RFC5941, Sharing Transaction Fraud Data. The MILE working group provides coordination for these various extension efforts to improve the capabilities for exchanging incident information. MILE has several objectives with the first being a description a subset of IODEF focused on ease of deployment and applicability to current information security data sharing use cases. MILE also describes a generalization of RID for secure exchange of other security-relevant XML formats. MILE produces additional guidance needed for the successful exchange of incident information for new use cases according to policy, security, and privacy requirements. Finally, MILE produces a document template with guidance for defining IODEF extensions to be followed when producing extensions to IODEF as appropriate, for: * labeling incident reports with data protection, data retention, and other policies, regulations, and laws restricting the handling of those reports * referencing structured security information from within incident reports * reporting forensic data generated during an incident investigation (computer or accounting) The WG will produce the following: * An informational document on IODEF Guidance. * A Standards Track document specifying the Real-time Inter-network Defense (RID). * A Standards Track document specifying the transport for RID. * An informational template for extensions to IODEF. * A Standards Track document for IODEF Extensions in IANA XML Registry. * A Standards Track document for IODEF Extension to support structured cybersecurity information. * A Standards Track document for Labeling for data protection, retention, policies, and regulations. * A Standards Track document for GRC Report Exchange. * A Standards Track document for IODEF Extension to support forensics. The drafts under consideration as WG items include: * Real-time Inter-network Defense (RID) bis: draft-moriarty-mile-rfc6045-bis-01 * Transport of Real-time Inter-network Defense (RID) Messages bis: draft-trammell-mile-rfc6046-bis-00 * Template for extensions to IODEF: draft-trammell-mile-template-01.txt * IODEF Extensions in IANA XML Registry: draft-trammell-mile-iodef-xmlreg-00.txt * GRC Report Exchange (Generalized RID for XML reports/documents): draft-moriarty-mile-grc-exchange-00.txt * IODEF-extension to support structured cybersecurity information: draft-takahashi-mile-sci-00.txt Goals and Milestones: Nov 2011 - WGLC Real-time Inter-network Defense (RID) Nov 2011 - WGLC Transport for Real-time Inter-network Defense (RID) Dec 2011 - Submit Real-time Inter-network Defense (RID) to IESG for consideration as Standards Track document Dec 2011 - Submit Transport Real-time Inter-network Defense (RID) to IESG for consideration as Standards Track document Dec 2011 - WGLC Template for extensions to IODEF Dec 2011 - WGLC IODEF Extensions in IANA XML Registry Dec 2011 - WGLC IODEF Extension to support structured cybersecurity information Feb 2012 - Submit Template for extensions to IODEF to IESG for consideration as Informational document Feb 2012 - Submit IODEF Extensions in IANA XML Registry to IESG for consideration as Standards Track document Feb 2012 - Submit IODEF Extension to support structured cybersecurity information to IESG for consideration as Standards Track document policies, and regulations Mar 2012 - WGLC IODEF Guidance Apr 2012 - Submit IODEF Extension Labeling for data protection, retention, policies, and regulations to IESG for consideration as Standards Track document Apr 2012 - Submit WGLC IODEF Guidance to IESG for consideration as Informational document May 2012 - WGLC GRC Report Exchange Jun 2012 - Submit GRC Report Exchange to IESG for consideration as Standards Track document Jun 2012 - WGLC Forensics extension Jul 2012 - Submit IODEF Forensics extension to IESG for consideration as Standards Track document Internet-Drafts: - GRC Report Exchange [draft-ietf-mile-grc-exchange-00] (68 pages) - Expert Review for IODEF Extensions in IANA XML Registry [draft-ietf-mile-iodef-xmlreg-01] (3 pages) - Real-time Inter-network Defense (RID) [draft-ietf-mile-rfc6045-bis-11] (84 pages) - Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS [draft-ietf-mile-rfc6046-bis-09] (8 pages) - IODEF-extension to support structured cybersecurity information [draft-ietf-mile-sci-04] (35 pages) - Guidelines for Defining Extensions to IODEF [draft-ietf-mile-template-04] (13 pages) Requests for Comments: RFC6545: Real-time Inter-network Defense (RID) (84 pages) * Replaces DRAFT-MORIARTY-MILE-RFC6045-BIS * Obsoletes RFC6045 RFC6546: Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS (8 pages) * Replaces DRAFT-TRAMMELL-MILE-RFC6046-BIS * Obsoletes RFC6046 Network Endpoint Assessment (nea) --------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Stephen R. Hanna Dr. Susan Thomson Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Stephen Farrell Mailing Lists: General Discussion: nea@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/nea Archive: http://www.ietf.org/mail-archive/web/nea Description of Working Group: Network Endpoint Assessment (NEA) architectures have been implemented in the industry to assess the "posture" of endpoint devices for the purposes of monitoring compliance to an organization's posture policy and optionally restricting access until the endpoint has been updated to satisfy the posture requirements. An endpoint that does not comply with posture policy may be vulnerable to a number of known threats that may exist on the network. The intent of NEA is to facilitate corrective actions to address these known vulnerabilities before a host is exposed to potential attack. Note that an endpoint that is deemed compliant may still be vulnerable to threats that may exist on the network. The network may thus continue to be exposed to such threats as well as the range of other threats not addressed by maintaining endpoint compliance. Posture refers to the hardware or software configuration of an endpoint as it pertains to an organization's security policy. Posture may include knowledge that software installed to protect the machine (e.g. patch management software, anti-virus software, host firewall software, host intrusion protection software or any custom software) is enabled and up-to-date. An endpoint supporting NEA protocols can be queried for posture information. An organization may make a range of policy decisions based on the posture of an endpoint. NEA is not intended to be prescriptive in this regard. Supported deployment scenarios will include, but are not limited to, providing normal access regardless of compliance result along with any recommendations for remediation ("advisory mode"), as well as providing restricted access sufficient for remediation purposes and any essential services until an endpoint is in compliance ("mandatory mode"). Specifying mechanisms for providing restricted access is outside the scope of the NEA WG. Since NEA involves many different components from different vendors, interoperability is important. The NEA working group will develop standard protocols at the following three layers in the architecture: the Posture Attribute protocol (PA), the Posture Broker protocol (PB), and the Posture Transport protocol (PT). PA and PB will be designed to support a variety of PT protocols. Together, PA, PB and the mandatory to implement PT protocols will allow interoperability between an NEA Client from one vendor and an NEA Server from another. Since there are already several non-standard protocols at these layers, the NEA working group will consider these existing protocols as candidates for the standard protocols. A requirements document will be written and used as a basis for evaluating the candidate protocols. The working group may decide to standardize one of the candidate protocols, use one of them as a basis for a new or revised protocol, or decide that a new protocol is needed. The NEA Requirements document will include a problem statement, definition of terms, requirements for the PA and PB protocols, and an overall security analysis. It will also include generic requirements for the protocol transporting PA, PB: the Posture Transport protocol (PT). The PA (Posture Attribute) protocol consists of posture attributes that are carried between a particular Posture Collector in a NEA client and a particular Posture Validator in a NEA Server. The PA protocol is carried inside the PB protocol. A base set of standard posture attributes will be specified that are expected to address many common posture policies. Vendor-specific attributes will also be supported; vendor-specific attributes will be identified by a private enterprise number and a vendor assigned value. Vendors are strongly encouraged to document vendor-specific attributes in an RFC. The NEA WG will investigate the use of a standard syntax for all attributes. The PB (Posture Broker) protocol aggregates posture attributes from one or more Posture Collectors in an NEA client and sends them to the NEA server for assessment by one or more Posture Validators. The PT (Posture Transport) protocol carries the PB protocol. The expectation is that the PT protocol is a shim protocol that defines an encapsulation of PB within an existing standard transport protocol. Existing standard transport protocols will be leveraged to the extent possible. The NEA WG may specify more than one PT to meet the requirements of different deployment scenarios. The NEA WG will specify at least one mandatory to implement PT protocol. PT protocol specifications must describe any limitations that they impose on PB and PA (e.g. half duplex). One commonly discussed issue with NEA systems is how to handle compromised endpoints, whose reports of their own posture may not be accurate. Detecting or handling such endpoints is out of scope of the NEA WG. Work on PA will focus on attributes useful for assessing posture of those endpoints reporting accurate information. However, the protocols developed by the NEA WG must be designed to accommodate emerging technologies for identifying and dealing with lying endpoints. Note that NEA is not chartered to develop standard protocols for remediation. NEA is intended to be used with new or existing tools that can be used in the absence of NEA. NEA is applicable to computing enterprise environments, where endpoints accessing the enterprise's network are owned and/or expected to conform to the policies set forth by the organization that owns and operates the network. All other cases are outside the scope of the NEA charter, since we do not know that NEA would be useful in such cases. NEA applicability and security considerations will be described in the appropriate NEA documents. Further work in the NEA WG will be considered via the rechartering process after the completion of these milestones. Goals and Milestones: Done - At IETF 67, discuss issues with NEA Requirements I-D Done - Submit first draft of NEA Requirements I-D Done - At IETF 68, resolve any open issues with requirements I-D Done - Discuss NEA Requirements I-D Done - WGLC on NEA requirements I-D Done - At IETF 69, resolve any remaining issues raised at Last Call Done - Submit NEA Requirements I-D to the IESG for IETF Last Call as Informational RFC Done - Submit revised NEA requirements I-D Done - Proposals for PA and PB due Done - Review and resolve proposals at IETF 71 Done - Post first WG version of PA and PB Done - Post second version of PA and PB Done - Resolve issues at IETF 72 Done - Post third version of PA and PB Done - WGLC on PA and PB Done - Resolve WGLC comments at IETF 73 Done - Post fourth version of PA and PB Done - IETF LC for PA and PB Done - IESG considers PA and PB for Proposed Standard Done - Call for proposals for the PT protocol(s) Done - Proposals due Done - Review PT protocol proposals Done - Decide how to resolve differences and issues Done - Post first WG version of PT protocols Done - Review and resolve issues Done - Post second WG version of PT protocols Done - WG Last Call on PT protocols Done - Resolve issues from WG Last Call Apr 2012 - Post new WG version of PT protocols Apr 2012 - Send PT-TLS to IESG for Standards Track Apr 2012 - Send PT-EAP to EMU WG for Review Apr 2012 - Publish -00 WG I-D on NEA Asokan Attack Apr 2012 - WGLC on NEA Asokan Attack May 2012 - If Needed, Publish -03 PT-EAP I-D and 2nd WGLC May 2012 - Send PT-EAP to IESG for Standards Track May 2012 - Publish -01 WG I-D on NEA Asokan Attack May 2012 - Send NEA Asokan Attack Analysis to IESG for Informational Internet-Drafts: - NEA Asokan Attack Analysis [draft-ietf-nea-asokan-00] (8 pages) - PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC) [draft-ietf-nea-pa-tnc-06] (86 pages) - PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC) [draft-ietf-nea-pb-tnc-06] (79 pages) - PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods [draft-ietf-nea-pt-eap-01] (20 pages) - PT-TLS: A TCP-based Posture Transport (PT) Protocol [draft-ietf-nea-pt-tls-04] (43 pages) - Network Endpoint Assessment (NEA): Overview and Requirements [draft-ietf-nea-requirements-07] (53 pages) Requests for Comments: RFC5209: Network Endpoint Assessment (NEA): Overview and Requirements (53 pages) * Replaces DRAFT-KHOSRAVI-NEA-REQUIREMENTS RFC5792: PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC) (86 pages) * Replaces DRAFT-SANGSTER-NEA-PA-TNC RFC5793: PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC) (79 pages) * Replaces DRAFT-SAHITA-NEA-PB-TNC Public-Key Infrastructure (X.509) (pkix) ---------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Dr. Stephen T. Kent Stefan Santesson Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Sean Turner Mailing Lists: General Discussion: pkix@ietf.org To Subscribe: pkix-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/pkix/ Description of Working Group: The PKIX Working Group was established in the fall of 1995 with the goal of developing Internet standards to support X.509-based Public Key Infrastructures (PKIs). Initially PKIX pursued this goal by profiling X.509 standards developed by the CCITT (later the ITU-T). Later, PKIX initiated the development of standards that are not profiles of ITU-T work, but rather are independent initiatives designed to address X.509-based PKI needs in the Internet. Over time this latter category of work has become the major focus of PKIX work, i.e., most PKIX-generated RFCs are no longer profiles of ITU-T X.509 documents. PKIX has produced a number of standards track and informational RFCs. RFC 3280 (Certificate and CRL Profile), and RCF 3281 (Attribute Certificate Profile) are recent examples of standards track RFCs that profile ITU-T documents. RFC 2560 (Online Certificate Status Profile), RFC 3779 (IP Address and AS Number Extensions), and RFC 3161 (Time Stamp Authority) are examples of standards track RFCs that are IETF-initiated. RFC 4055 (RSA) and RFC 3874 (SHA2) are examples of informational RFCs that describe how to use public key and hash algorithms in PKIs. PKIX Work Plan PKIX will continue to track the evolution of ITU-T X.509 documents, and will maintain compatibility between these documents and IETF PKI standards, since the profiling of X.509 standards for use in the Internet remains an important topic for the working group. PKIX does not endorse the use of specific cryptographic algorithms with its protocols. However, PKIX does publish standards track RFCs that describe how to identify algorithms and represent associated parameters in these protocols, and how to use these algorithms with these protocols. We anticipate efforts in this arena will continue to be required over time. PKIX will pursue new work items in the PKI arena if working group members express sufficient interest, and if approved by the cognizant Security Area director. For example, certificate validation under X. 509 and PKIX standards calls for a relying party to use a trust anchor as the start of a certificate path. Neither X.509 nor extant PKIX standards define protocols for the management of trust anchors. Existing mechanisms for managing trust anchors, e.g., in browsers, are limited in functionality and non-standard. There is considerable interest in the PKI community to define a standard model for trust anchor management, and standard protocols to allow remote management. Thus a future work item for PKIX is the definition of such protocols and associated data models. Goals and Milestones: Done - Complete approval of CMC, and qualified certificates documents Done - Complete time stamping document Done - Continue attribute certificate profile work Done - Complete data certification document Done - Complete work on attribute certificate profile Done - Standard RFCs for public key and attribute certificate profiles, CMP, OCSP, CMC, CRMF, TSP, Qualified Certificates, LDAP v2 schema, use of FTP/HTTP, Diffie-Hellman POP Done - INFORMATIONAL RFCs for X.509 PKI policies and practices, use of KEA Done - Experimental RFC for Data Validation and Certification Server Protocols Done - Production of revised certificate and CRL syntax and processing RFC (son-of-2459) Done - DPD/DVP Requirements RFC Done - Certificate Policy & CPS Informational RFC (revision) Done - Logotype Extension RFC Done - Proxy Certificate RFC Done - Cert Path Building approved as Informational RFC Done - CRMFbis approved as PROPOSED Standard RFC Done - CMPbis approved as PROPOSED Standard RFC Done - Principal Identifier approved as PROPOSED Standard RFC Done - Warranty Extensions approved as Informational RFC Done - Certificate Store approved as Informational RFC Done - PKIX Repository approved as Informational RFC Done - Subject Identification Method as Informational RFC Done - GOST Cryptographic Algorithms (RFC 4491) Done - Update to DirectoryString Processing for RFC 3280 Done - Attribute Certificate Policies approved as PROPOSED Standard (RFC 4476) Sep 2007 - Progression of CRMF, CMP, and CMP Transport to DRAFT Standard Sep 2007 - Progression of Qualified Certificates Profile RFC to DRAFT Standard Sep 2007 - Progression of Certificate & CRL Profile RFC to DRAFT Standard Sep 2007 - Progression of Time Stamp Protocols RFC to DRAFT Standard Sep 2007 - Progression of Logotype RFC to DRAFT Standard Nov 2007 - Progression of Proxy Certificate RFC to DRAFT Standard Nov 2007 - Progression of Attribute Certificate Profile RFC to DRAFT standard Feb 2008 - Update to CMC approved as PROPOSED Standard Mar 2008 - ECC Algorithms approved as PROPOSED Standard RFC Mar 2008 - Progression of CMC RFCs to DRAFT Standard Mar 2008 - SCVP approved as PROPOSED Standard RFC Internet-Drafts: - Lightweight OCSP Profile for High Volume Environments [draft-deacon-lightweight-ocsp-profile-00] (18 pages) - Certificate Management over CMS (CMC) [draft-ietf-pkix-2797-bis-07] (92 pages) - An Internet Attribute Certificate Profile for Authorization [draft-ietf-pkix-3281update-05] (48 pages) - An Internet Attribute Certificate Profile for Authorization [draft-ietf-pkix-ac509prof-09] (39 pages) - Attribute Certificate Management Messages over CMS [draft-ietf-pkix-acmc-01] (10 pages) - Attribute Certificate (AC) Policies Extension [draft-ietf-pkix-acpolicies-extn-08] (10 pages) - Attribute Certificate Request Message Format [draft-ietf-pkix-acrmf-01] (8 pages) - Architecture for Public-Key Infrastructure [draft-ietf-pkix-apki-00] (43 pages) - ASN.1 Translation [draft-ietf-pkix-asn1-translation-03] (24 pages) - The application/pkix-attr-cert Media Type for Attribute Certificates [draft-ietf-pkix-attr-cert-mime-type-03] (4 pages) - Clearance Attribute and Authority Clearance Constraints Certificate Extension [draft-ietf-pkix-authorityclearanceconstraints-03] (20 pages) - Basic Event Representation Token v1 [draft-ietf-pkix-bert1-01] (39 pages) - DNS Certification Authority Authorization (CAA) Resource Record [draft-ietf-pkix-caa-07] (16 pages) - Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile [draft-ietf-pkix-cert-utf8-03] (6 pages) - Syntaxes for Unambiguous Identification of Certificates and Public Keys [draft-ietf-pkix-certid-keyid-01] (9 pages) - Internet X.509 Public Key Infrastructure -- Certificate Image [draft-ietf-pkix-certimage-11] (14 pages) - Internet X.509 Public Key Infrastructure: Certification Path Building [draft-ietf-pkix-certpathbuild-05] (77 pages) - Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP [draft-ietf-pkix-certstore-http-09] (0 pages) - Certificate Management Messages over CMS [draft-ietf-pkix-cmc-05] (39 pages) - CMC Extensions: Server Side Key Generation and Key Escrow [draft-ietf-pkix-cmc-archive-01] (24 pages) - Certificate Management Messages over CMS (CMC): Compliance Requirements [draft-ietf-pkix-cmc-compl-05] (22 pages) - CMC Extensions: Server Key Generation [draft-ietf-pkix-cmc-serverkeygeneration-00] (22 pages) - Certificate Management over CMS (CMC): Transport Protocols [draft-ietf-pkix-cmc-trans-08] (7 pages) - Internet X.509 Public Key Infrastructure Certificate Management Message Formats [draft-ietf-pkix-cmmf-02] (19 pages) - Using HTTP as a Transport Protocol for CMP [draft-ietf-pkix-cmp-http-00] (0 pages) - Using TCP as a Transport Protocol for CMP [draft-ietf-pkix-cmp-tcp-00] (0 pages) - Internet X.509 Public Key Infrastructure -- HTTP Transport for CMP [draft-ietf-pkix-cmp-transport-protocols-18] (15 pages) - Cryptographic Message Syntax (CMS) Content Constraints X.509 Certificate Extension [draft-ietf-pkix-cms-content-constraints-00] (31 pages) - Internet X.509 Public Key Infrastructure Authority Information Access Certificate Revocation List (CRL) Extension [draft-ietf-pkix-crlaia-03] (8 pages) - Internet X.509 Certificate Request Message Format [draft-ietf-pkix-crmf-01] (20 pages) - Certificate Validation Protocol [draft-ietf-pkix-cvp-02] (31 pages) - Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols [draft-ietf-pkix-dcs-07] (48 pages) - Diffie-Hellman Proof-of-Possession Algorithms [draft-ietf-pkix-dhpop-03] (20 pages) - LDAPv3 DN strings for use with PKIs [draft-ietf-pkix-dnstrings-02] (0 pages) - Delegated Path Validation and Delegated Path Discovery Protocols [draft-ietf-pkix-dpv-dpd-00] (22 pages) - Delegated Path Validation and Delegated Path Discovery Protocol Requirements [draft-ietf-pkix-dpv-dpd-req-05] (13 pages) - Delegated Signature Validation Delegated Path Validation and Delegated Path Discovery Protocol Requirements [draft-ietf-pkix-dsv-dpv-dpd-req-00] (16 pages) - Delegated Signature Validation Protocol Requirements (DSV-REQ) [draft-ietf-pkix-dsv-req-00] (12 pages) - Internationalized Email Addresses in X.509 certificates [draft-ietf-pkix-eai-addresses-00] (5 pages) - NIST Recommended EC Domain Parameters For PKIX [draft-ietf-pkix-ecc-nist-recommended-curves-00] (5 pages) - Additional Algorithms and Identifiers for use of Elliptic Curve Cryptography with PKIX [draft-ietf-pkix-ecc-pkalgs-03] (21 pages) - Elliptic Curve Cryptography Subject Public Key Information [draft-ietf-pkix-ecc-subpubkeyinfo-11] (22 pages) - Enrollment over Secure Transport [draft-ietf-pkix-est-01] (31 pages) - Internet X.509 Public Key Infrastructure Extending trust in non repudiation tokens in time [draft-ietf-pkix-extend-trust-non-repudiation-token-00] (7 pages) - A String Representation of General Name [draft-ietf-pkix-generalname-00] (0 pages) - Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile [draft-ietf-pkix-gost-cppk-05] (19 pages) - Internet X.509 Public Key Infrastructure Impersonation Certificate Profile [draft-ietf-pkix-impersonation-00] (26 pages) - Internet Public Key Infrastructure [draft-ietf-pkix-ipki-00] (40 pages) - Internet X.509 Public Key Infrastructure Representation of Elliptic Curve Digital Signature Algorithm (ECDSA) Keys and Signatures in Internet X.509 Public Key Infrastructure Certificates [draft-ietf-pkix-ipki-ecdsa-02] (15 pages) - Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates [draft-ietf-pkix-ipki-kea-02] (10 pages) - Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework [draft-ietf-pkix-ipki-new-rfc2527-02] (81 pages) - Internet X.509 Public Key Infrastructure Certificate and CRL Profile [draft-ietf-pkix-ipki-part1-11] (128 pages) - Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework [draft-ietf-pkix-ipki-part4-03] (45 pages) - Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile [draft-ietf-pkix-ipki-pkalgs-05] (27 pages) - Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2 [draft-ietf-pkix-ipki2opp-08] (12 pages) - Internet X.509 Public Key Infrastructure Certificate Management Protocols [draft-ietf-pkix-ipki3cmp-09] (67 pages) - Internet Public Key Infrastructure Part V: Time Stamp Protocols [draft-ietf-pkix-ipki5tsp-00] (6 pages) - Internet Public Key Infrastructure [draft-ietf-pkix-ipki6np-00] (9 pages) - Limited AttributeCertificate Acquisition Protocol [draft-ietf-pkix-laap-01] (13 pages) - Internet X.509 Public Key Infrastructure LDAP Schema for X.509 Attribute Certificates [draft-ietf-pkix-ldap-ac-schema-02] (0 pages) - Internet X.509 Public Key Infrastructure LDAP Schema for X.509 CRLs [draft-ietf-pkix-ldap-crl-schema-03] (0 pages) - Internet X.509 Public Key Infrastructure Lightweight Directory Access Protocol Schema for X.509 Certificates [draft-ietf-pkix-ldap-pkc-schema-01] (32 pages) - Internet X.509 Public Key Infrastructure LDAP Schema and Syntaxes for PKIs [draft-ietf-pkix-ldap-pki-schema-00] (0 pages) - Internet X.509 Public Key Infrastructure LDAP Schema and Syntaxes for PMIs [draft-ietf-pkix-ldap-pmi-schema-00] (0 pages) - Internet X.509 Public Key Infrastructure Additional LDAP Schema for PKIs and PMIs [draft-ietf-pkix-ldap-schema-02] (19 pages) - Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv3 [draft-ietf-pkix-ldap-v3-05] (0 pages) - Internet X.509 Public Key Infrastructure LDAPv2 Schema [draft-ietf-pkix-ldapv2-schema-02] (7 pages) - The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments [draft-ietf-pkix-lightweight-ocsp-profile-11] (21 pages) - Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates [draft-ietf-pkix-logotypes-13] (23 pages) - New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX) [draft-ietf-pkix-new-asn1-08] (122 pages) - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile [draft-ietf-pkix-new-part1-12] (129 pages) - Update for Appendix A in draft-ietf-pkix-new-part1-12.txt [draft-ietf-pkix-new-part1-asn1-01] (24 pages) - Update for Section 3 in draft-ietf-pkix-ipki-pkalgs-05.txt [draft-ietf-pkix-new-pkalgs-asn1-01] (8 pages) - Internet X.509 Public Key Infrastructure ENHANCED CRL DISTRIBUTION OPTIONS [draft-ietf-pkix-ocdp-01] (6 pages) - X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP [draft-ietf-pkix-ocsp-08] (21 pages) - Internet Public Key Infrastructure Caching the Online Certificate Status Protocol [draft-ietf-pkix-ocsp-caching-00] (27 pages) - DPV and DPD over OCSP [draft-ietf-pkix-ocsp-dpvdpd-00] (8 pages) - Delegated Path Discovery with OCSP [draft-ietf-pkix-ocsp-path-00] (11 pages) - Delegated Path Validation [draft-ietf-pkix-ocsp-valid-00] (3 pages) - Online Certificate Status Protocol Algorithm Agility [draft-ietf-pkix-ocspagility-11] (12 pages) - Online Certificate Status Protocol, version 2 [draft-ietf-pkix-ocspv2-02] (23 pages) - X.509 Internet Public Key Infrastructure Online Certificate Status Protocol, version 2 [draft-ietf-pkix-ocspv2-ext-01] (31 pages) - OCSP Extensions [draft-ietf-pkix-ocspx-00] (0 pages) - Out-of-Band Certificate and Key Identifier Protocol (OCKID) [draft-ietf-pkix-okid-01] (0 pages) - Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP [draft-ietf-pkix-opp-ftp-http-04] (7 pages) - Other Certificates Extension [draft-ietf-pkix-other-certs-05] (9 pages) - Internet X.509 Public Key Infrastructure Permanent Identifier [draft-ietf-pkix-pi-11] (14 pages) - Supplemental Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and CRL Profile [draft-ietf-pkix-pkalgs-supp-01] (23 pages) - Internet X.509 Public Key Infrastructure Repository Locator Service [draft-ietf-pkix-pkixrep-04] (5 pages) - Policy Requirements for Time-Stamping Authorities (TSAs) [draft-ietf-pkix-pr-tsa-05] (40 pages) - Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile [draft-ietf-pkix-proxy-10] (48 pages) - PKI Resource Query Protocol (PRQP) [draft-ietf-pkix-prqp-04] (38 pages) - S/MIME Capabilities for Public Key Definitions [draft-ietf-pkix-pubkey-caps-06] (25 pages) - Internet X.509 Public Key Infrastructure Qualified Certificates Profile [draft-ietf-pkix-qc-05] (33 pages) - Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP) [draft-ietf-pkix-rfc2510bis-09] (104 pages) - Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) [draft-ietf-pkix-rfc2511bis-09] (33 pages) - X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP [draft-ietf-pkix-rfc2560bis-04] (43 pages) - Certificate Management Messages over CMS [draft-ietf-pkix-rfc2797-bis-01] (0 pages) - ESSCertIDv2 Update for RFC 3161 [draft-ietf-pkix-rfc3161-update-09] (8 pages) - Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) [draft-ietf-pkix-rfc3161bis-01] (30 pages) - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile [draft-ietf-pkix-rfc3280bis-11] (145 pages) - Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN) [draft-ietf-pkix-rfc3770bis-03] (11 pages) - Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters [draft-ietf-pkix-rfc4055-update-02] (7 pages) - Certificate Management over CMS (CMC) Updates [draft-ietf-pkix-rfc5272-bis-08] (40 pages) - Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile [draft-ietf-pkix-rfc5280-clarifications-04] (7 pages) - Internet X.509 Public Key Infrastructure:Roadmap [draft-ietf-pkix-roadmap-09] (55 pages) - Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile [draft-ietf-pkix-rsa-pkalgs-03] (23 pages) - Subject Certificate Access Extension [draft-ietf-pkix-sca-00] (0 pages) - Server-Based Certificate Validation Protocol (SCVP) [draft-ietf-pkix-scvp-33] (86 pages) - Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA [draft-ietf-pkix-sha2-dsa-ecdsa-10] (8 pages) - A 224-bit One-way Hash Function: SHA-224 [draft-ietf-pkix-sha224-01] (7 pages) - A 224-bit One-way Hash Function: SHA-224 [draft-ietf-pkix-sha244-02] (6 pages) - Internet X.509 Public Key Infrastructure Subject Identification Method (SIM) [draft-ietf-pkix-sim-08] (19 pages) - Internet X.509 Public Key Infrastructure: Qualified Certificates Profile [draft-ietf-pkix-sonof3039-06] (34 pages) - Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name [draft-ietf-pkix-srvsan-05] (12 pages) - Trust Anchor Format [draft-ietf-pkix-ta-format-04] (19 pages) - Trust Anchor Management Problem Statement [draft-ietf-pkix-ta-mgmt-problem-statement-01] (15 pages) - Trust Anchor Management Requirements [draft-ietf-pkix-ta-mgmt-reqs-06] (18 pages) - Traceable Anonymous Certificate [draft-ietf-pkix-tac-04] (32 pages) - Trust Anchor Management Protocol (TAMP) [draft-ietf-pkix-tamp-08] (98 pages) - Trusted Archive Protocol (TAP) [draft-ietf-pkix-tap-00] (34 pages) - Internet X.509 Public Key Infrastructure Technical Requirements for a non-Repudiation Service [draft-ietf-pkix-technr-03] (8 pages) - Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) [draft-ietf-pkix-time-stamp-15] (26 pages) - The PKIX UserGroupName GeneralName Type [draft-ietf-pkix-usergroup-01] (14 pages) - Internet X.509 Public Key Infrastructure Warranty Certificate Extension [draft-ietf-pkix-warranty-extn-04] (8 pages) - WEB based Certificate Access Protocol-- WebCAP/1.0 [draft-ietf-pkix-webcap-00] (26 pages) - Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN) [draft-ietf-pkix-wlan-extns-05] (9 pages) - X.509 Extensions for IP Addresses and AS Identifiers [draft-ietf-pkix-x509-ipaddr-as-extn-03] (30 pages) Requests for Comments: RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile (128 pages) * Obsoletes RFC3280 RFC2510: Internet X.509 Public Key Infrastructure Certificate Management Protocols (67 pages) * Obsoletes RFC4210 RFC2511: Internet X.509 Certificate Request Message Format (20 pages) * Obsoletes RFC4211 RFC2527: Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework (45 pages) * Obsoletes RFC3647 RFC2528: Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates (10 pages) RFC2559: Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2 (12 pages) * Updates RFC1778 * Obsoletes RFC3494 RFC2560: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP (21 pages) * Updates RFC6277 RFC2585: Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP (7 pages) RFC2587: Internet X.509 Public Key Infrastructure LDAPv2 Schema (7 pages) * Obsoletes RFC4523 RFC2797: Certificate Management Messages over CMS (39 pages) * Obsoletes RFC5272 RFC2875: Diffie-Hellman Proof-of-Possession Algorithms (20 pages) RFC3029: Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols (48 pages) RFC3039: Internet X.509 Public Key Infrastructure Qualified Certificates Profile (33 pages) * Obsoletes RFC3739 RFC3161: Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) (26 pages) * Updates RFC5816 RFC3279: Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (27 pages) * Updates RFC4055 * Updates RFC4491 * Updates RFC5480 * Updates RFC5758 RFC3280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (129 pages) * Obsoletes RFC2459 * Obsoletes RFC5280 * Updates RFC4325 * Updates RFC4630 RFC3281: An Internet Attribute Certificate Profile for Authorization (39 pages) * Obsoletes RFC5755 RFC3379: Delegated Path Validation and Delegated Path Discovery Protocol Requirements (13 pages) RFC3628: Policy Requirements for Time-Stamping Authorities (TSAs) (40 pages) RFC3647: Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework (81 pages) * Obsoletes RFC2527 RFC3709: Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates (23 pages) * Updates RFC6170 RFC3739: Internet X.509 Public Key Infrastructure: Qualified Certificates Profile (34 pages) * Obsoletes RFC3039 RFC3770: Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN) (9 pages) * Obsoletes RFC4334 RFC3779: X.509 Extensions for IP Addresses and AS Identifiers (30 pages) RFC3820: Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile (48 pages) RFC3874: A 224-bit One-way Hash Function: SHA-224 (7 pages) RFC4043: Internet X.509 Public Key Infrastructure Permanent Identifier (14 pages) RFC4055: Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (23 pages) * Updates RFC3279 * Updates RFC5756 RFC4059: Internet X.509 Public Key Infrastructure Warranty Certificate Extension (8 pages) RFC4158: Internet X.509 Public Key Infrastructure: Certification Path Building (77 pages) RFC4210: Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP) (104 pages) * Obsoletes RFC2510 RFC4211: Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) (33 pages) * Obsoletes RFC2511 RFC4325: Internet X.509 Public Key Infrastructure Authority Information Access Certificate Revocation List (CRL) Extension (8 pages) * Updates RFC3280 * Obsoletes RFC5280 RFC4334: Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN) (11 pages) * Obsoletes RFC3770 RFC4386: Internet X.509 Public Key Infrastructure Repository Locator Service (5 pages) RFC4387: Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP (0 pages) RFC4476: Attribute Certificate (AC) Policies Extension (10 pages) RFC4491: Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile (19 pages) * Updates RFC3279 RFC4630: Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (6 pages) * Updates RFC3280 * Obsoletes RFC5280 RFC4683: Internet X.509 Public Key Infrastructure Subject Identification Method (SIM) (19 pages) RFC4985: Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name (12 pages) RFC5019: The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments (21 pages) RFC5055: Server-Based Certificate Validation Protocol (SCVP) (86 pages) RFC5272: Certificate Management over CMS (CMC) (92 pages) * Obsoletes RFC2797 * Updates RFC6402 RFC5273: Certificate Management over CMS (CMC): Transport Protocols (7 pages) * Updates RFC6402 RFC5274: Certificate Management Messages over CMS (CMC): Compliance Requirements (22 pages) * Updates RFC6402 RFC5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (145 pages) * Obsoletes RFC3280 * Obsoletes RFC4325 * Obsoletes RFC4630 RFC5480: Elliptic Curve Cryptography Subject Public Key Information (22 pages) * Updates RFC3279 RFC5636: Traceable Anonymous Certificate (32 pages) RFC5697: Other Certificates Extension (9 pages) * Replaces DRAFT-FARRELL-PKIX-OTHER-CERTS RFC5755: An Internet Attribute Certificate Profile for Authorization (48 pages) * Obsoletes RFC3281 RFC5756: Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters (7 pages) * Updates RFC4055 RFC5758: Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA (8 pages) * Updates RFC3279 RFC5816: ESSCertIDv2 Update for RFC 3161 (8 pages) * Updates RFC3161 RFC5877: The application/pkix-attr-cert Media Type for Attribute Certificates (4 pages) RFC5912: New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX) (122 pages) * Replaces DRAFT-HOFFMAN-PKIX-NEW-ASN1 RFC5913: Clearance Attribute and Authority Clearance Constraints Certificate Extension (20 pages) * Replaces DRAFT-TURNER-CACLEARANCECONSTRAINTS RFC5914: Trust Anchor Format (19 pages) RFC5934: Trust Anchor Management Protocol (TAMP) (98 pages) RFC6024: Trust Anchor Management Requirements (18 pages) RFC6025: ASN.1 Translation (24 pages) RFC6170: Internet X.509 Public Key Infrastructure -- Certificate Image (14 pages) * Updates RFC3709 RFC6277: Online Certificate Status Protocol Algorithm Agility (12 pages) * Updates RFC2560 RFC6402: Certificate Management over CMS (CMC) Updates (40 pages) * Updates RFC5272 * Updates RFC5273 * Updates RFC5274 Transport Layer Security (tls) ------------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Eric Rescorla Joseph A. Salowey Eric Rescorla Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Sean Turner Tech Advisor: Allison Mankin Mailing Lists: General Discussion: tls@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tls Archive: http://www.ietf.org/mail-archive/web/tls/ Description of Working Group: The TLS Working Group was established in 1996 to standardize a 'transport layer' security protocol. The working group began with SSL version 3.0. The TLS Working Group has completed a series of specifications that describe the Transport Layer Security protocol versions 1.0, 1.1, and 1.2, extensions to the protocol, and new ciphersuites to be used with TLS. The primary goals of the WG are to maintain: - The TLS protocol, RFC 5246; - The DTLS protocol, draft-ietf-tls-rfc4347-bis. Significant changes to the protocol, such as a new version 1.3, are not within scope of the working group unless they are explicitly added to the charter. The secondary goals of the WG are to publish: - Guidelines for Specifying the Use of TLS/DTLS; - Recommendations for use of TLS (e.g., server ID); - Extensions to TLS and DTLS; and, - Cipher suites. Goals and Milestones: Done - Agreement on charter and issues in current draft. Done - Final draft for Secure Transport Layer Protocol ('STLP') Done - Working group 'Last Call' Done - Submit to IESG for consideration as a Proposed Standard. Done - First revised draft of TLS specification Done - TSL 1.1 Specification Done - First draft of TLS 1.2 specification, including CTR mode cipher suites Done - First draft of specification for cipher suites with combined encryption/authentication modes Dec 2011 - Heartbeat Extension Sent to IESG Internet-Drafts: - 56-bit Export Cipher Suites For TLS [draft-ietf-tls-56-bit-ciphersuites-01] (3 pages) - An Internet AttributeCertificate Profile for Authorization [draft-ietf-tls-ac509prof-00] (11 pages) - TLS extensions for AttributeCertificate based authorization [draft-ietf-tls-attr-cert-01] (11 pages) - Transport Layer Security (TLS) Cached Information Extension [draft-ietf-tls-cached-info-11] (14 pages) - Addition of Camellia Cipher Suites to Transport Layer Security (TLS) [draft-ietf-tls-camellia-06] (6 pages) - Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS) [draft-ietf-tls-ciphersuite-06] (6 pages) - Transport Layer Security Protocol Compression Methods [draft-ietf-tls-compression-07] (9 pages) - AES Counter Mode Cipher Suites for TLS and DTLS [draft-ietf-tls-ctr-01] (10 pages) - TLS Delegation Protocol [draft-ietf-tls-delegation-01] (10 pages) - DES and IDEA Cipher Suites for Transport Layer Security (TLS) [draft-ietf-tls-des-idea-02] (6 pages) - Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension [draft-ietf-tls-dtls-heartbeat-04] (9 pages) - Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) [draft-ietf-tls-ecc-12] (38 pages) - TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM) [draft-ietf-tls-ecc-new-mac-07] (6 pages) - ECDHE_PSK Cipher Suites for Transport Layer Security (TLS) [draft-ietf-tls-ecdhe-psk-05] (8 pages) - Update to Transport Layer Security (TLS) Extensions [draft-ietf-tls-emailaddr-00] (4 pages) - Transport Layer Security (TLS) Extensions [draft-ietf-tls-extensions-06] (26 pages) - Keying Material Exporters for Transport Layer Security (TLS) [draft-ietf-tls-extractor-07] (8 pages) - Upgrading to TLS Within HTTP/1.1 [draft-ietf-tls-http-upgrade-05] (13 pages) - HTTP Over TLS [draft-ietf-tls-https-03] (6 pages) - Clientside interoperability experiences for the SSL and TLS protocols [draft-ietf-tls-interoperability-00] (30 pages) - Kerberos Cipher Suites in Transport Layer Security (TLS) [draft-ietf-tls-kerb-01] (0 pages) - Addition of Kerberos Cipher Suites to Transport Layer Security (TLS) [draft-ietf-tls-kerb-cipher-suites-04] (4 pages) - Addition of MISTY1 to TLS [draft-ietf-tls-misty1-01] (3 pages) - The TLS Multiple Certificate Status Request Extension [draft-ietf-tls-multiple-cert-status-extension-00] (9 pages) - NTRU Cipher Suites for TLS [draft-ietf-tls-ntru-00] (15 pages) - TLS Out-of-Band Public Key Validation [draft-ietf-tls-oob-pubkey-03] (10 pages) - Extensions to TLS for OpenPGP keys [draft-ietf-tls-openpgp-02] (4 pages) - Using OpenPGP Keys for Transport Layer Security (TLS) Authentication [draft-ietf-tls-openpgp-keys-11] (13 pages) - Addition of Shared Key Authentication to Transport Layer Security (TLS) [draft-ietf-tls-passauth-00] (5 pages) - TLS Pathsec Protocol [draft-ietf-tls-pathsec-00] (50 pages) - The TLS Protocol Version 1.0 [draft-ietf-tls-protocol-06] (72 pages) - Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) [draft-ietf-tls-psk-09] (19 pages) - Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode [draft-ietf-tls-psk-new-mac-aes-gcm-05] (9 pages) - Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS) [draft-ietf-tls-psk-null-03] (5 pages) - Transport Layer Security (TLS) Renegotiation Indication Extension [draft-ietf-tls-renegotiation-03] (14 pages) - The Transport Layer Security (TLS) Protocol Version 1.1 [draft-ietf-tls-rfc2246-bis-13] (91 pages) - Transport Layer Security (TLS) Extensions [draft-ietf-tls-rfc3546bis-02] (29 pages) - The Transport Layer Security (TLS) Protocol Version 1.2 [draft-ietf-tls-rfc4346-bis-10] (101 pages) - Datagram Transport Layer Security Version 1.2 [draft-ietf-tls-rfc4347-bis-06] (33 pages) - Transport Layer Security (TLS) Extensions: Extension Definitions [draft-ietf-tls-rfc4366-bis-12] (29 pages) - AES Galois Counter Mode (GCM) Cipher Suites for TLS [draft-ietf-tls-rsa-aes-gcm-03] (8 pages) - TLS Extension for SEED and HAS-160 [draft-ietf-tls-seedhas-00] (4 pages) - Use of Shared Keys in the TLS Protocol [draft-ietf-tls-sharedkeys-02] (6 pages) - Using the Secure Remote Password (SRP) Protocol for TLS Authentication [draft-ietf-tls-srp-14] (26 pages) - SSH Transport Layer Protocol [draft-ietf-tls-ssh-00] (19 pages) - Modifications to the SSL protocol for TLS [draft-ietf-tls-ssl-mods-00] (4 pages) - The SSL Protocol Version 3.0 [draft-ietf-tls-ssl-version3-00] (63 pages) - Prohibiting Secure Sockets Layer (SSL) Version 2.0 [draft-ietf-tls-ssl2-must-not-04] (5 pages) - Suite B Cipher Suites for TLS [draft-ietf-tls-suiteb-00] (8 pages) - Wireless Extensions to TLS [draft-ietf-tls-wireless-00] (13 pages) Requests for Comments: RFC2246: The TLS Protocol Version 1.0 (72 pages) * Obsoletes RFC4346 * Updates RFC3546 * Updates RFC5746 * Updates RFC6176 RFC2712: Addition of Kerberos Cipher Suites to Transport Layer Security (TLS) (4 pages) RFC2817: Upgrading to TLS Within HTTP/1.1 (13 pages) * Updates RFC2616 RFC2818: HTTP Over TLS (6 pages) * Updates RFC5785 RFC3268: Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS) (6 pages) * Obsoletes RFC5246 RFC3546: Transport Layer Security (TLS) Extensions (26 pages) * Updates RFC2246 * Obsoletes RFC4366 RFC3749: Transport Layer Security Protocol Compression Methods (9 pages) RFC4132: Addition of Camellia Cipher Suites to Transport Layer Security (TLS) (6 pages) * Obsoletes RFC5932 RFC4279: Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) (19 pages) * Replaces DRAFT-ERONEN-TLS-PSK RFC4346: The Transport Layer Security (TLS) Protocol Version 1.1 (91 pages) * Obsoletes RFC2246 * Obsoletes RFC5246 * Updates RFC4366 * Updates RFC4680 * Updates RFC4681 * Updates RFC5746 * Updates RFC6176 RFC4366: Transport Layer Security (TLS) Extensions (29 pages) * Obsoletes RFC3546 * Updates RFC4346 * Obsoletes RFC5246 * Obsoletes RFC6066 * Updates RFC5746 RFC4492: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) (38 pages) * Updates RFC5246 RFC4785: Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS) (5 pages) RFC5054: Using the Secure Remote Password (SRP) Protocol for TLS Authentication (26 pages) RFC5081: Using OpenPGP Keys for Transport Layer Security (TLS) Authentication (13 pages) * Obsoletes RFC6091 RFC5246: The Transport Layer Security (TLS) Protocol Version 1.2 (101 pages) * Obsoletes RFC3268 * Obsoletes RFC4346 * Obsoletes RFC4366 * Updates RFC4492 * Updates RFC5746 * Updates RFC5878 * Updates RFC6176 RFC5288: AES Galois Counter Mode (GCM) Cipher Suites for TLS (8 pages) * Replaces DRAFT-SALOWEY-TLS-RSA-AES-GCM RFC5289: TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM) (6 pages) RFC5469: DES and IDEA Cipher Suites for Transport Layer Security (TLS) (6 pages) RFC5487: Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode (9 pages) * Replaces DRAFT-BADRA-TLS-PSK-NEW-MAC-AES-GCM RFC5489: ECDHE_PSK Cipher Suites for Transport Layer Security (TLS) (8 pages) * Replaces DRAFT-BADRA-ECDHE-TLS-PSK RFC5705: Keying Material Exporters for Transport Layer Security (TLS) (8 pages) * Replaces DRAFT-RESCORLA-TLS-EXTRACTOR RFC5746: Transport Layer Security (TLS) Renegotiation Indication Extension (14 pages) * Replaces DRAFT-RESCORLA-TLS-RENEGOTIATION * Updates RFC2246 * Updates RFC4346 * Updates RFC4347 * Updates RFC4366 * Updates RFC5246 RFC6066: Transport Layer Security (TLS) Extensions: Extension Definitions (29 pages) * Obsoletes RFC4366 RFC6176: Prohibiting Secure Sockets Layer (SSL) Version 2.0 (5 pages) * Replaces DRAFT-TURNER-SSL-MUST-NOT * Updates RFC2246 * Updates RFC4346 * Updates RFC5246 RFC6347: Datagram Transport Layer Security Version 1.2 (33 pages) * Obsoletes RFC4347 RFC6520: Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension (9 pages) Web Authorization Protocol (oauth) ---------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Hannes Tschofenig Derek Atkins Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Stephen Farrell Tech Advisor: Peter Saint-Andre Mailing Lists: General Discussion: oauth@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/oauth Archive: http://www.ietf.org/mail-archive/web/oauth/ Description of Working Group: The Web Authorization (OAuth) protocol allows a user to grant a third-party Web site or application access to the user's protected resources, without necessarily revealing their long-term credentials, or even their identity. For example, a photo-sharing site that supports OAuth could allow its users to use a third-party printing Web site to print their private pictures, without allowing the printing site to gain full control of the user's account. OAuth encompasses * a mechanism for a user to authorize issuance of credentials that a third party can use to access resources on the user's behalf and * a mechanism for using the issued credentials to authenticate HTTP requests. In April 2010 the OAuth 1.0 specification, documenting pre-IETF work, was published as an informational document (RFC 5849). The working group has since been developing OAuth 2.0, a standards-track version that will reflect IETF consensus. Version 2.0 will consider the implementation experience with version 1.0, a discovered security vulnerability (session fixation attack), the use cases and functionality proposed with OAuth WRAP [draft-hardt-oauth-01] and will * improve the terminology used, * consider broader use cases, * embody good security practices, * improve interoperability, and * provide guidelines for extensibility. The working group will develop authentication schemes for peers/servers taking part in OAuth (accessing protected resources). This includes * an HMAC-based authentication mechanism This document aims to provide a general purpose MAC authentication scheme that can be used both with OAuth 2.0 but also with other use cases. The WG will work with the security and applications area directors to ensure that this work gets appropriate review, e.g. via additional last calls in other relevant working groups such as HTTPBIS, * a specification for access protected by Transport Layer Security (bearer tokens), * an extension to OAuth 2.0 to allow access tokens to be requested when a client is in possession of a SAML assertion. A separate informational description will be produced to provide additional security analysis for audiences beyond the community of protocol implementers. Milestones will be added for the later items after the near-term work has been completed. Goals and Milestones: Done - Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item Done - Submit 'HTTP Authentication: MAC Authentication' as a working group item Jul 2011 - Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard Done - Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard Aug 2011 - Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard Oct 2011 - Submit 'SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0' to the IESG for consideration as a Proposed Standard Oct 2011 - Re-chartering working group Internet-Drafts: - OAuth 2.0 Assertion Profile [draft-ietf-oauth-assertions-03] (17 pages) - The OAuth Protocol: Authentication [draft-ietf-oauth-authentication-01] (21 pages) - SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 [draft-ietf-oauth-saml2-bearer-12] (16 pages) - An IETF URN Sub-Namespace for OAuth [draft-ietf-oauth-urn-sub-ns-02] (5 pages) - The OAuth 2.0 Authorization Framework [draft-ietf-oauth-v2-26] (66 pages) - The OAuth 2.0 Authorization Protocol: Bearer Tokens [draft-ietf-oauth-v2-bearer-19] (24 pages) - HTTP Authentication: MAC Access Authentication [draft-ietf-oauth-v2-http-mac-01] (20 pages) - OAuth 2.0 Threat Model and Security Considerations [draft-ietf-oauth-v2-threatmodel-02] (65 pages) - The OAuth Protocol: Web Delegation [draft-ietf-oauth-web-delegation-01] (18 pages) No Requests for Comments Application-Layer Traffic Optimization (alto) --------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Enrico Marocco Vijay K. Gurbani Transport Area Directors: Wesley Eddy Martin Stiemerling Transport Area Advisor: Martin Stiemerling Tech Advisor: Peter Saint-Andre Mailing Lists: General Discussion: alto@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/alto Archive: http://www.ietf.org/mail-archive/web/alto/ Description of Working Group: A significant part of the Internet traffic today is generated by peer-to-peer (P2P) applications used for file sharing, real-time communications, and live media streaming. P2P applications exchange large amounts of data, often uploading as much as downloading. In contrast to client/server architectures, P2P applications often must choose one or more suitable candidates from a selection of peers offering the same resource or service. One of the advantages of P2P systems comes from redundancy in resource availability. This requires choosing among a list of peers, yet applications have at best incomplete information to help the selection, e.g., topology of the network. Applications can sometimes obtain network information dynamically or measure link performance with respect to particular peers, but even when this is an option it takes time. The application cannot always start out with an optimal arrangement of peers, thus risking at least temporary poor performance and excessive cross-domain traffic. Providing more information for use in peer selection can improve P2P performance and lower ISP costs. The Working Group will design and specify an Application-Layer Traffic Optimization (ALTO) service that will provide applications with information to perform better-than-random initial peer selection. ALTO services may take different approaches at balancing factors such as maximum bandwidth, minimum cross-domain traffic, lowest cost to the user, etc. The WG will consider the needs of BitTorrent, tracker-less P2P, and other applications, such as content delivery networks (CDN) and mirror selection. The WG will focus on the following items: - A "problem statement" document providing a description of the problem and a common terminology. - A requirements document. This document will list requirements for the ALTO service, identifying, for example, types of information P2P applications may need for optimizing their choices. - A request/response protocol for querying the ALTO service to obtain information useful for peer selection, and a format for requests and responses. If the requirements analysis identifies the need to allow clients to delegate third-parties to query the ALTO service on their behalf, the WG will ensure that the protocol provides a mechanism to assert the consent of the delegating client. - A specification of core request and response formats and semantics to communicate network preferences to applications. Since ALTO services may be run by entities with different levels of knowledge about the underlying network, such preferences may have different representations. Initially the WG will consider: IP ranges to prefer and to avoid, ranked lists of the peers requested by the client, information about topological proximity and approximate geographic locations. Other usages will be considered as charter additions once the work for the initial services has been completed. - In order to query the ALTO server, clients must first know one or more ALTO servers that might provide useful information. The WG will look at service discovery mechanisms that are in use, or defined elsewhere (e.g. based on DNS SRV records or DHCP options). If such discovery mechanisms can be reused, the WG will produce a document to specify how they may be adopted for locating such servers. However, a new, general-purpose service discovery mechanism is not in scope. - An informational document discussing deployment related issues and documenting lessons learned from early implementation experiences. When the WG considers standardizing information that the ALTO server could provide, the following criteria are important to ensure real feasibility: - Can the ALTO service realistically discover that information? - Is the distribution of that information allowed by the operators of that service? - Is it information that a client will find useful? - Can a client get that information without excessive privacy concerns (e.g. by sending large lists of peers)? - Is it information that a client cannot find easily some other way? After these criteria are met, the importance of the data will be considered for prioritizing standardization work, for example the number of operators and clients that are likely to be able to provide or use that particular data. In any case, this WG will not propose standards on how congestion is signaled, remediated, or avoided, and will not deal with information representing instantaneous network state. Such issues belong to other IETF areas and will be treated accordingly by the specific area. This WG will focus solely on the communication protocol between applications and ALTO servers. Note that ALTO services may be useful in client-server environments as well as P2P environments, although P2P environments are the first focus. If, in the future, the IETF considers changes to other protocols for actually implementing ALTO services (e.g. application-layer protocols for Internet coordinate systems, routing protocol extensions for ISP-based solutions), such work will be done in strict coordination with the appropriate WGs. Issues related to the content exchanged in P2P systems are also excluded from the WG's scope, as is the issue dealing with enforcing the legality of the content. Goals and Milestones: Done - Working Group Last Call for problem statement Done - Submit problem statement to IESG as Informational Jan 2011 - Working Group Last Call for requirements document Jan 2011 - Working Group Last Call for request/response protocol Mar 2011 - Submit request/response protocol to IESG as Proposed Standard Mar 2011 - Submit requirements document to IESG as Informational May 2011 - Working Group Last Call of deployment considerations document Aug 2011 - Submit deployment considerations document to IESG as Informational Nov 2011 - Working Group Last Call of discovery mechanism Feb 2012 - Submit discovery mechanism to IESG as Proposed Standard Mar 2012 - Dissolve or re-charter Internet-Drafts: - ALTO Deployment Considerations [draft-ietf-alto-deployments-04] (46 pages) - Application-Layer Traffic Optimization (ALTO) Problem Statement [draft-ietf-alto-problem-statement-04] (15 pages) - ALTO Protocol [draft-ietf-alto-protocol-11] (68 pages) - Application-Layer Traffic Optimization (ALTO) Requirements [draft-ietf-alto-reqs-14] (22 pages) - ALTO Server Discovery [draft-ietf-alto-server-discovery-03] (27 pages) Requests for Comments: RFC5693: Application-Layer Traffic Optimization (ALTO) Problem Statement (15 pages) * Replaces DRAFT-MAROCCO-ALTO-PROBLEM-STATEMENT Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- Charter Last Modified: 2012-02-17 Current Status: Active Chairs: Dan Wing Dave Thaler Transport Area Directors: Wesley Eddy Martin Stiemerling Transport Area Advisor: Wesley Eddy Mailing Lists: General Discussion: behave@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/behave Archive: http://www.ietf.org/mail-archive/web/behave Description of Working Group: The working group creates documents to enable NATs to function in as deterministic a fashion as possible. To support deployments where communicating hosts require using different address families (IPv4 or IPv6), address family translation is needed to establish communication. In BEHAVE's specification work on this topic it will coordinate with the V6ops WG on requirements and operational considerations. "An IPv4 network" or "an IPv6 network" in the descriptions below refer to a network with a clearly identifiable administrative domain (e.g., an enterprise campus network, a mobile operator's cellular network, a residential subscriber network, etc.). It will also be that network that deploys the necessary equipment for translation. BEHAVE will adopt additional work items to finish four scenarios: An IPv6 network to IPv4 Internet, IPv6 Internet to an IPv4 network, An IPv6 network to an IPv4 network, and An IPv4 network to an IPv6 network. These additional work items include suggestions to application developers to improve application interactions with those translation scenarios. The following scenario remains in scope for discussion, and new milestones can be created to address this scenario: * An IPv4 application running on an IPv6-only connected host to the IPv6 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is embedded in the IPv4 host. The following scenarios remain in scope for discussion, but creating new milestones will require re-chartering: * An IPv4 network to IPv6 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv4 network using either public or private IPv4 address space. * IPv4 Internet to an IPv6 network, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv6 network where selected IPv6 hosts and services are to be reachable. * multicast translation, including control traffic (IGMP and MLD), Single Source Multicast (SSM) and Any Source Multicast (ASM). All translation solutions shall be capable of handling flows using TCP, UDP, DCCP, and SCTP, unless they prevent a timely completion of the work item. The parts of ICMP that can be translated are also required to work across a translation solution. Additional protocols directly on top of IP may be supported. Translation mechanisms must handle IP fragmentation. Translation mechanisms cannot transparently support protocols that embed network addresses within their protocol messages without application level gateways (ALGs). Because ALGs have security issues (like blocking usage of TLS), are error prone and brittle, and hinder application development, the usage of ALGs in the defined translators should be avoided. Instead application developers will need to be aware and use mechanisms that handle the address family translation. ALGs may be considered only for the most crucial of legacy applications. Solutions may solve more than one of the cases, however timely delivery is more important than a unified solution. Goals and Milestones: Done - Submit BCP that defines unicast UDP behavioral requirements for NATs to IESG Done - Submit a BCP that defines TCP behavioral requireents for NATs to IESG Done - Submit a BCP that defines ICMP behavioral requirements for NATs to IESG Done - Submit informational that discusses current NAT traversal techniques used by applications Done - Submit BCP that defines multicast UDP Done - Submit revision of RFC 3489 to IESG behavioral requirements for NATs to IESG Done - Submit informational document for rfc3489bis test vectors Done - Submit experimental document that describes how an application can determine the type of NAT it is behind Done - Submit BCP document for DCCP NAT behavior Done - Determine relative prioritization of the four translation cases. Documented in IETF74 minutes. Done - Determine what solutions(s) and components are needed to solve each of the four cases. Create new milestones for the solution(s) and the components. Documented in IETF74 minutes. Done - Submit to IESG: relaying of a TCP bytestream (std) Done - Submit to IESG: relay protocol (std) Done - Submit to IESG: TURN-URI document (std) Done - Submit to IESG: IPv6 relay protocol (std) Done - Submit to IESG: framework for IPv6/IPv4 translation (info) Done - Submit to IESG: stateless IPv6/IPv4 translation (std) Done - Submit to IESG: stateful IPv6/IPv4 translation (std) Done - Submit to IESG: DNS rewriting for IPv6/IPv4 translation (std) Done - Submit to IESG: IPv6 prefix for IPv6/IPv4 translator (std) Done - Determine need and scope of multicast 6/4 translation Oct 2010 - Submit to IESG: FTP ALG for IPv6/IPv4 translation (std) Dec 2010 - Submit to IESG: large scale NAT requirements (BCP) Feb 2011 - Submit to IESG: Analysis of NAT-PT considerations with IPv6/IPv4 translation (info) Apr 2011 - Submit to IESG: avoiding NAT64 with dual-stack host for local networks (std) Apr 2011 - Submit to IESG: SCTP NAT behavior (BCP) Apr 2011 - Submit to IESG: NAT64 load balancing (std/info) Apr 2011 - Submit to IESG: host-based NAT46 translation for IPv4-only applications to access IPv6-only servers (std) Internet-Drafts: - Analysis of Stateful 64 Translation [draft-ietf-behave-64-analysis-07] (15 pages) - IPv6 Addressing of IPv4/IPv6 Translators [draft-ietf-behave-address-format-10] (19 pages) - Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol [draft-ietf-behave-dccp-05] (11 pages) - DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers [draft-ietf-behave-dns64-11] (32 pages) - An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation [draft-ietf-behave-ftp64-12] (17 pages) - Common requirements for Carrier Grade NATs (CGNs) [draft-ietf-behave-lsn-requirements-06] (19 pages) - IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) [draft-ietf-behave-multicast-12] (17 pages) - NAT Behavioral Requirements for Unicast UDP [draft-ietf-behave-nat-00] (24 pages) - NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN) [draft-ietf-behave-nat-behavior-discovery-08] (31 pages) - NAT Behavioral Requirements for ICMP [draft-ietf-behave-nat-icmp-12] (27 pages) - Additional Definitions of Managed Objects for Network Address Translators (NAT) [draft-ietf-behave-nat-mib-00] (17 pages) - Network Address Translation (NAT) Behavioral Requirements for Unicast UDP [draft-ietf-behave-nat-udp-08] (29 pages) - Discovery of IPv6 Prefix Used for IPv6 Address Synthesis [draft-ietf-behave-nat64-discovery-heuristic-08] (14 pages) - Analysis of solution proposals for hosts to learn NAT64 prefix [draft-ietf-behave-nat64-learn-analysis-03] (25 pages) - State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs) [draft-ietf-behave-p2p-state-06] (32 pages) - Session Traversal Utilities for NAT (STUN) [draft-ietf-behave-rfc3489bis-18] (51 pages) - Stream Control Transmission Protocol (SCTP) Network Address Translation [draft-ietf-behave-sctpnat-06] (27 pages) - Test Vectors for Session Traversal Utilities for NAT (STUN) [draft-ietf-behave-stun-test-vectors-04] (11 pages) - NAT Behavioral Requirements for TCP [draft-ietf-behave-tcp-08] (21 pages) - IPv6 Addressing of IPv4/IPv6 Translators [draft-ietf-behave-translator-addressing-00] (24 pages) - Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) [draft-ietf-behave-turn-16] (81 pages) - Traversal Using Relays around NAT (TURN) Extension for IPv6 [draft-ietf-behave-turn-ipv6-11] (15 pages) - Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations [draft-ietf-behave-turn-tcp-07] (13 pages) - Traversal Using Relays around NAT (TURN) Resolution Mechanism [draft-ietf-behave-turn-uri-10] (15 pages) - Dual-Stack Hosts Using "Bump-in-the-Host" (BIH) [draft-ietf-behave-v4v6-bih-09] (29 pages) - Framework for IPv4/IPv6 Translation [draft-ietf-behave-v6v4-framework-10] (30 pages) - IP/ICMP Translation Algorithm [draft-ietf-behave-v6v4-xlate-23] (33 pages) - Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers [draft-ietf-behave-v6v4-xlate-stateful-12] (45 pages) Requests for Comments: BCP0127: Network Address Translation (NAT) Behavioral Requirements for Unicast UDP (29 pages) * Replaces DRAFT-IETF-BEHAVE-NAT BCP0135: IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) (17 pages) * Replaces DRAFT-WING-BEHAVE-MULTICAST BCP0142: NAT Behavioral Requirements for TCP (21 pages) * Replaces DRAFT-HOFFMAN-BEHAVE-TCP BCP0148: NAT Behavioral Requirements for ICMP (27 pages) * Replaces DRAFT-SRISURESH-BEHAVE-NAT-ICMP BCP0150: Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol (11 pages) * Replaces DRAFT-DENIS-BEHAVE-NAT-DCCP RFC4787: Network Address Translation (NAT) Behavioral Requirements for Unicast UDP (29 pages) * Replaces DRAFT-IETF-BEHAVE-NAT RFC5128: State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs) (32 pages) * Replaces DRAFT-SRISURESH-BEHAVE-P2P-STATE RFC5135: IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) (17 pages) * Replaces DRAFT-WING-BEHAVE-MULTICAST RFC5382: NAT Behavioral Requirements for TCP (21 pages) * Replaces DRAFT-HOFFMAN-BEHAVE-TCP RFC5389: Session Traversal Utilities for NAT (STUN) (51 pages) * Obsoletes RFC3489 RFC5508: NAT Behavioral Requirements for ICMP (27 pages) * Replaces DRAFT-SRISURESH-BEHAVE-NAT-ICMP RFC5597: Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol (11 pages) * Replaces DRAFT-DENIS-BEHAVE-NAT-DCCP RFC5766: Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) (81 pages) * Replaces DRAFT-ROSENBERG-MIDCOM-TURN RFC5769: Test Vectors for Session Traversal Utilities for NAT (STUN) (11 pages) * Replaces DRAFT-DENIS-BEHAVE-RFC3489BIS-TEST-VECTORS RFC5780: NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN) (31 pages) * Replaces DRAFT-MACDONALD-BEHAVE-NAT-BEHAVIOR-DISCOVERY RFC5928: Traversal Using Relays around NAT (TURN) Resolution Mechanism (15 pages) * Replaces DRAFT-PETITHUGUENIN-BEHAVE-TURN-URI RFC6052: IPv6 Addressing of IPv4/IPv6 Translators (19 pages) * Replaces DRAFT-IETF-BEHAVE-TRANSLATOR-ADDRESSING * Updates RFC4291 RFC6062: Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations (13 pages) RFC6144: Framework for IPv4/IPv6 Translation (30 pages) * Replaces DRAFT-BAKER-BEHAVE-V4V6-FRAMEWORK RFC6145: IP/ICMP Translation Algorithm (33 pages) * Replaces DRAFT-BAKER-BEHAVE-V4V6-TRANSLATION * Obsoletes RFC2765 RFC6146: Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (45 pages) * Replaces DRAFT-BAGNULO-BEHAVE-NAT64 RFC6147: DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers (32 pages) * Replaces DRAFT-BAGNULO-BEHAVE-DNS64 RFC6156: Traversal Using Relays around NAT (TURN) Extension for IPv6 (15 pages) RFC6384: An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation (17 pages) * Replaces DRAFT-VAN-BEIJNUM-BEHAVE-FTP64 RFC6535: Dual-Stack Hosts Using "Bump-in-the-Host" (BIH) (29 pages) * Replaces DRAFT-HUANG-BEHAVE-BIH * Obsoletes RFC2767 * Obsoletes RFC3338 Congestion Exposure (conex) --------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Marcelo Bagnulo Nandita Dukkipati Transport Area Directors: Wesley Eddy Martin Stiemerling Transport Area Advisor: Wesley Eddy Mailing Lists: General Discussion: conex@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/conex Archive: http://www.ietf.org/mail-archive/web/conex/ Description of Working Group: The purpose of the CONEX working group is to develop a mechanism by which senders inform the network about the congestion encountered by previous packets on the same flow. Today, the network may signal congestion by ECN markings or by dropping packets, and the receiver passes this information back to the sender in transport-layer acknowledgements. The mechanism to be developed by the CONEX WG will enable the sender to also relay the congestion information back into the network in-band at the IP layer, such that the total level of congestion is visible to all IP devices along the path, from where it could, for example, be provided as input to traffic management. The primary goal of the CONEX WG is to develop experimental specifications to achieve the above in IPv6 networks. The WG will also develop an abstract, higher-level description of the congestion exposure mechanism. Primary work items are: * An Informational document containing an abstract description of the congestion exposure mechanism that is independent of specific transport protocols and congestion information encoding techniques needed for different IP protocol versions. * An Experimental specification of an IPv6 packet structure that encapsulates CONEX information, defining a packet format and an interpretation. * An Experimental specification of a modification to TCP, for the timely transport of congestion information from the destination to the sender. It is believed that the CONEX mechanism will be useful as a generative technology that can be applied as a key element of congestion management solutions in a wide variety of use cases. However, the CONEX WG will initially focus on one use case, where the end hosts and the network that contains the destination end host are CONEX-enabled but other networks need not be. CONEX information can assist the network operator's traffic management and, for example, incentivize LEDBAT-like applications. Congestion-based billing is not within the scope of the WG. Experiments on use cases are encouraged and the WG will solicit feedback from such deployments. The WG may decide to document the experience from such use cases in Informational documents, covering: * Assumptions made * Deployment considerations * Advice on how to use the CONEX mechanism as an element of a congestion management solution * Security threats and advice on mitigation approaches (detailed specifications of threat mitigation techniques are out of scope) * Descriptions of results from experiments with the use case The CONEX WG is only chartered to work on a congestion exposure mechanism for IPv6 networks. When the output of the WG has seen adoption and has proven to be useful, the WG may propose to the IESG that it should be rechartered to extend this effort. The first result of the WG is the usage scenarios document. Other documents will not be considered for publication before this first document has seen IETF consensus (but may be worked on in the WG). Goals and Milestones: Mar 2011 - Submit use case description to IESG as Informational Jul 2011 - Submit abstract specification for the congestion exposure mechanism to IESG as Informational Nov 2011 - Submit specification of IPv6 packet structure to IESG as Experimental Nov 2011 - Submit specification for modification to TCP to IESG as Experimental Internet-Drafts: - Congestion Exposure (ConEx) Concepts and Abstract Mechanism [draft-ietf-conex-abstract-mech-04] (27 pages) - ConEx Concepts and Use Cases [draft-ietf-conex-concepts-uses-04] (15 pages) - IPv6 Destination Option for Conex [draft-ietf-conex-destopt-02] (8 pages) - TCP modifications for Congestion Exposure [draft-ietf-conex-tcp-modifications-02] (14 pages) No Requests for Comments Congestion and Pre-Congestion Notification (pcn) ------------------------------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Scott O. Bradner Steven Blake Transport Area Directors: Wesley Eddy Martin Stiemerling Transport Area Advisor: Martin Stiemerling Mailing Lists: General Discussion: pcn@ietf.org To Subscribe: pcn-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/pcn/ Description of Working Group: The Congestion and Pre-Congestion Notification (PCN) working group develops mechanisms to protect the quality-of-service of established inelastic flows within a DiffServ domain when congestion is imminent or existing. These mechanisms operate at the domain boundary, based on aggregated congestion and pre-congestion information from within the domain. The focus of the WG is on developing standards for the marking behavior of the interior nodes and the encoding and transport of the congestion information. To allow for future extensions to the mechanisms and their application to new deployment scenarios, they are logically separated into several components, namely, encoding and transport along forward path from marker to egress, metering of congestion information at the egress, and transport of congestion information back to the controlling ingress. Reaction mechanisms at the boundary consist of flow admission and flow termination. Although designed to work together, flow admission and flow termination are independent mechanisms, and the use of one does not require or prevent the use of the other. The WG may produce a small number of informational documents that describe how specific quality-of-service policies for a domain can be implemented using these two mechanisms. The PCN WG will specify the following components to protect the quality-of-service of flows within a DiffServ domain: (1) a general architecture for flow admission and termination based on aggregated (pre-)congestion information (2) a specification of conditions under which interior nodes generate (pre-)congestion information (3) encoding and transport of (pre-)congestion information between the interior and domain egress (4) metering of (pre-)congestion information at the domain egress (5) encoding and transport of (pre-)congestion information between the egress and the controlling domain ingress (6) ingress node control mechanisms for flow admission or termination, based on aggregated (pre-)congestion information The WG focuses on the marking behavior and encoding and transport mechanisms needed to realize the overall PCN architecture. Standards- track protocols and mechanisms are only developed where necessary for interoperability. For other components of the architecture, the WG may document examples or provide recommended solutions in informational documents. The architecture document will be comprehensive, and include security, manageability and operational considerations. All PCN mechanisms, including transport and encoding of (pre-congestion) information, are required to cleanly integrate with existing architectures and protocols such as DiffServ and ECN. If the PCN WG requires extensions or modifications to protocols that are products of other WGs, it may motivate their need and describe requirements in informational documents; design of such extensions and modifications will take place in the appropriate WGs. The initial scope of the PCN WG is restricted by the following assumptions: (A) these components are deployed in a single DiffServ domain, where all boundary and interior nodes are PCN-enabled and trust each other for correct PCN marking, encoding, transport and aggregation (B) all flows handled by these mechanisms are inelastic and constrained to a known maximum rate through policing or shaping (C) the number of flows across any potential aggregation bottleneck is sufficiently large for stateless, statistical mechanisms to be effective (D) flows may have different precedence, but the applicability of the PCN mechanisms for emergency use (911, GETS, WPS, MLPP, etc.) is out of scope After completion of the initial phase, the PCN WG may re-charter to develop solutions for scenarios where some of these restrictions are not in place. It may also re-charter to consider applying the PCN mechanisms to additional deployment scenarios (operation over concatenated DiffServ domains, PCN-aware application mechanisms, etc.). The WG may also consider to investigate additional response mechanisms that act on (pre-)congestion information. One example could be flow-rate adaptation (rather than flow admission/ termination) during times of congestion. The details of these work items are outside the scope of the initial phase; but the WG may consider their requirements to design components that are sufficiently general to support such extensions in the future. Goals and Milestones: Done - Submit Pre-Congestion Notification (PCN) Architecture to the IESG for consideration as an Informational RFC Mar 2009 - Submit Encoding and Transport of (Pre-) Congestion Information from within a DiffServ Domain to the Egress to the IESG for consideration as a Proposed Standard RFC Mar 2009 - Submit (Pre-) Congestion Detection within a DiffServ Domain to the IESG for consideration as a Proposed Standard RFC Mar 2009 - Submit Survey of Encoding and Transport Choices of (Pre-) Congestion Information within a DiffServ Domain to the IESG for consideration as an Informational RFC Jul 2009 - Submit Requirements for Signaling of (Pre-) Congestion Information from Egress to Ingress in a DiffServ Domain to the IESG for consideration as a Informational RFC Nov 2009 - Submit Suggested Flow Admission and Termination Boundary Mechanisms to the IESG for consideration as an Informational RFC Internet-Drafts: - Encoding 3 PCN-States in the IP header using a single DSCP [draft-ietf-pcn-3-in-1-encoding-11] (28 pages) - A PCN encoding using 2 DSCPs to provide 3 or more states [draft-ietf-pcn-3-state-encoding-02] (15 pages) - Pre-Congestion Notification (PCN) Architecture [draft-ietf-pcn-architecture-11] (61 pages) - Baseline Encoding and Transport of Pre-Congestion Information [draft-ietf-pcn-baseline-encoding-07] (18 pages) - PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation [draft-ietf-pcn-cl-edge-behaviour-15] (34 pages) - Overview of Pre-Congestion Notification Encoding [draft-ietf-pcn-encoding-comparison-09] (19 pages) - Metering and Marking Behaviour of PCN-Nodes [draft-ietf-pcn-marking-behaviour-05] (25 pages) - PCN Encoding for Packet-Specific Dual Marking (PSDM Encoding) [draft-ietf-pcn-psdm-encoding-02] (11 pages) - Requirements for Signaling of (Pre-) Congestion Information in a DiffServ Domain [draft-ietf-pcn-signaling-requirements-08] (7 pages) - PCN Boundary Node Behaviour for the Single Marking (SM) Mode of Operation [draft-ietf-pcn-sm-edge-behaviour-12] (32 pages) Requests for Comments: RFC5559: Pre-Congestion Notification (PCN) Architecture (61 pages) * Replaces DRAFT-EARDLEY-PCN-ARCHITECTURE RFC5670: Metering and Marking Behaviour of PCN-Nodes (25 pages) * Replaces DRAFT-EARDLEY-PCN-MARKING-BEHAVIOUR RFC5696: Baseline Encoding and Transport of Pre-Congestion Information (18 pages) * Replaces DRAFT-MONCASTER-PCN-BASELINE-ENCODING Content Delivery Networks Interconnection (cdni) ------------------------------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Richard Woundy Francois Le Faucheur Transport Area Directors: Wesley Eddy Martin Stiemerling Transport Area Advisor: Martin Stiemerling Mailing Lists: General Discussion: cdni@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/cdni Archive: http://www.ietf.org/mail-archive/web/cdni/ Description of Working Group: A Content Delivery Network (CDN) is an infrastructure of network elements operating at layer 4 through layer 7, arranged for the efficient distribution and delivery of digital content. Such content includes, but is not limited to, web pages and images delivered via HTTP, and streaming of continuous media delivered via HTTP, RTSP, RTMP, etc. CDNs typically provide services to multiple Content Service Providers (CSPs). CDNs provide numerous benefits: a shared platform for multi-service content delivery, reduced transmission costs for cacheable content, improved quality of experience for end users and increased robustness of delivery. For these reasons they are frequently used for large-scale content delivery. As a result of the significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure and many Network Service Providers and Enterprise Service Providers are deploying their own CDNs. Subject to the policy of the CSP, it is generally desirable that a given item of content can be delivered to an end user regardless of that end user's location or attachment network. This creates a need for interconnecting (previously) standalone CDNs so they can interoperate and collectively behave as a single delivery infrastructure. The goal of the CDNI Working Group is to allow the interconnection of separately administered CDNs in support of the end-to-end delivery of content from CSPs through multiple CDNs and ultimately to end users (via their respective User Agents). The CDNI WG aims at delivering a targeted, deployable solution in a short timeframe (18-24 months) as needed by the industry. It is expected that the CDNI interfaces will be realized using existing IETF protocols for transport and message exchange, and using existing object notation grammars/languages for the definition of CDNI objects and semantics. In the event that protocol extensions or new protocols are deemed necessary by the WG, the WG will recharter. The working group will focus on the following items: - A "problem statement" document providing a description of the problem and a common terminology. - A "use case" document describing scenarios for usage and applications of the CDNI solution and protocols. - A "framework" document providing a description of the different components of the CDNI architecture and how they interact with one another. This document will also include a "threat analysis" discussing the security concerns and threats, the trust model and privacy issues specific to CDNI. - A "requirements" document. This document lists the requirements for the CDNI architecture and the CDNI interfaces. In particular, this document will focus on identifying a reasonable set of more urgent and important requirements that will be addressed in the initial set of CDNI protocols and solutions produced by the working group. This document will list the requirements stemming from the threat analysis and to be met by each of the CDNI interfaces. - A specification of the "CDNI request-routing interface". This interface will allow an upstream CDN request routing system to obtain from the downstream CDN the information necessary to perform request redirection. - A specification of the "CDNI metadata interface". This interface will allow the CDNs to exchange content distribution metadata of inter-CDN scope. Content distribution metadata refers to the subset of content metadata that is relevant to the distribution of the content and therefore is to be processed by CDNs (for example, this may include information enabling: content acquisition, geo-blocking, enforcement of availability windows or access control). - A specification of the "CDNI logging interface". This interface will allow CDN logging systems to exchange logging information associated with actions that are relevant across CDNs (such as content distribution, content delivery and content routing actions) for purposes of accounting, analytics, monitoring, etc. - A specification of the "CDNI control interface". In particular, this interface will allow an upstream CDN to remove or invalidate content in a downstream CDN. The WG will discuss and address the security, management and operational issues specific to CDNI, inside the above documents and specifications. The working group will only define solutions for aspects of the CDN Interconnection problem space that require direct communication or interoperation between CDNs. In particular, the WG will not define: - New session, transport or network protocols. - New protocols for delivering content from a CDN to an End User/User Agent. - New protocols for ingestion of content or metadata between a CSP and a CDN. - New protocols for acquiring content across CDNs. - Protocols and algorithms for intra-CDN operations. - Support for Transparent Caching across CDNs. - New applications consuming CDNI logs. - Digital Right Management (DRM) mechanisms. The CDNI WG will work with other IETF WGs to assess, and where appropriate, leverage protocols developed by those WGs, in order to realize the CDNI requirements and CDNI interfaces. For example, the WG may assess the suitability of the ALTO protocol as a protocol to enable downstream CDNs to exchange information which may aid an upstream CDN with making CDNI request routing decisions. The CDNI WG will also coordinate with relevant groups outside the IETF such as UltraViolet. Goals and Milestones: Dec 2011 - Submit CDNI problem statement to IESG as Informational Mar 2012 - Submit CDNI use cases to IESG as Informational Jun 2012 - Submit CDNI framework to IESG as Informational Jun 2012 - Submit CDNI requirements to IESG as Informational Dec 2012 - Submit specification of the CDNI Request Routing/Redirection interface to IESG as Proposed Standard Dec 2012 - Submit specification of the CDNI Logging interface to IESG as Proposed Standard Dec 2012 - Submit specification of the CDNI Control interface to IESG as proposed Standard Jun 2013 - Submit specification of the CDNI Request Routing/Footprint & Capabilities Advertisement interface to IESG as Proposed Standard Jun 2013 - Submit specification of the CDNI Metadata Distribution interface to IESG as Proposed Standard Jun 2013 - Recharter or dissolve Internet-Drafts: - Framework for CDN Interconnection [draft-ietf-cdni-framework-00] (53 pages) - Content Distribution Network Interconnection (CDNI) Problem Statement [draft-ietf-cdni-problem-statement-05] (39 pages) - Content Distribution Network Interconnection (CDNI) Requirements [draft-ietf-cdni-requirements-02] (21 pages) - Use Cases for Content Delivery Network Interconnection [draft-ietf-cdni-use-cases-04] (18 pages) No Requests for Comments Datagram Congestion Control Protocol (dccp) ------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Thomas R. Phelan Pasi Sarolahti Transport Area Directors: Wesley Eddy Martin Stiemerling Transport Area Advisor: Wesley Eddy Mailing Lists: General Discussion: dccp@ietf.org To Subscribe: dccp-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/dccp/ Description of Working Group: The Datagram Congestion Control Protocol working group is maintaining the Datagram Congestion Control Protocol (DCCP). DCCP is a minimal, general-purpose transport protocol that provides two main functions: (1) the establishment, maintenance and tear-down of an unreliable packet flow and (2) congestion control of that packet flow. The DCCP WG is chartered to work in four areas: * maintenance of the core DCCP protocol * maintenance of the TFRC congestion control protocol * promoting the use of DCCP by upper layers * modular extensions to DCCP In the first area, the WG focuses on maintenance issues (i.e., bug fixes) to the current DCCP specifications. It also provides the venue for moving the DCCP specifications along the Standards Track. To maintain stable specifications, work in this area is tightly controlled and requires strong justification. The second area of work, maintains the TCP Friendly Rate Control (TFRC) congestion control protocol. This includes identification of issues, bug fixes, and progression of the specification along the Standards Track. In the third area, the WG will promote and support the adoption and use of DCCP by upper-layer applications and protocols. This includes specifications for using existing and emerging protocols and applications with DCCP (such as RTP over DCCP and DTLS over DCCP) as well as supporting documents that enhance DCCP deployment and management. In the fourth area, the WG identifies and develops modular extensions to the DCCP specifications that increase the usefulness of DCCP. The goal of this work is to make DCCP attractive to upper-layer protocols and applications. The WG will consider both requirements brought to it from external groups that develop or use upper-layer protocols and applications and may also itself identify a limited number of prospective applications and upper-layer protocols to investigate. This work will provide refinements to the existing congestion control schemes currently provided by DCCP and may also include, for example, mobility support for DCCP. (The acceptance of new work items on mobility requires the approval of the IESG.) This work includes the provision of new congestion control profiles, which are variants of existing ones, that better serve certain applications, for example, interactive applications. The WG may consider to recharter in the future to support the IRTF Internet Congestion Control Research Group (ICCRG) in the development of new congestion control algorithms through the definition of concrete specifications for these algorithms. New work items in the latter two areas must satisfy four conditions: (1) WG consensus on the suitability and projected quality of the proposed work item. (2) A core group of WG participants with sufficient energy and expertise to advance the work item according to the proposed schedule. (3) Commitment from the WG as a whole to provide sufficient and timely review of the proposed work item. (4) Agreement by the AD, who, depending on the scope of the proposed work item, may decide that an IESG review is needed first. The DCCP WG pursues its work in close collaboration with several other IETF WGs and IRTF RGs, including TSVWG, AVT, MMUSIC, BEHAVE, ICCRG and TMRG. Goals and Milestones: Done - Publish summary of required protocol functions/requirements Done - Decision to build on proposed DCCP protocol, alternate protocol, or quit and go home Done - Detailed review of spec and CCIDs Done - Public design review at IETF meeting Done - Working group last call for spec and CCIDs Done - Submit DCCP spec for IESG/IETF review to be Proposed Standard Done - Submit DCCP CCIDs for IESG/IETF review to be Proposed Standard Done - Complete WGLC draft-ietf-dccp-problem-xx as Informational Done - Complete WGLC draft-ietf-dccp-tfrc-voip as Experimental Done - Complete WGLC 'RTP over DCCP' as PS Done - Complete WGLC 'DTLS over DCCP' as PS Done - Complete WGLC for draft-ietf-dccp-rfc3448bis as PS Done - Complete WGLC for draft-ietf-dccp-serv-codes as PS Done - Complete WGLC draft-ietf-dccp-ccid4 as Experimental Done - Complete WGLC for draft-ietf-dccp-simul-open as PS Done - Complete WGLC draft-ietf-dccp-quickstart as Experimental Done - Complete WGLC for draft-ietf-dccp-tfrc-rtt-option as Proposed Standard Mar 2011 - Complete WGLC for draft-ietf-dccp-udpencap as Proposed Standard Internet-Drafts: - Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control [draft-ietf-dccp-ccid2-10] (22 pages) - Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC) [draft-ietf-dccp-ccid3-11] (40 pages) - DCCP CCID 3-Thin [draft-ietf-dccp-ccid3-thin-01] (11 pages) - Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP) [draft-ietf-dccp-ccid4-05] (22 pages) - Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP) [draft-ietf-dccp-dtls-06] (11 pages) - Problem Statement for the Datagram Congestion Control Protocol (DCCP) [draft-ietf-dccp-problem-03] (23 pages) - Quick-Start for the Datagram Congestion Control Protocol (DCCP) [draft-ietf-dccp-quickstart-05] (23 pages) - TCP Friendly Rate Control (TFRC): Protocol Specification [draft-ietf-dccp-rfc3448bis-06] (65 pages) - RTP and the Datagram Congestion Control Protocol (DCCP) [draft-ietf-dccp-rtp-07] (17 pages) - The Datagram Congestion Control Protocol (DCCP) Service Codes [draft-ietf-dccp-serv-codes-11] (26 pages) - Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal [draft-ietf-dccp-simul-open-08] (34 pages) - Datagram Congestion Control Protocol (DCCP) [draft-ietf-dccp-spec-13] (130 pages) - Faster Restart for TCP Friendly Rate Control (TFRC) [draft-ietf-dccp-tfrc-faster-restart-06] (24 pages) - Strategies for Streaming Media Applications Using TCP-Friendly Rate Control [draft-ietf-dccp-tfrc-media-02] (17 pages) - Sender RTT Estimate Option for the Datagram Congestion Control Protocol (DCCP) [draft-ietf-dccp-tfrc-rtt-option-06] (25 pages) - TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant [draft-ietf-dccp-tfrc-voip-07] (49 pages) - Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-UDP) [draft-ietf-dccp-udpencap-10] (19 pages) - Datagram Congestion Control Protocol (DCCP) User Guide [draft-ietf-dccp-user-guide-03] (26 pages) Requests for Comments: RFC4336: Problem Statement for the Datagram Congestion Control Protocol (DCCP) (23 pages) RFC4340: Datagram Congestion Control Protocol (DCCP) (130 pages) * Updates RFC5595 * Updates RFC5596 * Updates RFC6335 RFC4341: Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control (22 pages) RFC4342: Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC) (40 pages) * Updates RFC5348 * Updates RFC6323 RFC4828: TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant (49 pages) RFC5238: Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP) (11 pages) * Replaces DRAFT-PHELAN-DCCP-DTLS RFC5348: TCP Friendly Rate Control (TFRC): Protocol Specification (65 pages) * Replaces DRAFT-FLOYD-RFC3448BIS * Obsoletes RFC3448 * Updates RFC4342 RFC5595: The Datagram Congestion Control Protocol (DCCP) Service Codes (26 pages) * Replaces DRAFT-FAIRHURST-DCCP-SERV-CODES * Updates RFC4340 * Updates RFC6335 RFC5596: Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal (34 pages) * Replaces DRAFT-FAIRHURST-DCCP-BEHAVE-UPDATE * Updates RFC4340 RFC5622: Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP) (22 pages) * Replaces DRAFT-FLOYD-DCCP-CCID4 * Updates RFC6323 RFC5634: Quick-Start for the Datagram Congestion Control Protocol (DCCP) (23 pages) * Replaces DRAFT-FAIRHURST-TSVWG-DCCP-QS RFC5762: RTP and the Datagram Congestion Control Protocol (DCCP) (17 pages) * Replaces DRAFT-PERKINS-DCCP-RTP RFC6323: Sender RTT Estimate Option for the Datagram Congestion Control Protocol (DCCP) (25 pages) * Replaces DRAFT-RENKER-DCCP-TFRC-RTT-OPTION * Updates RFC4342 * Updates RFC5622 Decoupled Application Data Enroute (decade) ------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Haibin Song Richard Woundy Transport Area Directors: Wesley Eddy Martin Stiemerling Transport Area Advisor: Martin Stiemerling Tech Advisor: Alexey Melnikov Mailing Lists: General Discussion: decade@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/decade Archive: http://www.ietf.org/mail-archive/web/decade/ Description of Working Group: Peer-to-Peer (P2P) applications, including both P2P streaming and P2P file-sharing applications, make up a large fraction of traffic in the Internet today. One way to reduce access network and/or cross-domain bandwidth usage by P2P applications is to introduce storage capabilities in the network between hosts running P2P applications. Allowing P2P applications to store and retrieve data from inside the network can reduce traffic on the last-mile uplink, as well as backbone and transit links. Existing P2P caches often implement the specific P2P application protocols to operate transparently or act as super peers to provide in-network storage. However, it is challenging for P2P cache vendors to support a variety of evolving protocols. Also, for P2P applications, closed P2P caching systems limit effective utilization of in-network storage. Some P2P protocols may be entirely unsupported by a particular caching system. Additionally, applications may be better-equipped to decide how in-network storage is used to meet their specific requirements (e.g., data placement, access control and resource control). Note that providers of in-network storage may impose their own access control or resource usage policies. Both of these challenges can be effectively addressed by using open, standard protocols to access in-network storage. P2P applications can store and retrieve content in the in-network storage, as well as control resources (e.g., bandwidth, connections) consumed by peers in a P2P application. As a simple example, a peer can choose to store content in the in-network storage, and direct other peers to retrieve from that location, reducing last-mile link usage. Furthermore, since a P2P client may have multiple peers, it can control resources used by each peer to store and retrieve content. Though there are existing data access protocols (e.g., HTTP, NFS, WebDAV), they might be lacking capabilities for fine-grained access and resource control (e.g., bandwidth and connections) that are essential for today's advanced P2P applications. The Working Group (WG) will have three primary tasks. First, the WG will identify target applications to appropriately scope the problem and requirements. P2P applications are the primary target, but suitability to other applications with similar requirements may be considered depending on additional complexity required to support such applications. Second, the WG will identify the requirements to enable target applications to utilize in-network storage. Requirements will include the ability for an application to (1) store, retrieve, and manage data, (2) indicate access control policies for storing and retrieving data suitable to an environment with users across multiple administrative and security domains (e.g., in a P2P environment), and (3) indicate resource control policies for storing and retrieving data. Third, the WG will develop an architecture within which the DECADE protocol can be specified. This architecture will identify DECADE's relationship to existing IETF protocols and where (if any) new protocol is needed or extensions to existing protocols need to be made. The architecture will not specify a protocol or extension; if development of a new protocol is needed, the WG will seek to recharter for this purpose or might ask an existing WG to work on such extensions. The WG will focus on the following work items: - A "problem statement" document. This document provides a description of the problem and common terminology. - A requirements document. This document lists the requirements for the in-network storage service (e.g., supported operations) and the protocol to support it. The service will include storing, retrieving, and managing data as well as specifying both access control and resource control policies in the in-network storage pertaining to that data. - A survey document. This document will survey existing related mechanisms and protocols (e.g., HTTP, NFS, and WebDAV), and evaluate their applicability to DECADE. - An architecture document. This document will identify DECADE's relationship with existing IETF protocols. Existing protocols will be used wherever possible and appropriate to support DECADE's requirements. In particular, data storage, retrieval, and management may be provided by an existing IETF protocols. The WG will not limit itself to a single data transport protocol since different protocols may have varying implementation costs and performance tradeoffs. However, to keep interoperability manageable, a small number of specific, targeted, data transport protocols will be identified and used. - An document describing the integration of DECADE with existing P2P applications (e.g., integration with BitTorrent). If new protocol development is deemed necessary, the WG will be rechartered. It is not expected that all work items will be ready for IESG review by that point, but WG consensus must show that documents directing eventual protocol development (Requirements and Architecture document) have stabilized. This permits adjustments to such documents as necessary to maintain consistency as protocol development is done. The following issues are considered out-of-scope for the WG: - Specification of policies regarding copyright-protected or illegal content. - Locating the "best" in-network storage location from which to retrieve content if there are more than one location can provide the same content. - Developing a new protocol for data transport between P2P applications and in-network storage. Goals and Milestones: Done - Working Group Last Call for Problem Statement Done - Submit Problem Statement to IESG as Informational Done - Working Group Last Call for Survey document Done - Submit Survey document to IESG as Informational Jul 2011 - Working Group Last Call for Requirements document Jul 2011 - Working Group Last Call for Architecture document Aug 2011 - Submit Requirements document to IESG as Informational Sep 2011 - Identify need for rechartering Sep 2011 - Submit Architecture document to IESG as Informational Sep 2011 - Working Group Last Call for DECADE Integration Examples Dec 2011 - Submit DECADE Integration Examples to IESG as Informational Internet-Drafts: - DECADE Architecture [draft-ietf-decade-arch-05] (37 pages) - Integration Examples of DECADE System [draft-ietf-decade-integration-example-03] (23 pages) - DECoupled Application Data Enroute (DECADE) Problem Statement [draft-ietf-decade-problem-statement-06] (14 pages) - DECADE Requirements [draft-ietf-decade-reqs-06] (23 pages) - A Survey of In-Network Storage Systems [draft-ietf-decade-survey-06] (43 pages) Requests for Comments: RFC6392: A Survey of In-Network Storage Systems (43 pages) * Replaces DRAFT-SONG-DECADE-SURVEY * Replaces DRAFT-RAHMAN-DECADE-SURVEY FEC Framework (fecframe) ------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chair: Greg Shepherd Transport Area Directors: Wesley Eddy Martin Stiemerling Transport Area Advisor: Martin Stiemerling Mailing Lists: General Discussion: fecframe@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/fecframe Archive: http://www.ietf.org/mail-archive/web/fecframe Description of Working Group: The object of this group is to develop specifications for using forward error correction (FEC) codes with applications in the Internet to provide protection against packet loss. The group will develop a protocol framework for application of FEC codes to arbitrary packet flows over unreliable transport protocols over both IP multicast and unicast. The application of the FEC codec on an aggregate of multiple packet flows may be investigated and considered to be included in the solution. The FECFrame working group will use the building block approach (RFC 3269), especially the FEC Building Block (RFC 3452), developed by the RMT working group. The FEC Building Block was developed to ensure that the RMT framework developed can support multiple FEC codes and maintain independence between FEC codes and protocols based on the framework. The FECFrame WG may develop new FEC schemes if necessary to provide substantial performance gains for the intended applications. However the acceptance of any FEC scheme will require multiple, prior, detailed reviews of the FEC code by independent experts from both the IETF and the broader community, since it is likely that the IETF working group will not include a large enough number of suitable experts in its working set. If these reviews are positive, then Working Group acceptance of an FEC scheme work item still needs the approval of the responsible Area Director. A primary objective of this framework is to support FEC for real-time media applications using RTP over UDP, such as on demand streaming and audio/video broadcast. Other potential usages of the framework may be brought to the working group for consideration during the development of the requirements, to enable future support of those usages. The group will coordinate closely with the AVT and MMUSIC working groups to ensure that the streaming use-case is fully specified both in terms of interactions with RTP/RTCP and application layer signalling. The group will also coordinate with the DCCP working group, at least to consider that transport protocol's role in streaming media. The interactions of the framework with existing and used security mechanisms must also be considered. The group will work with the RMT working group to ensure that the FEC Building Block defined in RMT supports both the RMT use-cases (object delivery over multicast) and the more general FEC protection of flow(s) over unreliable unicast and multicast transport. Specification of hybrid schemes involving both retransmission and forward error correction is out of scope of the group. Goals and Milestones: Done - Working Group consensus on requirements and their prioritization for the FEC protocol framework Done - Completed selection of solution to develop and mature Done - FEC framework requirements WG soft-freeze Done - FEC Streaming Framework WG soft-freeze Done - FEC Grouping informational draft submitted to MMUSIC Done - FEC Streaming Framework submitted as Proposed Standard Done - Usage of FEC framework with RTP submitted as Proposed Standard Done - FEC SDP Elements submitted as Proposed Standard Dec 2011 - Transfer open FEC scheme documents to TSVWG Internet-Drafts: - SDP Elements for FEC Framework [draft-begen-fecframe-sdp-elements-00] (14 pages) - RTP Payload Format for Non-Interleaved and Interleaved Parity FEC [draft-ietf-fecframe-1d2d-parity-scheme-01] (39 pages) - Methods to convey FEC Framework Configuration Information [draft-ietf-fecframe-config-signaling-08] (17 pages) - Guidelines for Implementing DVB-IPTV Application-Layer Hybrid FEC Protection [draft-ietf-fecframe-dvb-al-fec-04] (11 pages) - Forward Error Correction (FEC) Framework [draft-ietf-fecframe-framework-15] (48 pages) - RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC) [draft-ietf-fecframe-interleaved-fec-scheme-09] (32 pages) - Simple LDPC-Staircase Forward Error Correction (FEC) Scheme for FECFRAME [draft-ietf-fecframe-ldpc-02] (20 pages) - Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in FEC Framework [draft-ietf-fecframe-pseudo-cdp-02] (11 pages) - Raptor FEC Schemes for FECFRAME [draft-ietf-fecframe-raptor-11] (23 pages) - FECFRAME requirements [draft-ietf-fecframe-req-02] (14 pages) - RTP Payload Format for Raptor FEC [draft-ietf-fecframe-rtp-raptor-07] (25 pages) - Session Description Protocol Elements for the Forward Error Correction (FEC) Framework [draft-ietf-fecframe-sdp-elements-11] (19 pages) - Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME [draft-ietf-fecframe-simple-rs-03] (21 pages) Requests for Comments: RFC6015: RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC) (32 pages) * Replaces DRAFT-BEGEN-FECFRAME-INTERLEAVED-FEC-SCHEME RFC6363: Forward Error Correction (FEC) Framework (48 pages) * Replaces DRAFT-WATSON-FECFRAME-FRAMEWORK RFC6364: Session Description Protocol Elements for the Forward Error Correction (FEC) Framework (19 pages) * Replaces DRAFT-BEGEN-FECFRAME-SDP-ELEMENTS IP Performance Metrics (ippm) ----------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Matthew J. Zekauskas Dr. Henk A.J Uijterwaal Transport Area Directors: Wesley Eddy Martin Stiemerling Transport Area Advisor: Wesley Eddy Mailing Lists: General Discussion: ippm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ippm Archive: http://www.ietf.org/mail-archive/web/ippm/ Description of Working Group: The IPPM WG has developed a set of standard metrics that can be applied to the quality, performance, and reliability of Internet data delivery services. These metrics are designed such that they can be performed by network operators, end users, or independent testing groups. It is important that the metrics not represent a value judgment (i.e. define "good" and "bad"), but rather provide unbiased quantitative measures of performance. Functions peripheral to Internet data delivery services, such as NOC/NIC services, are beyond the scope of this working group. The IPPM WG has produced documents that define specific metrics and procedures for accurately measuring and documenting these metrics. This is the current list of fundamental metrics and the existing set of derived metrics. - connectivity - one-way delay and loss - round-trip delay. - delay variation - loss patterns - packet reordering - bulk transport capacity - link bandwidth capacity - packet duplication The working group will advance these metrics along the standards track within the IETF. The WG will document the process of moving documents along the standards track, based on draft-bradner-metricstest. As this process is likely to be needed by other groups as well (in particular BMWG, PMOL), the group will collaborate with other groups in order to ensure that there is consensus amongst all groups expected to use the process. Additionally, the WG will produce Proposed Standard AS documents, comparable to applicability statements in RFC 2026, that will focus on procedures for measuring the individual metrics and how these metrics characterize features that are important to different service classes, such as bulk transport, periodic streams, packet bursts or multimedia streams. Each AS document will discuss the performance characteristics that are pertinent to a specified service class; clearly identify the set of metrics that aid in the description of those characteristics; specify the methodologies required to collect said metrics; and lastly, present the requirements for the common, unambiguous reporting of testing results. The AS documents can also discuss the use of the metrics to verify performance expectations, such as SLA's, report results to specific user groups or investigate network problems. The focus is, again, to define how this should be done, not to define a value judgment. The WG may define additional statistics for its metrics if needed. Specific topics of these AS documents must be approved by the Area Directors as charter additions. The WG will work on documents describing how to compose and decompose the results of its metrics over time or space. The WG has produced protocols to enable communication among test equipment that implements the one- and two-way metrics (OWAMP and TWAMP respectively). OWAMP and TWAMP will be advanced along the standards track. Further development of these protocols will also be done inside the WG. The metrics developed by the WG were developed inside an active measurement context, that is, the devices used to measure the metrics produce their own traffic. However, most metrics can be used inside a passive context as well. No work is planned is this area though, this may be changed with AD approval. The intent of the WG is to cooperate with other appropriate standards bodies and forums (such as ATIS IIF, ITU-T SG 12, 13 and 15, MEF) to promote consistent approaches and metrics. Within the IETF process, IPPM metrics definitions will be subject to as rigorous a scrutiny for usefulness, clarity, and accuracy as other protocol standards. The IPPM WG will interact with other areas of IETF activity whose scope intersect with the requirement of these specific metrics. The WG will, on request, provide input to other IETF WG on the use of these metrics. Goals and Milestones: Done - Submit drafts of standard metrics for connectivity and treno-bulk-throughput. Done - Submit a framework document describing terms and notions used in the IPPM effort, and the creation of metrics by the working group to IESG for publication as an Informational RFC. Done - Submit documents on delay and loss to IESG for publication as Informational RFCs. Done - Submit a document on connectivity to IESG for publication as an Informational RFC. Done - Submit a document on bulk-throughput to IESG for publication as an Informational RFC. Done - Submit draft on loss pattern sample metrics to the IESG for publication as an Informational RFC. Done - Submit draft on metrics for periodic streams to the IESG for publication as a Proposed Standard RFC. Done - Submit draft on IP delay variation to the IESG for publication as a Proposed Standard RFC. Done - First draft for AS on one-way delay and loss. Done - Submit draft on One-Way Active Measurement Protocol Requirements to the IESG for consideration as an Informational RFC. Done - Create initial draft on a MIB for reporting IPPM metrics. Done - Create initial draft on a packet reordering metric. Done - Create draft on a One-Way Active Measurement Protocol that satisfies the requirements document. Done - Submit draft on the One-Way Active Measurement Protocol to the IESG for consideration as a PS. Done - Submit draft on implementation reports for RFCs 2678-2681 to the IESG Done - Submit initial draft on framework for Composition and Aggregation Metrics Done - Submit draft on the One-Way Active Measurement Protocol to the IESG for consideration as a PS Done - Submit initial applicability statement for the IPPM and ITU Jitter Measurements to the WG Done - Submit draft on a packet reordering metric to the IESG for Proposed Standard Done - Submit link bandwidth capacity definitions draft to the IESG, for consideration as an Informational RFC Done - Submit draft on storing results of traceroute measurements to the IESG Done - Submit draft on Two-way active measurements protocol (TWAMP) to the IESG for consideration as proposed standard Done - Develop new charter text Done - Delay Variation Applicability Statement (Informational) to IESG Review Done - Assemble editorial team to work on the process draft (WG version of draft-bradner-metricstest) Done - -00 version of SLA validation draft Done - Submit 'more TWAMP' draft to IESG Done - Initial version of process draft Done - Submit draft-ietf-ippm-twamp-session-cntrl to IESG Done - Submit draft-ietf-ippm-reflect-octets to IESG Done - Submit draft on spatial composition of metrics to the IESG Done - Submit draft on Temporal Aggregation of Metrics to the IESG Done - Submit draft on spatial decomposition and multicast metrics to the IESG Nov 2010 - Final version of process draft Nov 2010 - Implementation report based on process draft Mar 2011 - Revise charter Internet-Drafts: - A Bulk Transfer Capacity Methodology for Cooperating Hosts [draft-ietf-ippm-btc-cap-00] (5 pages) - A Framework for Defining Empirical Bulk Transfer Capacity Metrics [draft-ietf-ippm-btc-framework-05] (9 pages) - Defining Network Capacity [draft-ietf-ippm-bw-capacity-05] (20 pages) - IPPM Metrics for Measuring Connectivity [draft-ietf-ippm-connectivity-04] (10 pages) - A One-way Delay Metric for IPPM [draft-ietf-ippm-delay-07] (20 pages) - Packet Delay Variation Applicability Statement [draft-ietf-ippm-delay-var-as-02] (39 pages) - A One-Way Packet Duplication Metric [draft-ietf-ippm-duplicate-08] (14 pages) - Framework for IP Performance Metrics [draft-ietf-ippm-framework-02] (38 pages) - Framework for Metric Composition [draft-ietf-ippm-framework-compagg-09] (18 pages) - Overview of Implementation reports relating to IETF work on IP Performance Measurements (IPPM, RFC 2678 - 2681) [draft-ietf-ippm-implement-02] (24 pages) - IP Packet Delay Variation Metric for IP Performance Metrics (IPPM) [draft-ietf-ippm-ipdv-09] (21 pages) - A One-way Packet Loss Metric for IPPM [draft-ietf-ippm-loss-07] (16 pages) - Loss Episode Metrics for IP Performance Metrics (IPPM) [draft-ietf-ippm-loss-episode-metrics-04] (22 pages) - One-way Loss Pattern Sample Metrics [draft-ietf-ippm-loss-pattern-06] (14 pages) - IP Performance Metrics (IPPM) Metrics Registry [draft-ietf-ippm-metrics-registry-08] (16 pages) - IP Performance Metrics (IPPM) Standard Advancement Testing [draft-ietf-ippm-metrictest-05] (37 pages) - Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP) [draft-ietf-ippm-more-twamp-02] (10 pages) - IP Performance Metrics (IPPM): Spatial and Multicast [draft-ietf-ippm-multimetrics-12] (52 pages) - Network performance measurement with periodic streams [draft-ietf-ippm-npmps-07] (20 pages) - A One-way Active Measurement Protocol (OWAMP) [draft-ietf-ippm-owdp-16] (56 pages) - One-way Active Measurement Protocol (OWAMP) Requirements [draft-ietf-ippm-owdp-reqs-06] (10 pages) - One-Way Metric Applicability Statement [draft-ietf-ippm-owmetric-as-01] (8 pages) - Packet Reordering Metrics [draft-ietf-ippm-reordering-13] (42 pages) - Reporting IP Performance Metrics to Users [draft-ietf-ippm-reporting-06] (42 pages) - Reporting IP Network Performance Metrics: Different Points of View [draft-ietf-ippm-reporting-metrics-09] (27 pages) - IP Performance Metrics (IPPM) reporting Information Base (MIB) [draft-ietf-ippm-reporting-mib-06] (80 pages) - A Round-trip Delay Metric for IPPM [draft-ietf-ippm-rt-delay-01] (20 pages) - Round-trip Packet Loss Metrics [draft-ietf-ippm-rt-loss-05] (13 pages) - Spatial Composition of Metrics [draft-ietf-ippm-spatial-composition-16] (30 pages) - Information Model and XML Data Model for Traceroute Measurements [draft-ietf-ippm-storetraceroutes-12] (72 pages) - Framework for TCP Throughput Testing [draft-ietf-ippm-tcp-throughput-tm-13] (24 pages) - Test Plan and Results for Advancing RFC 2679 on the Standards Track [draft-ietf-ippm-testplan-rfc2679-01] (31 pages) - TReno Bulk Transfer Capacity [draft-ietf-ippm-treno-btc-03] (5 pages) - A Two-Way Active Measurement Protocol (TWAMP) [draft-ietf-ippm-twamp-09] (26 pages) - Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features [draft-ietf-ippm-twamp-reflect-octets-09] (20 pages) - Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP) [draft-ietf-ippm-twamp-session-cntrl-07] (18 pages) - Ericsson TWAMP Value-Added Octets [draft-ietf-ippm-twamp-value-added-octets-03] (17 pages) - RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete [draft-morton-ippm-rfc4148-obsolete-03] (6 pages) Requests for Comments: BCP0108: IP Performance Metrics (IPPM) Metrics Registry (16 pages) BCP0176: IP Performance Metrics (IPPM) Standard Advancement Testing (37 pages) RFC2330: Framework for IP Performance Metrics (38 pages) * Replaces DRAFT-ALMES-IPPM-FRAMEWORK RFC2498: IPPM Metrics for Measuring Connectivity (10 pages) * Obsoletes RFC2678 RFC2679: A One-way Delay Metric for IPPM (20 pages) RFC2680: A One-way Packet Loss Metric for IPPM (16 pages) RFC2681: A Round-trip Delay Metric for IPPM (20 pages) RFC3148: A Framework for Defining Empirical Bulk Transfer Capacity Metrics (9 pages) RFC3357: One-way Loss Pattern Sample Metrics (14 pages) RFC3393: IP Packet Delay Variation Metric for IP Performance Metrics (IPPM) (21 pages) RFC3432: Network performance measurement with periodic streams (20 pages) RFC3763: One-way Active Measurement Protocol (OWAMP) Requirements (10 pages) RFC4148: IP Performance Metrics (IPPM) Metrics Registry (16 pages) * Obsoletes RFC6248 RFC4656: A One-way Active Measurement Protocol (OWAMP) (56 pages) RFC4737: Packet Reordering Metrics (42 pages) * Updates RFC6248 RFC5136: Defining Network Capacity (20 pages) RFC5357: A Two-Way Active Measurement Protocol (TWAMP) (26 pages) * Updates RFC5618 * Updates RFC5938 * Updates RFC6038 RFC5388: Information Model and XML Data Model for Traceroute Measurements (72 pages) * Replaces DRAFT-NICCOLINI-IPPM-STORETRACEROUTES RFC5481: Packet Delay Variation Applicability Statement (39 pages) * Replaces DRAFT-MORTON-IPPM-DELAY-VAR-AS RFC5560: A One-Way Packet Duplication Metric (14 pages) * Updates RFC6248 RFC5618: Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP) (10 pages) * Replaces DRAFT-MORTON-IPPM-MORE-TWAMP * Updates RFC5357 RFC5644: IP Performance Metrics (IPPM): Spatial and Multicast (52 pages) * Updates RFC6248 RFC5835: Framework for Metric Composition (18 pages) RFC5938: Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP) (18 pages) * Replaces DRAFT-MORTON-IPPM-TWAMP-SESSION-CNTRL * Updates RFC5357 RFC6038: Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features (20 pages) * Updates RFC5357 RFC6049: Spatial Composition of Metrics (30 pages) * Updates RFC6248 RFC6248: RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete (6 pages) * Obsoletes RFC4148 * Updates RFC4737 * Updates RFC5560 * Updates RFC5644 * Updates RFC6049 RFC6349: Framework for TCP Throughput Testing (24 pages) * Replaces DRAFT-CONSTANTINE-IPPM-TCP-THROUGHPUT-TM RFC6534: Loss Episode Metrics for IP Performance Metrics (IPPM) (22 pages) RFC6576: IP Performance Metrics (IPPM) Standard Advancement Testing (37 pages) Low Extra Delay Background Transport (ledbat) --------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Rolf Winter Murari Sridhavan Transport Area Directors: Wesley Eddy Martin Stiemerling Transport Area Advisor: Wesley Eddy Mailing Lists: General Discussion: ledbat@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ledbat Archive: http://www.ietf.org/mail-archive/web/ledbat Description of Working Group: The LEDBAT WG is chartered to standardize a congestion control mechanism that should saturate the bottleneck, maintain low delay, and yield to standard TCP. Applications that transmit large amounts of data for a long time with congestion-limited TCP, but without AQM, fill the buffer at the head of the bottleneck link. With FIFO queue, this increases the delay experienced by other applications. With buffer of one RTT, the delay doubles. In some cases, the extra delay may be much larger. This is a particularly acute and common case is when P2P applications upload over thin home uplinks: delays in these cases can sometimes be of the order of seconds. The IETF's standard end-to-end transport protocols have not been designed to minimize the extra delay introduced by them into the network. TCP, as a side effect of filling the buffer until it experiences drop-tail loss, effectively maximizes the delay. While this works well for applications that are not delay-sensitive, it harms interactive applications that share the same bottleneck. VoIP and games are particularly affected, but even web browsing may become problematic. LEDBAT is a transport-area WG that will focus on broadly applicable techniques that allow large amounts of data to be consistently transmitted without substantially affecting the delays experienced by other users and applications. The WG will work on the following: (1) An experimental congestion control algorithm for less-than-best-effort "background" transmissions, i.e., an algorithm that attempts to scavenge otherwise idle bandwidth for its transmissions in a way that minimizes interference with regular best-effort traffic. Desired features of such an algorithm are: * saturate the bottleneck * eliminate long standing queues and thus keep delay low when no other traffic is present * quickly yield to traffic sharing the same bottleneck queue that uses standard TCP congestion control * add little to the queueing delays induced by TCP traffic * operate well in networks with FIFO queueing with drop-tail discipline * be deployable for popular applications that currently comprise noticeable fractions of Internet traffic * where available, use explicit congestion notification (ECN), active queue management (AQM), and/or end-to-end differentiated services (DiffServ). Application of this algorithm to existing transport protocols (TCP, SCTP, DCCP) is expected to occur in the working groups that maintain those protocols. Once experience is gained with this congestion control algorithm on the Internet, the WG will consider if it is appropriate to ask the IESG to advance the document as a Proposed Standard. (2) A document that clarifies the current practices of application design and reasons behind them and discusses the tradeoffs surrounding the use of many concurrent TCP connections to one destination and/or to different destinations. Applications routinely open multiple TCP connections. For example, P2P applications maintain connections to a number of different peers while web browsers perform concurrent downloads from the same web server. Application designers pursue different goals when doing so: P2P apps need to maintain a well-connected mesh in the swarm while web browsers mainly use multiple connections to parallelize requests that involve application latency on the web server side. The IETF transport area community is concerned about this practice, because standard Internet congestion control results in different transport connections sharing bottleneck capacity. When an application uses several non-rate-limited transport connections to transfer through a bottleneck, it may obtain a larger fraction of the bottleneck than if it had used fewer connections. Although capacity is the most commonly considered bottleneck resource, middlebox state table entries are also an important resource for an end system communication. Other resource types may exist, and the guidelines are expected to comprehensively discuss them. Applications use a variety of techniques to mitigate these concerns. These techniques have not always been reviewed by the IETF and their interaction with TCP dynamics is poorly understood. The WG will document the known techniques, discussing the consequences and, where appropriate, provide guidance to application designers. Goals and Milestones: Oct 2009 - Submit 'Multiple Transport Connections in Applications Design' to the IESG for consideration as an Informational RFC Oct 2009 - Submit 'Low Extra Delay Background Transport (LEDBAT)' to the IESG for consideration as an Experimental RFC Feb 2010 - Submit 'A Survey of Lower-than-Best Effort Transport Protocols' to the IESG for consideration as an Informational RFC Internet-Drafts: - Low Extra Delay Background Transport (LEDBAT) [draft-ietf-ledbat-congestion-09] (19 pages) - LEDBAT Practices and Recommendations for Managing Multiple Concurrent TCP Connections [draft-ietf-ledbat-practices-recommendations-00] (15 pages) - A Survey of Lower-than-Best-Effort Transport Protocols [draft-ietf-ledbat-survey-07] (18 pages) Requests for Comments: RFC6297: A Survey of Lower-than-Best-Effort Transport Protocols (18 pages) * Replaces DRAFT-WELZL-LEDBAT-SURVEY Multipath TCP (mptcp) --------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Philip Eardley Yoshifumi Nishida Transport Area Directors: Wesley Eddy Martin Stiemerling Transport Area Advisor: Wesley Eddy Mailing Lists: General Discussion: multipathtcp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/multipathtcp Archive: http://www.ietf.org/mail-archive/web/multipathtcp/ Description of Working Group: The Multipath TCP (MPTCP) working group develops mechanisms that add the capability of simultaneously using multiple paths to a regular TCP session. The primary output of the group will be the protocol extensions needed to deploy MPTCP, and adaptations to congestion control to safely support multipath resource sharing. Initially the WG will only produce documents that are experimental or informational. Key goals for MPTCP are: to be deployable and usable without significant changes to existing Internet infrastructure; to be usable by unmodified applications; and to be stable and congestion-safe over the wide range of existing Internet paths. That will include handling MTU discovery on a per path basis and NAT interactions. The design's success in meeting the goals should be determined through experiments. However, it is expected that some results from large scale experiments can only be achievable after the publication of the initial design. The working group will provide a modular architecture that is designed to be easily extensible and adaptable. In particular, the congestion control mechanism is separated from the mechanisms for identifying and using multiple paths. The working group will focus on a solution requiring modification of both peers. One or both peers are expected to have multiple addresses, which often results in different network paths that are at least partially divergent. However, multiple addresses, even on different network interfaces, are no guarantee that the paths are divergent at all. The design needs to address the issues associated with fully or partially joint paths and shared bottlenecks. The design should allow for future extensions to handle cases where path diversity is attempted through other means than using different addresses. The design must also consider what happens when an end-point pair becomes unavailable during an ongoing session, especially a pair that has been used to establish an additional path (for this connection) between another end-point pair. Whilst MPTCP will require modifications to the TCP stack at both the peers, all existing applications should be able to use the new MPTCP stack without modification and gain benefits from multipath usage. The impact on different classes of applications will be considered and documented. An extended API will be defined to allow applications to express particular preferences for how MPTCP operates, and to get additional information about MPTCP-specific run-time events. The WG will carefully analyze and address in the appropriate protocol documents all new security threats introduced by MPTCP. The following items will be worked on: a. An architectural framework for congestion-dependent multipath transport protocols. This is an overview document which tracks the technical documents, describing how the modular components fit together, and will describe the motivations and the general approach that should be followed to enable congestion-dependent multipath transport. It will also analyze how MPTCP interacts with existing infrastructure elements and other address agility mechanisms, such as Mobile IP, HIP and SHIM6. The results of any experiment performed during the development should also be included or referenced in this document. b. A security threat analysis for multipath TCP. The ability to change the addresses used during a TCP session opens up new types of vulnerabilities and attacks. These and their mitigations will be documented. c. A coupled multipath-aware congestion control algorithm. This algorithm is the multipath equivalent of SACK/NewReno congestion control. As experience is gathered from implementations of various congestion control algorithms, it is expected that the working group will be rechartered to pursue additional work in these areas. d. Extensions to current TCP to support multi-addressed multipath TCP. This covers all on-the-wire changes required to create a two-ended MPTCP solution using multiple addresses at one or both ends. It will be designed in a modular fashion to allow alternative address management schemes to be explored in future. This document will also include a basic security model. e. An extended API describing how applications can exploit additional features of multipath transport. While MPTCP needs to be usable without any application changes, this API should be an optional extension that provides access to multipath information and enables control over the usage of multipath. f. An application considerations document, presenting the impacts that MPTCP may have on applications, such as performance changes. It should also discuss issues it create for applications, such as its effects on the usage of IPsec. Where appropriate, this group is expected to coordinate with, and will use input from, the MIF working group to support the use of multiple interfaces. Goals and Milestones: Done - Established WG consensus on the Architecture Done - Submit to IESG architectural guidelines and security threat analysis as informational RFC(s) Done - Submit to IESG basic coupled congestion control as an experimental RFC Mar 2012 - Submit to IESG protocol specification for MPTCP extensions as an experimental RFC Mar 2012 - Submit to IESG an extended API and application consideration for MPTCP as an informational RFC Mar 2012 - Recharter or close WG Internet-Drafts: - MPTCP Application Interface Considerations [draft-ietf-mptcp-api-05] (30 pages) - Architectural Guidelines for Multipath TCP Development [draft-ietf-mptcp-architecture-05] (29 pages) - Coupled Congestion Control for Multipath Transport Protocols [draft-ietf-mptcp-congestion-07] (13 pages) - TCP Extensions for Multipath Operation with Multiple Addresses [draft-ietf-mptcp-multiaddressed-07] (60 pages) - Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses [draft-ietf-mptcp-threat-08] (17 pages) Requests for Comments: RFC6181: Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses (17 pages) * Replaces DRAFT-BAGNULO-MPTCP-THREAT RFC6182: Architectural Guidelines for Multipath TCP Development (29 pages) * Replaces DRAFT-FORD-MPTCP-ARCHITECTURE RFC6356: Coupled Congestion Control for Multipath Transport Protocols (13 pages) * Replaces DRAFT-RAICIU-MPTCP-CONGESTION * Replaces DRAFT-MPTCP-CONGESTION Network File System Version 4 (nfsv4) ------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Spencer Shepler Brian Pawlowski Transport Area Directors: Wesley Eddy Martin Stiemerling Transport Area Advisor: Martin Stiemerling Tech Advisor: Leif Johansson Mailing Lists: General Discussion: nfsv4@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/nfsv4 Archive: http://www.ietf.org/mail-archive/web/nfsv4/ Description of Working Group: NFS Version 4 is the IETF standard for file sharing. To maintain NFS Version 4's utility and currency, the working group is chartered to (1) maintain the existing NFSv4, NFSv4.1 and related specifications, such as RPC and XDR, (2) progress these specifications along the standards track, (3) develop a protocol to create a federated namespace using NFSv4's existing referral mechanisms. (1) NFS version 4.0 maintenance Under this charter item, the WG correct errors and ambiguities in the protocol currently specified in RFC 3530 and advances it along the standards track. Extensions of any other kind are out of scope under this charter item. (2) NFS Version 4.1 Maintenance As with NFSv4.0, the WG will address errors or ambiguities in the NFSv4.1 protocol and related specifications in support of progressing implementations. (3) RPC and XDR protocol maintenance The NFSv4 protocol depends on two related specifications: ONC RPC and XDR. Similar to charter item (1), the WG may correct errors and ambiguities in the ONC RPC and XDR protocols currently specified by RFCs 1831, 1833 and 2203. In conjunction with the advancement of the NFSv4 specification along the standards track, the WG will also work on the advancements of its ONC RPC and XDR dependencies. The WG will also update the ONC RPC specification for compatibility with IPv6. Additionally, it will create an IANA registry for RPC program numbers and seed it with a registry Sun has been maintaining. (4) Federated Namespace The NFSv4 protocol provides a referral mechanism that allows a server to redirect a client to another server. The working group will produce documents describing a mechanism for creating a federated namespace (single global name space for a set of NFSv4 servers) using the NFSv4 protocol's referral capabilities. The file system federation protocol will enable file access and namespace traversal across collections of independently administered fileservers. No modifications will be made to the NFS client to server protocol. Goals and Milestones: Done - Issue strawman Internet-Draft for v4 Done - Submit Initial Internet-Draft of requirements document Done - Submit Final Internet-Draft of requirements document Done - AD reassesses WG charter Done - Submit v4 Internet-Draft sufficient to begin prototype implementations Done - Begin Interoperability testing of prototype implementations Done - Submit NFS version 4 to IESG for consideration as a Proposed Standard. Done - Conduct final Interoperability tests Done - Conduct full Interoperability tests for all NFSv4 features Done - Update API advancement draft Done - Form core design team to work on NFS V4 migration/replication requirements and protocol Done - Submit revised NFS Version 4 specification (revision to RFC 3010) to IESG for consideration as a Proposed Standard Done - Strawman NFS V4 replication/migration protocol proposal submitted as an ID Done - WG Last Call for RPC and NFS RDMA drafts Done - WG Last Call for rfc1831bis (RPC version 2) Done - WG Last Call for NFSv4.1 Object-based layout Done - WG Last Call for NFSv4 minor version 1 Done - WG Last Call for NFSv4.1 block/volume layout Done - Submit NFS Minor Version 1 to IESG for publication as a Proposed Standard Done - Submit Object-based pNFS Operations to IESG for publication as a Proposed Standard Done - Submit pNFS Block/Volume Layout to IESG for publication as a Proposed Standard May 2009 - WG Last Call for Requirements for Federated File Systems draft-ietf-nfsv4-federated-fs-reqts-01 Sep 2009 - WG Last Call for rfc3530bis (NFS version 4) Oct 2009 - WG Last Call for Administration Protocol for Federated Filesystems draft-ietf-nfsv4-federated-fs-admin-00.txt Oct 2009 - WG Last Call for NSDB Protocol for Federated Filesystems draft-ietf-nfsv4-federated-fs-protocol-00.txt Internet-Drafts: - NFS version 4 Protocol [draft-ietf-nfsv4-07] (234 pages) - NFS version 4 Protocol [draft-ietf-nfsv4-03-00] (230 pages) - Mapping Between NFSv4 and Posix Draft ACLs [draft-ietf-nfsv4-acl-mapping-05] (20 pages) - NFS Version 4 ACLs [draft-ietf-nfsv4-acls-00] (35 pages) - The Channel Conjunction Mechanism (CCM) for GSS [draft-ietf-nfsv4-ccm-03] (28 pages) - On the Use of Channel Bindings to Secure Channels [draft-ietf-nfsv4-channel-bindings-04] (17 pages) - NFS Version 4 Design Considerations [draft-ietf-nfsv4-designconsider-03] (26 pages) - NFSv4.1: Directory Delegations and Notifications [draft-ietf-nfsv4-directory-delegation-01] (24 pages) - A DNS RR for NFSv4 ID Domains [draft-ietf-nfsv4-dns-rr-00] (11 pages) - Administration Protocol for Federated Filesystems [draft-ietf-nfsv4-federated-fs-admin-09] (37 pages) - Using DNS SRV to Specify a Global File Name Space with NFS version 4 [draft-ietf-nfsv4-federated-fs-dns-srv-namespace-13] (12 pages) - NSDB Protocol for Federated Filesystems [draft-ietf-nfsv4-federated-fs-protocol-11] (63 pages) - Requirements for Federated File Systems [draft-ietf-nfsv4-federated-fs-reqts-06] (33 pages) - NFS operation over IPv4 and IPv6 [draft-ietf-nfsv4-ipv4v6-00] (14 pages) - NFS operation over IPv6 [draft-ietf-nfsv4-ipv6-00] (8 pages) - Requirements for Labeled NFS [draft-ietf-nfsv4-labreqs-02] (19 pages) - NFSv4 migration: Implementation experience and spec issues to resolve [draft-ietf-nfsv4-migration-issues-00] (37 pages) - Requirements for NFSv4.2 [draft-ietf-nfsv4-minorversion-2-requirements-00] (10 pages) - Network File System (NFS) Version 4 Minor Version 1 Protocol [draft-ietf-nfsv4-minorversion1-29] (612 pages) - Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description [draft-ietf-nfsv4-minorversion1-dot-x-12] (74 pages) - NFS Version 4 Minor Version 2 [draft-ietf-nfsv4-minorversion2-10] (92 pages) - NFSv4 Minor Version 2 Protocol External Data Representation Standard (XDR) Description [draft-ietf-nfsv4-minorversion2-dot-x-10] (81 pages) - Network File System (NFS) Remote Direct Memory Access (RDMA) Problem Statement [draft-ietf-nfsv4-nfs-rdma-problem-statement-08] (17 pages) - Network File System (NFS) Direct Data Placement [draft-ietf-nfsv4-nfsdirect-08] (12 pages) - NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5 [draft-ietf-nfsv4-nfssec-03] (18 pages) - NFSv4 pNFS Extensions [draft-ietf-nfsv4-pnfs-00] (63 pages) - pNFS Access Permissions Check [draft-ietf-nfsv4-pnfs-access-permissions-check-00] (12 pages) - Parallel NFS (pNFS) Block/Volume Layout [draft-ietf-nfsv4-pnfs-block-12] (30 pages) - pNFS block disk protection [draft-ietf-nfsv4-pnfs-block-disk-protection-01] (6 pages) - Object-Based Parallel NFS (pNFS) Operations [draft-ietf-nfsv4-pnfs-obj-12] (37 pages) - Implementation Guide for Referrals in NFSv4 [draft-ietf-nfsv4-referrals-00] (24 pages) - Server-to-Server Replication/Migration Protocol Design Principles [draft-ietf-nfsv4-repl-mig-design-00] (12 pages) - A Server-to-Server Replication/Migration Protocol [draft-ietf-nfsv4-repl-mig-proto-01] (30 pages) - NFS Version 4 Requirements [draft-ietf-nfsv4-requirements-03] (19 pages) - RPC: Remote Procedure Call Protocol Specification Version 2 [draft-ietf-nfsv4-rfc1831bis-13] (63 pages) - XDR: External Data Representation Standard [draft-ietf-nfsv4-rfc1832bis-06] (26 pages) - Network File System (NFS) version 4 Protocol [draft-ietf-nfsv4-rfc3010bis-05] (291 pages) - Network File System (NFS) Version 4 Protocol [draft-ietf-nfsv4-rfc3530bis-18] (321 pages) - Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description [draft-ietf-nfsv4-rfc3530bis-dot-x-11] (38 pages) - Object-Based Parallel NFS (pNFS) Operations [draft-ietf-nfsv4-rfc5664bis-01] (38 pages) - RPC Numbering Authority Transfer to IANA [draft-ietf-nfsv4-rpc-iana-03] (13 pages) - IPv6 extension to RPC [draft-ietf-nfsv4-rpc-ipv6-00] (13 pages) - IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats [draft-ietf-nfsv4-rpc-netid-06] (13 pages) - Remote Direct Memory Access Transport for Remote Procedure Call [draft-ietf-nfsv4-rpcrdma-09] (38 pages) - RPCSEC_GSS Version 2 [draft-ietf-nfsv4-rpcsec-gss-v2-06] (15 pages) - Remote Procedure Call (RPC) Security Version 3 [draft-ietf-nfsv4-rpcsec-gssv3-02] (23 pages) - NFSv4.1: SECINFO Changes [draft-ietf-nfsv4-secinfo-02] (15 pages) - NFSv4 Session Extensions [draft-ietf-nfsv4-sess-02] (69 pages) - NFS version 4 [draft-shepler-nfsv4-03] (133 pages) Requests for Comments: RFC2623: NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5 (18 pages) RFC2624: NFS Version 4 Design Considerations (26 pages) RFC3010: NFS version 4 Protocol (234 pages) * Obsoletes RFC3530 RFC3530: Network File System (NFS) version 4 Protocol (291 pages) * Obsoletes RFC3010 RFC4506: XDR: External Data Representation Standard (26 pages) * Obsoletes RFC1832 RFC5403: RPCSEC_GSS Version 2 (15 pages) * Updates RFC2203 RFC5531: RPC: Remote Procedure Call Protocol Specification Version 2 (63 pages) * Obsoletes RFC1831 RFC5532: Network File System (NFS) Remote Direct Memory Access (RDMA) Problem Statement (17 pages) RFC5661: Network File System (NFS) Version 4 Minor Version 1 Protocol (612 pages) RFC5662: Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description (74 pages) RFC5663: Parallel NFS (pNFS) Block/Volume Layout (30 pages) RFC5664: Object-Based Parallel NFS (pNFS) Operations (37 pages) RFC5665: IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats (13 pages) * Updates RFC1833 RFC5666: Remote Direct Memory Access Transport for Remote Procedure Call (38 pages) RFC5667: Network File System (NFS) Direct Data Placement (12 pages) RFC5716: Requirements for Federated File Systems (33 pages) * Replaces DRAFT-ELLARD-NFSV4-FEDERATED-FS STD0067: XDR: External Data Representation Standard (26 pages) * Obsoletes RFC1832 Peer to Peer Streaming Protocol (ppsp) -------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Yunfei Zhang Stefano Previdi Transport Area Directors: Wesley Eddy Martin Stiemerling Transport Area Advisor: Martin Stiemerling Mailing Lists: General Discussion: ppsp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ppsp Archive: http://www.ietf.org/mail-archive/web/ppsp/ Description of Working Group: The Peer-to-Peer Streaming Protocol (PPSP) working group develops two signaling and control protocols for a peer-to-peer (P2P) streaming system for transmitting live and time-shifted media content with near real-time delivery requirements. Two kinds of nodes exist in the targeted P2P streaming system, i.e., "peers" and "trackers". Peers are nodes that are actively sending and receiving streamed media content, and include both statically connected hosts as well as mobile devices with connectivity and IP addresses that change over time. The set of peers that are participating in a streaming session will dynamically change over time. Trackers are well-known nodes with stable connectivity that maintain meta information about the streamed content and the dynamic peer set. Trackers can be organized in centralized or distributed ways. The PPSP WG designs a protocol for signaling and control between trackers and peers (the PPSP "tracker protocol") and a signaling and control protocol for communication among the peers (the PPSP "peer protocol"). The two protocols enable peers to receive streaming data within the time constraints required by specific content items. The tracker protocol handles the initial and periodic exchange of meta information between trackers and peers, such as peer lists and content information. The peer protocol controls the advertising and exchange of media data availability between the peers. It is envisioned that the tracker protocol will be modeled as a request/response protocol between peers and trackers, and will carry information needed for the selection of peers suitable for real-time streaming. The peer protocol is envisioned to be modeled as a gossip-like protocol with periodic, pairwise exchanges of neighbor and media chunk availability information. Both protocols will be carried over TCP (or UDP, when delivery requirements cannot be met by TCP), likely in combination with ICE for NAT traversal support. Perfect privacy protection is a good feature to have but not a mandatory requirement for the peer and tracker protocols. The WG will consider to use existing protocols as design base for the tracker and peer protocols. Developing mechanisms for searching trackers that contain a specific media item is out of the scope of this WG. Additionally, the WG will work under the assumption that trackers are logically centralized entities (e.g., a single server or a server farm performing DNS-based local balancing). However, as far as it is possible, the WG will not make design decisions that could preclude the use of distributed trackers in the future (e.g., DHT-based trackers). A peer looking for a media chunk uses the tracker and peer protocols to locate a remote peer (or peers) that can provide it with that media chunk. Obtaining the media chunk from the remote peer will involve some type of signaling exchange plus the actual media transfer. The first task for this WG will be to decide which signaling and media transfer protocols will be used. The WG will consider existing protocols and, if needed, identify potential extensions to these protocols. The WG will consider the interactions between these protocols and the peer protocol (e.g., avoiding duplicate NAT traversal procedures). Examples of signaling protocols to be considered are SIP, RTSP, and HTTP. Examples of media transfer protocols to be considered are RTP and HTTP. PPSP is not chartered to work on media transmission protocols, media encoding techniques or other components of a P2P streaming system such as playout, scheduling and control, etc. The work items of the PPSP WG are: (1) A "problem statement" document that gives an overview of the proposed P2P streaming system, motivates the desire for standardized protocols, defines the envisioned scope of those standardized components and discusses common terminologies and concepts. (2) A "requirements" document that details the specific functional, operational and performance requirements of the two PPSP protocols. (3) An "architectural survey" document that summarizes current P2P streaming architectures, in particular tracker-based P2P streaming systems, and highlights best current practices. (4) A detailed specification of the PPSP peer protocol. (5) A detailed specification of the PPSP tracker protocol. (6) A "usage guide" that describes how the two PPSP protocols and existing IETF protocols, such as P2PSIP or ALTO, can be combined to create a deployable operational P2P streaming system. This document may also discuss variants of such a system that, for example, use layered media encoding and related media chunk descriptions in the peer protocol for more robust streaming. The work items of the PPSP WG interacts with the work performed in other IETF WGs, including P2PSIP, SIPCORE, AVT, ALTO, LEDBAT and MMUSIC. Whenever extensions or modification to the protocols developed in other WGs are deemed necessary, PPSP shall communicate and discuss the requirements for such extensions with the relevant WGs. PPSP is not chartered to design and specify such changes. Goals and Milestones: Dec 2010 - Submit problem statement to IESG as Informational Apr 2011 - Submit architectural survey to IESG as Informational Apr 2011 - Submit requirements document to IESG as Informational Aug 2011 - Submit PPSP peer protocol to IESG as Proposed Standard Aug 2011 - Submit PPSP tracker protocol to IESG as Proposed Standard Dec 2011 - Submit usage guide to IESG to IESG as Informational Internet-Drafts: - Peer-to-Peer Streaming Peer Protocol (PPSPP) [draft-ietf-ppsp-peer-protocol-01] (37 pages) - Problem Statement and Requirements of Peer-to-Peer Streaming Protocol (PPSP) [draft-ietf-ppsp-problem-statement-08] (27 pages) - P2P Streaming Protocol (PPSP) Requirements [draft-ietf-ppsp-reqs-05] (14 pages) - Survey of P2P Streaming Applications [draft-ietf-ppsp-survey-02] (35 pages) No Requests for Comments Reliable Multicast Transport (rmt) ---------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Lorenzo Vicisano Brian Adamson Transport Area Directors: Wesley Eddy Martin Stiemerling Transport Area Advisor: Martin Stiemerling Mailing Lists: General Discussion: rmt@ietf.org To Subscribe: rmt-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/rmt/ Description of Working Group: The purpose of this WG is to standardize reliable multicast transport. Initial efforts have focused solely on the standardization of the one-to-many transport of large amounts of data. Due to the large number of applications that fall into this category, and the sometimes orthogonal requirements these applications exhibit, it is believed that a "one size fits all" protocol will be unable to meet the requirements of all applications. In recognition of this observation, this working group will standardize two protocol instantiations, initially as Experimental protocols, and then as warranted, in the standards track, from the following families: 1) A NACK-based protocol. 2) An "Asynchronous Layered Coding protocol that uses Forward Error Correction. The WG will carry out protocol standardization in general by composing a a set of RFCs that specify - building blocks: A set of easily-separable coarse-grained modular components that are common to multiple protocols along with abstract APIs that define a building block's access methods and their arguments. - protocol instantiations: Specifications that define the necessary gluing logic and minimal additional functionality required to realize a working protocol from one or more building blocks. These specifications will also include an abstract API that defines the interface between the protocol implementation and an application. The WG has previously completed work on three documents to assist in the standardization process. RFC2887 describes the design-space in which the one-to-many transport protocols will be developed. RFC3048 explains the concepts of building-blocks and protocol instantiations. RFC3269 provides guidelines to authors of drafts that specify building-blocks and protocol instantiations. The WG will generate and submit for standardization drafts of the following building-blocks for use in the construction of the two protocols: congestion control, negative acknowledgments, forward error correction, and to address the RFC 2357 security requirements. Generic mechanisms for router assist are also considered for an additional building block. Initial work on the framework for router-assist has already been performed, the WG will evaluate whether to complete this task basing on available resource and interest. The WG will also standardize and generate RFCs for the following two protocol instantiations: A NACK-based protocol, and an Asynchronous Layered Coding (ALC) protocol that uses Forward Error Correction. RFC 3450 is the Experimental RFC of the ALC protocol instantiation. If new requirements are identified that cannot be satisfied with the building-blocks and protocol instantiations described above, the Area Directors in consultation with the IESG may add additional building-blocks and protocol instantiations to the working group deliverables. This working group will work closely with the Internet Research Task Force (IRTF) groups on Reliable Multicast (RMRG) and Secure Multicast (SMUG), especially for meeting the congestion control and security requirements mandated by RFC 2357. This working group may work with the Area Directors to recharter to standardize reliable multicast for additional scenarios beyond the one-to-many transport of bulk data once they are sufficiently well understood. Goals and Milestones: Done - Submit design-space, building-blocks, and guidelines drafts for publication as Informational RFCs Done - Initial Drafts for the following building blocks: negative acknowledgments, forward error correction, a generic signaling mechanism for router assist, and transport protection Done - Submit Initial Drafts for the two protocol instantiations. Done - Submit Initial Draft for Congestion Control Done - Complete building-block drafts WG Last-Call and submit for publication as Proposed Standard Done - Complete building blocks and protocol instantiations for ALC and submit for publication as Experimental RFC Done - WG Decision on whether to pursue the router-assist building block work. These milestones may have to be modified accordingly Done - Submit WEBRC (congestion control building block) for publication as Experimental Done - Submit NACK building block and protocol instantiation for publication as Experimental Done - Evaluate when and how the RMT Experimental specifications will be submitted for publication as Proposed Standard, and update this charter accordingly Done - Submit remaining congestion control building blocks (TFMCC, PGMCC) for publication as Experimental Done - Submit all the RMT Eperimental Specifications published before July 05 for publication as Proposed Standard Sep 2010 - Submit FLUTE SDP document for publication Sep 2010 - Submit RMT Security documents for publication Sep 2010 - Submit FCAST document for publication as Experimental Sep 2010 - Submit RaptorQ FEC Scheme document for publication Internet-Drafts: - Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents [draft-ietf-rmt-author-guidelines-03] (13 pages) - Forward Error Correction (FEC) Building Block [draft-ietf-rmt-bb-fec-07] (19 pages) - Basic Forward Error Correction (FEC) Schemes [draft-ietf-rmt-bb-fec-basic-schemes-revised-06] (27 pages) - Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC) Schemes [draft-ietf-rmt-bb-fec-ldpc-08] (40 pages) - Raptor Forward Error Correction Scheme for Object Delivery [draft-ietf-rmt-bb-fec-raptor-object-09] (53 pages) - RaptorQ Forward Error Correction Scheme for Object Delivery [draft-ietf-rmt-bb-fec-raptorq-06] (69 pages) - Reed-Solomon Forward Error Correction (FEC) Schemes [draft-ietf-rmt-bb-fec-rs-05] (35 pages) - Compact Forward Error Correction (FEC) Schemes [draft-ietf-rmt-bb-fec-supp-compact-01] (16 pages) - Reliable Multicast Transport Building Block Generic Router Assist - Signalling Protocol Specification [draft-ietf-rmt-bb-gra-signalling-01] (20 pages) - Reliable Multicast Transport Building Block: Layered Congestion Control [draft-ietf-rmt-bb-lcc-00] (20 pages) - Layered Coding Transport (LCT) Building Block [draft-ietf-rmt-bb-lct-04] (32 pages) - Layered Coding Transport (LCT) Building Block [draft-ietf-rmt-bb-lct-revised-11] (42 pages) - Reliable Multicast Transport Building Block: Multirate Congestion Control [draft-ietf-rmt-bb-mrcc-00] (20 pages) - Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks [draft-ietf-rmt-bb-norm-09] (30 pages) - Multicast Negative-Acknowledgment (NACK) Building Blocks [draft-ietf-rmt-bb-norm-revised-07] (43 pages) - PGMCC single rate multicast congestion control: Protocol Specification [draft-ietf-rmt-bb-pgmcc-03] (22 pages) - TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification [draft-ietf-rmt-bb-tfmcc-07] (32 pages) - Reliable Multicast Transport Building Block for TRACK [draft-ietf-rmt-bb-track-02] (44 pages) - Reliable Multicast Transport Building Block: Tree Auto-Configuration [draft-ietf-rmt-bb-tree-config-03] (27 pages) - Wave and Equation Based Rate Control (WEBRC) Building Block [draft-ietf-rmt-bb-webrc-04] (33 pages) - Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer [draft-ietf-rmt-buildingblocks-02] (22 pages) - The Reliable Multicast Design Space for Bulk Data Transfer [draft-ietf-rmt-design-space-01] (21 pages) - FCAST: Scalable Object Delivery for the ALC and NORM Protocols [draft-ietf-rmt-fcast-05] (35 pages) - Forward Error Correction (FEC) Building Block [draft-ietf-rmt-fec-bb-revised-07] (33 pages) - FLUTE - File Delivery over Unidirectional Transport [draft-ietf-rmt-flute-08] (35 pages) - FLUTE - File Delivery over Unidirectional Transport [draft-ietf-rmt-flute-revised-14] (45 pages) - SDP Descriptors for FLUTE [draft-ietf-rmt-flute-sdp-02] (35 pages) - Generic Router Assist (GRA) Building Block Motivation and Architecture [draft-ietf-rmt-gra-arch-02] (24 pages) - Generic Router Assist - Functional Specification [draft-ietf-rmt-gra-fspec-00] (15 pages) - The Use of Forward Error Correction (FEC) in Reliable Multicast [draft-ietf-rmt-info-fec-03] (20 pages) - Asynchronous Layered Coding (ALC) Protocol Instantiation [draft-ietf-rmt-pi-alc-08] (36 pages) - Asynchronous Layered Coding (ALC) Protocol Instantiation [draft-ietf-rmt-pi-alc-revised-10] (30 pages) - Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol [draft-ietf-rmt-pi-norm-10] (70 pages) - NACK-Oriented Reliable Multicast (NORM) Transport Protocol [draft-ietf-rmt-pi-norm-revised-14] (95 pages) - Security Requirements For TRACK [draft-ietf-rmt-pi-track-security-01] (0 pages) - Security and Reliable Multicast Transport Protocols: Discussions and Guidelines [draft-ietf-rmt-sec-discussion-06] (27 pages) - Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols [draft-ietf-rmt-simple-auth-for-alc-norm-06] (34 pages) - TRACK ARCHITECTURE A SCALEABLE REAL-TIME RELIABLE MULTICAST PROTOCOL [draft-ietf-rmt-track-arch-00] (0 pages) Requests for Comments: RFC2887: The Reliable Multicast Design Space for Bulk Data Transfer (21 pages) RFC3048: Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer (22 pages) RFC3269: Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents (13 pages) RFC3450: Asynchronous Layered Coding (ALC) Protocol Instantiation (36 pages) * Obsoletes RFC5775 RFC3451: Layered Coding Transport (LCT) Building Block (32 pages) * Obsoletes RFC5651 RFC3452: Forward Error Correction (FEC) Building Block (19 pages) * Obsoletes RFC5052 * Obsoletes RFC5445 RFC3453: The Use of Forward Error Correction (FEC) in Reliable Multicast (20 pages) RFC3695: Compact Forward Error Correction (FEC) Schemes (16 pages) * Obsoletes RFC5445 RFC3738: Wave and Equation Based Rate Control (WEBRC) Building Block (33 pages) RFC3926: FLUTE - File Delivery over Unidirectional Transport (35 pages) RFC3940: Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol (70 pages) * Obsoletes RFC5740 RFC3941: Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks (30 pages) * Obsoletes RFC5401 RFC4654: TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification (32 pages) RFC5052: Forward Error Correction (FEC) Building Block (33 pages) * Obsoletes RFC3452 RFC5053: Raptor Forward Error Correction Scheme for Object Delivery (53 pages) RFC5170: Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC) Schemes (40 pages) RFC5401: Multicast Negative-Acknowledgment (NACK) Building Blocks (43 pages) * Obsoletes RFC3941 RFC5445: Basic Forward Error Correction (FEC) Schemes (27 pages) * Obsoletes RFC3452 * Obsoletes RFC3695 RFC5510: Reed-Solomon Forward Error Correction (FEC) Schemes (35 pages) RFC5651: Layered Coding Transport (LCT) Building Block (42 pages) * Obsoletes RFC3451 RFC5740: NACK-Oriented Reliable Multicast (NORM) Transport Protocol (95 pages) * Obsoletes RFC3940 RFC5775: Asynchronous Layered Coding (ALC) Protocol Instantiation (30 pages) * Obsoletes RFC3450 RFC6330: RaptorQ Forward Error Correction Scheme for Object Delivery (69 pages) RFC6584: Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols (34 pages) * Replaces DRAFT-ROCA-RMT-SIMPLE-AUTH-FOR-ALC-NORM STORage Maintenance (storm) --------------------------- Charter Last Modified: 2012-02-03 Current Status: Active Chairs: Tom Talpey David L. Black Transport Area Directors: Wesley Eddy Martin Stiemerling Transport Area Advisor: Martin Stiemerling Mailing Lists: General Discussion: storm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/storm Archive: http://www.ietf.org/mail-archive/web/storm/ Description of Working Group: The IETF IPS (IP Storage) and RDDP (Remote Direct Data Placement) working groups have produced a significant number of storage protocols (e.g., iSCSI, iSER and FCIP) for which there is significant usage. The time has come to reflect feedback from implementation and usage into updated RFCs; this work may include: - Implementation-driven revisions and updates to existing protocols (i.e., updated RFCs that match the "running code"). - Interoperability reports as needed for the resulting revised protocols that are appropriate for Draft Standard RFC status. - Minor protocol changes or additions. Backwards compatibility is required. Significant changes to the existing protocol standards are out of scope, including any work on version 2 of any of these protocols. Security for these protocols is based on the functionality specified in RFC 3723 (Securing Block Storage Protocols over IP); the working group does not intend to make major changes or updates to that RFC. Stability is critical to the usage of these protocols, so backwards compatibility with existing implementations will be a requirement imposed on for all protocol changes and additions. Note that this is a requirement for implementation compatibility - if it is the case that all implementations of a protocol have done something different than what the RFC specifies, it is appropriate for a new RFC to document what the "running code" actually does and deprecate the unused original behavior. List of work items: (1) iSCSI: Combine RFCs 3720 (iSCSI), 3980 (NAA names), 4850 (node architecture key) and 5048 (corrections/clarifications) into one draft (3720bis), removing features that are not implemented in practice. This draft should be prepared so that it could become a Draft Standard RFC, but the Working Group has decided not to advance it to Draft Standard status. (2) iSCSI: Add features to support at least SAM-4 (4th version of the SCSI architecture) in a backwards-compatible fashion, as iSCSI is currently based on SAM-2. This will be a separate draft from the iSCSI update in the previous item. The Working Group may add additional minor useful iSCSI features to this draft, including features from draft versions of SAM-5. The iSCSI MIB (RFC 4544) should be updated to provide SNMP support for new features as appropriate. (3) FCIP: IP Protocol number 133 was allocated to a precursor of the FCIP protocol in 2000, but this allocated number is not used by FCIP. The Working Group has documented the deployed pre-standard use of this protocol number in RFC 6172, and IANA has updated the registry entry to reference RFC 6172. (4) iFCP: The Address Translation mode of iFCP needs to be deprecated (SHOULD NOT implement or use), as there are significant technical problems with its specification, and moreover, only the Address Transparent mode of iFCP is in use. This will be done via a short draft that updates RFC 4172, and not via a complete rewrite of RFC 4172. The Working Group has deprecated iFCP Address Translation mode in RFC 6172 and made the corresponding changes to the iFCP MIB (originally RFC 4369) in RFC 6173. (5) RDDP MPA: Good support for MPI applications requires a small update to the startup functionality to allow either end of the connection to initiate. In addition, a couple of minor changes to RDDP connection setup are needed based on implementation experience. (6) iSER: Experience with Infiniband implementations suggest a few minor updates to reflect what has been done in practice. (7) RDMA Protocol: Experience with the rddp (iWARP) RDMA Protocol (RFC 5040) suggests that some minor extensions are needed, specifically, the addition of immediate data support and remote atomic operations. The Working Group is expected to maintain good working relationships with INCITS Technical Committee T10 (SCSI standards) and INCITS Technical Committee T11 (Fibre Channel standards) via overlaps in membership as opposed to appointment of formal liaisons. The liaison process (including IAB appointment of a liaison or liaisons) remains available for use if needed. Recent changes in INCITS rules have removed public access to some T10 and T11 standards documents that are expected to be needed for the WG's program of work. Arrangements have been made with T10 and T11 for IETF participants to obtain copies of specific standards their personal use in IETF work as needed; contact the WG chair(s) for details. Goals and Milestones: Done - First version of combined iSCSI draft (3720bis) Done - First version of iSCSI SAM-4 (and other) new features draft Done - First version of RDDP MPA startup change draft Done - First version of FCIP protocol number and iFCP Address Translation mode draft Done - First version of iSER update draft Done - Working Group Last Call on FCIP protocol number and iFCP address change draft Done - Working Group Last Call on RDDP MPA startup change draft Done - Functionally complete iSCSI SAM-4 (and other) new features draft Done - Working Group decision on whether to seek Draft Standard RFC status for the combined iSCSI draft (3720bis). [Note: decision may be made significantly before this date.] Done - Working Group Last Call on combined iSCSI draft (3720bis) plus iSCSI SAM-4 (and other) new features draft Done - First version of iSCSI MIB update draft Done - Working Group Last Call on RDDP registries draft Done - Submit RDDP registries draft to IESG for consideration as a Standards Track document Done - Working Group Last Call on iSER update draft Done - Submit combined iSCSI draft and iSCSI new features draft to IESG for consideration as Standards Track documents Done - Working Group Last Call on iSCSI MIB update draft Done - Submit iSCSI MIB draft to IESG for consideration as a Standards Track document May 2012 - Submit iSER draft to IESG for consideration as a Standards Track document Jun 2012 - Working Group Last Call on RDMA Protocol Extensions draft Sep 2012 - Submit RDMA Protocol Extensions draft to IESG for consideration as a Standards Track document Internet-Drafts: - Deprecation of the Internet Fibre Channel Protocol (iFCP) Address Translation Mode [draft-ietf-storm-ifcp-ipn133-updates-03] (6 pages) - Definitions of Managed Objects for the Internet Fibre Channel Protocol (iFCP) [draft-ietf-storm-ifcpmib-07] (31 pages) - iSCSI Protocol (Consolidated) [draft-ietf-storm-iscsi-cons-05] (341 pages) - Internet Small Computer Systems Interface (iSCSI) SCSI Features Update [draft-ietf-storm-iscsi-sam-05] (1 pages) - Definitions of Managed Objects for Internet Small Computer System Interface (iSCSI) [draft-ietf-storm-iscsimib-01] (86 pages) - iSCSI Extensions for RDMA Specification [draft-ietf-storm-iser-08] (95 pages) - Enhanced Remote Direct Memory Access (RDMA) Connection Establishment [draft-ietf-storm-mpa-peer-connect-09] (25 pages) - IANA Registries for the Remote Direct Data Placement (RDDP) Protocols [draft-ietf-storm-rddp-registries-02] (11 pages) - RDMA Protocol Extensions [draft-ietf-storm-rdmap-ext-02] (31 pages) Requests for Comments: RFC6172: Deprecation of the Internet Fibre Channel Protocol (iFCP) Address Translation Mode (6 pages) * Updates RFC4172 RFC6173: Definitions of Managed Objects for the Internet Fibre Channel Protocol (iFCP) (31 pages) * Obsoletes RFC4369 RFC6580: IANA Registries for the Remote Direct Data Placement (RDDP) Protocols (11 pages) RFC6581: Enhanced Remote Direct Memory Access (RDMA) Connection Establishment (25 pages) * Updates RFC5043 * Updates RFC5044 TCP Maintenance and Minor Extensions (tcpm) ------------------------------------------- Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Michael Scharf Yoshifumi Nishida Pasi Sarolahti Transport Area Directors: Wesley Eddy Martin Stiemerling Transport Area Advisor: Wesley Eddy Mailing Lists: General Discussion: tcpm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tcpm Archive: http://www.ietf.org/mail-archive/web/tcpm/ Description of Working Group: TCP is currently the Internet's predominant transport protocol. To maintain TCP's utility the IETF has regularly updated both the protocol itself and the congestion control algorithms implemented by the protocol that are crucial for the stability of the Internet. These changes reflect our evolving understanding of transport protocols, congestion control and new needs presented by an ever-changing network. The TCPM WG will provide a venue within the IETF to work on these issues. The WG will serve several purposes: * The WG will mostly focus on maintenance issues (e.g., bug fixes) and modest changes to the protocol and algorithms that maintain TCP's utility. * The WG will be a venue for moving current TCP specifications along the standards track (as community energy is available for such efforts). * The WG will write a document that outlines "what is TCP". This document will be a roadmap of sorts to the various TCP specifications in the RFC series. TCPM will take a subset of the work which has been conducted in the Transport Area WG over the past several years. Specifically, some of the WG's initial work will be moved from the Transport Area WG (tsvwg). TCPM is expected to be the working group within the IETF to handle TCP changes. Proposals for additional TCP work items should be brought up within the working group. While fundamental changes to TCP or its congestion control algorithms (e.g., departure from loss-based congestion control) should be brought through TCPM, it is expected that such large changes will ultimately be handled by the Transport Area WG (tsvwg). All additional work items for TCPM will, naturally, require the approval of the Transport Services Area Area Directors and the IESG. TCP's congestion control algorithms are the model followed by alternate transports (e.g., SCTP and (in some cases) DCCP). In addition, the IETF has recently worked on several documents about algorithms that are specified for multiple protocols (e.g., TCP and SCTP) in the same document. Which WG shepherds such documents in the future will determined on a case-by-case basis. In any case, the TCPM WG will remain in close contact with other relevant WGs working on these protocols to ensure openness and stringent review from all angles. Specific Goals: * A document specifying a way to share the local "User TimeOut" value with the peer such that TCP connections can withstand long periods of disconnection. * The WG is coming to grips with how to deal with spoofed segments that can tear down connections, cause data corruption or performance problems. To this end the WG is generating an overview document as well as a scheme that mitigates some of the issues brought on by spoofed TCP segments using a challenge-response scheme to reduce the probabilities of a connection being impacted. Finally, the WG will produce a document outlining the potential impact of using ICMP messages to attack TCP streams. * The WG is writing an informational document about the ways in which TCPs can handle ICMP "soft errors". * The WG is updating the specification for Explicit Congestion Notification to allow for the use of ECN during part of TCP's three-way handshake to aid performance for short transfers. * The WG is writing an informational document that discusses commonly used, but not documented ways to combat SYN flooding attacks. * The WG is updating RFC 2581 to fix some minor specification problems and move it along the standards track. Goals and Milestones: Done - Submit FRTO draft to IESG for publication as an Experimental RFC Done - Submit TCP Roadmap document to IESG for publication as a Best Current Practices RFC Done - Submit NCR Reordering Mitigation draft to the IESG for publication as an Experimental RFC Done - Submit overview of spoofing attacks against TCP to IESG for publication as an Informational RFC Done - Submit User TimeOut option document to the IESG for publication as a Proposed Standard RFC Done - Submit SYN flooding document to the IESG for publication as an Informational RFC Done - Submit soft errors document to the IESG for publication as an Informational RFC Done - Submit In-Window Attack draft to IESG for publication as a Proposed Standard RFC Done - Submit ECN-SYN document to the IESG for publication as a Proposed Standard RFC Done - Submit revision of RFC 2581 to the IESG for publication as a Draft Standard Done - Submit TCP Authentication Option document to the IESG for Proposed Standard RFC Done - Submit ICMP attack document to the IESG for publication as an Informational RFC Done - Submit TCP Early-Retransmit document to the IESG for Experimental RFC Jul 2009 - Submit update to RFC 1323 to the IESG for Proposed Standard RFC Done - Submit MSS text revision originally from RFC 1323 appendix to the IESG for Proposed Standard RFC Done - Submit TCP Urgent Pointer draft to IESG for publication as a Proposed Standard RFC Aug 2010 - Submit document on security hardening of TCP implementations to the IESG for publication as a Best Current Practices RFC Done - Submit document on the use of SACK data to trigger loss recovery to the IESG for Proposed Standard Done - Submit document on mitigation of 'Long Connectivity Disruptions' to the IESG for Experimental Done - Submit document on moving undeployed TCP extensions to Historic status to the IESG for publication as an Informational RFC Done - Submit RFC2988bis document to the IESG for publication as a Proposed Standard Done - Submit document updating the NewReno RFC 3782 to the IESG for publication as Proposed Standard Sep 2011 - Submit document on increasing the initial window to IESG as Experimental Done - Submit RFC1948bis document to the IESG for publication as a Proposed Standard May 2012 - Submit document on a proportional rate reduction mechanism to the IESG as Experimental Sep 2012 - Submit document on shared use of experimental TCP options to the IESG for publication as a Proposed Standard RFC Sep 2012 - Submit document on a TCP fast open mechanism to the IESG for publication as an Experimental RFC Internet-Drafts: - Moving the Undeployed TCP Extensions RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693 to Historic Status [draft-eggert-tcpm-historicize-02] (4 pages) - TCP Extensions for High Performance [draft-ietf-tcpm-1323bis-01] (47 pages) - A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP [draft-ietf-tcpm-3517bis-02] (14 pages) - Support for Stronger Error Detection Codes in TCP for Jumbo Frames [draft-ietf-tcpm-anumita-tcp-stronger-checksum-00] (10 pages) - Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP) [draft-ietf-tcpm-early-rexmt-04] (12 pages) - Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets [draft-ietf-tcpm-ecnsyn-10] (35 pages) - Shared Use of Experimental TCP Options [draft-ietf-tcpm-experimental-options-00] (6 pages) - TCP Fast Open [draft-ietf-tcpm-fastopen-00] (21 pages) - Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP) [draft-ietf-tcpm-frto-02] (22 pages) - ICMP Attacks against TCP [draft-ietf-tcpm-icmp-attacks-12] (41 pages) - Increasing TCP's Initial Window [draft-ietf-tcpm-initcwnd-03] (22 pages) - TCP Sender Clarification for Persist Condition [draft-ietf-tcpm-persist-07] (11 pages) - Proportional Rate Reduction for TCP [draft-ietf-tcpm-proportional-rate-reduction-01] (16 pages) - Defending against Sequence Number Attacks [draft-ietf-tcpm-rfc1948bis-02] (13 pages) - TCP Congestion Control [draft-ietf-tcpm-rfc2581bis-07] (17 pages) - The NewReno Modification to TCP's Fast Recovery Algorithm [draft-ietf-tcpm-rfc3782-bis-05] (15 pages) - Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP [draft-ietf-tcpm-rfc4138bis-04] (21 pages) - Using TCP Selective Acknowledgement (SACK) Information to Determine Duplicate Acknowledgements for Loss Recovery Initiation [draft-ietf-tcpm-sack-recovery-entry-01] (18 pages) - TCP SYN Flooding Attacks and Common Mitigations [draft-ietf-tcpm-syn-flood-05] (24 pages) - Defending TCP Against Spoofing Attacks [draft-ietf-tcpm-tcp-antispoof-06] (29 pages) - Cryptographic Algorithms for the TCP Authentication Option (TCP-AO) [draft-ietf-tcpm-tcp-ao-crypto-03] (16 pages) - The TCP Authentication Option [draft-ietf-tcpm-tcp-auth-opt-11] (48 pages) - Improving the Robustness of TCP to Non-Congestion Events [draft-ietf-tcpm-tcp-dcr-07] (18 pages) - Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD) [draft-ietf-tcpm-tcp-lcd-03] (27 pages) - A Roadmap for Transmission Control Protocol (TCP) Specification Documents [draft-ietf-tcpm-tcp-roadmap-06] (42 pages) - Survey of Security Hardening Methods for Transmission Control Protocol (TCP) Implementations [draft-ietf-tcpm-tcp-security-03] (86 pages) - TCP's Reaction to Soft Errors [draft-ietf-tcpm-tcp-soft-errors-09] (17 pages) - Reducing the TIME-WAIT State Using TCP Timestamps [draft-ietf-tcpm-tcp-timestamps-04] (11 pages) - TCP User Timeout Option [draft-ietf-tcpm-tcp-uto-11] (17 pages) - TCP Options and MSS [draft-ietf-tcpm-tcpmss-04] (9 pages) - Improving TCP's Robustness to Blind In-Window Attacks [draft-ietf-tcpm-tcpsecure-13] (26 pages) - On the Implementation of the TCP Urgent Mechanism [draft-ietf-tcpm-urgent-data-07] (14 pages) - Cryptographic Algorithms, Use, & Implementation Requirments for TCP Authentication Option [draft-lebovitz-ietf-tcpm-tcp-ao-crypto-02] (16 pages) - Computing TCP's Retransmission Timer [draft-paxson-tcpm-rfc2988bis-02] (9 pages) Requests for Comments: BCP0159: Reducing the TIME-WAIT State Using TCP Timestamps (11 pages) * Replaces DRAFT-GONT-TCPM-TCP-TIMESTAMPS RFC4138: Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP) (22 pages) * Replaces DRAFT-IETF-TSVWG-TCP-FRTO * Updates RFC5682 RFC4614: A Roadmap for Transmission Control Protocol (TCP) Specification Documents (42 pages) * Updates RFC6247 RFC4653: Improving the Robustness of TCP to Non-Congestion Events (18 pages) RFC4953: Defending TCP Against Spoofing Attacks (29 pages) RFC4987: TCP SYN Flooding Attacks and Common Mitigations (24 pages) RFC5461: TCP's Reaction to Soft Errors (17 pages) RFC5482: TCP User Timeout Option (17 pages) RFC5562: Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets (35 pages) * Replaces DRAFT-IETF-TSVWG-ECNSYN RFC5681: TCP Congestion Control (17 pages) * Obsoletes RFC2581 RFC5682: Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP (21 pages) * Updates RFC4138 RFC5827: Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP) (12 pages) RFC5925: The TCP Authentication Option (48 pages) * Obsoletes RFC2385 RFC5926: Cryptographic Algorithms for the TCP Authentication Option (TCP-AO) (16 pages) * Replaces DRAFT-LEBOVITZ-IETF-TCPM-TCP-AO-CRYPTO RFC5927: ICMP Attacks against TCP (41 pages) RFC5961: Improving TCP's Robustness to Blind In-Window Attacks (26 pages) RFC6069: Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD) (27 pages) RFC6093: On the Implementation of the TCP Urgent Mechanism (14 pages) * Replaces DRAFT-GONT-TCPM-URGENT-DATA * Updates RFC793 * Updates RFC1011 * Updates RFC1122 RFC6191: Reducing the TIME-WAIT State Using TCP Timestamps (11 pages) * Replaces DRAFT-GONT-TCPM-TCP-TIMESTAMPS RFC6247: Moving the Undeployed TCP Extensions RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693 to Historic Status (4 pages) * Obsoletes RFC1072 * Obsoletes RFC1106 * Obsoletes RFC1110 * Obsoletes RFC1145 * Obsoletes RFC1146 * Obsoletes RFC1379 * Obsoletes RFC1644 * Obsoletes RFC1693 * Updates RFC4614 RFC6298: Computing TCP's Retransmission Timer (9 pages) * Updates RFC1122 * Obsoletes RFC2988 RFC6429: TCP Sender Clarification for Persist Condition (11 pages) * Replaces DRAFT-ANANTH-TCPM-PERSIST RFC6528: Defending against Sequence Number Attacks (13 pages) * Updates RFC793 * Obsoletes RFC1948 * Replaces DRAFT-GONT-TCPM-RFC1948BIS RFC6582: The NewReno Modification to TCP's Fast Recovery Algorithm (15 pages) * Obsoletes RFC3782 * Replaces DRAFT-HENDERSON-TCPM-RFC3782-BIS Transport Area Working Group (tsvwg) ------------------------------------ Charter Last Modified: 2011-12-09 Current Status: Active Chairs: Gorry Fairhurst James M. Polk Transport Area Directors: Wesley Eddy Martin Stiemerling Transport Area Advisor: Wesley Eddy Mailing Lists: General Discussion: tsvwg@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tsvwg Archive: http://www.ietf.org/mail-archive/web/tsvwg/ Description of Working Group: The Transport Area receives occasional proposals for the development and publication of RFCs dealing with transport topics that are not in scope of an existing working group or do not justify the formation of a new working group. TSVWG will serve as the forum for developing such work items in the IETF. The TSVWG 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. The currently active TSVWG work items mostly fall under the Following topics: (A) Maintenance of the Stream Control Transmission Protocol (SCTP), which involves bug fixes to the SCTP specifications and their progression along the standards track. This work item also includes a small number of modular extensions to SCTP. In order to maintain stable specifications, additional work on SCTP in TSVWG requires Area Director approval. (B) Maintenance of the Resource Reservation Protocol (RSVP) which involves bug fixes to RSVP specifications and their progression along the standards track. This work item may also include a small number of extensions to both RSVP and Integrated Services or advisory documents to address specific application scenarios. In order to maintain stable specifications, additional work on RSVP and/or Integrated Services in TSVWG requires Area Director approval. (C) Maintenance of IP Differentiated Services (DiffServ) mechanisms, which involves mostly advisory documents on the use of DiffServ in specific application scenarios. Other work items related to DiffServ require Area Director approval. (D) Selected other work items, which are mostly in TSVWG for historic reasons. Additional work that does not fall under one of the above topics in TSVWG must satisfy four conditions: (1) WG consensus on the suitability and projected quality of the proposed work item. (2) A core group of WG participants with sufficient energy and expertise to advance the work item according to the proposed schedule. (3) Commitment from the WG as a whole to provide sufficient and timely review of the proposed work item. (4) Agreement by the ADs, who, depending on the scope of the proposed work item, may decide that an IESG review is needed first. Goals and Milestones: Done - Updates to RFC 793 to resolve conflict between diffserv and TCP interpretation of IP Precedence submitted for publication as Proposed Standard Done - Addition to RFC 2018 to use TCP SACK for detecting unnecessary retransmissions submitted for publication as Proposed Standard Done - Submit I-D on TCP Congestion Window Validation to IESG for consideration as a Proposed Standard Done - Submit I-D on Computing TCP's Retransmission Timer to IESG for consideration as a Proposed Standard. Done - Submit revised ID for ECN to IESG for consideration as a proposed standard Done - Submit ID on UDP-lite to IESG for consideration as a proposed standard Done - TCP-Friendly Rate Control (TFRC) unicast congestion control algorithm submitted to IESG for consideration as a proposed standard Done - Submit ID for SCTP unreliable transport mode to IESG for consideration as a Proposed Standard Done - Submit 'Alternate Semantics for the ECN Field' to IESG for consideration as BCP Done - Submit 'Aggregation of RSVP Reservations over MPLS TE/DS-TE Tunnels' to IESG for consideration as PS Done - Submit Submit 'QoS Signaling in a Nested Virtual Private Network' to IESG for consideration as Informational Done - Submit 'Generic Aggregate RSVP Reservations' to IESG for consideration as PS Done - Submit 'Quick-Start for TCP and IP' to IESG for consideration as Experimental Done - Submit 'TCP Extended Statistics MIB' to IESG for consideration as PS Done - Submit 'Authenticated Chunks for Stream Control Transmission Protocol' to IESG as consideration as PS Done - Submit 'Padding Chunk and Parameter for SCTP' to IESG for consideration as PS Done - Submit 'SCTP Dynamic Address Reconfiguration' to IESG for consideration as Proposed Standard Done - Submit revision of 'Stream Control Transmission Protocol' to IESG for consideration as Proposed Standard Done - Submit 'Security Attacks Found Against SCTP and Current Countermeasures' to IESG for consideration as Informational Done - Submit 'Specifying New Congestion Control Algorithms' to IESG for consideration as Best Current Practice Done - Submit 'Aggregation of DiffServ Service Classes' to IESG for consideration as Informational Done - Submit 'Explicit Congestion Marking in MPLS' to IESG for consideration as Proposed Standard Done - Submit 'User-Defined Errors for RSVP' to IESG for consideration as Proposed Standard Done - Submit 'RSVP Extensions for Emergency Services' to IESG for consideration as Proposed Standard Done - Submit 'DSCPs for Capacity-Admitted Traffic' to IESG for consideration as Proposed Standard Done - Submit 'RSVP Proxy Approaches' to IESG for consideration as Informational Done - Submit 'RSVP Extensions for Path-Triggered RSVP Receiver Proxy' to IESG for consideration as Proposed Standard Done - Submit 'UDP Usage Guidelines for Application Designers' to IESG for consideration as Best Current Practice Done - Request publication of 'Support for RSVP in Layer 3 VPNs' as Proposed Standard RFC Done - Submit 'Port Randomization for Transport Protocols' to the IESG for consideration as a Best Current Practice Done - Submit 'Applicability of Keying Methods for RSVP Security' to IESG for consideration as Informational Done - Request publication of 'IANA Procedures for the Transport Protocol Port Number Space' as BCP RFC Done - Request publication of 'Datagram Transport Layer Security for Stream Control Transmission' as Proposed Standard Done - Request publication of 'Layered Encapsulation of Congestion Notification' as Proposed Standard Done - Submit 'SCTP Chunk Flags Registration' to IESG for consideration as a Proposed Standard Done - Submit 'Sockets API Extensions for SCTP' to IESG for consideration as Informational Done - Submit 'SCTP Stream Reconfiguration' to IESG for consideration as a Proposed Standard Done - Submit 'Deprecation of ICMP Source Quench messages' to IESG for consideration as a Proposed Standard Dec 2011 - Submit 'SCTP NAT Support' to IESG for consideration as a Proposed Standard Apr 2012 - Submit 'Byte and Packet Congestion Notification' to IESG for consideration as a Best Current Practice RFC Apr 2012 - Submit 'UDP Encapsulation of SCTP Packets' to IESG for consideration as a Proposed Standard RFC May 2012 - Submit Encoding and Transport of (Pre-) Congestion Information from the Domain Egress to the Ingress to the IESG for consideration as a Proposed Standard RFC May 2012 - Submit 'Intserv Multiple TSpec' to IESG for consideration as a Proposed Standard RFC Mar 2013 - Recommendations for Transport Port Uses Internet-Drafts: - A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP [draft-allman-tcp-sack-13] (10 pages) - An Extension to the Selective Acknowledgement (SACK) Option for TCP [draft-floyd-sack-00] (14 pages) - TCP Congestion Window Validation [draft-handley-tcp-cwv-01] (11 pages) - Stream Control Transmission Protocol [draft-ietf-tsvwg-2960bis-05] (150 pages) - Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration [draft-ietf-tsvwg-addip-sctp-22] (41 pages) - A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic [draft-ietf-tsvwg-admitted-realtime-dscp-07] (13 pages) - Byte and Packet Congestion Notification [draft-ietf-tsvwg-byte-pkt-congest-07] (43 pages) - Specifying New Congestion Control Algorithms [draft-ietf-tsvwg-cc-alt-04] (11 pages) - Aggregation of DiffServ Service Classes [draft-ietf-tsvwg-diffserv-class-aggr-07] (19 pages) - Configuration Guidelines for DiffServ Service Classes [draft-ietf-tsvwg-diffserv-service-classes-02] (59 pages) - Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions [draft-ietf-tsvwg-dsack-use-02] (7 pages) - Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP) [draft-ietf-tsvwg-dtls-for-sctp-06] (10 pages) - The Addition of Explicit Congestion Notification (ECN) to IP [draft-ietf-tsvwg-ecn-04] (63 pages) - Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field [draft-ietf-tsvwg-ecn-alternates-02] (17 pages) - An Open ECN Service in the IP layer [draft-ietf-tsvwg-ecn-ip-00] (15 pages) - Explicit Congestion Marking in MPLS [draft-ietf-tsvwg-ecn-mpls-02] (20 pages) - Tunnelling of Explicit Congestion Notification [draft-ietf-tsvwg-ecn-tunnel-10] (42 pages) - ECN Interactions with IP Tunnels [draft-ietf-tsvwg-ecn-tunnels-00] (13 pages) - Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets [draft-ietf-tsvwg-ecnsyn-00] (14 pages) - RSVP Extensions for Admission Priority [draft-ietf-tsvwg-emergency-rsvp-15] (33 pages) - HighSpeed TCP for Large Congestion Windows [draft-ietf-tsvwg-highspeed-01] (36 pages) - Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry [draft-ietf-tsvwg-iana-ports-10] (32 pages) - Increasing TCP's Initial Window [draft-ietf-tsvwg-initwin-04] (13 pages) - Integrated Services (IntServ) Extension to Allow Signaling of Multiple Traffic Specifications and Multiple Flow Specifications in RSVPv1 [draft-ietf-tsvwg-intserv-multiple-tspec-01] (26 pages) - Enhancing TCP's Loss Recovery Using Limited Transmit [draft-ietf-tsvwg-limited-xmit-00] (7 pages) - MLEF Without Capacity Admission Does Not Satisfy MLPP Requirements [draft-ietf-tsvwg-mlef-concerns-00] (20 pages) - Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite [draft-ietf-tsvwg-mlpp-that-works-04] (45 pages) - Stream Control Transmission Protocol (SCTP) Network Address Translation Support [draft-ietf-tsvwg-natsupp-02] (15 pages) - The NewReno Modification to TCP's Fast Recovery Algorithm [draft-ietf-tsvwg-newreno-02] (20 pages) - Recommendations for Transport-Protocol Port Randomization [draft-ietf-tsvwg-port-randomization-09] (36 pages) - Stream Control Transmission Protocol (SCTP) Partial Reliability Extension [draft-ietf-tsvwg-prsctp-03] (23 pages) - Quick-Start for TCP and IP [draft-ietf-tsvwg-quickstart-07] (90 pages) - Stream Control Transmission Protocol [draft-ietf-tsvwg-rfc2960-bis-00] (116 pages) - A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow [draft-ietf-tsvwg-rsvp-bw-reduction-02] (18 pages) - Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels [draft-ietf-tsvwg-rsvp-dste-05] (31 pages) - Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations [draft-ietf-tsvwg-rsvp-ipsec-05] (30 pages) - Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs [draft-ietf-tsvwg-rsvp-l3vpn-07] (38 pages) - Generic Aggregation of Resource ReSerVation Protocol (RSVP) for IPv4 And IPv6 Reservations over PCN domains [draft-ietf-tsvwg-rsvp-pcn-01] (26 pages) - Resource Reservation Protocol (RSVP) Proxy Approaches [draft-ietf-tsvwg-rsvp-proxy-approaches-09] (51 pages) - Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy [draft-ietf-tsvwg-rsvp-proxy-proto-11] (41 pages) - Applicability of Keying Methods for RSVP Security [draft-ietf-tsvwg-rsvp-security-groupkeying-11] (19 pages) - User-Defined Errors for RSVP [draft-ietf-tsvwg-rsvp-user-error-spec-08] (9 pages) - Authenticated Chunks for the Stream Control Transmission Protocol (SCTP) [draft-ietf-tsvwg-sctp-auth-08] (20 pages) - Stream Control Transmission Protocol (SCTP) Chunk Flags Registration [draft-ietf-tsvwg-sctp-chunk-flags-02] (8 pages) - Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP) [draft-ietf-tsvwg-sctp-padding-02] (8 pages) - Stream Control Transmission Protocol (SCTP) Stream Reconfiguration [draft-ietf-tsvwg-sctp-strrst-13] (33 pages) - UDP Encapsulation of SCTP Packets [draft-ietf-tsvwg-sctp-udp-encaps-03] (10 pages) - Stream Control Transmission Protocol (SCTP) Checksum Change [draft-ietf-tsvwg-sctpcsum-07] (14 pages) - Stream Control Transmission Protocol (SCTP) Specification Errata and Issues [draft-ietf-tsvwg-sctpimpguide-16] (109 pages) - Sockets API Extensions for the Stream Control Transmission Protocol (SCTP) [draft-ietf-tsvwg-sctpsocket-32] (113 pages) - Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures [draft-ietf-tsvwg-sctpthreat-05] (16 pages) - Limited Slow-Start for TCP with Large Congestion Windows [draft-ietf-tsvwg-slowstart-00] (7 pages) - Deprecation of ICMP Source Quench messages [draft-ietf-tsvwg-source-quench-06] (9 pages) - TCP with ECN: The Treatment of Retransmitted Data Packets [draft-ietf-tsvwg-tcp-ecn-00] (9 pages) - The Eifel Detection Algorithm for TCP [draft-ietf-tsvwg-tcp-eifel-alg-07] (12 pages) - The Eifel Response Algorithm for TCP [draft-ietf-tsvwg-tcp-eifel-response-06] (12 pages) - F-RTO: An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and SCTP [draft-ietf-tsvwg-tcp-frto-01] (19 pages) - TCP Extended Statistics MIB [draft-ietf-tsvwg-tcp-mib-extension-15] (82 pages) - Robust Explicit Congestion Notification (ECN) Signaling with Nonces [draft-ietf-tsvwg-tcp-nonce-04] (12 pages) - ULP Framing for TCP [draft-ietf-tsvwg-tcp-ulp-frame-01] (30 pages) - TCP Friendly Rate Control (TFRC): Protocol Specification [draft-ietf-tsvwg-tfrc-05] (26 pages) - Transport Layer Security over Stream Control Transmission Protocol [draft-ietf-tsvwg-tls-over-sctp-00] (8 pages) - Unicast UDP Usage Guidelines for Application Designers [draft-ietf-tsvwg-udp-guidelines-11] (28 pages) - The Lightweight User Datagram Protocol (UDP-Lite) [draft-ietf-tsvwg-udp-lite-02] (13 pages) - MIB for the UDP-Lite protocol [draft-ietf-tsvwg-udplite-mib-03] (35 pages) - SCTP Unreliable Data Mode Extension [draft-ietf-tsvwg-usctp-00] (10 pages) - Quality of Service (QoS) Signaling in a Nested Virtual Private Network [draft-ietf-tsvwg-vpn-signaled-preemption-02] (38 pages) - Computing TCP's Retransmission Timer [draft-paxson-tcp-rto-01] (6 pages) - TCP Processing of the IPv4 Precedence Field [draft-xiao-tcp-prec-03] (7 pages) Requests for Comments: BCP0124: Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field (17 pages) BCP0133: Specifying New Congestion Control Algorithms (11 pages) * Replaces DRAFT-FLOYD-TSVWG-CC-ALT BCP0145: Unicast UDP Usage Guidelines for Application Designers (28 pages) * Replaces DRAFT-EGGERT-TSVWG-UDP-GUIDELINES BCP0156: Recommendations for Transport-Protocol Port Randomization (36 pages) * Replaces DRAFT-LARSEN-TSVWG-PORT-RANDOMIZATION BCP0165: Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry (32 pages) * Replaces DRAFT-COTTON-TSVWG-IANA-PORTS * Updates RFC2780 * Updates RFC2782 * Updates RFC3828 * Updates RFC4340 * Updates RFC4960 * Updates RFC5595 RFC2861: TCP Congestion Window Validation (11 pages) RFC2873: TCP Processing of the IPv4 Precedence Field (7 pages) RFC2883: An Extension to the Selective Acknowledgement (SACK) Option for TCP (14 pages) RFC2988: Computing TCP's Retransmission Timer (6 pages) * Obsoletes RFC6298 RFC3042: Enhancing TCP's Loss Recovery Using Limited Transmit (7 pages) RFC3168: The Addition of Explicit Congestion Notification (ECN) to IP (63 pages) * Updates RFC793 * Updates RFC2003 * Updates RFC2401 * Updates RFC2474 * Obsoletes RFC2481 * Updates RFC4301 * Updates RFC6040 RFC3309: Stream Control Transmission Protocol (SCTP) Checksum Change (14 pages) * Updates RFC2960 * Obsoletes RFC4960 RFC3390: Increasing TCP's Initial Window (13 pages) * Obsoletes RFC2414 * Updates RFC2581 RFC3436: Transport Layer Security over Stream Control Transmission Protocol (8 pages) RFC3448: TCP Friendly Rate Control (TFRC): Protocol Specification (26 pages) * Obsoletes RFC5348 RFC3517: A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP (10 pages) RFC3522: The Eifel Detection Algorithm for TCP (12 pages) * Replaces DRAFT-LUDWIG-TSVWG-TCP-EIFEL-ALG RFC3540: Robust Explicit Congestion Notification (ECN) Signaling with Nonces (12 pages) RFC3649: HighSpeed TCP for Large Congestion Windows (36 pages) RFC3708: Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions (7 pages) RFC3742: Limited Slow-Start for TCP with Large Congestion Windows (7 pages) RFC3758: Stream Control Transmission Protocol (SCTP) Partial Reliability Extension (23 pages) * Replaces DRAFT-STEWART-TSVWG-PRSCTP RFC3782: The NewReno Modification to TCP's Fast Recovery Algorithm (20 pages) * Obsoletes RFC2582 * Obsoletes RFC6582 RFC3828: The Lightweight User Datagram Protocol (UDP-Lite) (13 pages) * Updates RFC6335 RFC4015: The Eifel Response Algorithm for TCP (12 pages) RFC4460: Stream Control Transmission Protocol (SCTP) Specification Errata and Issues (109 pages) RFC4495: A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow (18 pages) * Updates RFC2205 RFC4542: Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite (45 pages) * Replaces DRAFT-BAKER-TSVWG-MLPP-THAT-WORKS * Updates RFC5865 RFC4594: Configuration Guidelines for DiffServ Service Classes (59 pages) * Updates RFC5865 RFC4774: Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field (17 pages) * Updates RFC6040 RFC4782: Quick-Start for TCP and IP (90 pages) RFC4804: Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels (31 pages) RFC4820: Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP) (8 pages) * Replaces DRAFT-TUEXEN-TSVWG-SCTP-PADDING RFC4860: Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations (30 pages) RFC4895: Authenticated Chunks for the Stream Control Transmission Protocol (SCTP) (20 pages) RFC4898: TCP Extended Statistics MIB (82 pages) RFC4923: Quality of Service (QoS) Signaling in a Nested Virtual Private Network (38 pages) * Replaces DRAFT-BAKER-TSVWG-VPN-SIGNALED-PREEMPTION RFC4960: Stream Control Transmission Protocol (150 pages) * Replaces DRAFT-IETF-TSVWG-RFC2960-BIS * Obsoletes RFC2960 * Obsoletes RFC3309 * Updates RFC6096 * Updates RFC6335 RFC5033: Specifying New Congestion Control Algorithms (11 pages) * Replaces DRAFT-FLOYD-TSVWG-CC-ALT RFC5061: Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration (41 pages) RFC5062: Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures (16 pages) * Replaces DRAFT-STEWART-TSVWG-SCTPTHREAT RFC5097: MIB for the UDP-Lite protocol (35 pages) * Replaces DRAFT-RENKER-TSVWG-UDPLITE-MIB RFC5127: Aggregation of DiffServ Service Classes (19 pages) * Replaces DRAFT-CHAN-TSVWG-DIFFSERV-CLASS-AGGR RFC5129: Explicit Congestion Marking in MPLS (20 pages) * Updates RFC3032 * Updates RFC5462 RFC5284: User-Defined Errors for RSVP (9 pages) * Replaces DRAFT-SWALLOW-RSVP-USER-ERROR-SPEC RFC5405: Unicast UDP Usage Guidelines for Application Designers (28 pages) * Replaces DRAFT-EGGERT-TSVWG-UDP-GUIDELINES RFC5865: A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic (13 pages) * Replaces DRAFT-BAKER-TSVWG-ADMITTED-VOICE-DSCP * Updates RFC4542 * Updates RFC4594 RFC5945: Resource Reservation Protocol (RSVP) Proxy Approaches (51 pages) RFC5946: Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy (41 pages) * Replaces DRAFT-LEFAUCHEUR-TSVWG-RSVP-PROXY * Updates RFC2205 RFC6016: Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs (38 pages) * Replaces DRAFT-DAVIE-TSVWG-RSVP-L3VPN RFC6040: Tunnelling of Explicit Congestion Notification (42 pages) * Replaces DRAFT-BRISCOE-TSVWG-ECN-TUNNEL * Updates RFC3168 * Updates RFC4301 * Updates RFC4774 RFC6056: Recommendations for Transport-Protocol Port Randomization (36 pages) * Replaces DRAFT-LARSEN-TSVWG-PORT-RANDOMIZATION RFC6083: Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP) (10 pages) * Replaces DRAFT-TUEXEN-TSVWG-DTLS-FOR-SCTP RFC6096: Stream Control Transmission Protocol (SCTP) Chunk Flags Registration (8 pages) * Replaces DRAFT-TUEXEN-TSVWG-SCTP-CHUNK-FLAGS * Updates RFC4960 RFC6335: Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry (32 pages) * Replaces DRAFT-COTTON-TSVWG-IANA-PORTS * Updates RFC2780 * Updates RFC2782 * Updates RFC3828 * Updates RFC4340 * Updates RFC4960 * Updates RFC5595 RFC6401: RSVP Extensions for Admission Priority (33 pages) RFC6411: Applicability of Keying Methods for RSVP Security (19 pages) * Replaces DRAFT-BEHRINGER-TSVWG-RSVP-SECURITY-GROUPKEYING RFC6458: Sockets API Extensions for the Stream Control Transmission Protocol (SCTP) (113 pages) RFC6525: Stream Control Transmission Protocol (SCTP) Stream Reconfiguration (33 pages) * Replaces DRAFT-STEWART-TSVWG-SCTPSTRRST