alto calsify eai lemonade httpbis idnabis ltru morg oauth sieve vcarddav yam ancp autoconf csi dna dnsext dhc hip ipdvb 16ng 6man 6lowpan l2vpn l2tpext lisp mext mipshop mip4 mif ntp netlmm netext pppext pana pwe3 shim6 softwire savi tictoc trill adslmib bmwg capwap dime dnsop grow ipfix v6ops mboned netmod netconf opsec opsawg psamp pmol radext avt bliss xcon drinks dispatch ecrit xmpp geopriv mediactrl mmusic p2psip sipcore speermint simple speechsc enum bfd ccamp forces idr isis l3vpn manet mpls ospf pce pim rtgwg roll sidr vrrp btns dkim emu hokey isms ipsecme krb-wg kitten ltans msec nea keyprov pkix smime syslog sasl tls behave pcn dccp fecframe ippm ledbat nfsv4 nsis rmt rohc tcpm tsvwg Application-Layer Traffic Optimization (alto) --------------------------------------------- Charter Last Modified: 2009-04-22 Current Status: Active Working Group Chair(s): Jon Peterson Enrico Marocco Vijay Gurbani Applications Area Director(s): Lisa Dusseault Alexey Melnikov Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion:alto@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/alto Archive: http://www.ietf.org/mail-archive/web/alto/current/maillist.html Description of Working Group: A significant part of the Internet traffic today is generated by peer-to-peer (P2P) applications used for file sharing, real-time communications, and live media streaming. P2P applications exchange large amounts of data, often uploading as much as downloading. In contrast to client/server architectures, P2P applications often must choose one or more suitable candidates from a selection of peers offering the same resource or service. One of the advantages of P2P systems comes from redundancy in resource availability. This requires choosing among a list of peers, yet applications have at best incomplete information to help the selection, e.g., topology of the network. Applications can sometimes obtain network information dynamically or measure link performance with respect to particular peers, but even when this is an option it takes time. The application cannot always start out with an optimal arrangement of peers, thus risking at least temporary poor performance and excessive cross-domain traffic. Providing more information for use in peer selection can improve P2P performance and lower ISP costs. The Working Group will design and specify an Application-Layer Traffic Optimization (ALTO) service that will provide applications with information to perform better-than-random initial peer selection. ALTO services may take different approaches at balancing factors such as maximum bandwidth, minimum cross-domain traffic, lowest cost to the user, etc. The WG will consider the needs of BitTorrent, tracker-less P2P, and other applications, such as content delivery networks (CDN) and mirror selection. The WG will focus on the following items: - A "problem statement" document providing a description of the problem and a common terminology. - A requirements document. This document will list requirements for the ALTO service, identifying, for example, types of information P2P applications may need for optimizing their choices. - A request/response protocol for querying the ALTO service to obtain information useful for peer selection, and a format for requests and responses If the requirements analysis identifies the need to allow clients to delegate third-parties to query the ALTO service on their behalf, the WG will ensure that the protocol provides a mechanism to assert the consent of the delegating client. - A document defining core request and response formats and semantics to communicate network preferences to applications. Since ALTO services may be run by entities with different level of knowledge about the underlying network, such preferences may have different representations. Initially the WG will consider: IP ranges to prefer and to avoid, ranked lists of the peers requested by the client, information about topological proximity and approximate geographic locations. Other usages will be considered as charter additions once the work for the initial services has been completed. - In order to query the ALTO server, clients must first know one or more ALTO servers that might provide useful information. The WG will look at service discovery mechanisms that are in use, or defined elsewhere (e.g. based on DNS SRV records or DHCP options). If such discovery mechanisms can be reused, the WG will produce a document to specify how they may be adopted for locating such servers. However, a new, general-purpose service discovery mechanism is not in scope. When the WG considers standardizing information that the ALTO server could provide, the following criteria are important to ensure real feasibility. - Can the ALTO service realistically discover that information? - Is the distribution of that information allowed by the operators of that service? - Is it information that a client will find useful? - Can a client get that information without excessive privacy concerns (e.g. by sending large lists of peers)? - Is it information that a client cannot find easily some other way? After these criteria are met, the importance of the data will be considered for prioritizing standardization work, for example the number of operators and clients that are likely to be able to provide or use that particular data. In any case, this WG will not propose standards on how congestion is signaled, remediated, or avoided, and will not deal with information representing instantaneous network state. Such issues belong to other IETF areas and will be treated accordingly by the specific area. This WG will focus solely on the communication protocol between applications and ALTO servers. Note that ALTO services may be useful in client-server environments as well as P2P environments, although P2P environments are the first focus. If, in the future, the IETF considers changes to other protocols for actually implementing ALTO services (e.g. application-layer protocols for Internet coordinate systems, routing protocol extensions for ISP-based solutions), such work will be done in strict coordination with the appropriate WGs. Issues related to the content exchanged in P2P systems are also excluded from the WG's scope, as is the issue dealing with enforcing the legality of the content. Description of Working Group: A significant part of the Internet traffic today is generated by peer-to-peer (P2P) applications used for file sharing, real-time communications, and live media streaming. P2P applications exchange large amounts of data, often uploading as much as downloading. In contrast to client/server architectures, P2P applications often must choose one or more suitable candidates from a selection of peers offering the same resource or service. One of the advantages of P2P systems comes from redundancy in resource availability. This requires choosing among a list of peers, yet applications have at best incomplete information to help the selection, e.g., topology of the network. Applications can sometimes obtain network information dynamically or measure link performance with respect to particular peers, but even when this is an option it takes time. The application cannot always start out with an optimal arrangement of peers, thus risking at least temporary poor performance and excessive cross-domain traffic. Providing more information for use in peer selection can improve P2P performance and lower ISP costs. The Working Group will design and specify an Application-Layer Traffic Optimization (ALTO) service that will provide applications with information to perform better-than-random initial peer selection. ALTO services may take different approaches at balancing factors such as maximum bandwidth, minimum cross-domain traffic, lowest cost to the user, etc. The WG will consider the needs of BitTorrent, tracker-less P2P, and other applications, such as content delivery networks (CDN) and mirror selection. The WG will focus on the following items: - A "problem statement" document providing a description of the problem and a common terminology. - A requirements document. This document will list requirements for the ALTO service, identifying, for example, types of information P2P applications may need for optimizing their choices. - A request/response protocol for querying the ALTO service to obtain information useful for peer selection, and a format for requests and responses If the requirements analysis identifies the need to allow clients to delegate third-parties to query the ALTO service on their behalf, the WG will ensure that the protocol provides a mechanism to assert the consent of the delegating client. - A document defining core request and response formats and semantics to communicate network preferences to applications. Since ALTO services may be run by entities with different level of knowledge about the underlying network, such preferences may have different representations. Initially the WG will consider: IP ranges to prefer and to avoid, ranked lists of the peers requested by the client, information about topological proximity and approximate geographic locations. Other usages will be considered as charter additions once the work for the initial services has been completed. - In order to query the ALTO server, clients must first know one or more ALTO servers that might provide useful information. The WG will look at service discovery mechanisms that are in use, or defined elsewhere (e.g. based on DNS SRV records or DHCP options). If such discovery mechanisms can be reused, the WG will produce a document to specify how they may be adopted for locating such servers. However, a new, general-purpose service discovery mechanism is not in scope. When the WG considers standardizing information that the ALTO server could provide, the following criteria are important to ensure real feasibility. - Can the ALTO service realistically discover that information? - Is the distribution of that information allowed by the operators of that service? - Is it information that a client will find useful? - Can a client get that information without excessive privacy concerns (e.g. by sending large lists of peers)? - Is it information that a client cannot find easily some other way? After these criteria are met, the importance of the data will be considered for prioritizing standardization work, for example the number of operators and clients that are likely to be able to provide or use that particular data. In any case, this WG will not propose standards on how congestion is signaled, remediated, or avoided, and will not deal with information representing instantaneous network state. Such issues belong to other IETF areas and will be treated accordingly by the specific area. This WG will focus solely on the communication protocol between applications and ALTO servers. Note that ALTO services may be useful in client-server environments as well as P2P environments, although P2P environments are the first focus. If, in the future, the IETF considers changes to other protocols for actually implementing ALTO services (e.g. application-layer protocols for Internet coordinate systems, routing protocol extensions for ISP-based solutions), such work will be done in strict coordination with the appropriate WGs. Issues related to the content exchanged in P2P systems are also excluded from the WG's scope, as is the issue dealing with enforcing the legality of the content. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Apr 2009 Apr 2009 Application-Layer Traffic Optimization (ALTO) Requirements Apr 2009 Jul 2009 Application-Layer Traffic Optimization (ALTO) Problem Statement Calendaring and Scheduling Standards Simplification (calsify) ------------------------------------------------------------- Charter Last Modified: 2008-04-23 Current Status: Active Working Group Chair(s): Aki Niemi Eliot Lear Applications Area Director(s): Lisa Dusseault Alexey Melnikov Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion:ietf-calsify@osafoundation.org To Subscribe: http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Archive: http://lists.osafoundation.org/pipermail/ietf-calsify/ Description of Working Group: The Calendaring and Scheduling standards, defined in RFC's 2445, 2446, and 2447 were released in November 1998, and further described in RFC 3283. They were designed to progress the level of interoperability between dissimilar calendaring and scheduling systems. The Calendaring and Scheduling Core Object Specification, iCalendar, succeeded in establishing itself as the common format for exchanging calendaring information across the Internet. On the other hand, only basic interoperability has been achieved between different scheduling systems. The Calsify working group is chartered to: (1) Revise the Calendaring and Scheduling Standards to advance the state of interoperable calendaring and scheduling by addressing the known interoperability issues, errata, and problems found based on implementation experience. (2) Clarify the registration process for iCalendar extensions (i.e., the current core object specification only provides a template to register new properties). (3) Provide a means to ease transition from, and to co-exist with, the earlier iCalendar standards to the new ones. Proposing an XML representation or transformation of iCalendar objects is out of the scope of this working group. Depending on the results of the update process on the standards documents the working group will consider whether advancing the documents to draft standard is appropriate. If we decide to move the documents to draft status, milestones may get changed and/or added to allow for any additional work necessary to advance the documents. Description of Working Group: The Calendaring and Scheduling standards, defined in RFC's 2445, 2446, and 2447 were released in November 1998, and further described in RFC 3283. They were designed to progress the level of interoperability between dissimilar calendaring and scheduling systems. The Calendaring and Scheduling Core Object Specification, iCalendar, succeeded in establishing itself as the common format for exchanging calendaring information across the Internet. On the other hand, only basic interoperability has been achieved between different scheduling systems. The Calsify working group is chartered to: (1) Revise the Calendaring and Scheduling Standards to advance the state of interoperable calendaring and scheduling by addressing the known interoperability issues, errata, and problems found based on implementation experience. (2) Clarify the registration process for iCalendar extensions (i.e., the current core object specification only provides a template to register new properties). (3) Provide a means to ease transition from, and to co-exist with, the earlier iCalendar standards to the new ones. Proposing an XML representation or transformation of iCalendar objects is out of the scope of this working group. Depending on the results of the update process on the standards documents the working group will consider whether advancing the documents to draft standard is appropriate. If we decide to move the documents to draft status, milestones may get changed and/or added to allow for any additional work necessary to advance the documents. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2005 Apr 2009 iCalendar Transport-Independent Interoperability Protocol (iTIP) Oct 2005 Apr 2009 Internet Calendaring and Scheduling Core Object Specification (iCalendar) Email Address Internationalization (eai) ---------------------------------------- Charter Last Modified: 2009-04-03 Current Status: Active Working Group Chair(s): Harald Alvestrand XiaoDong Lee Applications Area Director(s): Lisa Dusseault Alexey Melnikov Applications Area Advisor: Alexey Melnikov Mailing Lists: General Discussion:ima@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ima Archive: http://www.ietf.org/mail-archive/web/ima Description of Working Group: Since early in the effort to internationalize domain names, which resulted in the standards associated with IDNA, it has been understood that internationalization of email address local parts is required. At the same time, email address internationalization poses a series of special problems. Constraints on the interpretation of local-parts by any system other than the final delivery one make address encoding nearly impossible. The need to use addresses in both the email envelope and in header fields, and to do so in ways that are at least compatible, suggests that this is not a simple and isolated problem. This working group will address one basic approach to email internationalization. That approach is based on the use of an SMTP extension to enable both the use of UTF-8 in envelope address local- parts and optionally in domain-parts and the use of UTF-8 in mail headers -- both in address contexts and wherever encoded-words are permitted today. Its initial target will be a set of experimental RFCs that specify the details of this approach and provide the basis for generating and testing interoperable implementations. Its work will include examining whether "downgrading" -- transforming an internationalized message to one that is compatible with unextended SMTP clients and servers and unextended MUAs -- is feasible and appropriate and, if it is, specifying a way to do so. If it is not, the WG will evaluate whether the effort is worth taking forward. Other approaches may be considered by the formation of other working groups. Key parts of this effort include extended analyses and, if necessary, proof of concept in three areas in addition to smooth operation when all systems and components along a message path have been upgraded to support the new facilities. They are o Examination of scenarios for the appearance of these facilities to users, including ways in which alternate addresses may be specified if those are needed for downgrading. o Examination of different locations at which downgrading might be required and accomplished, differentiating between requirements and capabilities at the point of origin (at or before the submission server), those that exist while the message is in transit, and those that apply after SMTP "final delivery" or in the logical vicinity or an IMAP or POP server. o Examination of the "mailing list question", i.e., how a mixture of traditional and internationalized addresses on a mailing list will impact message flows, error reports, and delivery notifications in all plausible combinations of servers and addresses, including internationalizated and traditional reverse paths. Once the Experimental RFCs are completed and implemented, the experience gathered will be evaluated. If the approach is found to have been successful (using criteria the WG will establish as an early work item), the WG will be rechartered to update the documents for processing onto the standards track. 1.6. Deliverables The following deliverables are foreseen in this charter. The WG chairs may structure the deliverables into specific documents or document sets as needed. Adding or removing documents outside of these deliverables will require a charter update. o Overview and architecture (Info) o Interworking scenarios, including the "mailing list question" (Info) o SMTP extensions specification (Exp) o Header format specification (Exp) o Downgrading specification in SMTP (Exp) o Downgrading specification in POP servers (Exp) o Downgrading specificatio n in IMAP servers (Exp) o Results and evaluation of experiment (Info) Going forward, it is possible that the SMTP downgrading specification will go for Informational due to the difficulty of fully specifying all necessary behavior. Additional possible documents suggested: Advice for MUA implementors (Info) Description of Working Group: Since early in the effort to internationalize domain names, which resulted in the standards associated with IDNA, it has been understood that internationalization of email address local parts is required. At the same time, email address internationalization poses a series of special problems. Constraints on the interpretation of local-parts by any system other than the final delivery one make address encoding nearly impossible. The need to use addresses in both the email envelope and in header fields, and to do so in ways that are at least compatible, suggests that this is not a simple and isolated problem. This working group will address one basic approach to email internationalization. That approach is based on the use of an SMTP extension to enable both the use of UTF-8 in envelope address local- parts and optionally in domain-parts and the use of UTF-8 in mail headers -- both in address contexts and wherever encoded-words are permitted today. Its initial target will be a set of experimental RFCs that specify the details of this approach and provide the basis for generating and testing interoperable implementations. Its work will include examining whether "downgrading" -- transforming an internationalized message to one that is compatible with unextended SMTP clients and servers and unextended MUAs -- is feasible and appropriate and, if it is, specifying a way to do so. If it is not, the WG will evaluate whether the effort is worth taking forward. Other approaches may be considered by the formation of other working groups. Key parts of this effort include extended analyses and, if necessary, proof of concept in three areas in addition to smooth operation when all systems and components along a message path have been upgraded to support the new facilities. They are o Examination of scenarios for the appearance of these facilities to users, including ways in which alternate addresses may be specified if those are needed for downgrading. o Examination of different locations at which downgrading might be required and accomplished, differentiating between requirements and capabilities at the point of origin (at or before the submission server), those that exist while the message is in transit, and those that apply after SMTP "final delivery" or in the logical vicinity or an IMAP or POP server. o Examination of the "mailing list question", i.e., how a mixture of traditional and internationalized addresses on a mailing list will impact message flows, error reports, and delivery notifications in all plausible combinations of servers and addresses, including internationalizated and traditional reverse paths. Once the Experimental RFCs are completed and implemented, the experience gathered will be evaluated. If the approach is found to have been successful (using criteria the WG will establish as an early work item), the WG will be rechartered to update the documents for processing onto the standards track. 1.6. Deliverables The following deliverables are foreseen in this charter. The WG chairs may structure the deliverables into specific documents or document sets as needed. Adding or removing documents outside of these deliverables will require a charter update. o Overview and architecture (Info) o Interworking scenarios, including the "mailing list question" (Info) o SMTP extensions specification (Exp) o Header format specification (Exp) o Downgrading specification in SMTP (Exp) o Downgrading specification in POP servers (Exp) o Downgrading specificatio n in IMAP servers (Exp) o Results and evaluation of experiment (Info) Going forward, it is possible that the SMTP downgrading specification will go for Informational due to the difficulty of fully specifying all necessary behavior. Additional possible documents suggested: Advice for MUA implementors (Info) Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- May 2006 Jun 2009 IMAP Support for UTF-8 Jun 2006 Jun 2009 POP3 Support for UTF-8 Feb 2008 Mar 2009 An update to the mailto URI scheme for Email Address Internationalization Oct 2008 Mar 2009 Displaying Downgraded Messages for Email Address Internationalization Enhancements to Internet email to Support Diverse Service Environments (lemonade) --------------------------------------------------------------------------------- Charter Last Modified: 2009-04-03 Current Status: Active Working Group Chair(s): Glenn Parsons Eric Burger Applications Area Director(s): Lisa Dusseault Alexey Melnikov Applications Area Advisor: Alexey Melnikov Secretary(ies): Alexey Melnikov Mailing Lists: General Discussion:lemonade@ietf.org To Subscribe: lemonade-request@ietf.org In Body: in boby 'subscribe' Archive: http://www.ietf.org/mail-archive/web/lemonade/index.html Description of Working Group: Lemonade is tasked to provide a set of enhancements and profiles of Internet email submission, transport, and retrieval protocols to facilitate operation on platforms with constrained resources, or communications links with high latency or limited bandwidth. A primary goal of this work is to ensure that those profiles and enhancements continue to interoperate with the existing Internet email protocols in use on the Internet, so that these environments and more traditional Internet users have access to a seamless service. Lemonade's work is at the crossroads of a body of work related to Internet messaging, in particular work done by the VPIM, FAX, and IMAPEXT IETF working groups. Given the potentially broad scope of activities this group could engage in, the group will focus specifically on the following work items: 0. An informational RFC or RFCs will be produced on LEMONADE architecture and the issues it seeks to address. 1. Enhance the existing IMAP4 message retrieval and message submission (RFC 2476) protocols to satisfy the requirements for handling streaming multimedia content. The existing standards-track CONNEG framework will be used if content negotiation capabilities are needed. The group will employ existing protocols (such as for streaming) with IMAP4 instead of duplicating such functionality within IMAP4. 2. Enhance the existing IMAP4 message retrieval and/or message submission (RFC 2476) protocols to satisfy the requirements for forwarding a message and/or its attachments without downloading the message to the client and subsequently uploading the message to a server. 3. Refine the existing IMAP4 message retrieval protocol to facilitate its use with devices that have limited capabilities such as mobile endpoints. At most one backwards compatible profile of IMAP4 will be produced by this effort. 4. Define a format for message notifications for servers reporting message status information to other servers. Specify the method for delivery of those notifications. 5. Create a specification describing the use of Internet message services in environments where message delivery may take place using either Internet protocols or through an MMS server using WAP to communicate with the receiving user agent. Any protocols defined by this working group will include appopriate security mechanisms, including authentication, privacy, and access control. Mandatory-to-implement security mechanisms will be specified as needed in order to guarantee secure protocol interoperability. The transport area will be consulted to deal with any transport-related issues that arise, especially in regards to items 1-4 above. The IAB is currently working on the specification of general guidelines and requirements for notification services. Once complete this work will be used as input to item 4 above. The working group is aware of several related activities in other groups: - 3GPP TSG T WG2 SWG3 Messaging - W3C Mulitmodal interaction Activity - Open Mobile Alliance - 3GPP2 TSG-X The goal is to coordinate efforts with at least these groups as required. While there is obvious synergy, given the end-of-life of the VPIM and FAX work groups and the similar membership, the working group does not expect to coordinate with these other groups. Description of Working Group: Lemonade is tasked to provide a set of enhancements and profiles of Internet email submission, transport, and retrieval protocols to facilitate operation on platforms with constrained resources, or communications links with high latency or limited bandwidth. A primary goal of this work is to ensure that those profiles and enhancements continue to interoperate with the existing Internet email protocols in use on the Internet, so that these environments and more traditional Internet users have access to a seamless service. Lemonade's work is at the crossroads of a body of work related to Internet messaging, in particular work done by the VPIM, FAX, and IMAPEXT IETF working groups. Given the potentially broad scope of activities this group could engage in, the group will focus specifically on the following work items: 0. An informational RFC or RFCs will be produced on LEMONADE architecture and the issues it seeks to address. 1. Enhance the existing IMAP4 message retrieval and message submission (RFC 2476) protocols to satisfy the requirements for handling streaming multimedia content. The existing standards-track CONNEG framework will be used if content negotiation capabilities are needed. The group will employ existing protocols (such as for streaming) with IMAP4 instead of duplicating such functionality within IMAP4. 2. Enhance the existing IMAP4 message retrieval and/or message submission (RFC 2476) protocols to satisfy the requirements for forwarding a message and/or its attachments without downloading the message to the client and subsequently uploading the message to a server. 3. Refine the existing IMAP4 message retrieval protocol to facilitate its use with devices that have limited capabilities such as mobile endpoints. At most one backwards compatible profile of IMAP4 will be produced by this effort. 4. Define a format for message notifications for servers reporting message status information to other servers. Specify the method for delivery of those notifications. 5. Create a specification describing the use of Internet message services in environments where message delivery may take place using either Internet protocols or through an MMS server using WAP to communicate with the receiving user agent. Any protocols defined by this working group will include appopriate security mechanisms, including authentication, privacy, and access control. Mandatory-to-implement security mechanisms will be specified as needed in order to guarantee secure protocol interoperability. The transport area will be consulted to deal with any transport-related issues that arise, especially in regards to items 1-4 above. The IAB is currently working on the specification of general guidelines and requirements for notification services. Once complete this work will be used as input to item 4 above. The working group is aware of several related activities in other groups: - 3GPP TSG T WG2 SWG3 Messaging - W3C Mulitmodal interaction Activity - Open Mobile Alliance - 3GPP2 TSG-X The goal is to coordinate efforts with at least these groups as required. While there is obvious synergy, given the end-of-life of the VPIM and FAX work groups and the similar membership, the working group does not expect to coordinate with these other groups. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jan 2006 Jul 2008 Lemonade Notifications Architecture Jan 2006 Feb 2009 The Lemonade Profile Jun 2006 Jun 2009 Streaming Internet Messaging Attachments Hypertext Transfer Protocol Bis (httpbis) ----------------------------------------- Charter Last Modified: 2008-08-21 Current Status: Active Working Group Chair(s): Mark Nottingham Applications Area Director(s): Lisa Dusseault Alexey Melnikov Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion:ietf-http-wg@w3.org To Subscribe: http://lists.w3.org/Archives/Public/ietf-http-wg/ Archive: Description of Working Group: HTTP is one of the most successful and widely-used protocols on the Internet today. However, its specification has several editorial issues. Additionally, after years of implementation and extension, several ambiguities have become evident, impairing interoperability and the ability to easily implement and use HTTP. The working group will refine RFC2616 to: * Incorporate errata and updates (e.g., references, IANA registries, ABNF) * Fix editorial problems which have led to misunderstandings of the specification * Clarify conformance requirements * Remove known ambiguities where they affect interoperability * Clarify existing methods of extensibility * Remove or deprecate those features that are not widely implemented and also unduly affect interoperability * Where necessary, add implementation advice * Document the security properties of HTTP and its associated echanisms (e.g., Basic and Digest authentication, cookies, TLS) for common applications In doing so, it should consider: * Implementer experience * Demonstrated use of HTTP * Impact on existing implementations and deployments The Working Group must not introduce a new version of HTTP and should not add new functionality to HTTP. The WG is not tasked with producing new methods, headers, or extension mechanisms, but may introduce new protocol elements if necessary as part of revising existing functionality which has proven to be problematic The Working Group's specification deliverables are: * A document that is suitable to supersede RFC 2616 * A document cataloguing the security properties of HTTP Description of Working Group: HTTP is one of the most successful and widely-used protocols on the Internet today. However, its specification has several editorial issues. Additionally, after years of implementation and extension, several ambiguities have become evident, impairing interoperability and the ability to easily implement and use HTTP. The working group will refine RFC2616 to: * Incorporate errata and updates (e.g., references, IANA registries, ABNF) * Fix editorial problems which have led to misunderstandings of the specification * Clarify conformance requirements * Remove known ambiguities where they affect interoperability * Clarify existing methods of extensibility * Remove or deprecate those features that are not widely implemented and also unduly affect interoperability * Where necessary, add implementation advice * Document the security properties of HTTP and its associated echanisms (e.g., Basic and Digest authentication, cookies, TLS) for common applications In doing so, it should consider: * Implementer experience * Demonstrated use of HTTP * Impact on existing implementations and deployments The Working Group must not introduce a new version of HTTP and should not add new functionality to HTTP. The WG is not tasked with producing new methods, headers, or extension mechanisms, but may introduce new protocol elements if necessary as part of revising existing functionality which has proven to be problematic The Working Group's specification deliverables are: * A document that is suitable to supersede RFC 2616 * A document cataloguing the security properties of HTTP Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Dec 2007 Mar 2009 HTTP/1.1, part 1: URIs, Connections, and Message Parsing Dec 2007 Mar 2009 HTTP/1.1, part 2: Message Semantics Dec 2007 Mar 2009 HTTP/1.1, part 3: Message Payload and Content Negotiation Dec 2007 Mar 2009 HTTP/1.1, part 4: Conditional Requests Dec 2007 Mar 2009 HTTP/1.1, part 5: Range Requests and Partial Responses Dec 2007 Mar 2009 HTTP/1.1, part 6: Caching Dec 2007 Mar 2009 HTTP/1.1, part 7: Authentication Jan 2008 Mar 2009 Security Requirements for HTTP Aug 2008 May 2009 Initial Hypertext Transfer Protocol (HTTP) Method Registrations Internationalized Domain Names in Applications (Revised) (idnabis) ------------------------------------------------------------------ Charter Last Modified: 2008-08-21 Current Status: Active Working Group Chair(s): Vinton Cerf Applications Area Director(s): Lisa Dusseault Alexey Melnikov Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion:idna-update@alvestrand.no To Subscribe: http://www.alvestrand.no/mailman/listinfo/idna-update Archive: http://www.alvestrand.no/pipermail/idna-update/ Description of Working Group: The original Internationalized Domain Name (IDN) WG specified rules for the use of characters other than Latin A(a)-Z(z), digits 0-9 and the hyphen (?-?) in domain names in RFC3490, RFC3491 and RFC3492 in 2002 (published in 2003 and often referenced collectively as ?IDNA2003?). These documents depend on RFC 3454 and were tied to Unicode version 3.2. An update to the current version (5.x) is required to accommodate additional scripts. In addition, experience has shown that significant improvements could be made in the protocol as presently specified. This WG is chartered to decouple IDNA from specific versions of Unicode using algorithms that define validity based on Unicode properties. It is recognized that some explicit exceptions may be necessary in any case, but attempts will be made to minimize these exceptions. Additional goals: - Separate requirements for valid IDNs at registration time (insertion of names into DNS zone files), vs. at resolution time (looking up those names) - Review, and if necessary revise, the algorithms and rules for handling right to left character sequences in an IDN context to allow labels based on additional scripts and languages and to make presentation as predictable as reasonably possible. - Permit use of some scripts that were inadvertently excluded by the original protocols. - Ensure practical stability of validity algorithms for IDNs. The constraints of the original IDN WG still apply to IDNABIS, namely to avoid disturbing the current use and operation of the domain name system, and for the DNS to continue to allow any system to resolve any domain name in a consistent way. The client-based approach of the original IDN work will be maintained -- substantially new protocols or mechanisms are not in scope. In particular, IDNs continue to use the "xn--" prefix and the same ASCII-compatible encoding, and the bidirectional algorithm follows the same basic design. The specifications are initially organized as four documents: overview and rationale, protocol, table algorithm, and improvements to the bidirectional algorithm. These documents are to be used as the basis for the discussion of the general direction of the work. This working group will be providing extended public review of the output of a design team that has been working on improvement of the IDNA specifications. This review-based approach is being used in part because of the way the work was undertaken by the team; in particular, the design team has been working with IETF visibility and has solicited and received significant amounts of technical review already from IETF participants and from others including experts in the Unicode specifications and the use of scripts in languages. If the public review provided by this Working Group confirms the basic method outlined in the input documents, it is expected that the working group will be able to respond with any needed changes and close in a short period of time. If technical issues arise that indicate a fundamentally different approach must be taken from the one outlined above, it is anticipated that this working group would close, and a new one with an appropriate charter would be considered. This work is intended to specify an improved means to produce and use stable and unambiguous IDN identifiers. There are a variety of generally unsolvable problems, notably the problem of characters that are confusingly similar in appearance (often known as the "phishing" problem) that are not specifically part of the scope of the WG although some of the preliminary results of the design team suggest that the improvements contemplated in the specifications might mitigate some of the ways in which the current IDNA specifications can be abused for phishing purposes. While it is referenced from the original IDNA2003 package, the original Stringprep specification, RFC 3454, is not formally part of the IDNA package and will not be altered by this work. The work will update or obsolete RFC 3490. It is not expected to continue to use Nameprep (RFC 3491). Nameprep is used by other specifications; determining how (or whether) to update those specifications and, consequently, the long-term status of Nameprep, are not part of this effort. The method for ASCII-compatible ("ACE") encoding of IDNs, "Punycode" (RFC 3492) will not be revised by this WG. Subject to the more general constraints described above, the WG is permitted to consider changes that are not strictly backwards-compatible. For any such change that is recommended, it is expected to document the reasons for the change, the characters affected, and possible transition strategies. The assumptions outlined above are considered critical to the WG constituted by this charter. The WG will stop work and recommend that a new charter be generated if it concludes that any of the following are necessary to meet its goals: (i) A change to the "punycode" algorithm or to the ACE approach to encoding names in the DNS. (ii) A change to the ACE prefix from "xn--" (iii) A change to the basic approach taken in the design team documents (Namely: independence from Unicode version and elimination of character mapping in the protocol) Description of Working Group: The original Internationalized Domain Name (IDN) WG specified rules for the use of characters other than Latin A(a)-Z(z), digits 0-9 and the hyphen (?-?) in domain names in RFC3490, RFC3491 and RFC3492 in 2002 (published in 2003 and often referenced collectively as ?IDNA2003?). These documents depend on RFC 3454 and were tied to Unicode version 3.2. An update to the current version (5.x) is required to accommodate additional scripts. In addition, experience has shown that significant improvements could be made in the protocol as presently specified. This WG is chartered to decouple IDNA from specific versions of Unicode using algorithms that define validity based on Unicode properties. It is recognized that some explicit exceptions may be necessary in any case, but attempts will be made to minimize these exceptions. Additional goals: - Separate requirements for valid IDNs at registration time (insertion of names into DNS zone files), vs. at resolution time (looking up those names) - Review, and if necessary revise, the algorithms and rules for handling right to left character sequences in an IDN context to allow labels based on additional scripts and languages and to make presentation as predictable as reasonably possible. - Permit use of some scripts that were inadvertently excluded by the original protocols. - Ensure practical stability of validity algorithms for IDNs. The constraints of the original IDN WG still apply to IDNABIS, namely to avoid disturbing the current use and operation of the domain name system, and for the DNS to continue to allow any system to resolve any domain name in a consistent way. The client-based approach of the original IDN work will be maintained -- substantially new protocols or mechanisms are not in scope. In particular, IDNs continue to use the "xn--" prefix and the same ASCII-compatible encoding, and the bidirectional algorithm follows the same basic design. The specifications are initially organized as four documents: overview and rationale, protocol, table algorithm, and improvements to the bidirectional algorithm. These documents are to be used as the basis for the discussion of the general direction of the work. This working group will be providing extended public review of the output of a design team that has been working on improvement of the IDNA specifications. This review-based approach is being used in part because of the way the work was undertaken by the team; in particular, the design team has been working with IETF visibility and has solicited and received significant amounts of technical review already from IETF participants and from others including experts in the Unicode specifications and the use of scripts in languages. If the public review provided by this Working Group confirms the basic method outlined in the input documents, it is expected that the working group will be able to respond with any needed changes and close in a short period of time. If technical issues arise that indicate a fundamentally different approach must be taken from the one outlined above, it is anticipated that this working group would close, and a new one with an appropriate charter would be considered. This work is intended to specify an improved means to produce and use stable and unambiguous IDN identifiers. There are a variety of generally unsolvable problems, notably the problem of characters that are confusingly similar in appearance (often known as the "phishing" problem) that are not specifically part of the scope of the WG although some of the preliminary results of the design team suggest that the improvements contemplated in the specifications might mitigate some of the ways in which the current IDNA specifications can be abused for phishing purposes. While it is referenced from the original IDNA2003 package, the original Stringprep specification, RFC 3454, is not formally part of the IDNA package and will not be altered by this work. The work will update or obsolete RFC 3490. It is not expected to continue to use Nameprep (RFC 3491). Nameprep is used by other specifications; determining how (or whether) to update those specifications and, consequently, the long-term status of Nameprep, are not part of this effort. The method for ASCII-compatible ("ACE") encoding of IDNs, "Punycode" (RFC 3492) will not be revised by this WG. Subject to the more general constraints described above, the WG is permitted to consider changes that are not strictly backwards-compatible. For any such change that is recommended, it is expected to document the reasons for the change, the characters affected, and possible transition strategies. The assumptions outlined above are considered critical to the WG constituted by this charter. The WG will stop work and recommend that a new charter be generated if it concludes that any of the following are necessary to meet its goals: (i) A change to the "punycode" algorithm or to the ACE approach to encoding names in the DNS. (ii) A change to the ACE prefix from "xn--" (iii) A change to the basic approach taken in the design team documents (Namely: independence from Unicode version and elimination of character mapping in the protocol) Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- May 2008 Jun 2009 Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale May 2008 May 2009 Internationalized Domain Names in Applications (IDNA): Protocol Oct 2008 Jun 2009 Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework May 2009 Jul 2009 Mapping Characters in IDNA Language Tag Registry Update (ltru) ----------------------------------- Charter Last Modified: 2009-04-03 Current Status: Active Working Group Chair(s): Randy Presuhn Martin Duerst Applications Area Director(s): Lisa Dusseault Alexey Melnikov Applications Area Advisor: Alexey Melnikov Mailing Lists: General Discussion:ltru@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ltru Archive: http://www.ietf.org/mail-archive/web/ltru/current/maillist.html Description of Working Group: The primary language subtags allowed by the current IANA Language Subtag Registry are limited to ISO 639-1 and ISO 639-2 in the same way as they were limited by RFC 3066. This covers approximately 500 possible language subtags. ISO 639-3, scheduled for approval towards the end of 2006, will make available around 7000 more code elements for identifying languages. The working group will prepare an update to the Language Subtag Registry procedures to allow the use of 3-letter code elements from ISO 639-3 as primary language subtags or extended language subtags as appropriate. The working group will also deliver means to update the current IANA Language Subtag Registry with the newly available subtags. The working group will examine, and if necessary clarify or adjust, procedures and guidelines with respect to extended language subtags and variant subtags. Use cases include the identification of signed languages, transliterations, and transcriptions. The working group will also consider how the draft work on ISO 639-6 may relate to the future development of language tags. The working group will clarify text where necessary. It may also make adjustments to the registration process and the form of the registry if this is deemed appropriate based on ongoing registration and operational experience. These adjustments and clarifications are not expected to delay the progress of the work. Work on the drafts is planned to start before ISO 639-3 is fully approved and published. However, the WG will not finalize the drafts before ISO 639-3 is fully approved. Description of Working Group: The primary language subtags allowed by the current IANA Language Subtag Registry are limited to ISO 639-1 and ISO 639-2 in the same way as they were limited by RFC 3066. This covers approximately 500 possible language subtags. ISO 639-3, scheduled for approval towards the end of 2006, will make available around 7000 more code elements for identifying languages. The working group will prepare an update to the Language Subtag Registry procedures to allow the use of 3-letter code elements from ISO 639-3 as primary language subtags or extended language subtags as appropriate. The working group will also deliver means to update the current IANA Language Subtag Registry with the newly available subtags. The working group will examine, and if necessary clarify or adjust, procedures and guidelines with respect to extended language subtags and variant subtags. Use cases include the identification of signed languages, transliterations, and transcriptions. The working group will also consider how the draft work on ISO 639-6 may relate to the future development of language tags. The working group will clarify text where necessary. It may also make adjustments to the registration process and the form of the registry if this is deemed appropriate based on ongoing registration and operational experience. These adjustments and clarifications are not expected to delay the progress of the work. Work on the drafts is planned to start before ISO 639-3 is fully approved and published. However, the WG will not finalize the drafts before ISO 639-3 is fully approved. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Sep 2006 Jun 2009 Tags for Identifying Languages Sep 2006 Feb 2009 Update to the Language Subtag Registry Message Organization (morg) --------------------------- Charter Last Modified: 2009-04-03 Current Status: Active Working Group Chair(s): Randall Gellens Timo Sirainen Applications Area Director(s): Lisa Dusseault Alexey Melnikov Applications Area Advisor: Alexey Melnikov Mailing Lists: General Discussion:morg@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/morg Archive: http://www.ietf.org/mail-archive/web/morg/current/maillist.html Description of Working Group: The IETF Message Organization extensions Working Group will work on IMAP extensions that improve clients' ability to find messages or groups of messages in an IMAP mailstore. As a secondary goal, the WG will design its extensions so as to minimize client/server round trips and bandwidth overhead. In particular the Working Group is chartered to finalize and publish the following IMAP extensions as proposed standards: (a) A SORT extension specifying new sort criteria for header fields containing email addresses. This extension will be based on draft-karp-morg-sortdisplay-00.txt. (b) A SEARCH extension specifying new search criteria for header fields containing email addresses. (c) A LIST extension for returning STATUS information in LIST responses. This extension will be based on draft-melnikov-imapext-status-in-list-00.txt. (d) An extension that formalizes a way to return message counters by message context using STATUS and SEARCH commands. (e) An extension that specifies Internet-search-engine-like searching. Such searches would be more flexible (and less formally defined) than substring-based searches, and may return their results in a significant order. They may include "relevance" scores or similar information that could be useful to the user. (f) New collation algorithms such as "ignore whitespace" and "numeric, ignoring punctuation". The WG group will determine which collations are needed, taking into consideration the needs of the protocols that use the collation framework. (g) An extension that allows searching for messages within a message thread. This extension will be based on draft-gulbrandsen-imap-inthread-03.txt. (h) An extension that allows searching of multiple mailboxes at the same time (based on draft-melnikov-imapext-multimailbox-search-03.txt), or of multiple mailbox views. The WG will determine which approach (mailboxes or views) is more suitable as part of its work. Additional documents may be added this list, but only via a charter revision. There must also be demonstrable willingness in the IMAP development community to actually implement a given extension before it can be added to this charter. Revising or replacing the base IMAP4rev1 specification (RFC 3501) is out of the scope of this WG. This WG will ensure that all extensions it proposes take into account any existing problems in the base specification of IMAP, and do not make them worse nor make the problems harder to address in the future. Description of Working Group: The IETF Message Organization extensions Working Group will work on IMAP extensions that improve clients' ability to find messages or groups of messages in an IMAP mailstore. As a secondary goal, the WG will design its extensions so as to minimize client/server round trips and bandwidth overhead. In particular the Working Group is chartered to finalize and publish the following IMAP extensions as proposed standards: (a) A SORT extension specifying new sort criteria for header fields containing email addresses. This extension will be based on draft-karp-morg-sortdisplay-00.txt. (b) A SEARCH extension specifying new search criteria for header fields containing email addresses. (c) A LIST extension for returning STATUS information in LIST responses. This extension will be based on draft-melnikov-imapext-status-in-list-00.txt. (d) An extension that formalizes a way to return message counters by message context using STATUS and SEARCH commands. (e) An extension that specifies Internet-search-engine-like searching. Such searches would be more flexible (and less formally defined) than substring-based searches, and may return their results in a significant order. They may include "relevance" scores or similar information that could be useful to the user. (f) New collation algorithms such as "ignore whitespace" and "numeric, ignoring punctuation". The WG group will determine which collations are needed, taking into consideration the needs of the protocols that use the collation framework. (g) An extension that allows searching for messages within a message thread. This extension will be based on draft-gulbrandsen-imap-inthread-03.txt. (h) An extension that allows searching of multiple mailboxes at the same time (based on draft-melnikov-imapext-multimailbox-search-03.txt), or of multiple mailbox views. The WG will determine which approach (mailboxes or views) is more suitable as part of its work. Additional documents may be added this list, but only via a charter revision. There must also be demonstrable willingness in the IMAP development community to actually implement a given extension before it can be added to this charter. Revising or replacing the base IMAP4rev1 specification (RFC 3501) is out of the scope of this WG. This WG will ensure that all extensions it proposes take into account any existing problems in the base specification of IMAP, and do not make them worse nor make the problems harder to address in the future. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jan 2009 Jan 2009 IMAP4 Multimailbox SEARCH Extension Jan 2009 Jan 2009 The IMAP SEARCH=INTHREAD and THREAD=REFS Extensions Jan 2009 Jan 2009 Display-based Address Sorting for the IMAP4 SORT Extension Jan 2009 Jan 2009 The IMAP SEARCH=ADDRESS Extension Feb 2009 May 2009 IMAP4 Extension for returning STATUS information in extended LIST Feb 2009 Feb 2009 Additional collation algorithms for use in IMAP and Sieve Apr 2009 May 2009 IMAP4 Extension for Fuzzy Search Open Authentication Protocol (oauth) ------------------------------------ Charter Last Modified: 2009-05-15 Current Status: Active Working Group Chair(s): Blaine Cook Peter Saint-Andre Applications Area Director(s): Lisa Dusseault Alexey Melnikov Applications Area Advisor: Lisa Dusseault Technical Advisor(s): Hannes Tschofenig Mailing Lists: General Discussion:oauth@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/oauth Archive: http://www.ietf.org/mail-archive/web/oauth/current/maillist.html Description of Working Group: OAuth allows a user to grant a third-party Web site or application access to their resources, without necessarily revealing their credentials, or even their identity. For example, a photo-sharing site that supports OAuth would allow its users to use a third-party printing Web site to access their private pictures, without gaining full control of the user account. OAuth consists of: * A mechanism for a user to authorize issuance of credentials which a third party can use to access resources on their behalf. * Mechanism for using the issued credential to authenticate HTTP requests (called "signatures" in current OAuth). The Working Group will produce one or more documents suitable for consideration as Proposed Standard that will: * Improve the terminology used. * Embody good security practice, or document gaps in its capabilities, and propose a path forward for addressing the gap. * Promote interoperability. * Provide guidelines for extensibility. This specifically means that as a starting point for the working group OAuth 1.0 (i.e., draft-hammer-oauth), which is a copy of the original OAuth specification in IETF draft format, is used and the available extension points are going to be utilized. In completing its work to update OAuth 1.0 to become OAuth 1.1, the group will strive to retain backwards compatibility with the OAuth 1.0 specification. However, changes that are not backwards compatible might be accepted if the group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. Furthermore, OAuth 1.0 defines three "signature" methods used to protect requests, namely PLAINTEXT, HMAC-SHA1, and RSA- SHA1. The group will work on new authentication ("signature") methods and will describe the environments where new security requirements justify their usage. Existing signature methods will not be modified but may be dropped as part of the backwards compatible profiling activity. The applicability of existing and new authentication methods to protocols other than HTTP will be investigated. The Working Group should consider: * Implementer experience. * The end-user experience, including internationalization. * Existing uses of OAuth. * Ability to achieve broad implementation. * Ability to address broader use cases than may be contemplated by the original authors. After delivering OAuth 1.1, the Working Group may consider defining additional functions and/or extensions, for example (but not limited to): * Discovery of OAuth configuration, e.g., http://oauth.net/discovery/1.0. * Comprehensive message integrity, e.g., http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/draf ts/1/spec.html. * Recommendations regarding the structure of the token. * Localization, e.g., http://oauth.googlecode.com/svn/spec/ext/language_preferenc e/1.0/drafts/2/spec.html. * Session-oriented tokens, e.g., http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts /1/spec.html. * Alternate token exchange profiles, e.g., draft-dehora- farrell-oauth-accesstoken-creds-00. The work on extensions is within the scope of the working group charter and requires consensus within the group to add new milestones. The Working Group will also define a generally applicable HTTP authentication mechanism (i.e., browser-based "2-leg" scenerio). Description of Working Group: OAuth allows a user to grant a third-party Web site or application access to their resources, without necessarily revealing their credentials, or even their identity. For example, a photo-sharing site that supports OAuth would allow its users to use a third-party printing Web site to access their private pictures, without gaining full control of the user account. OAuth consists of: * A mechanism for a user to authorize issuance of credentials which a third party can use to access resources on their behalf. * Mechanism for using the issued credential to authenticate HTTP requests (called "signatures" in current OAuth). The Working Group will produce one or more documents suitable for consideration as Proposed Standard that will: * Improve the terminology used. * Embody good security practice, or document gaps in its capabilities, and propose a path forward for addressing the gap. * Promote interoperability. * Provide guidelines for extensibility. This specifically means that as a starting point for the working group OAuth 1.0 (i.e., draft-hammer-oauth), which is a copy of the original OAuth specification in IETF draft format, is used and the available extension points are going to be utilized. In completing its work to update OAuth 1.0 to become OAuth 1.1, the group will strive to retain backwards compatibility with the OAuth 1.0 specification. However, changes that are not backwards compatible might be accepted if the group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. Furthermore, OAuth 1.0 defines three "signature" methods used to protect requests, namely PLAINTEXT, HMAC-SHA1, and RSA- SHA1. The group will work on new authentication ("signature") methods and will describe the environments where new security requirements justify their usage. Existing signature methods will not be modified but may be dropped as part of the backwards compatible profiling activity. The applicability of existing and new authentication methods to protocols other than HTTP will be investigated. The Working Group should consider: * Implementer experience. * The end-user experience, including internationalization. * Existing uses of OAuth. * Ability to achieve broad implementation. * Ability to address broader use cases than may be contemplated by the original authors. After delivering OAuth 1.1, the Working Group may consider defining additional functions and/or extensions, for example (but not limited to): * Discovery of OAuth configuration, e.g., http://oauth.net/discovery/1.0. * Comprehensive message integrity, e.g., http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/draf ts/1/spec.html. * Recommendations regarding the structure of the token. * Localization, e.g., http://oauth.googlecode.com/svn/spec/ext/language_preferenc e/1.0/drafts/2/spec.html. * Session-oriented tokens, e.g., http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts /1/spec.html. * Alternate token exchange profiles, e.g., draft-dehora- farrell-oauth-accesstoken-creds-00. The work on extensions is within the scope of the working group charter and requires consensus within the group to add new milestones. The Working Group will also define a generally applicable HTTP authentication mechanism (i.e., browser-based "2-leg" scenerio). Internet-Drafts: No Current Internet-Drafts. Sieve Mail Filtering Language (sieve) ------------------------------------- Charter Last Modified: 2009-06-23 Current Status: Active Working Group Chair(s): Cyrus Daboo Aaron Stone Applications Area Director(s): Lisa Dusseault Alexey Melnikov Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion:ietf-mta-filters@imc.org To Subscribe: ietf-mta-filters-request@imc.org In Body: body=subscribe Archive: http://www.imc.org/ietf-mta-filters/mail-archive/ Description of Working Group: The SIEVE email filtering language is specified in RFC 5228, together with a number of extensions. The SIEVE working group is being re-chartered to: (1) Finish work on existing in-progress Working Group documents: (a) Notify mailto (draft-ietf-sieve-notify-mailto) (c) Mime loops (draft-ietf-sieve-mime-loop) (d) Refuse/reject (draft-ietf-sieve-refuse-reject) (2) Finalize and publish the following SIEVE extensions as proposed standards: (a) iHave (draft-freed-sieve-ihave) (b) Notary (draft-freed-sieve-notary) (c) SIEVE in XML (draft-freed-sieve-in-xml) (d) Notify-sip (draft-melnikov-sieve-notify-sip-message) (e) ManageSIEVE (draft-martin-managesieve) (f) RegEx (draft-ietf-sieve-regex) (g) Meta-data (draft-melnikov-sieve-imapext-metadata) (h) Include/multi-script (draft-daboo-sieve-include) (i) Address data (draft-melnikov-sieve-external-lists) (j) Support for Sieve in IMAP (draft-ietf-lemonade-imap-sieve) Additional drafts may be added to this list, but only via a charter revision. There must also be demonstrable willingness in the SIEVE development community to actually implement a given extension before it can be added to this charter. (3) Work on a specification to describe how EAI/IDN issues should be handled in SIEVE. (4) Work on a "Benefits of SIEVE" guide for client and server vendors that: (a) Describes the SIEVE protocol and its suite of extensions. (b) Explains the benefits of server-side filtering in practical terms. (c) Shows how client-side filtering can be migrated to SIEVE. (5) Produce one or more informational RFCs containing a set of test scripts and test email messages that are to be filtered by the scripts, and the expected results of that filtering. This will serve as the basis of a interoperability test suite to help determine the suitability of moving the base specification and selected extensions to Draft status. Description of Working Group: The SIEVE email filtering language is specified in RFC 5228, together with a number of extensions. The SIEVE working group is being re-chartered to: (1) Finish work on existing in-progress Working Group documents: (a) Notify mailto (draft-ietf-sieve-notify-mailto) (c) Mime loops (draft-ietf-sieve-mime-loop) (d) Refuse/reject (draft-ietf-sieve-refuse-reject) (2) Finalize and publish the following SIEVE extensions as proposed standards: (a) iHave (draft-freed-sieve-ihave) (b) Notary (draft-freed-sieve-notary) (c) SIEVE in XML (draft-freed-sieve-in-xml) (d) Notify-sip (draft-melnikov-sieve-notify-sip-message) (e) ManageSIEVE (draft-martin-managesieve) (f) RegEx (draft-ietf-sieve-regex) (g) Meta-data (draft-melnikov-sieve-imapext-metadata) (h) Include/multi-script (draft-daboo-sieve-include) (i) Address data (draft-melnikov-sieve-external-lists) (j) Support for Sieve in IMAP (draft-ietf-lemonade-imap-sieve) Additional drafts may be added to this list, but only via a charter revision. There must also be demonstrable willingness in the SIEVE development community to actually implement a given extension before it can be added to this charter. (3) Work on a specification to describe how EAI/IDN issues should be handled in SIEVE. (4) Work on a "Benefits of SIEVE" guide for client and server vendors that: (a) Describes the SIEVE protocol and its suite of extensions. (b) Explains the benefits of server-side filtering in practical terms. (c) Shows how client-side filtering can be migrated to SIEVE. (5) Produce one or more informational RFCs containing a set of test scripts and test email messages that are to be filtered by the scripts, and the expected results of that filtering. This will serve as the basis of a interoperability test suite to help determine the suitability of moving the base specification and selected extensions to Draft status. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Mar 2006 Nov 2008 Sieve Email Filtering: MIME part Tests, Iteration, Extraction, Replacement and Enclosure Mar 2007 Mar 2009 Sieve Email Filtering: Delivery Status Notifications and Deliver-By Extensions Oct 2008 Jan 2009 A Protocol for Remotely Managing Sieve Scripts Dec 2008 Mar 2009 Sieve Notification Mechanism: SIP MESSAGE Mar 2009 May 2009 Sieve Email Filtering: Include Extension vCard and CardDAV (vcarddav) ---------------------------- Charter Last Modified: 2009-04-03 Current Status: Active Working Group Chair(s): Kurt Zeilenga Marc Blanchet Applications Area Director(s): Lisa Dusseault Alexey Melnikov Applications Area Advisor: Alexey Melnikov Mailing Lists: General Discussion:vcarddav@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/vcarddav Archive: http://www.ietf.org/mail-archive/web/vcarddav Description of Working Group: A personal address book (PAB) contains a read/write copy of attributes describing a user's interpersonal contacts. This is distinct from a directory which contains a primarily read-only copy of users within an organization. While these two data objects share a large number of common attributes, their use and access patterns are fundamentally different. The IETF has a standards-track data format (vCard) which has been successfully used to interchange both personal-address-book and user directory entry data objects. However, due to the lack of a standard access control model for LDAP, the lack of a standard LDAP schema and DIT-model for vCard PAB objects, and the different access patterns for PAB data (as opposed to directory data), the use of LDAP as an access protocol for PABs has had mixed results in practice. Moreover, the vCard format has been extended by many parties and the current specification is ambiguous for some objects. If the deployed protocols related to interpersonal communication are viewed as a component-based system, there are a number of points in the system that would benefit from a standards track access protocol for personal address book data. This includes: * Mail User Agents use PAB data to assist outgoing email addressing and may use vCard attachments to transport PAB data between users. * Calendar User Agents use PAB data to invite attendees to events * Instant Messaging User Agents can provide additional information about a user's buddies if they can be associated with a user's PAB entry. * A server-side Sieve engine with the spamtest/virustest extension would benefit from access to a user's PAB to provide per-user white list capabilities. * Various deployed challenge-response mechanisms for email present in Mail Transfer Agents, such as TMDA, would be improved by a PAB-based white list. * Mobile device synchronization software might be simplified by a single cross-platform PAB access protocol. * A voice conference or IP telephony system could access a user's PAB to provide name-based or nickname-based dialing. This WG will produce the following outputs: (1) A revision of the vCard specification (RFC2426) at proposed standard status. This revision shall include other vCard standardized extensions (RFC 2739, 4770) and extensions assisting synchronization technologies (for example, a per-entry UUID or per-attribute sequence number). Other extensions shall be considered either in the base specification or in additional documents. (2) An address book access protocol leveraging the vCard data format. The Internet-draft draft-daboo-carddav will be the starting point. The WG is explicitly cautioned to keep the base specification feature set small with an adequate extension mechanism, as failure to do so was a problem for previous PAB efforts (ACAP). The WG will consider arguments of the form "feature X must be in the base feature set because ..." with great skepticism. These documents will consider security implications carefully. The WG will consider developing a mechanism that provides the ability to check if an email address (or im address, etc) is in the user's PAB without providing unrestricted access to all of the user's PAB data. The WG should also consider developing a mechanism that allows the user to grant this limited permission to a third-party service (such as a server-based Sieve engine) for white-list purposes. Once the primary outputs are complete, the WG will consider the following secondary outputs: (3) An XML schema which is semantically identical to vCard in all ways and can be mechanically translated to and from vCard format without loss of data. While vCard has deployed successfully and will remain the preferred interchange format, a standard XML schema which preserves vCard semantics might make vCard data more accessible to XML- centric technologies such as AJAX and XSLT. Such a standard format would be preferable to multiple proprietary XML schemas, particularly if vCard semantics were lost by some of them and a lossy gateway problem resulted. (4) Identifying useful deployed vCard vendor extensions and creating standards track versions of those extensions. (5) Cooperate with the Sieve WG to produce a Sieve extension for address book Sieve tests. (6) LDAP mapping to the new vCard format without loss of data. Description of Working Group: A personal address book (PAB) contains a read/write copy of attributes describing a user's interpersonal contacts. This is distinct from a directory which contains a primarily read-only copy of users within an organization. While these two data objects share a large number of common attributes, their use and access patterns are fundamentally different. The IETF has a standards-track data format (vCard) which has been successfully used to interchange both personal-address-book and user directory entry data objects. However, due to the lack of a standard access control model for LDAP, the lack of a standard LDAP schema and DIT-model for vCard PAB objects, and the different access patterns for PAB data (as opposed to directory data), the use of LDAP as an access protocol for PABs has had mixed results in practice. Moreover, the vCard format has been extended by many parties and the current specification is ambiguous for some objects. If the deployed protocols related to interpersonal communication are viewed as a component-based system, there are a number of points in the system that would benefit from a standards track access protocol for personal address book data. This includes: * Mail User Agents use PAB data to assist outgoing email addressing and may use vCard attachments to transport PAB data between users. * Calendar User Agents use PAB data to invite attendees to events * Instant Messaging User Agents can provide additional information about a user's buddies if they can be associated with a user's PAB entry. * A server-side Sieve engine with the spamtest/virustest extension would benefit from access to a user's PAB to provide per-user white list capabilities. * Various deployed challenge-response mechanisms for email present in Mail Transfer Agents, such as TMDA, would be improved by a PAB-based white list. * Mobile device synchronization software might be simplified by a single cross-platform PAB access protocol. * A voice conference or IP telephony system could access a user's PAB to provide name-based or nickname-based dialing. This WG will produce the following outputs: (1) A revision of the vCard specification (RFC2426) at proposed standard status. This revision shall include other vCard standardized extensions (RFC 2739, 4770) and extensions assisting synchronization technologies (for example, a per-entry UUID or per-attribute sequence number). Other extensions shall be considered either in the base specification or in additional documents. (2) An address book access protocol leveraging the vCard data format. The Internet-draft draft-daboo-carddav will be the starting point. The WG is explicitly cautioned to keep the base specification feature set small with an adequate extension mechanism, as failure to do so was a problem for previous PAB efforts (ACAP). The WG will consider arguments of the form "feature X must be in the base feature set because ..." with great skepticism. These documents will consider security implications carefully. The WG will consider developing a mechanism that provides the ability to check if an email address (or im address, etc) is in the user's PAB without providing unrestricted access to all of the user's PAB data. The WG should also consider developing a mechanism that allows the user to grant this limited permission to a third-party service (such as a server-based Sieve engine) for white-list purposes. Once the primary outputs are complete, the WG will consider the following secondary outputs: (3) An XML schema which is semantically identical to vCard in all ways and can be mechanically translated to and from vCard format without loss of data. While vCard has deployed successfully and will remain the preferred interchange format, a standard XML schema which preserves vCard semantics might make vCard data more accessible to XML- centric technologies such as AJAX and XSLT. Such a standard format would be preferable to multiple proprietary XML schemas, particularly if vCard semantics were lost by some of them and a lossy gateway problem resulted. (4) Identifying useful deployed vCard vendor extensions and creating standards track versions of those extensions. (5) Cooperate with the Sieve WG to produce a Sieve extension for address book Sieve tests. (6) LDAP mapping to the new vCard format without loss of data. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Mar 2008 May 2009 vCard Format Specification May 2008 Mar 2009 vCard Extensions to WebDAV (CardDAV) May 2008 Mar 2009 Extended MKCOL for WebDAV Yet Another Mail (yam) ---------------------- Charter Last Modified: 2009-05-26 Current Status: Active Working Group Chair(s): Tony Hansen Chris Newman Applications Area Director(s): Lisa Dusseault Alexey Melnikov Applications Area Advisor: Alexey Melnikov Mailing Lists: General Discussion:yam@ietf.org To Subscribe: yam-request@ietf.org In Body: in body 'subscribe' Archive: http://www.ietf.org/mail-archive/web/yam/index.html Description of Working Group: The Yet Another Mail (YAM) WG will revise existing Internet Mail specifications currently at Draft Standard to advance them to Full Standard. YAM will focus strictly on advancing email-related specifications for which the community already has some years of experience with deployment and interoperability. Its function is not to reopen or reconsider protocols - if a specification is found to need significant technical work, YAM will remove it from the WG's agenda. This charter's scope of work is the set of email-related RFCs that are currently at Draft Standard. Each document will be examined, along with its errata, and a recommendation made as to whether it is suitable for advancement to Full Standard. If it is not, the WG may recommend whether it should be republished at Draft Standard, moved to Historic, or recycled to Proposed Standard. However, any actual work to facilitate publication of a document at other than Full Standard is outside the WG's scope. If the WG cannot quickly reach consensus about further work on a document, it will drop the documents from its agenda without further comment or effort. The purpose of this working group is to work on protocols that are already recognized as effectively full standards, improving their written specifications to align with that status. The working group does not intend to revise the actual protocols in any way and will avoid document changes that might even accidentally introduce protocol changes, destabilize a protocol, or introduce semantic or syntactic changes. In particular, it will avoid adding new document sections that were not previously required and making BNF grammar changes that didn't originate from interoperability problems or difficulties in comprehension by implementors. If an existing protocol implementation is conforming to the Draft Standard version of the protocol specification, it must also be conforming to the resulting Full Standard version. Hence, specification changes that create a violation of this requirement are out of scope of the working group charter. On a case by case basis, substantive changes may be considered, if they will modify text to match existing conforming implementations -- that is, implementations that are already deployed with significant use. Specifically, such changes will be permitted to relax requirements or to fix BNF bugs where the intent is and has been clear. The WG will consult with the IESG about proposed changes before it starts working on them. Once the document is done by the WG, approval proceeds using the normal IETF approval process. The two step approach is proposed in order to save both IESG and WG time and to avoid late surprises when a document is considered done by the WG. After the tasks of this charter are completed, the WG will consider rechartering to move selected mature specifications that are still at Proposed Standard to higher maturity levels, or to work on those documents previously identified as needing to be republished at Draft Standard or Proposed Standard. The underpinnings of this WG effort are: (1) Wide deployment and use of interoperable implementations of an existing standards-track protocol demonstrates a presumption that the existing specification is adequate. The burden of demonstrating the contrary lies with those who believe that they see significant technical or documentation defects. (2) It is generally in the best interest of the IETF and the Internet community to see specifications of mature protocols advance on the standards track, eliminating any uncertainty as to whether the protocols have been adequately understood and tested. To that end, YAM will avoid modification of documents simply to adjust them to match contemporary IETF notational or linguistic norms. Obviously, updating of references, boilerplate, and the equivalent are exceptions to this, but success in the WG requires that there be a good-faith commitment by both its participants and the IESG to avoid seeking changes that (a) do not contribute in a substantial and substantive way to the quality and comprehensibility of the specification, or that (b) force a change to the existing protocol. The steps to be followed by the WG are, approximately: o The WG will start work by analyzing the following email related documents which are currently Draft Standards, removing any that have significant technical defects or whose advancement may be controversial under the advancement criteria specified in RFC 2026: RFC 1652 8BITMIME RFC 1864 Content-MD5 RFC 2045, 2046, 2047, 2049 MIME base specs RFC 3282 Content-language RFC 3461 DSNs RFC 3462 Multipart/Report RFC 3463 Enhanced Status Codes RFC 3464 Message Format for DSNs RFC 3798 Message Disposition Notification RFC 4409 Message Submission RFC 5321 SMTP RFC 5322 Internet Message Format o Form review and editing teams for each document to be advanced. o Formulate a list of proposed changes (stated in general terms, rather than specific wording). o Obtain WG consensus and consult with IESG on these changes. o Post I-Ds for WG consideration and consensus formation. o Recommend resulting documents to IESG for publication processing. o Rinse and repeat. Description of Working Group: The Yet Another Mail (YAM) WG will revise existing Internet Mail specifications currently at Draft Standard to advance them to Full Standard. YAM will focus strictly on advancing email-related specifications for which the community already has some years of experience with deployment and interoperability. Its function is not to reopen or reconsider protocols - if a specification is found to need significant technical work, YAM will remove it from the WG's agenda. This charter's scope of work is the set of email-related RFCs that are currently at Draft Standard. Each document will be examined, along with its errata, and a recommendation made as to whether it is suitable for advancement to Full Standard. If it is not, the WG may recommend whether it should be republished at Draft Standard, moved to Historic, or recycled to Proposed Standard. However, any actual work to facilitate publication of a document at other than Full Standard is outside the WG's scope. If the WG cannot quickly reach consensus about further work on a document, it will drop the documents from its agenda without further comment or effort. The purpose of this working group is to work on protocols that are already recognized as effectively full standards, improving their written specifications to align with that status. The working group does not intend to revise the actual protocols in any way and will avoid document changes that might even accidentally introduce protocol changes, destabilize a protocol, or introduce semantic or syntactic changes. In particular, it will avoid adding new document sections that were not previously required and making BNF grammar changes that didn't originate from interoperability problems or difficulties in comprehension by implementors. If an existing protocol implementation is conforming to the Draft Standard version of the protocol specification, it must also be conforming to the resulting Full Standard version. Hence, specification changes that create a violation of this requirement are out of scope of the working group charter. On a case by case basis, substantive changes may be considered, if they will modify text to match existing conforming implementations -- that is, implementations that are already deployed with significant use. Specifically, such changes will be permitted to relax requirements or to fix BNF bugs where the intent is and has been clear. The WG will consult with the IESG about proposed changes before it starts working on them. Once the document is done by the WG, approval proceeds using the normal IETF approval process. The two step approach is proposed in order to save both IESG and WG time and to avoid late surprises when a document is considered done by the WG. After the tasks of this charter are completed, the WG will consider rechartering to move selected mature specifications that are still at Proposed Standard to higher maturity levels, or to work on those documents previously identified as needing to be republished at Draft Standard or Proposed Standard. The underpinnings of this WG effort are: (1) Wide deployment and use of interoperable implementations of an existing standards-track protocol demonstrates a presumption that the existing specification is adequate. The burden of demonstrating the contrary lies with those who believe that they see significant technical or documentation defects. (2) It is generally in the best interest of the IETF and the Internet community to see specifications of mature protocols advance on the standards track, eliminating any uncertainty as to whether the protocols have been adequately understood and tested. To that end, YAM will avoid modification of documents simply to adjust them to match contemporary IETF notational or linguistic norms. Obviously, updating of references, boilerplate, and the equivalent are exceptions to this, but success in the WG requires that there be a good-faith commitment by both its participants and the IESG to avoid seeking changes that (a) do not contribute in a substantial and substantive way to the quality and comprehensibility of the specification, or that (b) force a change to the existing protocol. The steps to be followed by the WG are, approximately: o The WG will start work by analyzing the following email related documents which are currently Draft Standards, removing any that have significant technical defects or whose advancement may be controversial under the advancement criteria specified in RFC 2026: RFC 1652 8BITMIME RFC 1864 Content-MD5 RFC 2045, 2046, 2047, 2049 MIME base specs RFC 3282 Content-language RFC 3461 DSNs RFC 3462 Multipart/Report RFC 3463 Enhanced Status Codes RFC 3464 Message Format for DSNs RFC 3798 Message Disposition Notification RFC 4409 Message Submission RFC 5321 SMTP RFC 5322 Internet Message Format o Form review and editing teams for each document to be advanced. o Formulate a list of proposed changes (stated in general terms, rather than specific wording). o Obtain WG consensus and consult with IESG on these changes. o Post I-Ds for WG consideration and consensus formation. o Recommend resulting documents to IESG for publication processing. o Rinse and repeat. Internet-Drafts: No Current Internet-Drafts. Access Node Control Protocol (ancp) ----------------------------------- Charter Last Modified: 2009-04-13 Current Status: Active Working Group Chair(s): Wojciech Dec Matthew Bocci Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Technical Advisor(s): Dan Romascanu Mailing Lists: General Discussion:ancp@ietf.org To Subscribe: ancp-request@ietf.org In Body: In Body: subscribe your_email_address Archive: http://www.ietf.org/mail-archive/web/ancp/current/maillist.html Description of Working Group: Purpose: The purpose of the ANCP WG is to standardize an IP based Access Node Control Protocol (ANCP) for use in service provider Digital Subscriber Line (DSL) 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 acess loop connections from Subscribers. In DSL, this is often referred to as a Digital Subscriber Line Access Multiplexer (DSLAM) Network Access Server (NAS) - Network device which aggregates multiplexedSubscriber traffic from a number of Access Nodes. The NAS plays a central role in per-subsciber policy enforcement and QoS. Often referred to as an 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 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, over a DSL access and aggregation network. 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 DSL 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 Scalabilty: 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 the management framewoirk 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 work, and with IEEE 802.1ag. 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) 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 acess loop connections from Subscribers. In DSL, this is often referred to as a Digital Subscriber Line Access Multiplexer (DSLAM) Network Access Server (NAS) - Network device which aggregates multiplexedSubscriber traffic from a number of Access Nodes. The NAS plays a central role in per-subsciber policy enforcement and QoS. Often referred to as an 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 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, over a DSL access and aggregation network. 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 DSL 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 Scalabilty: 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 the management framewoirk 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 work, and with IEEE 802.1ag. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2006 May 2009 Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks Jan 2007 Mar 2009 Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) Mar 2007 Mar 2009 Protocol for Access Node Control Mechanism in Broadband Networks Ad-Hoc Network Autoconfiguration (autoconf) ------------------------------------------- Charter Last Modified: 2009-04-02 Current Status: Active Working Group Chair(s): Ryuji Wakikawa Thomas Clausen Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:autoconf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf Archive: http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html Description of Working Group: In order to communicate among themselves, ad hoc nodes (refer to RFC 2501) need to configure their network interface(s) with local addresses that are valid within an ad hoc network. Ad hoc nodes may also need to configure globally routable addresses, in order to communicate with devices on the Internet. From the IP layer perspective, an ad hoc network presents itself as a L3 multi-hop network formed over a collection of links. The main purpose of the AUTOCONF WG is to describe the addressing model for ad hoc networks and how nodes in these networks configure their addresses. It is required that such models do not cause problems for ad hoc-unaware parts of the system, such as standard applications running on an ad hoc node or regular Internet nodes attached to the ad hoc nodes. This group's effort may include the development of new protocol mechanisms, should the existing IP autoconfiguration mechanisms be found inadequate. However, the first task of the working group is to describe one practical addressing model for ad hoc networks. Once this sole work item is completed, the group can be rechartered to work on additional issues. Description of Working Group: In order to communicate among themselves, ad hoc nodes (refer to RFC 2501) need to configure their network interface(s) with local addresses that are valid within an ad hoc network. Ad hoc nodes may also need to configure globally routable addresses, in order to communicate with devices on the Internet. From the IP layer perspective, an ad hoc network presents itself as a L3 multi-hop network formed over a collection of links. The main purpose of the AUTOCONF WG is to describe the addressing model for ad hoc networks and how nodes in these networks configure their addresses. It is required that such models do not cause problems for ad hoc-unaware parts of the system, such as standard applications running on an ad hoc node or regular Internet nodes attached to the ad hoc nodes. This group's effort may include the development of new protocol mechanisms, should the existing IP autoconfiguration mechanisms be found inadequate. However, the first task of the working group is to describe one practical addressing model for ad hoc networks. Once this sole work item is completed, the group can be rechartered to work on additional issues. Internet-Drafts: No Current Internet-Drafts. Cga & Send maIntenance (csi) ---------------------------- Charter Last Modified: 2009-04-13 Current Status: Active Working Group Chair(s): Marcelo Bagnulo Gabriel Montenegro Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion:cga-ext@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/cga-ext Archive: http://www.ietf.org/mail-archive/web/cga-ext/current/maillist.html Description of Working Group: The Secure Neighbor Discovery (SEND) protocol defined by RFC 3971 provides security mechanisms protecting different functions of the Neighbor Discovery (ND) protocol defined by RFC 2461. This includes address resolution (discovering link layer address of another node attached to the link), router discovery (discovering routers attached to the link), and neighbor unreachability detection (detecting that a node attached to the link is no longer reachable). SEND protection of address resolution and neighbor unreachability detection functions relies on IPv6 address proof-of-ownership and message integrity protection provided respectively via Cryptographically Generated Addresses (CGAs) and RSA Digital Signatures. CGAs are defined in RFC 3972, and are extended with a CGA extension format defined in RFC 4581, and a support for multiple hash functions defined in RFC 4982. While CGAs were originally defined for the SEND protocol, they have proved to be a useful security tool in other environments too, and its usage has been proposed to secure other protocols such as the Shim6 multihoming protocol and the Mobile IPv6 protocol. While there is very little deployment of SEND to date, there are a number of implementations, recommendations in the NIST and DOD profiles call for use of SEND, and operating system vendors are considering adding SEND to their next releases. As a result, it is desirable to review the current state of the SEND and CGA specifications, maintain and complement them where necessary. Up to date cryptographic algorithms are needed, and the protocols need to be able to deal with certain common situations currently not supported. Specifically, the WG will look at the following issues: - Develop an informational document analyzing the implications of recent attacks on hash functions used by SeND protocol. Current SeND specification uses the SHA-1 hash algorithm and does not provides support for hash algorithm agility, hence the critical need for understanding the impact of the attacks on the SeND protocol. In addition, if as a result of the aforementioned analysis it is deemed necessary, standard-track extensions to the SeND protocol to support multiple hash algorithms will be defined. - Specify a standards-track CGA and SeND extensions to support multiple public key algorithms. As currently defined CGA and SeND can only use RSA keys, and they lack support for other public key algorithms (e.g. Elliptic Curve Cryptography -- ECC). - Develop X.509 certificate management tools for SeND. SeND utilizes X.509v3 certificates for performing router authorization. It uses the X.509 extension for IP addresses to verify whether the router is authorized to advertise the mentioned IP addresses. Since the IP addresses extension does not explicitly mention what functions the node can perform for the IP addresses it becomes impossible to know the reason for which the certificate was allowed. In order to facilitate issuance of certificates for specific functions, we need to encode the functions permitted for the certificate into the certificate itself. The WG will develop a certificate profile, including a definition of X.509 Extended Key Usage for SeND . In addition, the WG will recommend best practices for (1) enrollment, (2) revocation checking, and (3) publishing of certificates. This WG will ensure that the profile and recommended practices will cover usage by hosts in addition to routers. The working group will coordinate this activity with the PKIX and SIDR WGs. Prior to IESG submission of the certificate profile, the working group will seek input from and coordinate with other groups enabling cryptographic identification of device-related properties (e.g., IEEE 802.1ar, IEEE 802.16, WiMAX Forum, IETF CAPWAP WG). - Develop a standard track document defining a mechanism to perform SeND certificate provisioning for routers. SeND protocol as defined in RFC3971 specifies how IPv6 nodes can trust the prefixes advertised by a router. The solution is based on the use of the IP Address Delegation extension (RFC3779) in X.509 v3 certificates (RFC3280). This work will provide the tools require to provision with the certificates to the routers in an automatic manner. The working will coordinate this activity with the PKIX WG. - Produce a problem statement document for Neighbor Discovery Proxies and then specify standards-track SEND Extensions to support Neighbor Discovery Proxies: SEND protocol as currently defined in RFC 3971 lacks of support for ND Proxies defined in RFC 3775 and RFC 4389. Extensions to the SEND protocol will be defined in order to provide equivalent SEND security capabilities to ND Proxies. - Develop an informational document analysing different approaches to allow SeND and CGAs to be used in conjunction with DHCP, and making recommendations on which are the best suited. Recharter based on the result of the analysis. - Update base specifications (RFC 3971 and 3972). 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). Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Sep 2008 Mar 2009 SeND Hash Threat Analysis Oct 2008 Mar 2009 Securing Neighbor Discovery Proxy Problem Statement Jul 2009 Jul 2009 Certificate profile and certificate management for SEND Detecting Network Attachment (dna) ---------------------------------- Charter Last Modified: 2008-09-23 Current Status: Active Working Group Chair(s): Greg Daley Suresh Krishnan Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:dna@eng.monash.edu.au To Subscribe: majordomo@ecselists.eng.monash.edu.au In Body: subscribe dna Archive: http://ecselists.eng.monash.edu.au/~warchive/dna/ Description of Working Group: When an IPv6 node detects or suspects that its underlying link layer (L2) connectivity has or may have undergone a change, it needs to check whether its IP layer (L3) addressing and routing configurations are still valid or have changed. In the case that the L3 connectivity has changed, the node needs to reconfigure and may need to initiate mobility procedures, such as sending Mobile IP binding updates. Changes in an L2 connection do not necessarily mean that there has been change in L3 connectivity. For the purposes of detecting network attachment, an L3 link is defined as the topological range within which IP packets may be sent without resorting to forwarding. In other words, a link is the range where a given IP configuration is valid. In IPv6, the IP layer configuration information includes the set of valid unicast addresses[RFC 2462, RFC 3315], the Duplicate Address Detection (DAD) status of the addresses[RFC 2462], valid routing prefixes[RFC 2461], set of default routers[RFC 2461], neighbor and destination caches[RFC 2461], multicast listener (MLD) state[RFC 2710]. The current IPv6 stateless and stateful autoconfiguration procedures may take a fairly long time due to delays associated with Router Discovery and Duplicate Address Detection. The main goal of this WG is to develop mechanisms that reduce or avoid such delays, in cases where they are not necessary. For example if an interface comes back up after having been down momentarily, it can be quicker to verify that one is still attached to the same link than rerunning the full reconfiguration as if one were connecting to a new L3 link and had no previous configuration information cached. In some wireless technologies, the link layer state and events may not give an accurate indication of whether or not the IP addressing configuration and routability have changed. For example, a host may be able to see a base station but still be unable to deliver or receive IP packets within the L3 link. Moreover, a hardware indication that a radio link is up does not necessarily mean that all link layer configuration, such as authentication or virtual LAN connectivity has been completed. Therefore detecting network attachment requires not only change detection but IP layer connectivity testing. The purpose of the DNA working group is to define standards track and BCP documents that allow hosts to detect their IP layer configuration and connectivity status quickly, proposing some optimization to the current specifications that would allow a host to reconfigure its IPv6 layer faster than today. The group will define a set of goals for detecting network attachment, describing existing issues and important properties of potential solutions. The working group will describe best current practice for nodes making use of existing information for detecting network attachment. The working group will define a set of extensions to the current IPv6 configuration protocols [RFC 2461, 2462, possibly RFC 3315] that allow the nodes to discover whether L3 configuration or connectivity may have changed more reliably and easily than today. Initiation of L3 link change detection procedures can be achieved either through reception (or lack of reception) of messages at the IP layer or through indications from other layers. The working group will produce an informational document that contains a catalogue of the indications currently available from a subset of wireless link layer technologies. The DNA WG will not define new procedures or APIs related to link layers. Documents * Define goals for detecting network attachment in IPv6 (Informational). * Specify recommendations for detecting network attachment and L3 link change in IPv6 networks (BCP). * Define a protocol extension for detecting network attachment and L3 link change in IPv6 networks more reliably and easily (Standards Track). * Document existing link layer (L2) information which is useful to start detecting network attachment (Informational). Description of Working Group: When an IPv6 node detects or suspects that its underlying link layer (L2) connectivity has or may have undergone a change, it needs to check whether its IP layer (L3) addressing and routing configurations are still valid or have changed. In the case that the L3 connectivity has changed, the node needs to reconfigure and may need to initiate mobility procedures, such as sending Mobile IP binding updates. Changes in an L2 connection do not necessarily mean that there has been change in L3 connectivity. For the purposes of detecting network attachment, an L3 link is defined as the topological range within which IP packets may be sent without resorting to forwarding. In other words, a link is the range where a given IP configuration is valid. In IPv6, the IP layer configuration information includes the set of valid unicast addresses[RFC 2462, RFC 3315], the Duplicate Address Detection (DAD) status of the addresses[RFC 2462], valid routing prefixes[RFC 2461], set of default routers[RFC 2461], neighbor and destination caches[RFC 2461], multicast listener (MLD) state[RFC 2710]. The current IPv6 stateless and stateful autoconfiguration procedures may take a fairly long time due to delays associated with Router Discovery and Duplicate Address Detection. The main goal of this WG is to develop mechanisms that reduce or avoid such delays, in cases where they are not necessary. For example if an interface comes back up after having been down momentarily, it can be quicker to verify that one is still attached to the same link than rerunning the full reconfiguration as if one were connecting to a new L3 link and had no previous configuration information cached. In some wireless technologies, the link layer state and events may not give an accurate indication of whether or not the IP addressing configuration and routability have changed. For example, a host may be able to see a base station but still be unable to deliver or receive IP packets within the L3 link. Moreover, a hardware indication that a radio link is up does not necessarily mean that all link layer configuration, such as authentication or virtual LAN connectivity has been completed. Therefore detecting network attachment requires not only change detection but IP layer connectivity testing. The purpose of the DNA working group is to define standards track and BCP documents that allow hosts to detect their IP layer configuration and connectivity status quickly, proposing some optimization to the current specifications that would allow a host to reconfigure its IPv6 layer faster than today. The group will define a set of goals for detecting network attachment, describing existing issues and important properties of potential solutions. The working group will describe best current practice for nodes making use of existing information for detecting network attachment. The working group will define a set of extensions to the current IPv6 configuration protocols [RFC 2461, 2462, possibly RFC 3315] that allow the nodes to discover whether L3 configuration or connectivity may have changed more reliably and easily than today. Initiation of L3 link change detection procedures can be achieved either through reception (or lack of reception) of messages at the IP layer or through indications from other layers. The working group will produce an informational document that contains a catalogue of the indications currently available from a subset of wireless link layer technologies. The DNA WG will not define new procedures or APIs related to link layers. Documents * Define goals for detecting network attachment in IPv6 (Informational). * Specify recommendations for detecting network attachment and L3 link change in IPv6 networks (BCP). * Define a protocol extension for detecting network attachment and L3 link change in IPv6 networks more reliably and easily (Standards Track). * Document existing link layer (L2) information which is useful to start detecting network attachment (Informational). Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2006 Mar 2009 Tentative Options for Link-Layer Addresses in IPv6 Neighbour Discovery Apr 2008 Jul 2009 Simple procedures for Detecting Network Attachment in IPv6 DNS Extensions (dnsext) ----------------------- Charter Last Modified: 2009-04-13 Current Status: Active Working Group Chair(s): Olafur Gudmundsson Andrew Sullivan Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion:namedroppers@ops.ietf.org To Subscribe: namedroppers-request@ops.ietf.org Archive: http://ops.ietf.org/lists/namedroppers/ Description of Working Group: The DNS has a large installed base and repertoire of protocol specifications. The DNSEXT WG group will actively advance DNS protocol-related RFCs on the standards track while thoroughly reviewing further proposed extensions. The scope of the DNSEXT WG is confined to the DNS protocol, particularly changes that affect DNS protocols "on the wire" or the internal processing of DNS data. DNS operations are out of scope for the WG. The WG will limit itself to review of proposals for new extensions, clarification to the DNS protocol, including DNSSEC, and review of DNS protocol related work which may originate elsewhere in the IETF, including AD-sponsored submissions or drafts in other working groups. Adoption of new DNSEXT standards track working group items will require changes to this charter. The WG does not intend to hold face to face meetings, though may do so if deemed necessary for resolution of a specific issue at hand. The DNSEXT WG will conduct the specified RFC2929bis review of RR templates as they are posted and also maintain a living ID of errata for the DNSSEC document set. Description of Working Group: The DNS has a large installed base and repertoire of protocol specifications. The DNSEXT WG group will actively advance DNS protocol-related RFCs on the standards track while thoroughly reviewing further proposed extensions. The scope of the DNSEXT WG is confined to the DNS protocol, particularly changes that affect DNS protocols "on the wire" or the internal processing of DNS data. DNS operations are out of scope for the WG. The WG will limit itself to review of proposals for new extensions, clarification to the DNS protocol, including DNSSEC, and review of DNS protocol related work which may originate elsewhere in the IETF, including AD-sponsored submissions or drafts in other working groups. Adoption of new DNSEXT standards track working group items will require changes to this charter. The WG does not intend to hold face to face meetings, though may do so if deemed necessary for resolution of a specific issue at hand. The DNSEXT WG will conduct the specified RFC2929bis review of RR templates as they are posted and also maintain a living ID of errata for the DNSSEC document set. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Mar 2000 Mar 2009 DNS Zone Transfer Protocol (AXFR) May 2005 Jan 2009 Clarifications and Implementation Notes for DNSSECbis Feb 2006 Jun 2009 Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC Sep 2006 Jun 2009 Update to DNAME Redirection in the DNS Jun 2008 May 2009 Deprecation of HMAC-MD5 in DNS TSIG and TKEY Resource Records Nov 2008 Jul 2009 DNS Proxy Implementation Guidelines Dynamic Host Configuration (dhc) -------------------------------- Charter Last Modified: 2009-04-16 Current Status: Active Working Group Chair(s): John Jason Brzozowski Ted Lemon Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion:dhcwg@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/dhcwg Archive: http://www.ietf.org/mail-archive/web/dhcwg/current/maillist.html Description of Working Group: The dhc working group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCPv4 is currently a "Draft Standard" and is documented in RFC 2131 and RFC 2132. DHCPv6 is currently a "Proposed Standard" and is documented in RFC 3315. Subsequent RFCs document additional options and other enhancements to the specifications. The DHC WG is responsible for reviewing DHCP options or other extensions (for both IPv4 and IPv6). The DHC WG is expected to review all proposed extensions to DHCP to ensure that they are consistent with the DHCP specification and other option formats, that they do not duplicate existing mechanisms, etc. Generally speaking, the DHC WG will not be responsible for evaluating the semantic content of proposed options. Similarly, the ownership of specifications typically belongs the relevant working group that needs more functionality from DHCP, not the DHC WG. The DHC WG coordinates reviews of the proposed options together with those working groups. It is required that those working groups have consensus to take on the work and that the work is within their charter. Exceptionally, with AD agreement, this same process can also be used for Individual Submissions originating outside WGs. However, the DHC WG can in some cases develop its own options that relate to either maintenance of existing specifications or improvements in the operation of the DHCP infrastructure itself. The DHC WG has the following main objectives: * Develop extensions to the DHCP infrastructure as required to meet new applications and deployments of DHCP. The topics currently in development are: - Subnet allocation mechanisms - Virtual subnet identification option - Option for passing DNS domain information in DHCPv6 - DHCP relay agent assignment notification in DHCPv6 - Option for DHCPv6 server reply sequence numbers - Rebinding capability for DHCPv6 Reconfigure messages - Behavior of layer 2 relay agents The adoption of new items requires explicit agreement from the AD or rechartering. * Write analyses of the DHCPv4 and DHCPv6 specifications, including RFC 2131, RFC 2132, RFC 3315 and other RFCs defining additional options, which identifies ambiguities, contradictory specifications and other obstacles to development of interoperable implementations. Recommend a process for resolving identified problems and incorporating the resolutions into the DHCP specification. Secondly, advance DHCPv4 (RFC 2131 and RFC 2132) and DHCPv6 (RFC 3315) in IETF Standards Track. Thirdly, specify guidelines for creating new DHCP options, and report on the status of DHCPv4 option reclassification. * Assess the requirements for a dual-stack host to use DHCP to obtain configuration settings for both IPv4 and IPv6. Hosts that include implementations of both IPv4 and IPv6 ("dual-stack hosts") may use DHCP to obtain configuration settings (including assigned addresses) for both IPv4 and IPv6. The DHCPv4 and DHCPv6 specifications (RFC 2131, RFC 2132, RFC 3315 and subsequent RFCs) do not explicitly explain how a dual-stack host uses DHCP to obtain configuration settings for both IP stacks. The DHC WG will evaluate solutions for configuration of dual-stack hosts through DHCP and select a solution that will be developed and published by the WG. * Hold a discussion whether on-link prefix information and default router information is needed in DHCP in addition to router advertisements. Actual solutions are out of scope for the WG, however. 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. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jul 2001 Mar 2009 Virtual Subnet Selection Options for DHCPv4 and DHCPv6 Feb 2003 Mar 2009 Subnet Allocation Option Jan 2006 Feb 2009 DHCPv6 Relay Agent Assignment Notification (RAAN) Option Nov 2006 Feb 2009 DHCPv6 Server Reply Sequence Number Option Sep 2007 Feb 2009 Guidelines for Creating New DHCP Options Jan 2008 Mar 2009 Container Option for Server Configuration Jan 2008 Apr 2009 Layer 2 Relay Agent Information Jun 2008 Feb 2009 Extensions to Layer 2 Relay Agent Aug 2008 Apr 2009 DHCPv6 option for network boot Oct 2008 Jan 2009 DHCPv4 Leasequery by relay agent remote ID Jan 2009 Jan 2009 DHCPv6 Vendor-specific Message Jan 2009 Jan 2009 DHCPv4 Vendor-specific Message Feb 2009 Feb 2009 Bulk DHCPv4 Lease Query Feb 2009 Mar 2009 Dynamic Host Configuration Protocol DHCPINFORM Message Clarifications Jun 2009 Jun 2009 Forcerenew Nonce Authentication Jul 2009 Jul 2009 Lightweight DHCPv6 Relay Agent (LDRA) Host Identity Protocol (hip) ---------------------------- Charter Last Modified: 2009-04-13 Current Status: Active Working Group Chair(s): David Ward Gonzalo Camarillo Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion:hipsec@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/hipsec Archive: http://www.ietf.org/mail-archive/web/hipsec/current/maillist.html Description of Working Group: The Host Identity Protocol (HIP) provides a method of separating the end-point identifier and locator roles of IP addresses. It introduces a new Host Identity (HI) name space, based on public keys. The public keys are typically, but not necessarily, self generated. The specifications for the architecture and protocol details for these mechanisms consist of: HIP Architecture (RFC 4423) Host Identity Protocol (RFC 5201) There are several publicly known interoperating implementations, some of which are open source. Currently, the HIP base protocol works well with any pair of co-operating end-hosts. However, to be more useful and more widely deployable, HIP needs some support from the existing infrastructure, including the DNS, and a new piece of infrastructure, called the HIP rendezvous server. +-------------------------------------------------------+ | The purpose of this Working Group is to define the | | minimal infrastructure elements that are needed for | | HIP experimentation on a wide scale. | +-------------------------------------------------------+ At this point, the missing elements for running such wide-scale experiments are a NAT traversal solution, a description on the interactions between legacy (i.e., HIP unaware) applications and HIP, and a native API for HIP. Additionally, the working group will specify, also in Experimental RFCs, how to build HIP-based overlays. HIP-based overlays have received a lot of attention in different fora and are seen as a key area for HIP experimentation where the benefits HIP brings may be most relevant. Note that even though the specifications are chartered for Experimental, it is understood that their quality and security properties should match the standards track requirements. The main purpose for producing Experimental documents instead of standards track ones are the unknown effects that the mechanisms may have on applications and on the Internet at large. In parallel to this working group, there is an IRTF Research Group with a broader scope that includes efforts both on developing the more forward looking aspects of the HIP architecture and on exploring the effects that HIP may have on the applications and the Internet. The following are charter items for the working group: o Specify how legacy (i.e., HIP unaware) applications can be made to work with HIP. o Specify a solution for HIP to traverse legacy (i.e., HIP unaware) NATs. This solution will be based on existing NAT traversal mechanisms such as ICE (Interactive Connectivity Establishment). o Specify a native HIP socket API. o Specify a framework to build HIP-based overlays. This framework will describe how HIP can perform some of the tasks needed to build an overlay and how technologies developed somewhere else (e.g., a peer protocol developed in the P2PSIP WG) can complement HIP by performing the tasks HIP was not designed to perform. o Specify how to generate ORCHIDs from other node identifiers including both cryptographic ones (leading to cryptographic delegation) and non-cryptographic ones (e.g., identifiers defined by a peer protocol). o Specify how to carry certificates in the base exchange. This was removed from the base HIP spec so that the mechanism is specified in a stand-alone spec. o Specify how to carry upper-layer data over specified HIP packets. These include some of the existing HIP packets and possibly new HIP packets (e.g., a HIP packet that occurs outside a HIP base exchange). Description of Working Group: The Host Identity Protocol (HIP) provides a method of separating the end-point identifier and locator roles of IP addresses. It introduces a new Host Identity (HI) name space, based on public keys. The public keys are typically, but not necessarily, self generated. The specifications for the architecture and protocol details for these mechanisms consist of: HIP Architecture (RFC 4423) Host Identity Protocol (RFC 5201) There are several publicly known interoperating implementations, some of which are open source. Currently, the HIP base protocol works well with any pair of co-operating end-hosts. However, to be more useful and more widely deployable, HIP needs some support from the existing infrastructure, including the DNS, and a new piece of infrastructure, called the HIP rendezvous server. +-------------------------------------------------------+ | The purpose of this Working Group is to define the | | minimal infrastructure elements that are needed for | | HIP experimentation on a wide scale. | +-------------------------------------------------------+ At this point, the missing elements for running such wide-scale experiments are a NAT traversal solution, a description on the interactions between legacy (i.e., HIP unaware) applications and HIP, and a native API for HIP. Additionally, the working group will specify, also in Experimental RFCs, how to build HIP-based overlays. HIP-based overlays have received a lot of attention in different fora and are seen as a key area for HIP experimentation where the benefits HIP brings may be most relevant. Note that even though the specifications are chartered for Experimental, it is understood that their quality and security properties should match the standards track requirements. The main purpose for producing Experimental documents instead of standards track ones are the unknown effects that the mechanisms may have on applications and on the Internet at large. In parallel to this working group, there is an IRTF Research Group with a broader scope that includes efforts both on developing the more forward looking aspects of the HIP architecture and on exploring the effects that HIP may have on the applications and the Internet. The following are charter items for the working group: o Specify how legacy (i.e., HIP unaware) applications can be made to work with HIP. o Specify a solution for HIP to traverse legacy (i.e., HIP unaware) NATs. This solution will be based on existing NAT traversal mechanisms such as ICE (Interactive Connectivity Establishment). o Specify a native HIP socket API. o Specify a framework to build HIP-based overlays. This framework will describe how HIP can perform some of the tasks needed to build an overlay and how technologies developed somewhere else (e.g., a peer protocol developed in the P2PSIP WG) can complement HIP by performing the tasks HIP was not designed to perform. o Specify how to generate ORCHIDs from other node identifiers including both cryptographic ones (leading to cryptographic delegation) and non-cryptographic ones (e.g., identifiers defined by a peer protocol). o Specify how to carry certificates in the base exchange. This was removed from the base HIP spec so that the mechanism is specified in a stand-alone spec. o Specify how to carry upper-layer data over specified HIP packets. These include some of the existing HIP packets and possibly new HIP packets (e.g., a HIP packet that occurs outside a HIP base exchange). Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Nov 2006 Jun 2009 Basic HIP Extensions for Traversal of Network Address Translators Nov 2006 May 2009 Basic Socket Interface Extensions for Host Identity Protocol (HIP) Oct 2008 Jul 2009 HIP Certificates Oct 2008 Mar 2009 HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment IP over DVB (ipdvb) ------------------- Charter Last Modified: 2009-05-26 Current Status: Active Working Group Chair(s): Gorry Fairhurst Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Secretary(ies): Martin Stiemerling Mailing Lists: General Discussion:ipdvb@erg.abdn.ac.uk To Subscribe: majordomo@erg.abdn.ac.uk In Body: subscribe ipdvb at majordomo@erg.abdn.ac.uk Archive: http://www.erg.abdn.ac.uk/ipdvb/archive/ Description of Working Group: The WG will develop new protocols and architectures to enable better deployment of IP over MPEG-2 transport and provide easier interworking with IP networks. Specific properties of this subnetwork technology include link-layer support for unicast and multicast, large numbers of down-stream receivers, and efficiency of transmission. These properties resemble those in some other wireless networks. The specific focus of the group is on the use of MPEG-2 transport (examples include the Digital Video Broadcast (DVB) standards: DVB-RCS; DVB-S and DVB-T and related ATSC Specifications) in next generation networks and is not concerned with the development, replacement, or retention of existing protocols on the existing generation of networks. The WG will endeavour to reuse existing open standard technologies, giving guidance on usage in IP networks, whenever they are able to fulfill requirements. For instance, we acknowledge the existing Multiprotocol Encapsulation (MPE) [ATSC A/90;ETSI EN 301192] and that this will continue to be deployed in the future to develop new markets. Any alternative encapsulation would need to co-exist with MPE. Appropriate standards will be defined to support transmission of IPv4 and IPv6 datagrams between IP networks connected using MPEG-2 transport subnetworks. This includes options for encapsulation, dynamic unicast address resolution for IPv4/IPv6, and the mechanisms needed to map routed IP multicast traffic to the MPEG-2 transport subnetwork. The standards will be appropriate to both MPE and any alternative encapsulation method developed. The developed protocols may also be applicable to other multicast enabled subnetwork technologies supporting large numbers of directly connected systems. The current list of work items is: Specify the requirements and architecture for supporting IPv4/IPv6 via MPEG-2 transmission networks. Such requirements should consider the range of platforms currently (or anticipated to be) in use. This draft will be an Informational RFC. Define a standards-track RFC defining an efficient encapsulation method. The design will consider the need for MAC addresses, the potential need for synchronisation between streams, support for a wide range of IPv4/IPv6 and multicast traffic. Provide an Informational RFC describing a framework for unicast and multicast address resolution over MPEG-2 transmission networks. The document will describe options for the address resolution process, relating these to appropriate usage scenarios and suggesting appropriate protocol mechanisms for both the existing Multi-Protocol Encapsulation (MPE) and the efficient encapsulation (2). Consideration will be paid to existing standards, and the cases for IPv6 and IPv4 will be described. Define standards-track RFC(s) to specify procedures for dynamic address resolution for IPv4/IPv6. This will describe the protocol and syntax of the information exchanged to bind unicast and multicast flows to the MPEG-2 TS Logical Channels. This will include specific optimisations appropriate for networks reaching large numbers of down-stream systems. Description of Working Group: The WG will develop new protocols and architectures to enable better deployment of IP over MPEG-2 transport and provide easier interworking with IP networks. Specific properties of this subnetwork technology include link-layer support for unicast and multicast, large numbers of down-stream receivers, and efficiency of transmission. These properties resemble those in some other wireless networks. The specific focus of the group is on the use of MPEG-2 transport (examples include the Digital Video Broadcast (DVB) standards: DVB-RCS; DVB-S and DVB-T and related ATSC Specifications) in next generation networks and is not concerned with the development, replacement, or retention of existing protocols on the existing generation of networks. The WG will endeavour to reuse existing open standard technologies, giving guidance on usage in IP networks, whenever they are able to fulfill requirements. For instance, we acknowledge the existing Multiprotocol Encapsulation (MPE) [ATSC A/90;ETSI EN 301192] and that this will continue to be deployed in the future to develop new markets. Any alternative encapsulation would need to co-exist with MPE. Appropriate standards will be defined to support transmission of IPv4 and IPv6 datagrams between IP networks connected using MPEG-2 transport subnetworks. This includes options for encapsulation, dynamic unicast address resolution for IPv4/IPv6, and the mechanisms needed to map routed IP multicast traffic to the MPEG-2 transport subnetwork. The standards will be appropriate to both MPE and any alternative encapsulation method developed. The developed protocols may also be applicable to other multicast enabled subnetwork technologies supporting large numbers of directly connected systems. The current list of work items is: Specify the requirements and architecture for supporting IPv4/IPv6 via MPEG-2 transmission networks. Such requirements should consider the range of platforms currently (or anticipated to be) in use. This draft will be an Informational RFC. Define a standards-track RFC defining an efficient encapsulation method. The design will consider the need for MAC addresses, the potential need for synchronisation between streams, support for a wide range of IPv4/IPv6 and multicast traffic. Provide an Informational RFC describing a framework for unicast and multicast address resolution over MPEG-2 transmission networks. The document will describe options for the address resolution process, relating these to appropriate usage scenarios and suggesting appropriate protocol mechanisms for both the existing Multi-Protocol Encapsulation (MPE) and the efficient encapsulation (2). Consideration will be paid to existing standards, and the cases for IPv6 and IPv4 will be described. Define standards-track RFC(s) to specify procedures for dynamic address resolution for IPv4/IPv6. This will describe the protocol and syntax of the information exchanged to bind unicast and multicast flows to the MPEG-2 TS Logical Channels. This will include specific optimisations appropriate for networks reaching large numbers of down-stream systems. Internet-Drafts: No Current Internet-Drafts. IP over IEEE 802.16 Networks (16ng) ----------------------------------- Charter Last Modified: 2009-07-02 Current Status: Active Working Group Chair(s): Gabriel Montenegro Soohong Daniel Park Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Technical Advisor(s): Maximilian Riegel Dave Thaler Secretary(ies): Jihoon Lee Mailing Lists: General Discussion:16ng@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/16ng Archive: http://www.ietf.org/mail-archive/web/16ng Description of Working Group: Broadband Wireless Access Networks address the inadequacies of low bandwidth wireless communication for user requirements such as high quality data/voice service, wide coverage, etc. The IEEE 802.16 Working Group on Broadband Wireless Access Standards develops standards and recommended practices to support the development and deployment of Broadband Wireless Metropolitan Area Networks. A particularity of IEEE 802.16 is that it does not include a rigid upper edge MAC service interface. Instead, it provides multiple "convergence sublayers (CS)" with the assumption that the choice and configuration of the upper edge will be done in accordance with the needs of a specific deployment environment (which might be DSL replacement, mobile access, 802.11 or CDMA backhaul etc.). Specifically, immediately subsequent to network entry, an 802.16 subscriber station has no capability whatsoever for data (as opposed to management) connectivity. Especially, in IP CS case, the criteria by which the Base Station (or other headend elements) sets up the 802.16 MAC connections for data transport are not part of the 802.16 standard, and depend on the type of data services being offered (e.g., the set up of link layer connections will be different for IPv4 and IPv6 services). Additionally - as IEEE 802.16 is a point-to-multipoint network ? an 802.16 subscriber station is not capable of multicasting (e.g., for neighbor discovery, ARP, IP multicasting services, etc.) or direct communication to the other nodes attached to the same Base Station within the same subnet (prefix). Unlike 3G or xDSL technologies, IEEE 802.16 is not part of an end-to- end system definition. Currently, the WiMAX Forum, and, in particular, its NWG (Network Working Group) is defining a network architecture based on IEEE 802.16. The principal objective of the 16ng working group is to specify the operation of IPv4 and IPv6 over IEEE 802.16, taking into account the IPv4, IPv6 and Ethernet Convergence Sublayers. The working group may issue recommendations to IEEE 802.16 and WiMax aiming at improving support for IP. The scope of this working group is as follows (WG Deliverables); - Produce "16ng Problem Statement, Goal and Requirement" to identify the specific gaps in the 802.16 MAC for IPv4/IPv6 support, describe possible network models (ie. point-to-point, broadcast etc.), and provide 16ng related terminology to be used for the base guideline while defining solution frameworks. [Informational RFC] - Produce "IPv6 over IEEE 802.16 Networks in conjunction with IPv6 CS" to define IPv6 operation including the transmission of IPv6 over IEEE 802.16 link, Neighbor Discovery Protocol, Stateful (DHCPv6) and Stateless Address Configuration, Broadcast, Multicast, etc. [Proposed Standard RFC] - Produce "IPv6 over IEEE 802.16 Networks in conjunction with Ethernet CS" to define IPv6 operation including the transmission of IPv6 over IEEE 802.16 link, Neighbor Discovery Protocol, Stateful (DHCPv6) and Stateless Address Configuration, Broadcast, Multicast, etc. [Proposed Standard RFC] - Produce "IPv4 over IEEE 802.16 Networks in conjunction with IPv4 CS" to define IPv4 operation including the transmission of IPv4 over IEEE 802.16 links, ARP operation, Stateful Address Configuration (DHCPv4), Broadcast, Multicast, etc [Proposed Standard RFC] - Produce "IPv4 over IEEE 802.16 Networks in conjunction with Ethernet CS" to define IPv4 operation including the transmission of IPv4 over IEEE 802.16 links, ARP operation, Stateful Address Configuration (DHCPv4), Broadcast, Multicast, etc [Proposed Standard RFC] - Produce "IP deployment over IEEE 802.16 Networks" to illustrate the IP deployment scenarios including IP CS and Ethernet CS considerations over IEEE 802.16 networks based on the WiMAX and WiBro. [Informational RFC] This working group will take dual stack operation into account in its specifications, and reuse existing specifications whenever reasonable and possible. The ability to negotiate the used Convergence Sublayer is required, as no single mandatory CS can be specified for the clients. Work based on the Ethernet CS needs to take into account interoperability with existing hosts and other devices that employ Ethernet? to allow bridging. Description of Working Group: Broadband Wireless Access Networks address the inadequacies of low bandwidth wireless communication for user requirements such as high quality data/voice service, wide coverage, etc. The IEEE 802.16 Working Group on Broadband Wireless Access Standards develops standards and recommended practices to support the development and deployment of Broadband Wireless Metropolitan Area Networks. A particularity of IEEE 802.16 is that it does not include a rigid upper edge MAC service interface. Instead, it provides multiple "convergence sublayers (CS)" with the assumption that the choice and configuration of the upper edge will be done in accordance with the needs of a specific deployment environment (which might be DSL replacement, mobile access, 802.11 or CDMA backhaul etc.). Specifically, immediately subsequent to network entry, an 802.16 subscriber station has no capability whatsoever for data (as opposed to management) connectivity. Especially, in IP CS case, the criteria by which the Base Station (or other headend elements) sets up the 802.16 MAC connections for data transport are not part of the 802.16 standard, and depend on the type of data services being offered (e.g., the set up of link layer connections will be different for IPv4 and IPv6 services). Additionally - as IEEE 802.16 is a point-to-multipoint network ? an 802.16 subscriber station is not capable of multicasting (e.g., for neighbor discovery, ARP, IP multicasting services, etc.) or direct communication to the other nodes attached to the same Base Station within the same subnet (prefix). Unlike 3G or xDSL technologies, IEEE 802.16 is not part of an end-to- end system definition. Currently, the WiMAX Forum, and, in particular, its NWG (Network Working Group) is defining a network architecture based on IEEE 802.16. The principal objective of the 16ng working group is to specify the operation of IPv4 and IPv6 over IEEE 802.16, taking into account the IPv4, IPv6 and Ethernet Convergence Sublayers. The working group may issue recommendations to IEEE 802.16 and WiMax aiming at improving support for IP. The scope of this working group is as follows (WG Deliverables); - Produce "16ng Problem Statement, Goal and Requirement" to identify the specific gaps in the 802.16 MAC for IPv4/IPv6 support, describe possible network models (ie. point-to-point, broadcast etc.), and provide 16ng related terminology to be used for the base guideline while defining solution frameworks. [Informational RFC] - Produce "IPv6 over IEEE 802.16 Networks in conjunction with IPv6 CS" to define IPv6 operation including the transmission of IPv6 over IEEE 802.16 link, Neighbor Discovery Protocol, Stateful (DHCPv6) and Stateless Address Configuration, Broadcast, Multicast, etc. [Proposed Standard RFC] - Produce "IPv6 over IEEE 802.16 Networks in conjunction with Ethernet CS" to define IPv6 operation including the transmission of IPv6 over IEEE 802.16 link, Neighbor Discovery Protocol, Stateful (DHCPv6) and Stateless Address Configuration, Broadcast, Multicast, etc. [Proposed Standard RFC] - Produce "IPv4 over IEEE 802.16 Networks in conjunction with IPv4 CS" to define IPv4 operation including the transmission of IPv4 over IEEE 802.16 links, ARP operation, Stateful Address Configuration (DHCPv4), Broadcast, Multicast, etc [Proposed Standard RFC] - Produce "IPv4 over IEEE 802.16 Networks in conjunction with Ethernet CS" to define IPv4 operation including the transmission of IPv4 over IEEE 802.16 links, ARP operation, Stateful Address Configuration (DHCPv4), Broadcast, Multicast, etc [Proposed Standard RFC] - Produce "IP deployment over IEEE 802.16 Networks" to illustrate the IP deployment scenarios including IP CS and Ethernet CS considerations over IEEE 802.16 networks based on the WiMAX and WiBro. [Informational RFC] This working group will take dual stack operation into account in its specifications, and reuse existing specifications whenever reasonable and possible. The ability to negotiate the used Convergence Sublayer is required, as no single mandatory CS can be specified for the clients. Work based on the Ethernet CS needs to take into account interoperability with existing hosts and other devices that employ Ethernet? to allow bridging. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Dec 2006 Jan 2009 Transmission of IP over Ethernet over IEEE 802.16 Networks May 2007 Jun 2009 Transmission of IPv4 packets over IEEE 802.16's IP Convergence Sublayer IPv6 Maintenance (6man) ----------------------- Charter Last Modified: 2008-12-16 Current Status: Active Working Group Chair(s): Robert Hinden Brian Haberman Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:ipv6@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipv6 Archive: http://www.ietf.org/mail-archive/web/ipv6 Description of Working Group: The 6man working group is responsible for the maintenance, upkeep, and advancement of the IPv6 protocol specifications and addressing architecture. It is not chartered to develop major changes or additions to the IPv6 specifications. The working group will address protocol limitations/issues discovered during deployment and operation. It will also serve as a venue for discussing the proper location for working on IPv6-related issues within the IETF. The working group's work items are as follows: o Complete work on RA Flags Option o Complete work on RH0 Deprecation o Complete work on IPv6 over PPP Compression Negotiation o Complete work on Centrally Allocated Unique Local Addresses (ULA-C) All new work items not listed above require the approval of the working group and the sponsoring Area Director before they will be taken on by the working group. 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. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jan 2008 Jul 2009 Solution approaches for address-selection problems May 2008 May 2009 IPv6 Subnet Model: the Relationship between Links and Subnet Prefixes Sep 2008 Jul 2009 Handling of overlapping IPv6 fragments IPv6 over Low power WPAN (6lowpan) ---------------------------------- Charter Last Modified: 2009-04-13 Current Status: Active Working Group Chair(s): Carsten Bormann Geoffrey Mulligan Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion:6lowpan@lists.ietf.org To Subscribe: 6lowpan-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/6lowpan/current/maillist.html Description of Working Group: Background/Introduction: Well-established fields such as control networks, and burgeoning ones such as "sensor" (or transducer) networks, are increasingly being based on wireless technologies. Most (but certainly not all) of these nodes are amongst the most constrained that have ever been networked wirelessly. Extreme low power (such that they will run potentially for years on batteries) and extreme low cost (total device cost in single digit dollars, and riding Moore's law to continuously reduce that price point) are seen as essential enablers towards their deployment in networks with the following characteristics: * Significantly more devices than current local area networks * Severely limited code and ram space (e.g., highly desirable to fit the required code--MAC, IP and anything else needed to execute the embedded application--in, for example, 32K of flash memory, using 8-bit microprocessors) * Unobtrusive but very different user interface for configuration (e.g., using gestures or interactions involving the physical world) A chief component of these devices is wireless communication technology. In particular, the IEEE 802.15.4 standard is very promising for the lower (physical and link) layers. As for higher layer functions, there is considerable interest from non-IETF groups in using IP technology. The IEEE 1451.5 standard for wireless transducers has a chapter for 6LoWPAN and the ISA SP100 standard for wireless industrial networks has adopted 6LoWPAN for their network layer. This working group is expected to coordinate and interact with such groups. Description of Working Group: ----------------------------- The Working Group has completed two RFCs: "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" (RFC4919) that documents and discusses the problem space and "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" (RFC4944) which defines the format for the adaptation between IPv6 and 802.15.4. The Working Group will generate the necessary documents to ensure interoperable implementations of 6LoWPAN networks and will define the necessary security and management protocols and constructs for building 6LoWPAN networks, paying particular attention to protocols already available. 6lowpan will work closely with the Routing Over Low power and Lossy networks (roll) working group which is developing IPv6 routing solutions for low power and lossy networks (LLNs). Work Items: ----------- 1. Produce "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations" to define limited extensions to IPv6 Neighbor Discovery [RFC4861] for use specifically in low-power networks. This document (or documents) will define how to bootstrap a 6LoWPAN network and explore ND optimizations such as reusing the structure of the 802.15.4 network (e.g., by using the coordinators), and reduce the need for multicast by having devices talk to coordinators (without creating a single point-of-failure, or changing the semantics of the IPv6 ND multicasts). This document or documents will be a proposed standard. 2. Produce "6LoWPAN Improved Header Compression" to describe mechanisms to allow enhancements to the 6LoWPAN headers. Specifically this document will describe compression of addresses that are not link-local. Additionally this document may include other enhancements or optimizations of the HC1 or HC2 6LoWPAN headers. This document will be a proposed standard. 3. Produce "6LoWPAN Architecture" to describe the design and implementation of 6LoWPAN networks. This document will cover the concepts of "Mesh Under" and "Route Over", 802.15.4 design issues such as operation with sleeping nodes, network components (both battery- and line-powered), addressing, and IPv4/IPv6 network connections. This document will be informational. 4. As a separate Internet Draft, "6LoWPAN Routing Requirements" will describe 6LoWPAN-specific requirements on routing protocols used in 6LoWPANs, addressing both the "route-over" and "mesh-under" approach. This document will be created and owned by this working group but is expected to be reviewed by the ROLL WG. This document will be informational. 5. Produce "Use Cases for 6LoWPAN" to define, for a small set of applications with sufficiently unique requirements, how 6LoWPANs can solve those requirements, and which protocols and configuration variants can be used for these scenarios. The use cases will cover protocols for transport, application layer, discovery, configuration and commissioning. This document will be informational. 6. Produce "6LoWPAN Security Analysis" to define the threat model of 6LoWPANs, to document suitability of existing key management schemes and to discuss bootstrapping/installation/commissioning/setup issues. This document will be referenced from the "security considerations" of the other 6LoWPAN documents. This document will be informational. The working group will continue to reuse existing protocols and mechanisms whenever reasonable and possible. Non-milestone work items: ------------------------- The Working Group will keep two running, often-respun documents: -- implementers guide, collecting clarifying information based on input from implementers, in particular as it becomes available from interoperability events. -- interoperability guide, providing information for interoperability events, such as temporary interoperability testing strategies or information about test harnesses used for interoperability testing. Both documents will be WG documents, but their disposition is not decided at this point (one example for such a document became RFC 4815 after five years of maintenance and 22 revisions). 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). Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2008 Jun 2009 Compression Format for IPv6 Datagrams in 6LoWPAN Networks Oct 2008 Mar 2009 Design and Application Spaces for 6LoWPANs Nov 2008 May 2009 Neighbor Discovery for 6LoWPAN Nov 2008 Mar 2009 Problem Statement and Requirements for 6LoWPAN Routing Layer 2 Virtual Private Networks (l2vpn) ---------------------------------------- Charter Last Modified: 2009-04-13 Current Status: Active Working Group Chair(s): Shane Amante Vach Kompella Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Technical Advisor(s): Alex Zinin Mailing Lists: General Discussion:l2vpn@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/l2vpn Archive: http://www.ietf.org/mail-archive/web/l2vpn/current/maillist.html Description of Working Group: The L2VPN working group is responsible for defining and specifying a limited number of solutions for supporting provider-provisioned Layer-2 Virtual Private Networks (L2VPNs). Layer-2 VPN's comprise the following: 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that emulates an Ethernet (V)LAN across an IP or an MPLS-enabled IP Packet Switched Network (PSN). 2. Virtual Private Wire Service (VPWS) -- A Layer 2 service that provides point-to-point connectivity for a variety of link layers, including Frame Relay, ATM, Ethernet, PPP, etc., across an IP or MPLS-enabled IP PSN. 3. Virtual Private Multicast Service (VPMS) -- A Layer 2 service that Provides point-to-multipoint connectivity for a variety of link layers, including Frame Relay, ATM, Ethernet, PPP, etc., across an IP or MPLS-enabled IP PSN. 4. IP-only L2VPN -- A point-to-point or point-to-multipoint "IP-only" service over an IP or MPLS-enabled PSN. This service is similar to VPWS because it supports a variety of link-layer protocols on the Attachment Circuits, including Frame Relay, ATM, Ethernet, PPP, etc. IP-only L2VPN's are different from both VPLS and VPWS because unicast Layer-2 frames containing IP data packets, either IPv4 or IPv6, are de- encapsulated leaving only the IP data packet to be transmitted over the PSN. An IP-only L2VPN service also differs from L3VPN service, since no routing protocol operates between the PE and CE; furthermore, connectivity from CE to CE is provided via an emulated Layer-2 service over the PSN, which results in the CE's appearing to be directly attached to each other at Layer-2. The WG will address two specific types of IP-only L2VPN: a) Those with Attachment Circuits (ACs) that use the same Layer 2 framing at all attachment points in the same L2VPN; and, b) Those with ACs that use different Layer 2 framing at various attachment points in the same L2VPN. For (b), inter-working between link-layers is strictly out of scope beyond that which is minimally necessary to ensure that IP packets are transported from an AC of one type, across the IP or MPLS-enabled IP PSN, and to an AC of another type in as transparent a manner as possible to the CEs on both sides of the service. VPLS, VPWS and VPMS operate over Pseudowires (PWs) as defined by the PWE3 WG. As with a single PW, an L2VPN emulates a "native" service over a PSN that is reasonably faithful to, but may not be entirely indistinguishable from, the native service itself. Further, following in the "edge-to-edge" nature of the PWs that it uses, the L2VPN WG will not define any new mechanisms which exert control over the underlying PSN. When necessary it may, however, recommend or require the use of existing PSN QoS and path control mechanisms between PW endpoints which make up the L2VPN. L2VPN's will make use of existing IETF specified mechanisms unless there are technical reasons why the existing mechanisms are insufficient or unnecessary. The L2VPN WG is responsible for specification of the discovery and membership of PE's participating in a VPLS, VPWS or IP-only L2VPN as well as the membership of CE devices to a specific instance of a L2VPN. The L2VPN WG will provide extensions of existing protocols that will be discussed in protocol-specific WG's. In particular, the L2VPN WG may define extensions to pseudowire management mechanisms (including OAM), specifically Pseudowire Virtual Circuit Connectivity Verification (VCCV), for VPLS. Those VCCV extensions will be reviewed by PWE3 to ensure they are inline with the overall design/architecture of VCCV and MPLS. The L2VPN WG will not define new encapsulations, control (set-up, configuration, maintenance or tear-down), or resiliency mechanisms specifically related to pseudowires, because those must be defined by the PWE3 WG. Furthermore, the L2VPN WG will not define protocol inter- working between a VPLS or VPWS and native service-layer control, OAM or or resiliency mechanisms, as those will be defined by the PWE3 WG. On the other hand, the L2VPN WG may define how to operate native service- layer control, IEEE 802.1 OAM or resiliency mechanisms on top of a VPLS or VPWS service. The L2VPN WG scope includes the following: 1. Discovery of PE's participating in a Layer-2 VPN and the associated topology required for connectivity of the VPLS or VPWS service. 2. Signaling of information related to the discovery and membership of PE's within a L2VPN. These procedures must use PWE3 control and management procedures, or define requirements for extensions of PWE3 protocols to suit the needs of an L2VPN. Once those requirements are reviewed by the L2VPN WG, they should be provided to the PWE3 WG to derive solutions. 3. MIB's for Layer-2 VPN solutions. 4. Specification of requirements and framework that will define Operations Administration and Management (OAM) procedures for VPLS and VPWS VPN's, related to the operation of VPLS and VPWS VPN's over IP/MPLS PSN's. In addition, the L2VPN WG will define OAM solutions for VPLS and VPWS VPN's. 5. Mechanisms to permit optimization of multicast data traffic within a VPLS or VPWS VPN over an IP/MPLS PSN. 6. Improved service convergence for multi-homed CE's to VPLS PE's. Specifically, upon failure of a primary path from a CE to VPLS PE, initiate a rapid switch-over to an alternate path. If required, interactions with native service-layer resiliency mechanisms will be provided via solutions from other IETF WG's such as PWE3. 7. Enhancements to increase the scalability of the Control Plane and Data Plane (e.g.: number of PW's and MAC Forwarding Database, respectively) of VPLS PE nodes. 8. Define requirements and solutions for Auto-Discovery and Signaling of Inter-AS VPLS and VPWS L2VPN's, in addition to Inter-AS solutions for multicast-optimized VPLS and VPMS Layer-2 VPN's. The L2VPN WG currently works on the following tasks: - Define MIB's appropriate for each type of Layer-2 VPN. - Specification of Operations Administration and Management (OAM) mechanisms for VPLS, VPWS and IP-only VPN's. - Specification of procedures to permit optimization of L2VPN multicast data traffic within the PSN. - Define enhancements to increase scalability of VPLS PE nodes, to provide aggregation of learned customer MAC addresses at VPLS PE's. - Identify requirements for multi-homing of CE's to VPLS PE's. elements. Based on these requirements, define solutions for achieving fast convergence after a switchover to an alternate path, for example through optimized MAC flushing within a VPLS domain. - Identify requirements for Inter-AS VPLS and VPWS services. Define Inter-AS enhancements to VPLS and VPWS based on these requirements. - Include extensions to L2VPN protocols and RFC's necessary to create an MPLS Transport Profile (MPLS-TP). The work on the MPLS TP needs to be coordinated between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) that are chartered to do MPLS TP work. Where necessary, the WG will coordinate its activities with IEEE 802.1 and ITU. Description of Working Group: The L2VPN working group is responsible for defining and specifying a limited number of solutions for supporting provider-provisioned Layer-2 Virtual Private Networks (L2VPNs). Layer-2 VPN's comprise the following: 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that emulates an Ethernet (V)LAN across an IP or an MPLS-enabled IP Packet Switched Network (PSN). 2. Virtual Private Wire Service (VPWS) -- A Layer 2 service that provides point-to-point connectivity for a variety of link layers, including Frame Relay, ATM, Ethernet, PPP, etc., across an IP or MPLS-enabled IP PSN. 3. Virtual Private Multicast Service (VPMS) -- A Layer 2 service that Provides point-to-multipoint connectivity for a variety of link layers, including Frame Relay, ATM, Ethernet, PPP, etc., across an IP or MPLS-enabled IP PSN. 4. IP-only L2VPN -- A point-to-point or point-to-multipoint "IP-only" service over an IP or MPLS-enabled PSN. This service is similar to VPWS because it supports a variety of link-layer protocols on the Attachment Circuits, including Frame Relay, ATM, Ethernet, PPP, etc. IP-only L2VPN's are different from both VPLS and VPWS because unicast Layer-2 frames containing IP data packets, either IPv4 or IPv6, are de- encapsulated leaving only the IP data packet to be transmitted over the PSN. An IP-only L2VPN service also differs from L3VPN service, since no routing protocol operates between the PE and CE; furthermore, connectivity from CE to CE is provided via an emulated Layer-2 service over the PSN, which results in the CE's appearing to be directly attached to each other at Layer-2. The WG will address two specific types of IP-only L2VPN: a) Those with Attachment Circuits (ACs) that use the same Layer 2 framing at all attachment points in the same L2VPN; and, b) Those with ACs that use different Layer 2 framing at various attachment points in the same L2VPN. For (b), inter-working between link-layers is strictly out of scope beyond that which is minimally necessary to ensure that IP packets are transported from an AC of one type, across the IP or MPLS-enabled IP PSN, and to an AC of another type in as transparent a manner as possible to the CEs on both sides of the service. VPLS, VPWS and VPMS operate over Pseudowires (PWs) as defined by the PWE3 WG. As with a single PW, an L2VPN emulates a "native" service over a PSN that is reasonably faithful to, but may not be entirely indistinguishable from, the native service itself. Further, following in the "edge-to-edge" nature of the PWs that it uses, the L2VPN WG will not define any new mechanisms which exert control over the underlying PSN. When necessary it may, however, recommend or require the use of existing PSN QoS and path control mechanisms between PW endpoints which make up the L2VPN. L2VPN's will make use of existing IETF specified mechanisms unless there are technical reasons why the existing mechanisms are insufficient or unnecessary. The L2VPN WG is responsible for specification of the discovery and membership of PE's participating in a VPLS, VPWS or IP-only L2VPN as well as the membership of CE devices to a specific instance of a L2VPN. The L2VPN WG will provide extensions of existing protocols that will be discussed in protocol-specific WG's. In particular, the L2VPN WG may define extensions to pseudowire management mechanisms (including OAM), specifically Pseudowire Virtual Circuit Connectivity Verification (VCCV), for VPLS. Those VCCV extensions will be reviewed by PWE3 to ensure they are inline with the overall design/architecture of VCCV and MPLS. The L2VPN WG will not define new encapsulations, control (set-up, configuration, maintenance or tear-down), or resiliency mechanisms specifically related to pseudowires, because those must be defined by the PWE3 WG. Furthermore, the L2VPN WG will not define protocol inter- working between a VPLS or VPWS and native service-layer control, OAM or or resiliency mechanisms, as those will be defined by the PWE3 WG. On the other hand, the L2VPN WG may define how to operate native service- layer control, IEEE 802.1 OAM or resiliency mechanisms on top of a VPLS or VPWS service. The L2VPN WG scope includes the following: 1. Discovery of PE's participating in a Layer-2 VPN and the associated topology required for connectivity of the VPLS or VPWS service. 2. Signaling of information related to the discovery and membership of PE's within a L2VPN. These procedures must use PWE3 control and management procedures, or define requirements for extensions of PWE3 protocols to suit the needs of an L2VPN. Once those requirements are reviewed by the L2VPN WG, they should be provided to the PWE3 WG to derive solutions. 3. MIB's for Layer-2 VPN solutions. 4. Specification of requirements and framework that will define Operations Administration and Management (OAM) procedures for VPLS and VPWS VPN's, related to the operation of VPLS and VPWS VPN's over IP/MPLS PSN's. In addition, the L2VPN WG will define OAM solutions for VPLS and VPWS VPN's. 5. Mechanisms to permit optimization of multicast data traffic within a VPLS or VPWS VPN over an IP/MPLS PSN. 6. Improved service convergence for multi-homed CE's to VPLS PE's. Specifically, upon failure of a primary path from a CE to VPLS PE, initiate a rapid switch-over to an alternate path. If required, interactions with native service-layer resiliency mechanisms will be provided via solutions from other IETF WG's such as PWE3. 7. Enhancements to increase the scalability of the Control Plane and Data Plane (e.g.: number of PW's and MAC Forwarding Database, respectively) of VPLS PE nodes. 8. Define requirements and solutions for Auto-Discovery and Signaling of Inter-AS VPLS and VPWS L2VPN's, in addition to Inter-AS solutions for multicast-optimized VPLS and VPMS Layer-2 VPN's. The L2VPN WG currently works on the following tasks: - Define MIB's appropriate for each type of Layer-2 VPN. - Specification of Operations Administration and Management (OAM) mechanisms for VPLS, VPWS and IP-only VPN's. - Specification of procedures to permit optimization of L2VPN multicast data traffic within the PSN. - Define enhancements to increase scalability of VPLS PE nodes, to provide aggregation of learned customer MAC addresses at VPLS PE's. - Identify requirements for multi-homing of CE's to VPLS PE's. elements. Based on these requirements, define solutions for achieving fast convergence after a switchover to an alternate path, for example through optimized MAC flushing within a VPLS domain. - Identify requirements for Inter-AS VPLS and VPWS services. Define Inter-AS enhancements to VPLS and VPWS based on these requirements. - Include extensions to L2VPN protocols and RFC's necessary to create an MPLS Transport Profile (MPLS-TP). The work on the MPLS TP needs to be coordinated between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) that are chartered to do MPLS TP work. Where necessary, the WG will coordinate its activities with IEEE 802.1 and ITU. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Sep 2003 May 2006 Provisioning, Autodiscovery, and Signaling in L2VPNs Sep 2004 Jul 2008 L2VPN OAM Requirements and Framework Oct 2004 Jun 2009 ARP Mediation for IP Interworking of Layer 2 VPN Jul 2006 Sep 2008 VPLS Interoperability with CE Bridges Jan 2009 Jan 2009 Framework and Requirements for Virtual Private Multicast Service (VPMS) Apr 2009 Apr 2009 LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS May 2009 May 2009 Extensions to VPLS PE model for Provider Backbone Bridging Layer Two Tunneling Protocol Extensions (l2tpext) ------------------------------------------------- Charter Last Modified: 2009-06-25 Current Status: Active Working Group Chair(s): Ignacio Goyret Carlos Pignataro Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion:l2tpext@ietf.org To Subscribe: l2tpext-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/l2tpext/index.html Description of Working Group: This group is responsible for extensions to the Layer 2 Tunneling Protocol. Examples of L2TP "extensions" include any changes to the L2TP encapsulation, control messages, or new AVPs sent in IETF standard control messages. I. L2TP Background: L2TP (RFC2661) provides a means for tunneling PPP over IP. Because PPP can effectivly carry any traffic (e.g., IP (RFC 1332), IPX (RFC 1552), etc.) it can effectively be used to tunnel arbitrary protocols over IP. L2TP provides: - An extensible control protocol for dynamic setup, maintenance, and teardown of multiple layer 2 tunnels between two logical endpoints. - An encapsulation method for tunneling PPP frames between each endpoint. This includes multiplexing of multiple, discrete, PPP streams between each endpoint. L2TP looks (in most ways) like just another point-to-point link to PPP and may thereby take advantage of the work done for any protocol defined for use over a traditional PPP WAN link. It should be noted, however, that the ability to dynamically establish a PPP connection between any two IP connected endpoints brings new applications and challenges of scale to existing PPP implementations and protocol definitions that must be considered. As high-speed broadband access to the home replaces traditional dialup infrastructure, L2TP has been utilized as one standard method for aggregation and delivery of PPP connections over packet networks. Thus, rather than a relatively small scale or low speed circuit-switched connection such as an analog modem or ISDN connection at the L2TP Access Concentrator (LAC), we see PPP being received over ATM PVCs which are generally higher speed and "always-on" vs. temporally connected. Further, there are non-IETF standard PPP tunneling protocols that have been developed and deployed, including PPPoE (RFC 2516) and the 3GPP2 Wireless GPRS Tunneling Protocol Standard (http://www.3gpp.org) that interface with L2TP at various points in the network. While it is unfortunate that there is more than one standard method for tunneling PPP defined, each of these have their own installed bases and specific application-driven nuances. Proper integration with these various tunneling methods as they "hand-off" to the L2TP portion of the network must be ensured. II. L2TP Interaction with PWE3 for Pseudo-Wire Transport: In addition to tunneling PPP, L2TPEXT will develop protocol extensions necessary for the tunneling of specific "pseudo-wires" as defined in the PWE3 WG. Specific milestone identification for this activity is currently subject to ongoing work and results from PWE3. III. WG Activities The Working Group is currently focussed on the following activities: - RFC2661 bundles data transport, protocol signaling, and PPP emulation methods into a single document. This working group will separate RFC2661 into stand-alone documents for greater modularity. This will consist of a base L2TP document defining common tunneling constructs and encapsulation, and a PPP document defining the use of these constructs for tunneling of PPP sessions as defined in RFC2661. Documents for tunneling of pseudo-wires defined in PWE3 will be forthcoming as well. As RFC2661 is rewritten to separate the tunnel setup and maintenance sections for support of new applications and increased modularity, some modifications to the base protocol may be necessary. This includes addition of a Pseudo Wire AVP to identify the pseudo wire being carried (with PPP identified as 0). In all cases, these will follow the extensible models offered in the L2TP base protocol design, with as much attention to backwards compatibility as possible given the new requirements. In addition to its broader scope, L2TPEXT has ongoing work to complete from its inception as a tunneling protocol for PPP only. While RFC2661 will ultimately be made obsolete by a new L2TP base specification and companion PPP over L2TP specification, documents based on RFC2661 which do not require this new degree of modularity will still be published in the near term. These include: - Identification of specific parameters and modes of IPsec in order to aid interoperability when IPsec is used to secure L2TP traffic. - An L2TP MIB for network management. - An L2TP Differentiated Services Extension to negotiate DSCP parameters to be set for packets associated with a given L2TP tunnel, sessions within a tunnel, or L2TP control traffic which may need differentiated QoS settings. - Extensions to L2TP for additional or more robust control information for informational or operational purposes as deemed necessary based on operational experience. These include better transfer of L2TP PPP LCP Information between tunnel endpoints when such state needs to be shared, PPP Disconnect codes within L2TP control messages for better debugging, and L2TP session information for enhanced logging, billing, and error reporting. - Standard methods for operation over such packet networks such as Frame Relay and AAL5. - L2TP defines a base encapsulation for operation in typical environments for tunneling PPP at the time RFC2661 was being developed. In cases where bandwidth cost is at a premium, the size of the L2TP header becomes more significant. L2TP will define a compressed version of the L2TP header for these environments that takes advantage of the L2TP control plane to establish operational parameters allowing removal of information from individual packets. 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. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2005 Apr 2009 Layer Two Tunneling Protocol version 3 - Setup of Time-Division Multiplexing (TDM) Pseudowires Oct 2008 Apr 2009 L2TPv3 Extended Circuit Status Values Locator/ID Separation Protocol (lisp) ------------------------------------- Charter Last Modified: 2009-06-24 Current Status: Active Working Group Chair(s): Sam Hartman Darrel Lewis Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Technical Advisor(s): Joel Halpern Secretary(ies): Terry Manderson Mailing Lists: General Discussion:lisp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lisp Archive: http://www.ietf.org/mail-archive/web/lisp/current/maillist.html Description of Working Group: The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system and the impending exhaustion of the IPv4 address space. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the "locator/identifier separation". The basic idea behind the separation is that the Internet architecture combines two functions, routing locators, (where you are attached to the network) and identifiers (who you are) in one number space: The IP address. Proponents of the separation architecture postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system. The separation aims to decouple locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. LISP supports the separation of the IPv4 and IPv6 address space following a network-based map-and-encapsulate scheme (RFC 1955). In LISP, both identifiers and locators are IP addresses. In LISP, identifiers are composed of two parts: a "global" portion that uniquely identifies a particular site and a "local" portion that identifies an interface within a site. The "local" portion may be subdivided to identify a particular network within the site. For a given identifier, LISP maps the "global" portion of the identifier into a set of locators that can be used by de-capsulation devices to reach the identified interface; as a consequence a host would typically change identifiers when it moves from one site to another or whenever it moves from one subnet to another within an site. Typically, the same IP address will not be used as an identifier and locator in LISP. LISP requires no changes to end-systems or to most routers. LISP aims for an incrementally deployable protocol. A number of approaches are being looked at in parallel in the IRTF and IETF. At this time, these proposals are at an early stage. All proposals (including LISP) have potentially harmful side-effects to Internet traffic carried by the involved routers, have parts where deployment incentives may be lacking, and are NOT RECOMMENDED for deployment beyond experimental situations at this stage. Many of the proposals have components (such as the identifier to locator mapping system) where it is not yet known what kind of design alternative is the best one among many. However, despite these issues it would be valuable to write concrete protocol specifications and develop implementations that can be used to understand the characteristics of these designs. The LISP WG is chartered to work on the LISP base protocol (draft-farinacci-lisp-12.txt), the LISP+ALT mapping system (draft-fuller-lisp-alt-05.txt), LISP Interworking (draft-lewis-lisp-interworking-02.txt), LISP Map Server (draft-fuller-lisp-ms-00.txt), and LISP multicast (draft-farinacci-lisp-multicast-01.txt) for these purposes, with the given drafts as a starting point. The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. The Working Group will also develop security profiles for the ALT and/or other mapping systems. It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF (e.g., the Routing Research Group) that attempts to understand which type of a solution is optimal. The LISP WG is NOT chartered to develop the final or standard solution for solving the routing scalability problem. Its specifications are Experimental and labeled with accurate disclaimers about their limitations and not fully understood implications for Internet traffic. In addition, as these issues are understood, the working group will analyze and document the implications of LISP on Internet traffic, applications, routers, and security. This analysis will explain what role LISP can play in scalable routing. The analysis should also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on (draft-meyer-loc-id-implications) as well as the manageability and operability of LISP. Description of Working Group: The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system and the impending exhaustion of the IPv4 address space. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the "locator/identifier separation". The basic idea behind the separation is that the Internet architecture combines two functions, routing locators, (where you are attached to the network) and identifiers (who you are) in one number space: The IP address. Proponents of the separation architecture postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system. The separation aims to decouple locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. LISP supports the separation of the IPv4 and IPv6 address space following a network-based map-and-encapsulate scheme (RFC 1955). In LISP, both identifiers and locators are IP addresses. In LISP, identifiers are composed of two parts: a "global" portion that uniquely identifies a particular site and a "local" portion that identifies an interface within a site. The "local" portion may be subdivided to identify a particular network within the site. For a given identifier, LISP maps the "global" portion of the identifier into a set of locators that can be used by de-capsulation devices to reach the identified interface; as a consequence a host would typically change identifiers when it moves from one site to another or whenever it moves from one subnet to another within an site. Typically, the same IP address will not be used as an identifier and locator in LISP. LISP requires no changes to end-systems or to most routers. LISP aims for an incrementally deployable protocol. A number of approaches are being looked at in parallel in the IRTF and IETF. At this time, these proposals are at an early stage. All proposals (including LISP) have potentially harmful side-effects to Internet traffic carried by the involved routers, have parts where deployment incentives may be lacking, and are NOT RECOMMENDED for deployment beyond experimental situations at this stage. Many of the proposals have components (such as the identifier to locator mapping system) where it is not yet known what kind of design alternative is the best one among many. However, despite these issues it would be valuable to write concrete protocol specifications and develop implementations that can be used to understand the characteristics of these designs. The LISP WG is chartered to work on the LISP base protocol (draft-farinacci-lisp-12.txt), the LISP+ALT mapping system (draft-fuller-lisp-alt-05.txt), LISP Interworking (draft-lewis-lisp-interworking-02.txt), LISP Map Server (draft-fuller-lisp-ms-00.txt), and LISP multicast (draft-farinacci-lisp-multicast-01.txt) for these purposes, with the given drafts as a starting point. The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. The Working Group will also develop security profiles for the ALT and/or other mapping systems. It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF (e.g., the Routing Research Group) that attempts to understand which type of a solution is optimal. The LISP WG is NOT chartered to develop the final or standard solution for solving the routing scalability problem. Its specifications are Experimental and labeled with accurate disclaimers about their limitations and not fully understood implications for Internet traffic. In addition, as these issues are understood, the working group will analyze and document the implications of LISP on Internet traffic, applications, routers, and security. This analysis will explain what role LISP can play in scalable routing. The analysis should also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on (draft-meyer-loc-id-implications) as well as the manageability and operability of LISP. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- May 2009 May 2009 LISP for Multicast Environments May 2009 May 2009 Locator/ID Separation Protocol (LISP) May 2009 May 2009 Interworking LISP with IPv4 and IPv6 May 2009 May 2009 LISP Alternative Topology (LISP+ALT) May 2009 May 2009 LISP Map Server Mobility EXTensions for IPv6 (mext) ----------------------------------- Charter Last Modified: 2008-12-16 Current Status: Active Working Group Chair(s): Julien Laganier Marcelo Bagnulo Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:mext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mext Archive: http://www.ietf.org/mail-archive/web/mext Description of Working Group: Mobile IPv6 specifies routing support which permits an IPv6 host to continue using its home address as it moves around the Internet, enabling continuity of sessions. Mobile IPv6 supports transparency above the IP layer, including maintenance of active transport level sessions. In addition, network mobility (NEMO) mechanisms built on top of Mobile IPv6 allow managing the mobility of an entire network, as it changes its point of attachment to the Internet. The base specifications consist of: o RFC 3775 (Mobile IPv6) o RFC 3963 (NEMO) o RFC 4877 (Mobile IPv6 Operation with IKEv2) The MEXT Working Group continues the work of the former MIP6, NEMO, and MONAMI6 Working Groups. The primary goal of MEXT will be to (A) enhance base IPv6 mobility by continuing work on developments that are required for wide-scale deployments and specific deployment scenarios. Additionally, (B) the working group will ensure that any issues identified by implementation and interoperability experience are addressed, and that the base specifications are maintained. (C) The group will also produce informational documentation, such as design rationale documents or description of specific issues within the protocol. Deployment considerations call for (A.1) solutions to enable dual-stack operation, (A.2) mechanisms to support high-availability home agents, (A.3) allowing the use of multiple interfaces in mobile nodes, (A.4) ways to employ Mobile IPv6 in the presence of firewalls, (A.5) address the specific needs of automotive and aviation communities for route optimisation in network mobility, (A.6) support for AAA is needed as a continuation of earlier work on bootstrapping, (A.7) revocation of binding, (A.8) generic notification message format and (A.9) extended DMSIP home network support . Work items related to large scale deployment include: (A.1) A Solution for Mobile IPv6 and NEMO session continuity for dual stack hosts which attach to IPv4 access networks. Additionally provide a mechanism for carrying IPv4 packets via the Home agent for Mobile IPv6 or NEMO capable dual-stack hosts. (A.2) A protocol based solution for enhancing the reliability of home agents and a method to force a host/router to switch home agents. A mechanism to force an MN to switch the HA that is currently serving it. This is required in deployments where the HA needs to be taken offline for maintenance. (A.3) Use of multiple interfaces. Today, the protocols do not provide suppport for simultaneous differentiated use of multiple access technologies. Several proposals exist for such support, and some of them have been implemented and tested. When a mobile host/router uses multiple network interfaces simultaneously, or when multiple prefixes are available on a single network interface, the mobile host/router would end up with multiple Care-of Addresses (CoAs). In addition, the Home Agent might be attached to multiple network interfaces, or to a single network interface with multiple prefixes, hence resulting in the option to use multiple IP addresses for the Home Agent. This could result in the possibility of using a multitude of bi-directional tunnels between pairs of {Home Agent address, CoA} and a number of associated issues: establishment, selection and modification of multiple simultaneous tunnels. The objective of the WG is to produce a clear problem statement and to produce standard track specifications to the problems associated with the simultaneous use of multiple addresses for either mobile hosts using Mobile IPv6 or mobile routers using NEMO Basic Support and their variants (FMIPv6, HMIPv6, etc). Where the effects of having multiple prefixes on a single interface is identical to the effects of having multiple interfaces each with a single prefix, the WG will consider a generalized approach to cater for multiple prefixes available to a mobile host/router. The WG uses existing tunneling mechanisms defined for Mobile IPv6. The involved nodes need to select which tunnel instance to use when multiple ones are available due to multiple addresses on either end. But the WG does not plan to define a new mechanism for this, but rather document how to use existing mechanisms based upon preferences or policies. In particular, the WG will consider that a tunnel is alive as long as packets can be exchanged with the corresponding peer. In addition, local information, such as interface up/down events, or other failure detection mechanisms can be used to quickly detect failure of tunnel(s). Deliverables related to this include - A document explaining the motivations for a node using multiple interfaces and the scenarios where it may end up with multiple global addresses on its interfaces [Informational] - An analysis document explaining what are the limitations for mobile hosts using multiple simultaneous Care-of Addresses and Home Agent addresses using Mobile IPv6, whether issues are specific to Mobile IPv6 or not [Informational]. - A protocol extension to support the registration of multiple Care-of Addresses at a given Home Agent address [Standard Track]. - A "Flow/binding policies exchange" solution for an exchange of policies from the mobile host/router to the Home Agent and from the Home Agent to the mobile host/router influencing the choice of the Care-of Address and Home Agent address. The solution involves two specifications, one for the policy format and another for its transport [both Standard Track]. (A.4) Work on solutions to deal with firewalls and the problems that firewalls cause as identified in RFC 4487. (A.5) Route optimization of network mobility. Three use cases have been identified for this. These are called the Aviation case, the Automotive case, and the Personal Mobile Router (consumer electronics) case, though the actual technical problems are characterized by the type of movements and environments more than by the specific industry using the technology. The group will explore these cases to gather requirements and proceed with solving the open issues. (1) Airline and spacecraft community, who are deploying NEMO for control systems, as well as Internet connectivity and entertainment systems. This use case is characterized by fast (~ 1000 km/h) moving objects over large distances (across continents). The main technical problem is that tunneling-based solutions imply a roundtrip to another continent and that BGP based solutions imply significant churn in the global Internet routing table. (2) Automotive industry who are deploying NEMO for in-car communication, entertainment, and data gathering, possible control systems use, and communication to roadside devices. This use case is characterized by moderately fast (~ 100-300 km/h) moving objects that employ local or cellular networks for connectivity. (3) Personal Mobile Routers, which are consumer devices that allow the user to bring a NEMO network with the user while mobile, and communicate with peer NEMO Basic Support nodes and nodes served by them. After gathering the requirements for these types of deployments, the working group will evaluate what type of route optimization needs to be performed (if any), and formulate a solution to those problems. If no requirements for those scenarios can be collected by the deadline, it will be assumed that the work is premature, and that type of deployment will be dropped from the WG. The group will only consider airline and spacecraft solutions that combine tunneling solutions for small movements with either federated tunnel servers or slowly changing end host prefixes. The group will only consider personal mobile router requirements about optimized routes to another mobile router belonging to the same operator. The group will only consider automotive industry requirements to allow MR-attached hosts to directly access the network where MR has attached to. Work on automotive and personal mobile router solutions requires rechartering. The WG will not consider extensions to routing protocols. The group will not consider general multi-homing problems that are not related to the deployment and maintenance of Mobile IPv6 or NEMO Basic Support protocols. The group will also not consider general route optimization, or other problems that are not related to the deployment and maintenance of NEMO Basic Support protocols. Similarly, the group will not consider or rely on the results of general routing architecture, Internet architecture, or identifier-locator split issues that are discussed in separate, long term efforts elsewhere in the IETF. Finally, the group will not consider solutions that require changes from correspondent nodes in the general Internet (A.6) Bootstrapping mechanisms developed earlier in the MIP6 WG require AAA support for Mobile IPv6. Part of this work is already being done in the DIME WG, but the MEXT WG is chartered to complete a design for RADIUS. (A.7) Binding Revocation for IP Mobility: Define a binding revocation mechanism for Mobile IPv6 and its extensions. This mechanism can be used by any entity involved in the base Mobile IPv6 protocol or one of its extensions to request its corresponding entity to terminate either one, multiple or all binding cache entries. (A.8) Generic Notification Message for Mobile IPv6: A proposal for defining generic notification framework that can be used by the mobility entities for sending and receiving asynchronous notification messages was proposed and the same was adopted by the WG. (A.9) Extended DSMIPv6 Home Network Support: DSMIPv6 assumes the home network to be dual stack providing simultaneous IPv6 and IPv4 network access. It is proposed to extend DSMIPv6 to support home networks which provides IPv4, or IPv6 respectively, direct network access only, but where virtual IPv6 home network connectivity, or virtual IPv4 home network connectivity respectively, may be obtained by tunneling to the HA. The latter shall be obtained by DSMIPv6 operation using the v4HoA address as Care-of-address for the v6HoA address, and vice versa, the v6HoA address as care-of-address for the v4HoA address. Work items related to base specification maintenance include: (B.1) Create and maintain issue lists that are generated on the basis of implementation and interoperability experience. Address specific issues with specific updates or revisions of the base specification. One specific area of concern that should be analyzed and addressed relates to multilink subnets. This work item relates only to corrections and clarifications. The working group shall not revisit design decisions or change the protocol. (B.2) Update the IANA considerations of RFC 3775 to allow extensions for experimental purposes as well passing of optional vendor-specific information. (B.3) Finish working group documents that are currently in process, and submit for RFC. This includes prefix delegation protocol mechanism for network mobility, and a MIB for NEMO Basic Support. Work items related to informational documentation include: (C.1) Produce a design rationale that documents the historical thinking behind the introduction of an alternative security mechanism, the Authentication Protocol (RFC 4285). (C.2) Virtual Home Link configuration for Mobile IPv6: A proposal has been made on Mobile IPv6 home link configuration on virtual links. The proposal does not describe any new protocol, but provides the operational and configuration details and additionally provides implementation guidance for achieving this configuration. The group employs IPsec and IKE as a security mechanism. The group shall refrain, however, from making generic extensions to these protocols. Any proposed extension must be reviewed by the INT and SEC ADs before it can be accepted as a part of a work item. Description of Working Group: Mobile IPv6 specifies routing support which permits an IPv6 host to continue using its home address as it moves around the Internet, enabling continuity of sessions. Mobile IPv6 supports transparency above the IP layer, including maintenance of active transport level sessions. In addition, network mobility (NEMO) mechanisms built on top of Mobile IPv6 allow managing the mobility of an entire network, as it changes its point of attachment to the Internet. The base specifications consist of: o RFC 3775 (Mobile IPv6) o RFC 3963 (NEMO) o RFC 4877 (Mobile IPv6 Operation with IKEv2) The MEXT Working Group continues the work of the former MIP6, NEMO, and MONAMI6 Working Groups. The primary goal of MEXT will be to (A) enhance base IPv6 mobility by continuing work on developments that are required for wide-scale deployments and specific deployment scenarios. Additionally, (B) the working group will ensure that any issues identified by implementation and interoperability experience are addressed, and that the base specifications are maintained. (C) The group will also produce informational documentation, such as design rationale documents or description of specific issues within the protocol. Deployment considerations call for (A.1) solutions to enable dual-stack operation, (A.2) mechanisms to support high-availability home agents, (A.3) allowing the use of multiple interfaces in mobile nodes, (A.4) ways to employ Mobile IPv6 in the presence of firewalls, (A.5) address the specific needs of automotive and aviation communities for route optimisation in network mobility, (A.6) support for AAA is needed as a continuation of earlier work on bootstrapping, (A.7) revocation of binding, (A.8) generic notification message format and (A.9) extended DMSIP home network support . Work items related to large scale deployment include: (A.1) A Solution for Mobile IPv6 and NEMO session continuity for dual stack hosts which attach to IPv4 access networks. Additionally provide a mechanism for carrying IPv4 packets via the Home agent for Mobile IPv6 or NEMO capable dual-stack hosts. (A.2) A protocol based solution for enhancing the reliability of home agents and a method to force a host/router to switch home agents. A mechanism to force an MN to switch the HA that is currently serving it. This is required in deployments where the HA needs to be taken offline for maintenance. (A.3) Use of multiple interfaces. Today, the protocols do not provide suppport for simultaneous differentiated use of multiple access technologies. Several proposals exist for such support, and some of them have been implemented and tested. When a mobile host/router uses multiple network interfaces simultaneously, or when multiple prefixes are available on a single network interface, the mobile host/router would end up with multiple Care-of Addresses (CoAs). In addition, the Home Agent might be attached to multiple network interfaces, or to a single network interface with multiple prefixes, hence resulting in the option to use multiple IP addresses for the Home Agent. This could result in the possibility of using a multitude of bi-directional tunnels between pairs of {Home Agent address, CoA} and a number of associated issues: establishment, selection and modification of multiple simultaneous tunnels. The objective of the WG is to produce a clear problem statement and to produce standard track specifications to the problems associated with the simultaneous use of multiple addresses for either mobile hosts using Mobile IPv6 or mobile routers using NEMO Basic Support and their variants (FMIPv6, HMIPv6, etc). Where the effects of having multiple prefixes on a single interface is identical to the effects of having multiple interfaces each with a single prefix, the WG will consider a generalized approach to cater for multiple prefixes available to a mobile host/router. The WG uses existing tunneling mechanisms defined for Mobile IPv6. The involved nodes need to select which tunnel instance to use when multiple ones are available due to multiple addresses on either end. But the WG does not plan to define a new mechanism for this, but rather document how to use existing mechanisms based upon preferences or policies. In particular, the WG will consider that a tunnel is alive as long as packets can be exchanged with the corresponding peer. In addition, local information, such as interface up/down events, or other failure detection mechanisms can be used to quickly detect failure of tunnel(s). Deliverables related to this include - A document explaining the motivations for a node using multiple interfaces and the scenarios where it may end up with multiple global addresses on its interfaces [Informational] - An analysis document explaining what are the limitations for mobile hosts using multiple simultaneous Care-of Addresses and Home Agent addresses using Mobile IPv6, whether issues are specific to Mobile IPv6 or not [Informational]. - A protocol extension to support the registration of multiple Care-of Addresses at a given Home Agent address [Standard Track]. - A "Flow/binding policies exchange" solution for an exchange of policies from the mobile host/router to the Home Agent and from the Home Agent to the mobile host/router influencing the choice of the Care-of Address and Home Agent address. The solution involves two specifications, one for the policy format and another for its transport [both Standard Track]. (A.4) Work on solutions to deal with firewalls and the problems that firewalls cause as identified in RFC 4487. (A.5) Route optimization of network mobility. Three use cases have been identified for this. These are called the Aviation case, the Automotive case, and the Personal Mobile Router (consumer electronics) case, though the actual technical problems are characterized by the type of movements and environments more than by the specific industry using the technology. The group will explore these cases to gather requirements and proceed with solving the open issues. (1) Airline and spacecraft community, who are deploying NEMO for control systems, as well as Internet connectivity and entertainment systems. This use case is characterized by fast (~ 1000 km/h) moving objects over large distances (across continents). The main technical problem is that tunneling-based solutions imply a roundtrip to another continent and that BGP based solutions imply significant churn in the global Internet routing table. (2) Automotive industry who are deploying NEMO for in-car communication, entertainment, and data gathering, possible control systems use, and communication to roadside devices. This use case is characterized by moderately fast (~ 100-300 km/h) moving objects that employ local or cellular networks for connectivity. (3) Personal Mobile Routers, which are consumer devices that allow the user to bring a NEMO network with the user while mobile, and communicate with peer NEMO Basic Support nodes and nodes served by them. After gathering the requirements for these types of deployments, the working group will evaluate what type of route optimization needs to be performed (if any), and formulate a solution to those problems. If no requirements for those scenarios can be collected by the deadline, it will be assumed that the work is premature, and that type of deployment will be dropped from the WG. The group will only consider airline and spacecraft solutions that combine tunneling solutions for small movements with either federated tunnel servers or slowly changing end host prefixes. The group will only consider personal mobile router requirements about optimized routes to another mobile router belonging to the same operator. The group will only consider automotive industry requirements to allow MR-attached hosts to directly access the network where MR has attached to. Work on automotive and personal mobile router solutions requires rechartering. The WG will not consider extensions to routing protocols. The group will not consider general multi-homing problems that are not related to the deployment and maintenance of Mobile IPv6 or NEMO Basic Support protocols. The group will also not consider general route optimization, or other problems that are not related to the deployment and maintenance of NEMO Basic Support protocols. Similarly, the group will not consider or rely on the results of general routing architecture, Internet architecture, or identifier-locator split issues that are discussed in separate, long term efforts elsewhere in the IETF. Finally, the group will not consider solutions that require changes from correspondent nodes in the general Internet (A.6) Bootstrapping mechanisms developed earlier in the MIP6 WG require AAA support for Mobile IPv6. Part of this work is already being done in the DIME WG, but the MEXT WG is chartered to complete a design for RADIUS. (A.7) Binding Revocation for IP Mobility: Define a binding revocation mechanism for Mobile IPv6 and its extensions. This mechanism can be used by any entity involved in the base Mobile IPv6 protocol or one of its extensions to request its corresponding entity to terminate either one, multiple or all binding cache entries. (A.8) Generic Notification Message for Mobile IPv6: A proposal for defining generic notification framework that can be used by the mobility entities for sending and receiving asynchronous notification messages was proposed and the same was adopted by the WG. (A.9) Extended DSMIPv6 Home Network Support: DSMIPv6 assumes the home network to be dual stack providing simultaneous IPv6 and IPv4 network access. It is proposed to extend DSMIPv6 to support home networks which provides IPv4, or IPv6 respectively, direct network access only, but where virtual IPv6 home network connectivity, or virtual IPv4 home network connectivity respectively, may be obtained by tunneling to the HA. The latter shall be obtained by DSMIPv6 operation using the v4HoA address as Care-of-address for the v6HoA address, and vice versa, the v6HoA address as care-of-address for the v4HoA address. Work items related to base specification maintenance include: (B.1) Create and maintain issue lists that are generated on the basis of implementation and interoperability experience. Address specific issues with specific updates or revisions of the base specification. One specific area of concern that should be analyzed and addressed relates to multilink subnets. This work item relates only to corrections and clarifications. The working group shall not revisit design decisions or change the protocol. (B.2) Update the IANA considerations of RFC 3775 to allow extensions for experimental purposes as well passing of optional vendor-specific information. (B.3) Finish working group documents that are currently in process, and submit for RFC. This includes prefix delegation protocol mechanism for network mobility, and a MIB for NEMO Basic Support. Work items related to informational documentation include: (C.1) Produce a design rationale that documents the historical thinking behind the introduction of an alternative security mechanism, the Authentication Protocol (RFC 4285). (C.2) Virtual Home Link configuration for Mobile IPv6: A proposal has been made on Mobile IPv6 home link configuration on virtual links. The proposal does not describe any new protocol, but provides the operational and configuration details and additionally provides implementation guidance for achieving this configuration. The group employs IPsec and IKE as a security mechanism. The group shall refrain, however, from making generic extensions to these protocols. Any proposed extension must be reviewed by the INT and SEC ADs before it can be accepted as a part of a work item. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jun 2006 May 2009 Multiple Care-of Addresses Registration Dec 2007 Jan 2009 NEMO Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks Dec 2007 May 2008 AAA Goals for Mobile IPv6 Feb 2008 Jan 2009 Automotive Industry Requirements for NEMO Route Optimization May 2008 Apr 2009 Flow Bindings in Mobile IPv6 and Nemo Basic Support Jun 2008 Mar 2009 Mobility Support in IPv6 Jun 2008 Mar 2009 DHCPv6 Prefix Delegation for NEMO Jul 2008 Jun 2009 Binding Revocation for IPv6 Mobility Oct 2008 May 2009 Guidelines for firewall administrators regarding MIPv6 traffic Oct 2008 May 2009 Guidelines for firewall vendors regarding MIPv6 traffic Mobility for IP: Performance, Signaling and Handoff Optimization (mipshop) -------------------------------------------------------------------------- Charter Last Modified: 2009-05-22 Current Status: Active Working Group Chair(s): Stefano Faccin Vijay Devarapalli Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:mipshop@ietf.org To Subscribe: mipshop-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/mipshop/index.html Description of Working Group: Mobile IPv6 enables IPv6 mobile nodes to continue a session using a given "home address" in spite of changes in its point of attachment to the network. These changes may cause delay, packet loss, and also represent signaling overhead traffic on the network. The MIPSHOP WG has so far worked on two technologies to address these issues. Hierarchical Mobile IPv6 (HMIPv6) reduces the amount and latency of signaling between a MN, its Home Agent and one or more correspondent nodes. Mobile IPv6 Fast Handovers (FMIPv6) reduces packet loss by providing fast IP connectivity as soon as the mobile node establishes a new point of attachment at a new link. The MIPSHOP WG will continue to work on HMIPv6 and FMIPv6, and the necessary extensions to improve these protocols. The MIPSHOP WG will also identify missing components that are required for deploying these protocols and standardize the necessary extensions. The WG will also address using these protocols to provide fast handovers for network-based mobility management protocols like Proxy Mobile IPv6. The IEEE 802.21 Media Independent Handover (MIH) working group aims at providing services to assist with handoffs between heterogeneous link-layer technologies, and across IP subnet boundaries. MIH services can be delivered through link-layer specific solutions and/or through a "layer 3 or above" protocol. MIPSHOP will define the delivery of information for MIH services for this latter case. A L3 based mechanism to identify a valid information server is also required. The MIPSHOP will work on developing a protocol for transport of MIH services information and mechanisms for discovering the MIH server. Security for the transport of MIH information will also be addressed. The MOBOPTS Research Group in the IRTF is chartered to work on optimizations related to Mobile IPv6 and IP handoffs among other things. The MIPSHOP WG will take mature proposals from the MOBOPTS group and standardize them in the IETF on a case-by-case basis. The MIPSHOP WG will also consider and standardize optimizations for the Mobile IPv6 protocol and IP mobility in general. Scope of MIPSHOP: The working group will work on: 1. FMIPv6 Mobile Node - Access Router security using the AAA infrastructure Currently MIPSHOP has produced a standards track protocol for setting up security between the mobile node and access router for security FMIPv6 signaling messages. However, the protocol depends on SeND (Secure Neighbor Discovery) to be available on the mobile node and the access router. An alternate mechanism that leverages the AAA infrastructure would be useful. Many target systems where FMIPv6 is likely to be used use a AAA infrastructure to authenticate and authorize network access. The working group will work on a Informational document describing how the AAA infrastructure could be used for setting up security associations between the mobile node and the access router. 2. Prefix Management for point-to-point links with FMIPv6 Using FMIPv6 over point-to-points like requires some additional considerations with respect to managing and allocating prefixes for the mobile node on these point-to-point links. Therefore the WG will work on an Informational document to address the issues. 3. Handover optimizations when Proxy Mobile IPv6 is used for handovers Proxy Mobile IPv6 (PMIPv6) is a network-based mobility management protocol where a node in the access network, called the Mobile Access Gateway (MAG) handles mobility on behalf of the mobile node. It has been proposed to use FMIPv6 to optimize the handover in terms of reducing the packet loss and transferring relevant context from the old MAG to the new MAG. The working group will also work on other optimizations like the use of a transient binding cache entry for improving a PMIPv6-based handover. 4. Work on protocols and extensions for transporting information related to IEEE 802.21: The work includes the layer 3 protocol for transporting MIH related information and DHCP and DNS extensions for discovering the information servers. Description of Working Group: Mobile IPv6 enables IPv6 mobile nodes to continue a session using a given "home address" in spite of changes in its point of attachment to the network. These changes may cause delay, packet loss, and also represent signaling overhead traffic on the network. The MIPSHOP WG has so far worked on two technologies to address these issues. Hierarchical Mobile IPv6 (HMIPv6) reduces the amount and latency of signaling between a MN, its Home Agent and one or more correspondent nodes. Mobile IPv6 Fast Handovers (FMIPv6) reduces packet loss by providing fast IP connectivity as soon as the mobile node establishes a new point of attachment at a new link. The MIPSHOP WG will continue to work on HMIPv6 and FMIPv6, and the necessary extensions to improve these protocols. The MIPSHOP WG will also identify missing components that are required for deploying these protocols and standardize the necessary extensions. The WG will also address using these protocols to provide fast handovers for network-based mobility management protocols like Proxy Mobile IPv6. The IEEE 802.21 Media Independent Handover (MIH) working group aims at providing services to assist with handoffs between heterogeneous link-layer technologies, and across IP subnet boundaries. MIH services can be delivered through link-layer specific solutions and/or through a "layer 3 or above" protocol. MIPSHOP will define the delivery of information for MIH services for this latter case. A L3 based mechanism to identify a valid information server is also required. The MIPSHOP will work on developing a protocol for transport of MIH services information and mechanisms for discovering the MIH server. Security for the transport of MIH information will also be addressed. The MOBOPTS Research Group in the IRTF is chartered to work on optimizations related to Mobile IPv6 and IP handoffs among other things. The MIPSHOP WG will take mature proposals from the MOBOPTS group and standardize them in the IETF on a case-by-case basis. The MIPSHOP WG will also consider and standardize optimizations for the Mobile IPv6 protocol and IP mobility in general. Scope of MIPSHOP: The working group will work on: 1. FMIPv6 Mobile Node - Access Router security using the AAA infrastructure Currently MIPSHOP has produced a standards track protocol for setting up security between the mobile node and access router for security FMIPv6 signaling messages. However, the protocol depends on SeND (Secure Neighbor Discovery) to be available on the mobile node and the access router. An alternate mechanism that leverages the AAA infrastructure would be useful. Many target systems where FMIPv6 is likely to be used use a AAA infrastructure to authenticate and authorize network access. The working group will work on a Informational document describing how the AAA infrastructure could be used for setting up security associations between the mobile node and the access router. 2. Prefix Management for point-to-point links with FMIPv6 Using FMIPv6 over point-to-points like requires some additional considerations with respect to managing and allocating prefixes for the mobile node on these point-to-point links. Therefore the WG will work on an Informational document to address the issues. 3. Handover optimizations when Proxy Mobile IPv6 is used for handovers Proxy Mobile IPv6 (PMIPv6) is a network-based mobility management protocol where a node in the access network, called the Mobile Access Gateway (MAG) handles mobility on behalf of the mobile node. It has been proposed to use FMIPv6 to optimize the handover in terms of reducing the packet loss and transferring relevant context from the old MAG to the new MAG. The working group will also work on other optimizations like the use of a transient binding cache entry for improving a PMIPv6-based handover. 4. Work on protocols and extensions for transporting information related to IEEE 802.21: The work includes the layer 3 protocol for transporting MIH related information and DHCP and DNS extensions for discovering the information servers. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Dec 2007 Jan 2009 IEEE 802.21 Mobility Services Framework Design (MSFD) Apr 2008 May 2009 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery Apr 2008 Jun 2009 Locating IEEE 802.21 Mobility Servers using DNS Oct 2008 Jun 2009 Fast Handovers for Proxy Mobile IPv6 Oct 2008 Jun 2009 Transient Binding for Proxy Mobile IPv6 Feb 2009 Mar 2009 Mobile IPv6 Fast Handovers Mobility for IPv4 (mip4) ------------------------ Charter Last Modified: 2008-09-18 Current Status: Active Working Group Chair(s): Henrik Levkowetz Pete McCann Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:mip4@ietf.org To Subscribe: mip4-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/mip4/index.html Description of Working Group: IP mobility support for IPv4 nodes (hosts and routers) is specified in RFC3344. RFC 3344 mobility allows a node to continue using its "permanent" home address as it moves around the Internet. The Mobile IP protocols support transparency above the IP layer, including maintenance of active TCP connections and UDP port bindings. Besides the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal with concerns such as optimization, security, extensions, AAA support, and deployment issues. MIPv4 is currently being deployed on a wide basis (e.g., in cdma2000 networks). The scope of the deployment is on a fairly large scale and accordingly, the MIP4 WG will focus on deployment issues and on addressing known deficiencies and shortcomings in the protocol that have come up as a result of deployment experience. Specifically, the working group will complete the work items to facilitate interactions with AAA environments, interactions with enterprise environments when MIPv4 is used therein, and updating existing protocol specifications in accordance with deployment needs and advancing those protocols that are on the standards track. Work expected to be done by the MIP4 WG as proposed by this charter is as follows: 1. MIPv4 has been a proposed standard for several years. It has been adopted by other standard development organizations and has been deployed commercially. One of the next steps for the WG is to advance the protocol to draft standard status. As part of advancing base Mobile IP specs to DS, the MIPv4 NAI RFC (2794) will be revised to reflect implementation experience. 2. Work items that are pending from the previous Mobile IP WG, which will be completed by the MIP4 WG, are: - completion of the MIB for the revised base Mobile IP specification (2006bis) - regional registration draft. 3. The MIP4 WG will also complete the work on MIPv4 interactions in VPN scenarios. This work will involve identifying the requirements and a solution development for MIPv4 operation in the presence of IPsec VPNs. 4. Additionally, a proposal has been made for how MOBIKE could work together with MIPv4. This proposal does not describe any new protocol, but formulates a best current practice for deploying MOBIKE together with MIPv4. The working group will adopt and complete this document. 5. Some issues have been raised with respect to RFC3519. These will be identified and addressed as appropriate, through errata, revision of RFC 3519, and/or supplemental documents as needed. 6. It has been proposed that the FMIP protocol, which has been standardised for MIPv6 in the MIPSHOP working group, should also be published as an experimental protocol for MIPv4. A draft for this exists. The working group will take up and carry this work forward to publication 7. An extension to carry generic strings in the Registration Reply message has been proposed. The purpose is to supply supplemental human-readable information intended to the MN user. The working group will complete the specification and applicability statement of such an extension. 8. RADIUS attributes for MIP4. A set of RADIUS attributes has been proposed for MIPv4. The working group will first produce a requirements specification, describing how the work differs from the requirements in RFC 2977 and the functionality provided by RFC 4004 (the MIPv4 Diameter App). The reason why this first step is required is that RFC 3127 shows that full RFC 2977 functionality can't be provided by even a considerably extended RADIUS, so we need to match the requirements to what can be done within RADIUS. Provided the requirements work finds approval with ADs and RADEXT WG, the workgroup 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. 9. MIPv4 Extension for Configuration Options. Several drafts have proposed extensions to help improve configuration of MIPv4 clients. The latest proposal is for a general configuration option extension which could carry information such as e.g., DNS address and DHCP server address. The working group will take on and complete one proposal for a configuration option extension. 10. Dual-stack Support There have been several proposals for how to enable an IPv6 connection over a network that supports Mobile IPv4. A protocol enhancement to MIPv4 would allow for IPv6 support in a region where Mobile IPv4 has already been implemented and deployed. This would allow a dual stack mobile node to maintain IPv6 connectivity when using MIPv4. The solution would therefore be applicable only to networks that are not deploying Mobile IPv6. The working group will take on and complete one proposal for IPv6 over Mobile IPv4. This work is restricted to a small protocol extension similar to current Mobile IPv4 functionality. Support for advanced Mobile IPv6 functionality is strictly outside the scope. A problem statement covering both Mobile IPv4 and IPv6 dual-stack issues is expected to come out of MIP6 WG, and will not be developed in MIP4 WG. 11. MIPv4 Moving Network Support The Network Mobility (nemo) working group deals with the problem of mobility of a whole network, such as might exist inside a vehicle, train, or airplane. The nemo working group has developed draft specifications for both IPv6 and IPv4 mobile networks. However, it has been recognized that the IPv4 version of the protocol can be viewed as an extension of the basic Mobile IPv4 protocol, and there is good reason to do this extension in the mip4 working group. The working group will take on the MIPv4 network mobility internet draft and progress it along the standards track. In addition, the working group will take up extensions to the basic MIPv4 moving network support in the areas of dynamic prefix assignment and foreign agent support. 12. Asynchronous Notification Mechanism In some situations, there is a need for Mobile IPv4 entities, such as the home agent, foreign agent and mobile node to send and receive asynchronous notification events related to the operation of the MIPv4 protocol. A couple of examples of such events are registration revocation from a home agent to a foreign agent in order to terminate the service (to release resources and end charging), and notification of pending HA shutdown and indication of alternative serving HA, from a HA to the mobile node. The base Mobile IP Specification [RFC3344] does not have a provision for this. A new MIPv4 message pair which would support asynchronous notifications, and a notification model describing how to use these messages has been proposed. The working group will take on the existing MIPv4 notification message draft as a starting point, review and update it as needed, and progress it as a standards track document. In addition, the working group will also consider defining specific usages of the notification message based on the examples in the current document. 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 specs to DS, the MIPv4 NAI RFC (2794) will be revised to reflect implementation experience. 2. Work items that are pending from the previous Mobile IP WG, which will be completed by the MIP4 WG, are: - completion of the MIB for the revised base Mobile IP specification (2006bis) - regional registration draft. 3. The MIP4 WG will also complete the work on MIPv4 interactions in VPN scenarios. This work will involve identifying the requirements and a solution development for MIPv4 operation in the presence of IPsec VPNs. 4. Additionally, a proposal has been made for how MOBIKE could work together with MIPv4. This proposal does not describe any new protocol, but formulates a best current practice for deploying MOBIKE together with MIPv4. The working group will adopt and complete this document. 5. Some issues have been raised with respect to RFC3519. These will be identified and addressed as appropriate, through errata, revision of RFC 3519, and/or supplemental documents as needed. 6. It has been proposed that the FMIP protocol, which has been standardised for MIPv6 in the MIPSHOP working group, should also be published as an experimental protocol for MIPv4. A draft for this exists. The working group will take up and carry this work forward to publication 7. An extension to carry generic strings in the Registration Reply message has been proposed. The purpose is to supply supplemental human-readable information intended to the MN user. The working group will complete the specification and applicability statement of such an extension. 8. RADIUS attributes for MIP4. A set of RADIUS attributes has been proposed for MIPv4. The working group will first produce a requirements specification, describing how the work differs from the requirements in RFC 2977 and the functionality provided by RFC 4004 (the MIPv4 Diameter App). The reason why this first step is required is that RFC 3127 shows that full RFC 2977 functionality can't be provided by even a considerably extended RADIUS, so we need to match the requirements to what can be done within RADIUS. Provided the requirements work finds approval with ADs and RADEXT WG, the workgroup 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. 9. MIPv4 Extension for Configuration Options. Several drafts have proposed extensions to help improve configuration of MIPv4 clients. The latest proposal is for a general configuration option extension which could carry information such as e.g., DNS address and DHCP server address. The working group will take on and complete one proposal for a configuration option extension. 10. Dual-stack Support There have been several proposals for how to enable an IPv6 connection over a network that supports Mobile IPv4. A protocol enhancement to MIPv4 would allow for IPv6 support in a region where Mobile IPv4 has already been implemented and deployed. This would allow a dual stack mobile node to maintain IPv6 connectivity when using MIPv4. The solution would therefore be applicable only to networks that are not deploying Mobile IPv6. The working group will take on and complete one proposal for IPv6 over Mobile IPv4. This work is restricted to a small protocol extension similar to current Mobile IPv4 functionality. Support for advanced Mobile IPv6 functionality is strictly outside the scope. A problem statement covering both Mobile IPv4 and IPv6 dual-stack issues is expected to come out of MIP6 WG, and will not be developed in MIP4 WG. 11. MIPv4 Moving Network Support The Network Mobility (nemo) working group deals with the problem of mobility of a whole network, such as might exist inside a vehicle, train, or airplane. The nemo working group has developed draft specifications for both IPv6 and IPv4 mobile networks. However, it has been recognized that the IPv4 version of the protocol can be viewed as an extension of the basic Mobile IPv4 protocol, and there is good reason to do this extension in the mip4 working group. The working group will take on the MIPv4 network mobility internet draft and progress it along the standards track. In addition, the working group will take up extensions to the basic MIPv4 moving network support in the areas of dynamic prefix assignment and foreign agent support. 12. Asynchronous Notification Mechanism In some situations, there is a need for Mobile IPv4 entities, such as the home agent, foreign agent and mobile node to send and receive asynchronous notification events related to the operation of the MIPv4 protocol. A couple of examples of such events are registration revocation from a home agent to a foreign agent in order to terminate the service (to release resources and end charging), and notification of pending HA shutdown and indication of alternative serving HA, from a HA to the mobile node. The base Mobile IP Specification [RFC3344] does not have a provision for this. A new MIPv4 message pair which would support asynchronous notifications, and a notification model describing how to use these messages has been proposed. The working group will take on the existing MIPv4 notification message draft as a starting point, review and update it as needed, and progress it as a standards track document. In addition, the working group will also consider defining specific usages of the notification message based on the examples in the current document. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Sep 2003 Apr 2009 The Definitions of Managed Objects for IP Mobility Support using SMIv2, revised Mar 2007 Mar 2009 Generic Notification Message for Mobile IPv4 Jun 2007 Feb 2009 The Definitions of Managed Objects for Mobile IP UDP Tunneling Multiple Interfaces (mif) ------------------------- Charter Last Modified: 2009-04-27 Current Status: Active Working Group Chair(s): Margaret Wasserman Hui Deng Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:mif@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/mif Archive: http://www.ietf.org/mail-archive/web/mif Description of Working Group: Many hosts have the ability to attach to multiple networks simultaneously. This can happen over multiple physical network interfaces, a combination of physical and virtual interfaces (VPNs or tunnels), or even indirectly through multiple default routers being on the same link. For instance, current laptops and smartphones typically have multiple access network interfaces. A host attached to multiple networks has to make decisions about default router selection, address selection, DNS server selection, choice of interface for packet transmission, and the treatment of configuration information received from the various networks. Some configuration objects are global to the node, some are local to the interface, and some are related to a particular prefix. Various issues arise when contradictory configuration objects that are global to the node are received on different interfaces. At best, decisions about these matters have an efficiency effect. At worst, they have more significant effects such as security impacts, or even lead to communication not being possible at all. A number of operating systems have implemented various techniques to deal with attachments to multiple networks. Some devices employ only one interface at a time and some allow per-host configuration of preferences between the interfaces but still use just one at a time. Other systems allow per-application preferences or implement sophisticated policy managers that can be configured by users or controlled externally. The purpose of the MIF working group is to describe the issues of attaching to multiple networks on hosts and document existing practice. The group shall also analyze the impacts and effectiveness of these existing mechanisms. The WG shall employ and refer to existing IETF work in this area, including, for instance, strong/weak models (RFC 1122), address selection (RFC 3484), ICE and other mechanisms higher layers can use for address selection, DHCP mechanisms, Router Advertisement mechanisms, and DNS recommendations. The focus of the working group should be on documenting the system level effects to host IP stacks and identification of gaps between the existing IETF recommendations and existing practice. The working group shall address both IPv4 and IPv6 as well as stateless and stateful configuration. Network discovery and selection on lower layers as defined by RFC 5113 is out of scope. Also, the group shall not develop new protocol or policy mechanisms; recommendations and gap analysis from the group are solely based on existing solutions. The group shall not assume any software beyond basic IP protocol support on its peers or in network nodes. No work will be done to enable traffic flows to move from one interface to another. The group recognizes existing work on mechanisms that require peer or network support for moving traffic flows such as RFC 5206, RFC 4980 and the use of multiple care-of addresses in Mobile IPv6. This group does not work on or impact such mechanisms. Once the group has completed its work items, the IETF can make an informed decision about rechartering the working group to define new mechanisms or asking other, specialized working groups (such as DHC or 6MAN) to deal with specific issues. Description of Working Group: Many hosts have the ability to attach to multiple networks simultaneously. This can happen over multiple physical network interfaces, a combination of physical and virtual interfaces (VPNs or tunnels), or even indirectly through multiple default routers being on the same link. For instance, current laptops and smartphones typically have multiple access network interfaces. A host attached to multiple networks has to make decisions about default router selection, address selection, DNS server selection, choice of interface for packet transmission, and the treatment of configuration information received from the various networks. Some configuration objects are global to the node, some are local to the interface, and some are related to a particular prefix. Various issues arise when contradictory configuration objects that are global to the node are received on different interfaces. At best, decisions about these matters have an efficiency effect. At worst, they have more significant effects such as security impacts, or even lead to communication not being possible at all. A number of operating systems have implemented various techniques to deal with attachments to multiple networks. Some devices employ only one interface at a time and some allow per-host configuration of preferences between the interfaces but still use just one at a time. Other systems allow per-application preferences or implement sophisticated policy managers that can be configured by users or controlled externally. The purpose of the MIF working group is to describe the issues of attaching to multiple networks on hosts and document existing practice. The group shall also analyze the impacts and effectiveness of these existing mechanisms. The WG shall employ and refer to existing IETF work in this area, including, for instance, strong/weak models (RFC 1122), address selection (RFC 3484), ICE and other mechanisms higher layers can use for address selection, DHCP mechanisms, Router Advertisement mechanisms, and DNS recommendations. The focus of the working group should be on documenting the system level effects to host IP stacks and identification of gaps between the existing IETF recommendations and existing practice. The working group shall address both IPv4 and IPv6 as well as stateless and stateful configuration. Network discovery and selection on lower layers as defined by RFC 5113 is out of scope. Also, the group shall not develop new protocol or policy mechanisms; recommendations and gap analysis from the group are solely based on existing solutions. The group shall not assume any software beyond basic IP protocol support on its peers or in network nodes. No work will be done to enable traffic flows to move from one interface to another. The group recognizes existing work on mechanisms that require peer or network support for moving traffic flows such as RFC 5206, RFC 4980 and the use of multiple care-of addresses in Mobile IPv6. This group does not work on or impact such mechanisms. Once the group has completed its work items, the IETF can make an informed decision about rechartering the working group to define new mechanisms or asking other, specialized working groups (such as DHC or 6MAN) to deal with specific issues. Internet-Drafts: No Current Internet-Drafts. Network Time Protocol (ntp) --------------------------- Charter Last Modified: 2009-04-13 Current Status: Active Working Group Chair(s): Brian Haberman Karen O'Donoghue Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion:ntpwg@lists.ntp.isc.org To Subscribe: https://lists.ntp.isc.org/mailman/listinfo/ntpwg Archive: http://lists.ntp.isc.org/pipermail/ntpwg Description of Working Group: The Network Time Protocol (NTP) is widely deployed and used in the Internet. However, the standardization status of this protocol has lagged in the IETF. RFC 1305 (NTP version 3) was published in March 1992 and remains unchanged and at Draft Standard status. RFC 1305 represents the majority of full NTP implementations deployed today. RFC 2030 (SNTP version 4) was published as an Informational RFC in October 1996 as a lightweight version of NTP for deployments not requiring the full functionality of NTP. SNTP now represents the majority of both NTP traffic and NTP implementation issues on the Internet. A good deal of work has been produced in the NTP community updating both NTPv3 and SNTPv4. This work is ongoing and available through the collaborative development effort in the NTP community, but it has not been reflected back into the NTP specifications. The goal of this working group is to document NTPv4 based on the extensive work of the NTP community and to advance the standardization status of NTP. It is an explicit goal of this effort to have NTPv4 interoperate with the deployed base avoiding any backwards-incompatible changes. A number of topics have been raised as potential work items for an update to NTP including support for IPv6, security considerations including authentication, automatic configuration including possible requirements for DHCP, and algorithm improvements. This working group will focus first on delivering NTPv4 and will defer additional development efforts until after the delivery of NTPv4. Support for IPv6 and defining mechanisms for securing NTP transactions is considered part of the core NTPv4 functionality. Potential further modifications and additions to the NTP protocol will be documented for possible further work beyond the initial NTPv4 effort. The working group will initially focus on the following deliverables: 1. NTPv4 Scope and Requirements Document (documenting the scope of the NTPv4 update and identifying issues deferred for future work). 2. NTPv4 Protocol Specification (documenting the protocol on the wire) 3. NTPv4 Architecture and Algorithms Specification (documenting the architecture, mathematical algorithms, and behavior of NTP servers and clients) 4. NTPv4 MIB (provision for management and monitoring of NTP via SNMP) 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) Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jul 2005 Sep 2008 Network Time Protocol Version 4 Protocol And Algorithms Specification Jun 2006 Aug 2008 Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4) Sep 2007 May 2009 Network Time Protocol Version 4 Autokey Specification May 2008 Mar 2009 Network Time Protocol (NTP) Server Option for DHCPv6 Network-based Localized Mobility Management (netlmm) ---------------------------------------------------- Charter Last Modified: 2008-12-16 Current Status: Active Working Group Chair(s): Vidya Narayanan Jonne Soininen Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:netlmm@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/netlmm In Body: to subscribe Archive: http://www.ietf.org/mail-archive/web/netlmm Description of Working Group: The IETF has defined both local and global mobility management protocols that are intended to handle IP mobility for nodes. All IP mobility management protocols defined thus far require the involvement of the mobile node in order to accomplish mobility. This working group is tasked with defining a network-based local mobility management protocol, where local IP mobility is handled without involvement from the mobile node. The idea is that the mobile node may move across multiple access routers without encountering a change in its IP address, thereby hiding the mobility from the IP layer and above. As part of the first phase of efforts in this working group, a protocol for such network-based local mobility has been developed. This protocol, Proxy Mobile IPv6 (PMIPv6), has been developed based on Mobile IPv6, after considering other alternative approaches. With this protocol, unmodified IP nodes may change access routers without having to change the IP address on an interface, within a given administrative domain. This is accomplished by having Mobile Access Gateways (MAGs), often part of the access routers in a network, send binding updates on behalf of mobile nodes attached to them, to a Local Mobility Anchor (LMA). The LMA manages the mobility of the mobile nodes across the MAGs within a given PMIPv6 domain. The PMIPv6 protocol is being adopted as part of several wide-area wireless network (e.g., 3GPP, 3GPP2, WiMAX) and local area network environments. The current charter of this working group involves specification of some necessary features that make the deployment of this protocol feasible in these various environments. As part of this effort, it is essential to support mobility for IPv4 end nodes. Some means of dealing with overlapping private IPv4 addresses of mobile nodes and supporting separation of flows between the MAG and LMA is also required. Further, given that local and global mobility management protocols are likely to be deployed in some combination in various environments, it is necessary to clearly define the interactions between PMIPv6 and MIPv6. Interactions with AAA protocols such as RADIUS and Diameter may be required for authorization or provisioning purposes. When multiple LMAs are present, an automated LMA discovery mechanism may be needed to facilitate deployment. The above items are in scope of the current charter. The MAG and LMA are considered to be IPv6 capable for all efforts of this protocol. Also, all features defined must work with unmodified IP nodes. Specifying any changes to mobile nodes is out of scope of the current charter. Handoff and route optimizations are also out of scope. There is, however, considerable interest in optimization work, for instance, and a future recharter of this working group is likely to address this in some manner. NETLMM WG Deliverables ---------------------- 1) Interface between a PMIPv6 MAG and MN: This interface will define the interaction between a regular IP node and a MAG that will be used to trigger various mobility management actions on the MAG. This is necessary for the MAG to properly trigger binding updates to the LMA and create appropriate mobility management state. 2) IPv4 Support for PMIPv6: This will define the support for IPv4 nodes in PMIPv6. This will also define the protocol operation over an IPv4 transport between the MAG and LMA, by employing protocol extensions already developed in the MEXT WG. 3) Interactions between Mobile IPv6 and Proxy Mobile IPv6: This will highlight the interactions required between these protocols in various methods of co-existence of these in a system, with a view to documenting the best practices to be used. The scenarios considered will include a hierarchical model of local and global mobility management using PMIPv6 and MIPv6 respectively, a mixed mode of the two with some nodes supporting MIPv6 and others not, and the use of MIPv6 upon movement of nodes outside a PMIPv6 domain. 4) GRE Keying option for PMIPv6: This will define a mechanism using GRE keys to support separation of flows between a MAG and LMA. 5) RADIUS support for PMIPv6: This will define the interactions between RADIUS and PMIPv6 to support policy provisioning and authorization. 6) Automatic LMA discovery: This will define the ability for MAGs to automatically discover and use an LMA within a PMIPv6 domain. The scope of this effort may include specifying the use of DNS or DHCP based LMA discovery or LMA discovery using policy information retrieved via AAA protocols. 7) MIB for PMIPv6: This will define the MIB for the protocol for interoperability purposes. 8) PMIPv6 path management and failure detection: This will define an extension to the PMIPv6 protocol allowing PMIPv6 peers to verify bidirectional reachability with their peer, detect failure of their peer, and signal their own failure to their peer. Description of Working Group: The IETF has defined both local and global mobility management protocols that are intended to handle IP mobility for nodes. All IP mobility management protocols defined thus far require the involvement of the mobile node in order to accomplish mobility. This working group is tasked with defining a network-based local mobility management protocol, where local IP mobility is handled without involvement from the mobile node. The idea is that the mobile node may move across multiple access routers without encountering a change in its IP address, thereby hiding the mobility from the IP layer and above. As part of the first phase of efforts in this working group, a protocol for such network-based local mobility has been developed. This protocol, Proxy Mobile IPv6 (PMIPv6), has been developed based on Mobile IPv6, after considering other alternative approaches. With this protocol, unmodified IP nodes may change access routers without having to change the IP address on an interface, within a given administrative domain. This is accomplished by having Mobile Access Gateways (MAGs), often part of the access routers in a network, send binding updates on behalf of mobile nodes attached to them, to a Local Mobility Anchor (LMA). The LMA manages the mobility of the mobile nodes across the MAGs within a given PMIPv6 domain. The PMIPv6 protocol is being adopted as part of several wide-area wireless network (e.g., 3GPP, 3GPP2, WiMAX) and local area network environments. The current charter of this working group involves specification of some necessary features that make the deployment of this protocol feasible in these various environments. As part of this effort, it is essential to support mobility for IPv4 end nodes. Some means of dealing with overlapping private IPv4 addresses of mobile nodes and supporting separation of flows between the MAG and LMA is also required. Further, given that local and global mobility management protocols are likely to be deployed in some combination in various environments, it is necessary to clearly define the interactions between PMIPv6 and MIPv6. Interactions with AAA protocols such as RADIUS and Diameter may be required for authorization or provisioning purposes. When multiple LMAs are present, an automated LMA discovery mechanism may be needed to facilitate deployment. The above items are in scope of the current charter. The MAG and LMA are considered to be IPv6 capable for all efforts of this protocol. Also, all features defined must work with unmodified IP nodes. Specifying any changes to mobile nodes is out of scope of the current charter. Handoff and route optimizations are also out of scope. There is, however, considerable interest in optimization work, for instance, and a future recharter of this working group is likely to address this in some manner. NETLMM WG Deliverables ---------------------- 1) Interface between a PMIPv6 MAG and MN: This interface will define the interaction between a regular IP node and a MAG that will be used to trigger various mobility management actions on the MAG. This is necessary for the MAG to properly trigger binding updates to the LMA and create appropriate mobility management state. 2) IPv4 Support for PMIPv6: This will define the support for IPv4 nodes in PMIPv6. This will also define the protocol operation over an IPv4 transport between the MAG and LMA, by employing protocol extensions already developed in the MEXT WG. 3) Interactions between Mobile IPv6 and Proxy Mobile IPv6: This will highlight the interactions required between these protocols in various methods of co-existence of these in a system, with a view to documenting the best practices to be used. The scenarios considered will include a hierarchical model of local and global mobility management using PMIPv6 and MIPv6 respectively, a mixed mode of the two with some nodes supporting MIPv6 and others not, and the use of MIPv6 upon movement of nodes outside a PMIPv6 domain. 4) GRE Keying option for PMIPv6: This will define a mechanism using GRE keys to support separation of flows between a MAG and LMA. 5) RADIUS support for PMIPv6: This will define the interactions between RADIUS and PMIPv6 to support policy provisioning and authorization. 6) Automatic LMA discovery: This will define the ability for MAGs to automatically discover and use an LMA within a PMIPv6 domain. The scope of this effort may include specifying the use of DNS or DHCP based LMA discovery or LMA discovery using policy information retrieved via AAA protocols. 7) MIB for PMIPv6: This will define the MIB for the protocol for interoperability purposes. 8) PMIPv6 path management and failure detection: This will define an extension to the PMIPv6 protocol allowing PMIPv6 peers to verify bidirectional reachability with their peer, detect failure of their peer, and signal their own failure to their peer. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Apr 2007 Jun 2009 IPv4 Support for Proxy Mobile IPv6 Aug 2008 May 2009 GRE Key Option for Proxy Mobile IPv6 Sep 2008 Apr 2009 Heartbeat Mechanism for Proxy Mobile IPv6 Oct 2008 Jun 2009 Interactions between PMIPv6 and MIPv6: scenarios and related issues May 2009 May 2009 LMA Discovery for Proxy Mobile IPv6 Network-Based Mobility Extensions (netext) ------------------------------------------ Charter Last Modified: 2009-06-18 Current Status: Active Working Group Chair(s): Rajeev Koodli Basavaraj Patil Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:netext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netext Archive: http://www.ietf.org/mail-archive/web/netext/current/maillist.html Description of Working Group: Proxy Mobile IPv6, specified in RFC 5213, is a network-based mobility protocol. It uses a Mobile Access Gateway (MAG) and a Local Mobility Anchor (LMA) to allow hosts to move around within a domain while keeping their address or address prefix stable. Proxy Mobile IPv6 has been incorporated into a number of products and deployments are starting. Certain deployment considerations, including localized routing and bulk refresh of lifetime are already emerging. The working group will focus on the following topics relevant for network-based mobility: Localized Routing: a specification for routing traffic between the MAG(s) without involving the LMA. That is, allow the MAGs to route traffic between hosts from one MAG to another, without being tunneled all the way to the LMA. This reduces latency and backhaul load. Applications such as voice can benefit from the reduced latency. 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. The work in this charter is entirely internal to the network and does not affect hosts in any way (except perhaps through impacting packet forwarding capacity visible to the hosts). 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. This initial charter excludes a number of possible work items that were discussed in the March 2009 BOF. The working group should continue the discussion about a possible update of its charter and principles under which the new work items must operate under. The completion of the work items in the initial charter is not a requirement for the rechartering to become possible. 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. 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. The work in this charter is entirely internal to the network and does not affect hosts in any way (except perhaps through impacting packet forwarding capacity visible to the hosts). 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. This initial charter excludes a number of possible work items that were discussed in the March 2009 BOF. The working group should continue the discussion about a possible update of its charter and principles under which the new work items must operate under. The completion of the work items in the initial charter is not a requirement for the rechartering to become possible. Internet-Drafts: No Current Internet-Drafts. Point-to-Point Protocol Extensions (pppext) ------------------------------------------- Charter Last Modified: 2009-06-09 Current Status: Active Working Group Chair(s): James Carlson Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:pppext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/pppext In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/pppext/index.html Description of Working Group: The Point-to-Point Protocol (PPP, RFC 1661) is a mature protocol with a large number of subprotocols, encapsulations and other extensions. The PPPEXT working group exists to provide a forum for asking clarifications about the existing specifications and to defend against enhancements of questionable value. The group is not expected to create new specifications, and if a need for such work comes up, a recharter is required. The group may, however, advance existing specifications to the next level in the standards track, if a need for that comes up. Similarly, the group may classify existing specifications as Historic where this is appropriate. 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. Internet-Drafts: No Current Internet-Drafts. Protocol for carrying Authentication for Network Access (pana) -------------------------------------------------------------- Charter Last Modified: 2008-08-21 Current Status: Active Working Group Chair(s): Basavaraj Patil Alper Yegin Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Technical Advisor(s): Jari Arkko Mailing Lists: General Discussion:pana@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/pana In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/pana/index.html Description of Working Group: In some scenarios, an IP-based device is required to authenticate itself to the network prior to being authorized to use it. This authentication usually requires a protocol that can support various authentication methods, dynamic service provider selection, and roaming clients. In the absence of such an authentication protocol on most of the link-layers, architectures have resorted to filling the gap by using a number of inadequate methods. For example, inserting an additional layer between link-layer and network-layer mostly for client authentication purpose (e.g., PPPoE), overloading another network-layer protocol to achieve this goal (e.g., Mobile IPv4 with Registration- required flag), and even defining application-layer ad-hoc authentication mechanisms (e.g., http redirects with web-based login). In these and other cases, a network-layer authentication protocol may provide a cleaner solution to the authentication problem. The goal of PANA is to define a protocol that allows clients to authenticate themselves to the access network using IP protocols. Such a protocol would allow a client to interact with a site's back-end AAA infrastructure to gain access without needing to understand the particular AAA infrastructure protocols that are in use at the site. It would also allow such interactions to take place without a link-layer specific mechanism. PANA would be applicable to both multi-access and point-to-point links. It would provide support for various authentication methods, dynamic service provider selection, and roaming clients. Mobile IPv4 developed its own protocols for performing PANA-like functions (e.g., MN-FA interaction). Mobile IPv6 does not have the equivalent of a Foreign Agent (FA) that would allow the access/visited network to authenticate the MN before allowing access. The PANA authentication agent (PAA) can perform the authentication function attributed to the FA in Mobile IPv4, in Mobile IPv6 networks. The WG will work with the assumption that a PANA client (PaC) is already configured with an IP address before using PANA. This IP address will provide limited reachability to the PaC until it is authenticated with the PAA. Upon successful authentication, PaC is granted broader network access possibly by either a new IP address assignment, or by enforcement points changing filtering rules for the same IP address. PANA will neither define any new authentication protocol nor define key distribution, key agreement or key derivation protocols. It is believed that PANA will be able to meet its goals if it is able to carry EAP payloads. Note, however, that EAP may need to be extended in order for PANA to meet the need for all of its intended usages. Such extensions are outside the scope of the PANA WG. PANA will develop an IP-based protocol that allows a device to authenticate itself with the network (and to a PAA in particular) in order to be granted network access. The PAA itself may interface with other AAA backend infrastructures for authenticating and authorizing the service being requested by the host, but such interactions are transparent to the PaC. Network access authentication enables the client to be authorized for packet data service. However it is possible that the underlying link itself is insecure, i.e the packets being transmitted between the client (PaC) and the enforcement point (EP) in the network are not protected by any physical or cryptographic means. In such cases, PANA will enable the establishment of an IPsec SA between the PaC and the EP (a router) to enable access control. In networks that have physical security or ciphering as a link-layer feature, no such SA is required. Hence the establishment of the IPsec SA is optional. The WG will deliver a document that explains how such an IPsec SA is established by using IKE after successful PANA authentication. No enhancements to either IKE or IPsec are expected. The PAA does not necessarily act as an enforcement point (EP) to prevent unauthorized access or usage of the network. When a PaC succesfully authenticates itself to the PAA, EP(s) (e.g., access routers) will need to be suitably notified. SNMP will be used by the PAA to deliver the authorization information to one or more EPs when the PAA is separated from EPs. The WG will document the solution based on SNMP for carrying the authorization information between the PAA and the EP. The WG will also propose a solution of how the PaC discovers the IP address of PAA for sending the authentication request. The PANA WG will deliver - A mechanism for the PAC to discover the PAA on the link. - The PANA protocol itself, capable of carrying multiple authentication methods (e.g. using EAP) - A document that describes how SNMP is used to deliver authorization information from the PAA to the EP in the scenarios where the PAA and EP are separated. - A document that explains the establishment of an IPsec SA between the client and a router (EP) subsequent to authentication for securing the data packets. Description of Working Group: In some scenarios, an IP-based device is required to authenticate itself to the network prior to being authorized to use it. This authentication usually requires a protocol that can support various authentication methods, dynamic service provider selection, and roaming clients. In the absence of such an authentication protocol on most of the link-layers, architectures have resorted to filling the gap by using a number of inadequate methods. For example, inserting an additional layer between link-layer and network-layer mostly for client authentication purpose (e.g., PPPoE), overloading another network-layer protocol to achieve this goal (e.g., Mobile IPv4 with Registration- required flag), and even defining application-layer ad-hoc authentication mechanisms (e.g., http redirects with web-based login). In these and other cases, a network-layer authentication protocol may provide a cleaner solution to the authentication problem. The goal of PANA is to define a protocol that allows clients to authenticate themselves to the access network using IP protocols. Such a protocol would allow a client to interact with a site's back-end AAA infrastructure to gain access without needing to understand the particular AAA infrastructure protocols that are in use at the site. It would also allow such interactions to take place without a link-layer specific mechanism. PANA would be applicable to both multi-access and point-to-point links. It would provide support for various authentication methods, dynamic service provider selection, and roaming clients. Mobile IPv4 developed its own protocols for performing PANA-like functions (e.g., MN-FA interaction). Mobile IPv6 does not have the equivalent of a Foreign Agent (FA) that would allow the access/visited network to authenticate the MN before allowing access. The PANA authentication agent (PAA) can perform the authentication function attributed to the FA in Mobile IPv4, in Mobile IPv6 networks. The WG will work with the assumption that a PANA client (PaC) is already configured with an IP address before using PANA. This IP address will provide limited reachability to the PaC until it is authenticated with the PAA. Upon successful authentication, PaC is granted broader network access possibly by either a new IP address assignment, or by enforcement points changing filtering rules for the same IP address. PANA will neither define any new authentication protocol nor define key distribution, key agreement or key derivation protocols. It is believed that PANA will be able to meet its goals if it is able to carry EAP payloads. Note, however, that EAP may need to be extended in order for PANA to meet the need for all of its intended usages. Such extensions are outside the scope of the PANA WG. PANA will develop an IP-based protocol that allows a device to authenticate itself with the network (and to a PAA in particular) in order to be granted network access. The PAA itself may interface with other AAA backend infrastructures for authenticating and authorizing the service being requested by the host, but such interactions are transparent to the PaC. Network access authentication enables the client to be authorized for packet data service. However it is possible that the underlying link itself is insecure, i.e the packets being transmitted between the client (PaC) and the enforcement point (EP) in the network are not protected by any physical or cryptographic means. In such cases, PANA will enable the establishment of an IPsec SA between the PaC and the EP (a router) to enable access control. In networks that have physical security or ciphering as a link-layer feature, no such SA is required. Hence the establishment of the IPsec SA is optional. The WG will deliver a document that explains how such an IPsec SA is established by using IKE after successful PANA authentication. No enhancements to either IKE or IPsec are expected. The PAA does not necessarily act as an enforcement point (EP) to prevent unauthorized access or usage of the network. When a PaC succesfully authenticates itself to the PAA, EP(s) (e.g., access routers) will need to be suitably notified. SNMP will be used by the PAA to deliver the authorization information to one or more EPs when the PAA is separated from EPs. The WG will document the solution based on SNMP for carrying the authorization information between the PAA and the EP. The WG will also propose a solution of how the PaC discovers the IP address of PAA for sending the authentication request. The PANA WG will deliver - A mechanism for the PAC to discover the PAA on the link. - The PANA protocol itself, capable of carrying multiple authentication methods (e.g. using EAP) - A document that describes how SNMP is used to deliver authorization information from the PAA to the EP in the scenarios where the PAA and EP are separated. - A document that explains the establishment of an IPsec SA between the client and a router (EP) subsequent to authentication for securing the data packets. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2003 Jul 2005 PANA Enabling IPsec based Access Control Jun 2005 Jul 2009 Basic Security Requirements of Authentication Protocol on Ad hoc Oct 2005 Jun 2009 Pre-authentication Support for PANA Pseudowire Emulation Edge to Edge (pwe3) ---------------------------------------- Charter Last Modified: 2009-04-13 Current Status: Active Working Group Chair(s): Stewart Bryant Matthew Bocci Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Technical Advisor(s): David Black Secretary(ies): David Sinicrope Mailing Lists: General Discussion:pwe3@ietf.org To Subscribe: pwe3-request@ietf.org In Body: subscribe your_email_address Archive: http://www.ietf.org/mail-archive/web/pwe3/index.html Description of Working Group: Network transport service providers and their users are seeking to rationalize their networks by migrating their existing services and platforms onto IP or MPLS enabled IP packet switched networks (PSN). This migration requires communications services that can emulate the essential properties of traditional communications links over a PSN. Some service providers wish to use MPLS technology to replace existing transport network infrastructure, relying upon pseudowire technology is an integral component of these network convergence architectures. Pseudowire Emulation Edge to Edge (PWE3) will specify the encapsulation, transport, control, management, interworking and security of services emulated over IETF-specified PSNs. A pseudowire emulates a point-to-point or point-to-multipoint link, and provides a single service which is perceived by its user as an unshared link or circuit of the chosen service. It is not intended that an emulated service will be indistinguishable from the service that is being emulated. The emulation need only be sufficient for the satisfactory operation of the service. Emulation necessarily involves a degree of cost-performance trade-off. In some cases it may be necessary to design more than one emulation mechanism in order to resolve these design conflicts. All emulated service definitions must include an applicability statement describing the faithfulness of the emulation. Switching, multiplexing, modification or other operation on the traditional service, unless required as part of the emulation, is out of the scope of the PWE3 WG. PWE3 will make use of existing IETF-specified mechanisms unless there are technical reasons why the existing mechanisms are insufficient or unnecessary. PWE3 operates "edge to edge" and will not exert control on the underlying PSN, other than to use any existing QoS or path control mechanism to provide the required connectivity between the endpoints of the PW. PWE3 will co-ordinate this with the AVT and TICTOC WGs. Where AVT or TICTOC require extensions to PWs to support time or frequency transfer this work will be undertaken by the PWE3 WG in co-ordination with the these WGs. A PW operating over a shared PSN does not necessarily have the same intrinsic security as a dedicated, purpose built, network. In some cases this is satisfactory, while in other cases it will be necessary to enhance the security of the PW to emulate the intrinsic security of the emulated service. PW specifications MUST include a description of how they are to be operated over a shared PSN with adequate security. PWE3 will work with the MPLS, L2VPN and other relevant WGs for definitions of common solutions for the secure operation of pseudowires. Whilst a service provider may traffic engineer their network in such a way that PW traffic will not cause significant congestion, a PW deployed by an end-user may cause congestion of the underlying PSN. Suitable congestion avoidance mechanisms are therefore needed to protect the Internet from the unconstrained deployment of PWs. Congestion avoidance may be more difficult with P2MP pseudowires than P2P pseudowires. The WG will consider both cases. PWE3 will work closely with the L2VPN WG to ensure a clear demarcation is defined for where PWE3 stops and L2VPN starts, in particular in defining point-multipoint (P2MP) PWs. PWE3 will work with MPLS and L2VPN to enhance the OAM suite for transport applications. PWE3 will coordinate very closely with any WG that is responsible for protocols which PWE3 intends to extend (e.g., the MPLS WG for LDP), as well as foster interaction with WGs that intend to extend PWE3 protocols. The IETF PWE3 WG is the design authority for pseudo-wire over IP/MPLS PSN technology. An entity or individual that wishes to propose extensions or changes to this technology must bring the corresponding proposals to the PWE3 WG that would treat them via a process similar to one described in RFC 4929 for the MPLS/GMPLS change process. WG Objectives: Specify the following PW types: Most of the initial specific PW types have been specified (e.g., Frame Realy, Ethernet, ATM). Investigation into and specification of a "generic PW" type and/or MPLS PW should be undertaken. PWE3 will specify a PW type for the special case where the access service payloads at both ends are known to consist entirely of IP packets. PWE3 will not specify mechanisms by which a PW connects two different access services unless the Network Layer protocol is IP or MPLS. Specify the control and management functions of chartered PW types, to include PW setup, configuration, maintenance and tear-down. The PWE3 WG will do this in its entirety for MPLS PSNs, and the L2TPEXT WG will develop the L2TP specifics for L2TPv3-based PWs. Specify Operations and Management (OAM) mechanisms for all PW types, suitable for operation over both IP/L2TPv3 and MPLS PSNs, and capable of providing the necessary interworking with the OAM mechanisms of the emulated service. Define requirements for and mechanisms to provide interconnection of PWs (to include inter-domain PWs). Define requirements for and mechanisms to provide protection and restoration of PWs. Publish document outlining PW-specific congestion avoidance and response guidelines. Publish document outlining PW-specific security considerations. Specify requirements and mechanisms for P2MP functionality for PWs. This work will be coordinated with the L2VPN and MPLS working groups. Publish requirements and specification for PW to take advantage of multiple PSN paths that exist between PEs. Publish requirements and specification for enhanced OAM. Include extensions to the PWE3 protocols and RFCs necessary to create an MPLS Transport Profile (MPLS-TP). The work on the MPLS TP needs to be coordinated between three primary working groups (MPLS, PWE3, L2VPN and CCAMP) that are chartered to do MPLS TP work. 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. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jun 2002 Jan 2008 Pseudowire (PW) Management Information Base (MIB) Jun 2002 Jan 2008 Pseudowire (PW) over MPLS PSN Management Information Base (MIB) Aug 2002 Jan 2008 SONET/SDH Circuit Emulation Service Over Packet (CEP) Management Information Base (MIB) Using SMIv2 Oct 2002 Feb 2009 Ethernet Pseudowire (PW) Management Information Base (MIB) Oct 2003 Oct 2008 Managed Objects for ATM over Packet Switched Network (PSN) May 2004 Oct 2008 Managed Objects for TDM over Packet Switched Network (PSN) Sep 2004 Jun 2009 Pseudo Wire (PW) OAM Message Mapping Jul 2005 Jun 2009 Segmented Pseudowire Jan 2006 Mar 2009 Dynamic Placement of Multi Segment Pseudo Wires Jan 2006 Feb 2009 An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge Mar 2006 Jan 2009 Encapsulation Methods for Transport of Fibre Channel frames Over MPLS Networks Feb 2007 Jun 2009 Pseudowire Congestion Control Framework May 2007 Jun 2009 Application of Ethernet Pseudowires to MPLS Transport Networks Nov 2007 Jun 2009 Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV) Dec 2008 May 2009 LDP extensions for AII reachability Jan 2009 Jan 2009 Reliable Fibre Channel Transport Over MPLS Networks Feb 2009 Feb 2009 MPLS and Ethernet OAM Interworking Jun 2009 Jun 2009 Inter-Chassis Communication Protocol for L2VPN PE Redundancy Jul 2009 Jul 2009 Flow Aware Transport of Pseudowires over an MPLS PSN Site Multihoming by IPv6 Intermediation (shim6) ----------------------------------------------- Charter Last Modified: 2008-04-23 Current Status: Active Working Group Chair(s): Kurt Lindqvist Geoff Huston Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Technical Advisor(s): Thomas Narten Mailing Lists: General Discussion:shim6@psg.com To Subscribe: shim6-request@psg.com Archive: http://ops.ietf.org/lists/shim6/ Description of Working Group: For the purposes of redundancy, load sharing, operational policy or cost, a site may be multi-homed, with the site's network having connections to multiple IP service providers. The current Internet routing infrastructure permits multi-homing using provider independent addressing, and adapts to changes in the availability of these connections. However if the site uses multiple provider-assigned address prefixes for every host within the site, host application associations cannot use alternate paths, such as for surviving the changes or for creating new associations, when one or more of the site's address prefixes becomes unreachable. This working group will produce specifications for an IPv6-based site multi-homing solution that inserts a new sub-layer (shim) into the IP stack of end-system hosts. It will enable hosts on multi-homed sites to use a set of provider- assigned IP address prefixes and switch between them without upsetting transport protocols or applications. The work will be based on the architecture developed by the IETF multi6 working group. The shim6 working group is to complete the required protocol developments and the architecture and security analysis of the required protocols. Requirements for the solution are: o The approach must handle re-homing both existing communication and being able to establish new communication when one or more of the addresses is unreachable. o IPv6 NAT devices are assumed not to exist, or not to present an obstacle about which the shim6 solution needs to be concerned. o Only IPv6 is considered. o Changes in the addresses that are used below the shim will be invisible to the upper layers, which will see a fixed address (termed Upper Layer Identifier or ULID). o ULIDs will be actual IP addresses, permitting existing applications to continue to work unchanged, and permitting application referrals to work, as long as the IP Addresses are available. o The solution should assume ingress filtering may be applied at network boundaries. o The solution must allow the global routing system to scale even if there is a very large number of multi-homed sites. This implies that re-homing not be visible to the routing system. o Compatibility will remain for existing mobility mechanisms. It will be possible to use Mobile IPv6 on a node that also supports Shim6. However, any optimizations or advanced configurations are out of scope for shim6. o The approach is to provide an optimized way to handle a static set of addresses, while also providing a way to securely handle dynamic changes in the set of addresses. The dynamic changes might be useful for future combinations of multi-homing and IP mobility, but the working group will not take on such mobility capabilities directly. o The specifications must specifically refer to all applicable threats and describe how they are handled, with the requirement being that the resulting solution not introduce any threats that make the security any less than in today's Internet. The background documents to be considered by the WG include: RFC 3582 draft-ietf-multi6-architecture-04.txt draft-ietf-multi6-things-to-think-about-01.txt draft-ietf-multi6-multihoming-threats-03.txt The input documents that the WG will use as the basis for its design are: draft-huston-l3shim-arch-00.txt draft-ietf-multi6-functional-dec-00.txt draft-ietf-multi6-l3shim-00.txt draft-ietf-multi6-failure-detection-00.txt draft-ietf-multi6-hba-00.txt draft-ietf-multi6-app-refer-00.txt In addition to the network layer shim solution, the shim6 WG is specifically chartered to work on: o Solutions for site exit router selection that work when each ISP uses ingress filtering, i.e. when the chosen site exit needs to be related to the source address chosen by the host. This site exit router selection and the associated address selection process should work whether or not the peer site supports the shim6 protocol. o Solutions to establish new communications after an outage has occurred that do not require shim support from the non-multihomed end of the communication. The Working Group will explore whether such solutions are also useful when both ends support the shim. o The possible impact of the use of multiple locators at both ends on congestion control, traffic engineering, and QoS will be analysed in conjunction with the Transport Area. o The relationships between Upper Layer Identifiers (ULIDs) and unique local addresses. o ICMP error demuxing for locator failure discovery. o If necessary, develop and specify formats and structure for: - Cryptographically protected locators - Carrying the flow label across the shim layer defined in the multi6 architecture. The shim6 WG is to publish, as standards track RFC's, specifications with enough details to allow fully interoperable implementations. Description of Working Group: For the purposes of redundancy, load sharing, operational policy or cost, a site may be multi-homed, with the site's network having connections to multiple IP service providers. The current Internet routing infrastructure permits multi-homing using provider independent addressing, and adapts to changes in the availability of these connections. However if the site uses multiple provider-assigned address prefixes for every host within the site, host application associations cannot use alternate paths, such as for surviving the changes or for creating new associations, when one or more of the site's address prefixes becomes unreachable. This working group will produce specifications for an IPv6-based site multi-homing solution that inserts a new sub-layer (shim) into the IP stack of end-system hosts. It will enable hosts on multi-homed sites to use a set of provider- assigned IP address prefixes and switch between them without upsetting transport protocols or applications. The work will be based on the architecture developed by the IETF multi6 working group. The shim6 working group is to complete the required protocol developments and the architecture and security analysis of the required protocols. Requirements for the solution are: o The approach must handle re-homing both existing communication and being able to establish new communication when one or more of the addresses is unreachable. o IPv6 NAT devices are assumed not to exist, or not to present an obstacle about which the shim6 solution needs to be concerned. o Only IPv6 is considered. o Changes in the addresses that are used below the shim will be invisible to the upper layers, which will see a fixed address (termed Upper Layer Identifier or ULID). o ULIDs will be actual IP addresses, permitting existing applications to continue to work unchanged, and permitting application referrals to work, as long as the IP Addresses are available. o The solution should assume ingress filtering may be applied at network boundaries. o The solution must allow the global routing system to scale even if there is a very large number of multi-homed sites. This implies that re-homing not be visible to the routing system. o Compatibility will remain for existing mobility mechanisms. It will be possible to use Mobile IPv6 on a node that also supports Shim6. However, any optimizations or advanced configurations are out of scope for shim6. o The approach is to provide an optimized way to handle a static set of addresses, while also providing a way to securely handle dynamic changes in the set of addresses. The dynamic changes might be useful for future combinations of multi-homing and IP mobility, but the working group will not take on such mobility capabilities directly. o The specifications must specifically refer to all applicable threats and describe how they are handled, with the requirement being that the resulting solution not introduce any threats that make the security any less than in today's Internet. The background documents to be considered by the WG include: RFC 3582 draft-ietf-multi6-architecture-04.txt draft-ietf-multi6-things-to-think-about-01.txt draft-ietf-multi6-multihoming-threats-03.txt The input documents that the WG will use as the basis for its design are: draft-huston-l3shim-arch-00.txt draft-ietf-multi6-functional-dec-00.txt draft-ietf-multi6-l3shim-00.txt draft-ietf-multi6-failure-detection-00.txt draft-ietf-multi6-hba-00.txt draft-ietf-multi6-app-refer-00.txt In addition to the network layer shim solution, the shim6 WG is specifically chartered to work on: o Solutions for site exit router selection that work when each ISP uses ingress filtering, i.e. when the chosen site exit needs to be related to the source address chosen by the host. This site exit router selection and the associated address selection process should work whether or not the peer site supports the shim6 protocol. o Solutions to establish new communications after an outage has occurred that do not require shim support from the non-multihomed end of the communication. The Working Group will explore whether such solutions are also useful when both ends support the shim. o The possible impact of the use of multiple locators at both ends on congestion control, traffic engineering, and QoS will be analysed in conjunction with the Transport Area. o The relationships between Upper Layer Identifiers (ULIDs) and unique local addresses. o ICMP error demuxing for locator failure discovery. o If necessary, develop and specify formats and structure for: - Cryptographically protected locators - Carrying the flow label across the shim layer defined in the multi6 architecture. The shim6 WG is to publish, as standards track RFC's, specifications with enough details to allow fully interoperable implementations. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2006 May 2009 Socket Application Program Interface (API) for Multihoming Shim Softwires (softwire) -------------------- Charter Last Modified: 2009-04-13 Current Status: Active Working Group Chair(s): Alain Durand David Ward Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Technical Advisor(s): Xing Li Mailing Lists: General Discussion:softwires@ietf.org To Subscribe: softwires-request@ietf.org In Body: With a subject line: subscribe Archive: http://www.ietf.org/mail-archive/web/softwires/current/maillist.html Description of Working Group: The Softwires Working Group is specifying the standardization of discovery, control and encapsulation methods for connecting IPv4 networks across IPv6 networks and IPv6 networks across IPv4 networks in a way that will encourage multiple, inter-operable implementations. For various reasons, native IPv4 and/or IPv6 transport may not be available in all cases, and there is a need to tunnel IPv4 in IPv6 or IPv6 in IPv4 to cross a part of the network which is not IPv4 or IPv6 capable. The Softwire Problem Statement, RFC 4925, identifies two distinct topological scenarios that the WG will provide solutions for, "Hubs and Spokes" and "Mesh." In the former case, hosts or "stub" networks are attached via individual, point-to-point, IPv4 over IPv6 or IPv6 over IPv4 softwires to a centralized Softwire Concentrator. In the latter case (Mesh), network islands of one Address Family (IPv4 or IPv6) are connected over a network of another Address Family via point to multi-point softwires among Address family Border Routers (AFBRs). The focus of this WG is to: Document the softwire encapsulation and control protocol usage for one Address Family (IPv6 or IPv4) over another within the defined problem spaces set out in RFC 4925. Define "Dual-Stack Lite" which uses softwires and IPv4 NAT functions to reduce the amount of Global and RFC 1918 Local IPv4 addressing necessary for a Service Provider with an IPv6-enabled network to continue delivering IPv4 reachability to its customers. The WG will reuse existing technologies as much as possible and only when necessary, create additional protocol building blocks. For generality, all base SOFTWIRE encapsulation mechanisms should support all combinations of IP versions over one other (IPv4 over IPv6, IPv6 over IPv4, IPv4 over IPv4, IPv6 over IPv6). IPv4 to IPv6 translation mechanisms (NAT-PT), new addressing schemes, and block address assignments are out of scope. DHCP options developed in this group will be reviewed jointly with the DHC WG. BGP and other routing and signaling protocols developed in this group will be reviewed jointly with the proper working groups and other workings that may take interest (e.g. IDR, L3VPN, PIM, LDP, SAAG, etc). Description of Working Group: The Softwires Working Group is specifying the standardization of discovery, control and encapsulation methods for connecting IPv4 networks across IPv6 networks and IPv6 networks across IPv4 networks in a way that will encourage multiple, inter-operable implementations. For various reasons, native IPv4 and/or IPv6 transport may not be available in all cases, and there is a need to tunnel IPv4 in IPv6 or IPv6 in IPv4 to cross a part of the network which is not IPv4 or IPv6 capable. The Softwire Problem Statement, RFC 4925, identifies two distinct topological scenarios that the WG will provide solutions for, "Hubs and Spokes" and "Mesh." In the former case, hosts or "stub" networks are attached via individual, point-to-point, IPv4 over IPv6 or IPv6 over IPv4 softwires to a centralized Softwire Concentrator. In the latter case (Mesh), network islands of one Address Family (IPv4 or IPv6) are connected over a network of another Address Family via point to multi-point softwires among Address family Border Routers (AFBRs). The focus of this WG is to: Document the softwire encapsulation and control protocol usage for one Address Family (IPv6 or IPv4) over another within the defined problem spaces set out in RFC 4925. Define "Dual-Stack Lite" which uses softwires and IPv4 NAT functions to reduce the amount of Global and RFC 1918 Local IPv4 addressing necessary for a Service Provider with an IPv6-enabled network to continue delivering IPv4 reachability to its customers. The WG will reuse existing technologies as much as possible and only when necessary, create additional protocol building blocks. For generality, all base SOFTWIRE encapsulation mechanisms should support all combinations of IP versions over one other (IPv4 over IPv6, IPv6 over IPv4, IPv4 over IPv4, IPv6 over IPv6). IPv4 to IPv6 translation mechanisms (NAT-PT), new addressing schemes, and block address assignments are out of scope. DHCP options developed in this group will be reviewed jointly with the DHC WG. BGP and other routing and signaling protocols developed in this group will be reviewed jointly with the proper working groups and other workings that may take interest (e.g. IDR, L3VPN, PIM, LDP, SAAG, etc). Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jun 2006 Jun 2009 Softwire Security Analysis and Requirements Dec 2008 May 2009 Load Balancing for Mesh Softwires Mar 2009 Mar 2009 Dual-stack lite broadband deployments post IPv4 exhaustion Source Address Validation Improvements (savi) --------------------------------------------- Charter Last Modified: 2008-11-05 Current Status: Active Working Group Chair(s): Christian Vogt Bill Fenner Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Technical Advisor(s): Jianping Wu Secretary(ies): Jun Bi Mailing Lists: General Discussion:savi@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/savi Archive: http://www.ietf.org/mail-archive/web/savi/current/maillist.html Description of Working Group: While ingress filtering [RFC 2827, BCP 38] provides a way to validate IP source addresses at an aggregated level, there is not yet a standardized mechanism for IP source address validation at a finer granularity. Having a finer granularity would be helpful in a number of situations, including filtering traffic from customer interfaces implemented as ports in a layer 3 aware bridge or a router, general improvements in filtering accuracy in enterprise networks, etc. Depending on the situation, there may be a requirement for blocking spoofed packets or merely logging packets that appear to be spoofed. Partial solutions exist to prevent nodes from spoofing the IP source address of another node in the same IP link (e.g., the "IP source guard"), but are proprietary. The purpose of the proposed "Source Address Validation Improvements" working group is to standardize mechanisms that prevent nodes attached to the same IP link from spoofing each other's IP addresses. The scope of the WG is as follows: - The working group considers only solutions implemented on systems located on the same IP link as a to-be-verified node. The goal of the working group is the LAN environment and solutions running in routers or layer 3 aware Ethernet bridges. - Both IPv4 and IPv6 need to be covered. - The first goal of the working group is on unicast traffic, but using the same mechanisms to police multicast traffic is also within the scope. - All address assignment mechanisms need to be supported, including stateless, stateful, and manual configuration; as well as privacy and cryptographically generated addresses. - Solutions are preferably based on observing user traffic, or on observing or using existing signaling protocols. Examples of protocols that can be useful to observe/use are ARP, Neighbor Discovery, DHCP, and DHCP Prefix Delegation protocols. Observing addresses in IP headers can also be useful. The gathered information is used to determine what IP source addresses in packets are appropriate. Where automatic operation is impossible or would lead to sub-optimal validation results, solutions may require manual configuration. - Interdomain scenarios (across Autonomous Systems) that require information from routing protocols like BGP are out of scope. Nevertheless, solution may observe routing protocol signaling to detect that a device is a router. - Tracking other protocols is not within the scope of the WG. - No changes to hosts are allowed. - The WG is prohibited from creating its own protocols or extensions/modifications of current protocols. These limitations in the scope may be relaxed through later rechartering. For instance, solutions tailored for PPP links and specific environments may be added later, or solutions involving co-operation of the nodes on the link may be developed once the baseline solutions have been completed. However, the WG is already chartered to work also on a solution for Ethernet-based broadband access networks that are used in DSL environments. This work is a specialization of the working group's primary LAN-based solution. In order to reach a result that is widely usable and unlikely to disturb existing network practices, the working group needs to take into account - nodes that use static addresses, - nodes with multiple IP addresses on the same interface, - nodes that use multiple link-layer addresses on the same interface, - nodes that have multiple interfaces to the same link, - attachment of another bridge at a bridge port, - presence of routers, NATs, and other similar devices on the same link, including their distinction from hosts with multiple interfaces or hosts with multiple IP addresses on a single interface, - use of SEcure Neighbor Discovery in some networks, - nodes that move to another port on the same link, and - hosts with anycast addresses. However, should such wide applicability turn out to be impossible, the working group will document the limitations of the solutions in due manner. In particular, it is likely that anycast addressing and nodes that employ multiple interfaces for load balancing at link layer are indistinguishable from an actual spoofing attack. There may also be a difference in the applicability between blocking and merely logging spoofed packets. In any case, the solutions may require to be explicitly turned on for each network or interface where they are applicable. For background information, the working group will also develop a threats analysis document that describes what threats the solutions from the WG protect against. This document also contrasts SAVI to existing solutions. 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. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jan 2009 Jan 2009 SAVI Threat Scope Jan 2009 Jan 2009 A Solution Space Analysis for First-Hop IP Source Address Validation Jan 2009 Mar 2009 First-Come First-Serve Source-Address Validation Implementation Jan 2009 Jan 2009 SeND-based Source-Address Validation Implementation Timing over IP Connection and Transfer of Clock (tictoc) -------------------------------------------------------- Charter Last Modified: 2009-04-13 Current Status: Active Working Group Chair(s): Yaakov Stein Stewart Bryant Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion:tictoc@ietf.org To Subscribe: TICTOC-request@ietf.org In Body: In Body: subscribe your_email_address 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. 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. Internet-Drafts: No Current Internet-Drafts. Transparent Interconnection of Lots of Links (trill) ---------------------------------------------------- Charter Last Modified: 2009-05-07 Current Status: Active Working Group Chair(s): Erik Nordmark Donald Eastlake 3rd Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Ralph Droms Mailing Lists: General Discussion:rbridge@postel.org To Subscribe: http://www.postel.org/mailman/listinfo/rbridge Archive: http://www.postel.org/pipermail/rbridge Description of Working Group: The TRILL WG will design a solution for shortest-path frame routing in multi-hop IEEE 802.1-compliant Ethernet networks with arbitrary topologies, using an existing link-state routing protocol technology. This work will initially be based on draft-perlman-rbridge-03.txt. The design should have the following properties: - Minimal or no configuration required - Load-splitting among multiple paths - Routing loop mitigation (possibly through a TTL field) - Support of multiple points of attachment - Support for broadcast and multicast - No significant service delay after attachment - No less secure than existing bridged solutions Any changes introduced to the Ethernet service model should be analyzed and clearly documented. To ensure compatibility with IEEE VLANs and the Ethernet service model, the WG will request an IEEE liaison relationship with IEEE 802.1, and IEEE 802.1 will be asked to review the architecture document and specification(s) before they are submitted to the IESG. It is not an explicit requirement that the solution should be able to run on existing IP routers or IEEE 802 switches as a software upgrade. However, the working group should take deployment considerations into account, to ensure that the solution can interwork with bridges in a flexible manner (e.g., to allow incremental deployment into LANs that currently use 802.1D bridges). The TRILL working will work with the L2VPN WG to develop interworking between TRILL and 802.1D bridges at the edge, such that a bridged sub-cloud could be attached to TRILL devices in more than one place for redundancy. The solution must not interfere with the end-to-end transparency of the Internet architecture or with end-to-end congestion control and QOS mechanisms. The WG will work on the following items: (1) Develop a problem statement and architecture document that describes the high-level TRILL architecture, discusses the scalability of that architecture, describes the threat model and security impacts of the TRILL solution, and describes the expected impacts (if any) of the TRILL solution on the Ethernet service model. (2) Define the requirements for a TRILL-capable routing protocol, and select one or more existing routing protocols that could meet those requirements. (3) Work with the appropriate Routing area working group to extend an existing routing protocol to meet the TRILL working group requirements. Note: The TRILL working group is not chartered to develop a new routing protocol or to make substantial modifications to an existing routing protocol. If, during the requirements definition and selection phase, the TRILL working group discovers that no existing routing protocol will meet their needs, we will need to re-assess the TRILL WG charter to determine how/if this work should proceed. (4) Produce a (set of) TRILL specification(s) for standards track publication that define(s) what information must be carried in an encapsulation header for data packets. Although this work will initially be undertaken only for 802.1-compliant links, it may later be expanded to non-802.1 links, so the design should be link-layer agnostic to whatever extent possible. The TRILL working group is chartered to undertake all of the above tasks and may begin work on more than one of these tasks in parallel. However, the problem statement and architecture document should be completed before the details of the base protocol are finalized, while there is still time to consider changes to the architecture without major impacts on established specifications. Description of Working Group: The TRILL WG will design a solution for shortest-path frame routing in multi-hop IEEE 802.1-compliant Ethernet networks with arbitrary topologies, using an existing link-state routing protocol technology. This work will initially be based on draft-perlman-rbridge-03.txt. The design should have the following properties: - Minimal or no configuration required - Load-splitting among multiple paths - Routing loop mitigation (possibly through a TTL field) - Support of multiple points of attachment - Support for broadcast and multicast - No significant service delay after attachment - No less secure than existing bridged solutions Any changes introduced to the Ethernet service model should be analyzed and clearly documented. To ensure compatibility with IEEE VLANs and the Ethernet service model, the WG will request an IEEE liaison relationship with IEEE 802.1, and IEEE 802.1 will be asked to review the architecture document and specification(s) before they are submitted to the IESG. It is not an explicit requirement that the solution should be able to run on existing IP routers or IEEE 802 switches as a software upgrade. However, the working group should take deployment considerations into account, to ensure that the solution can interwork with bridges in a flexible manner (e.g., to allow incremental deployment into LANs that currently use 802.1D bridges). The TRILL working will work with the L2VPN WG to develop interworking between TRILL and 802.1D bridges at the edge, such that a bridged sub-cloud could be attached to TRILL devices in more than one place for redundancy. The solution must not interfere with the end-to-end transparency of the Internet architecture or with end-to-end congestion control and QOS mechanisms. The WG will work on the following items: (1) Develop a problem statement and architecture document that describes the high-level TRILL architecture, discusses the scalability of that architecture, describes the threat model and security impacts of the TRILL solution, and describes the expected impacts (if any) of the TRILL solution on the Ethernet service model. (2) Define the requirements for a TRILL-capable routing protocol, and select one or more existing routing protocols that could meet those requirements. (3) Work with the appropriate Routing area working group to extend an existing routing protocol to meet the TRILL working group requirements. Note: The TRILL working group is not chartered to develop a new routing protocol or to make substantial modifications to an existing routing protocol. If, during the requirements definition and selection phase, the TRILL working group discovers that no existing routing protocol will meet their needs, we will need to re-assess the TRILL WG charter to determine how/if this work should proceed. (4) Produce a (set of) TRILL specification(s) for standards track publication that define(s) what information must be carried in an encapsulation header for data packets. Although this work will initially be undertaken only for 802.1-compliant links, it may later be expanded to non-802.1 links, so the design should be link-layer agnostic to whatever extent possible. The TRILL working group is chartered to undertake all of the above tasks and may begin work on more than one of these tasks in parallel. However, the problem statement and architecture document should be completed before the details of the base protocol are finalized, while there is still time to consider changes to the architecture without major impacts on established specifications. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- May 2006 Jun 2009 Rbridges: Base Protocol Specification Jan 2009 Jan 2009 RBridge VLAN Mapping ADSL MIB (adslmib) ------------------ Charter Last Modified: 2009-02-11 Current Status: Active Working Group Chair(s): Michael Sneed Menachem Dodge Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Technical Advisor(s): Randy Presuhn Editor(s): Faye Ly Greg Bathrick Bob Ray Rajesh Abbi Scott Baillie Menachem Dodge Clay Sikes Moti Morgenstern Umberto Bonollo Mailing Lists: General Discussion:adslmib@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/adslmib Archive: http://www.ietf.org/mail-archive/web/adslmib/current/maillist.html Description of Working Group: The working group will define a set of managed objects to be used for management of newer versions of Digital Subscriber Line (xDSL) as defined in ITU-T Recommendation G.997.1 (02/2006). The MIB 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, and the AToM MIB. The working group will consider the input of the DSL forum and the ITU in the definition of this MIB. Description of Working Group: The working group will define a set of managed objects to be used for management of newer versions of Digital Subscriber Line (xDSL) as defined in ITU-T Recommendation G.997.1 (02/2006). The MIB 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, and the AToM MIB. The working group will consider the input of the DSL forum and the ITU in the definition of this MIB. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2006 May 2009 Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2) Feb 2007 May 2009 xDSL multi-pair bonding (G.Bond) MIB Benchmarking Methodology (bmwg) ------------------------------- Charter Last Modified: 2008-08-21 Current Status: Active Working Group Chair(s): Al Morton Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Ronald Bonica Mailing Lists: General Discussion:bmwg@ietf.org To Subscribe: bmwg-request@ietf.org In Body: subscribe your_email_address Archive: http://www.ietf.org/mail-archive/web/bmwg/index.html Description of Working Group: The major goal of the Benchmarking Methodology Working Group is to make a series of recommendations concerning the measurement of the performance characteristics of various internetworking technologies; further, these recommendations may focus on the systems or services that are built from these technologies. Each recommendation will describe the class of equipment, system, or service being addressed; discuss the performance characteristics that are pertinent to that class; clearly identify a set of metrics that aid in the description of those characteristics; specify the methodologies required to collect said metrics; and lastly, present the requirements for the common, unambiguous reporting of benchmarking results. To better distinguish the BMWG from other measurement initiatives in the IETF, the scope of the BMWG is limited to technology characterization using simulated stimuli in a laboratory environment. Said differently, the BMWG does not attempt to produce benchmarks for live, operational networks. Moreover, the benchmarks produced by this WG shall strive to be vendor independent or otherwise have universal applicability to a given technology class. Because the demands of a particular technology may vary from deployment to deployment, a specific non-goal of the Working Group is to define acceptance criteria or performance requirements. An ongoing task is to provide a forum for discussion regarding the advancement of measurements designed to provide insight on the operation inter-networking technologies. In addition to its current work plan, the BMWG is explicitly tasked to develop benchmarks and methodologies for the following technologies: * MPLS Forwarding: Develop specific methods to characterize the latency and forwarding performance of MPLS devices, extending the fundamental recommendations of RFC 1242 and RFC 2544 to this networking technology. * SIP Networking Devices: Develop new terminology and methods to characterize the key performance aspects of network devices using SIP, including the signaling plane scale and service rates while considering load conditions on both the signaling and media planes. This work will be harmonized with related SIP performance metric definitions prepared by the PMOL working group. Description of Working Group: The major goal of the Benchmarking Methodology Working Group is to make a series of recommendations concerning the measurement of the performance characteristics of various internetworking technologies; further, these recommendations may focus on the systems or services that are built from these technologies. Each recommendation will describe the class of equipment, system, or service being addressed; discuss the performance characteristics that are pertinent to that class; clearly identify a set of metrics that aid in the description of those characteristics; specify the methodologies required to collect said metrics; and lastly, present the requirements for the common, unambiguous reporting of benchmarking results. To better distinguish the BMWG from other measurement initiatives in the IETF, the scope of the BMWG is limited to technology characterization using simulated stimuli in a laboratory environment. Said differently, the BMWG does not attempt to produce benchmarks for live, operational networks. Moreover, the benchmarks produced by this WG shall strive to be vendor independent or otherwise have universal applicability to a given technology class. Because the demands of a particular technology may vary from deployment to deployment, a specific non-goal of the Working Group is to define acceptance criteria or performance requirements. An ongoing task is to provide a forum for discussion regarding the advancement of measurements designed to provide insight on the operation inter-networking technologies. In addition to its current work plan, the BMWG is explicitly tasked to develop benchmarks and methodologies for the following technologies: * MPLS Forwarding: Develop specific methods to characterize the latency and forwarding performance of MPLS devices, extending the fundamental recommendations of RFC 1242 and RFC 2544 to this networking technology. * SIP Networking Devices: Develop new terminology and methods to characterize the key performance aspects of network devices using SIP, including the signaling plane scale and service rates while considering load conditions on both the signaling and media planes. This work will be harmonized with related SIP performance metric definitions prepared by the PMOL working group. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Mar 2003 Apr 2009 Terminology for Benchmarking IPsec Devices Jun 2003 Mar 2009 Benchmarking Methodology for Link-State IGP Data Plane Route Convergence Jun 2003 Mar 2009 Terminology for Benchmarking Link-State IGP Data Plane Route Convergence Jun 2003 Mar 2009 Considerations for Benchmarking Link-State IGP Data Plane Route Convergence Oct 2005 Apr 2009 Methodology for Benchmarking IPsec Devices Oct 2006 Mar 2009 Benchmarking Terminology for Protection Performance Oct 2006 Mar 2009 Methodology for benchmarking MPLS protection mechanisms Sep 2008 Apr 2009 MPLS Forwarding Benchmarking Methodology for IP Flows Mar 2009 Mar 2009 Terminology for Benchmarking Session Initiation Protocol (SIP) Networking Devices Mar 2009 Mar 2009 Methodology for Benchmarking SIP Networking Devices Control And Provisioning of Wireless Access Points (capwap) ----------------------------------------------------------- Charter Last Modified: 2008-08-21 Current Status: Active Working Group Chair(s): Mahalingam Mani Dorothy Gellert Margaret Wasserman Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Technical Advisor(s): David Borman Scott Kelly Bob O'Hara Charles Clancy Mailing Lists: General Discussion:capwap@frascone.com To Subscribe: http://lists.frascone.com/mailman/listinfo/capwap Archive: http://lists.frascone.com/pipermail/capwap Description of Working Group: The original CAPWAP WG charter included drafting a problem statement and a taxonomy of architectures. The new charter of the CAPWAP WG proposes building upon the original charter and developing a CAPWAP protocol to provide interoperability among WLAN backend architectures. The intent of the CAPWAP protocol is to facilitate control, management and provisioning of WLAN Termination Points (WTPs) specifying the services, functions and resources relating to 802.11 WLAN Termination Points in order to allow for interoperable implementations of WTPs and ACs. The revised CAPWAP WG will reference two classes of the Centralized WLAN Architecture family, namely the Local MAC and the Split MAC, as described in the CAPWAP Architecture Taxonomy draft. The protocol will define the CAPWAP control plane including the primitives to control data access. An effective Centralized CAPWAP Architecture impacts how WLAN data traffic is managed over the backend network. This implies the abilitiy to control how data is forwarded by negotiating existng data encapsulation mechanisms and specifying data payload formats in order to ensure interoperability between CAPWAP vendors. No other specifications of the CAPWAP data plane are within the scope of this charter. The CAPWAP WG will strive for extensibility in the protocol design to favor future applicability to other access technologies, especially IEEE 802.16. While accommodation of any access technology other than IEEE 802.11 is not required for successful completion, there are clear deployment advantages if a wide range of access technologies are accommodated. In summary, the primary goals of the group will be: 1. Defining a set of Objectives based on the architecture taxonomy work that lists the requirements for an interoperable CAPWAP protocol. In addition, the WG will incorporate requirements derived from the inputs provided by Enterprise and (hotspot) Providers based on the WLAN deployment challenges addressed by CAPWAP architecture. This document will: a. include objectives to address problems described in the CAPWAP Problem statement document b. Describe each objective, its benefit to the protocol and how it satisfies the problem statement. c. Prioritize and classify the objectives into 3 categories: i. Mandatory and Accepted ii. Desirable iii. Rejected d. Undergo review in IEEE 802 as needed This should result in the first WG Last Call for Objectives draft. To avoid requirements bloat and stalemate, the WG has a hard deadline on the Objectives phase. The WG MUST reach WG consensus on the objectives draft by Feb 2005. This is for several reasons: * We must send this for review to IEEE at that time. * We must have a reasonably stable set of objectives so that candidate submissions are aware of the objectives to be met. The 2nd WG Last Call (in April) for the objectives draft is to ensure that the WG has consensus on any changes that may result from IEEE and expert review. So it is not the intention that the WG keeps adding new Objectives after Feb 2005. If the WG cannot reach consensus on the Objectives draft by the May 2005 milestone to the IESG, the WG will close. 2. Evaluating a set of candidate proposals that include existing IETF protocols and any proposals leading to the selection of a protocol on which to base the CAPWAP standard. 3. Developing a CAPWAP protocol standard that meets the Mandatory and Accepted objectives from the Evaluation draft and contains the minimal set of feature needed to control and provision WLAN Access Points. Specifically The CAPWAP protocol document will address the following considerations: a. Architecture b. Operations c. Security d. Network Management e. Scalability f. Performance 4. A MIB Document to support the CAPWAP protocol. In addition, the CAPWAP WG will maintain its Liaison with the IEEE to ensure consistency of its work with the IEEE 802.11 Standard. Deliverables: * Objectives/Criteria Document for CAPWAP protocol * Protocol evaluation and base protocol selection document * CAPWAP Protocol standard * MIB support standard Description of Working Group: The original CAPWAP WG charter included drafting a problem statement and a taxonomy of architectures. The new charter of the CAPWAP WG proposes building upon the original charter and developing a CAPWAP protocol to provide interoperability among WLAN backend architectures. The intent of the CAPWAP protocol is to facilitate control, management and provisioning of WLAN Termination Points (WTPs) specifying the services, functions and resources relating to 802.11 WLAN Termination Points in order to allow for interoperable implementations of WTPs and ACs. The revised CAPWAP WG will reference two classes of the Centralized WLAN Architecture family, namely the Local MAC and the Split MAC, as described in the CAPWAP Architecture Taxonomy draft. The protocol will define the CAPWAP control plane including the primitives to control data access. An effective Centralized CAPWAP Architecture impacts how WLAN data traffic is managed over the backend network. This implies the abilitiy to control how data is forwarded by negotiating existng data encapsulation mechanisms and specifying data payload formats in order to ensure interoperability between CAPWAP vendors. No other specifications of the CAPWAP data plane are within the scope of this charter. The CAPWAP WG will strive for extensibility in the protocol design to favor future applicability to other access technologies, especially IEEE 802.16. While accommodation of any access technology other than IEEE 802.11 is not required for successful completion, there are clear deployment advantages if a wide range of access technologies are accommodated. In summary, the primary goals of the group will be: 1. Defining a set of Objectives based on the architecture taxonomy work that lists the requirements for an interoperable CAPWAP protocol. In addition, the WG will incorporate requirements derived from the inputs provided by Enterprise and (hotspot) Providers based on the WLAN deployment challenges addressed by CAPWAP architecture. This document will: a. include objectives to address problems described in the CAPWAP Problem statement document b. Describe each objective, its benefit to the protocol and how it satisfies the problem statement. c. Prioritize and classify the objectives into 3 categories: i. Mandatory and Accepted ii. Desirable iii. Rejected d. Undergo review in IEEE 802 as needed This should result in the first WG Last Call for Objectives draft. To avoid requirements bloat and stalemate, the WG has a hard deadline on the Objectives phase. The WG MUST reach WG consensus on the objectives draft by Feb 2005. This is for several reasons: * We must send this for review to IEEE at that time. * We must have a reasonably stable set of objectives so that candidate submissions are aware of the objectives to be met. The 2nd WG Last Call (in April) for the objectives draft is to ensure that the WG has consensus on any changes that may result from IEEE and expert review. So it is not the intention that the WG keeps adding new Objectives after Feb 2005. If the WG cannot reach consensus on the Objectives draft by the May 2005 milestone to the IESG, the WG will close. 2. Evaluating a set of candidate proposals that include existing IETF protocols and any proposals leading to the selection of a protocol on which to base the CAPWAP standard. 3. Developing a CAPWAP protocol standard that meets the Mandatory and Accepted objectives from the Evaluation draft and contains the minimal set of feature needed to control and provision WLAN Access Points. Specifically The CAPWAP protocol document will address the following considerations: a. Architecture b. Operations c. Security d. Network Management e. Scalability f. Performance 4. A MIB Document to support the CAPWAP protocol. In addition, the CAPWAP WG will maintain its Liaison with the IEEE to ensure consistency of its work with the IEEE 802.11 Standard. Deliverables: * Objectives/Criteria Document for CAPWAP protocol * Protocol evaluation and base protocol selection document * CAPWAP Protocol standard * MIB support standard Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- May 2008 May 2009 CAPWAP Protocol Base MIB Jun 2008 May 2009 CAPWAP Protocol Binding MIB for IEEE 802.11 Diameter Maintenance and Extensions (dime) ------------------------------------------ Charter Last Modified: 2009-06-10 Current Status: Active Working Group Chair(s): Hannes Tschofenig Victor Fajardo Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion:dime@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dime Archive: http://www.ietf.org/mail-archive/web/dime/current/maillist.html Description of Working Group: The Diameter Maintanence and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use in applications such as IP telephony and Local Area Network authentication, authorization and accounting. The IETF has recently completed work on the Diameter Base protocol. There is on-going work on defining RADIUS extensions. The work done in the DiME WG will ensure that work done in RADext is also available for Diameter. The immediate goals of the DiME working group are to address the following issues: - Maintaining and/or progressing, along the standards track, the Diameter procotol and Diameter Applications. Every revised document to be "maintained" requires explicit approval before it will be accepted as a WG document. - An informational RFC on a Diameter API. - Diameter Application design guidelines. This document will provide guidelines for design of new Diameter Applications. It will detail when to consider reusing an existing application and when to develop a new application. Interaction between vendor & SDO specific extensions and applications will be covered. - Diameter QoS application. This document will develop a new Diameter application for supporting QoS in AAA deployments. The NSIS WG will be consulted on proper design of QoS attributes. - Diameter URI. RFC 3588 defines an AAA URI which has some known problems. A document revising the AAA URI as a specific Diameter URI will be developed. - Diameter extensions for MIPv6. This may include support for Mobile IP extensions, like FMIP; as well as support for MIP bootstrapping. Additionally, AAA systems require interoperability in order to work. Uncontrolled extensibility is not a mechanism for interoperability. Therefore, the working group, along with the AD, will need to evaluate any potential extensions and require verification that the proposed extension is needed. Coordination with other IETF working groups and other SDOs will used to ensure this. Description of Working Group: The Diameter Maintanence and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use in applications such as IP telephony and Local Area Network authentication, authorization and accounting. The IETF has recently completed work on the Diameter Base protocol. There is on-going work on defining RADIUS extensions. The work done in the DiME WG will ensure that work done in RADext is also available for Diameter. The immediate goals of the DiME working group are to address the following issues: - Maintaining and/or progressing, along the standards track, the Diameter procotol and Diameter Applications. Every revised document to be "maintained" requires explicit approval before it will be accepted as a WG document. - An informational RFC on a Diameter API. - Diameter Application design guidelines. This document will provide guidelines for design of new Diameter Applications. It will detail when to consider reusing an existing application and when to develop a new application. Interaction between vendor & SDO specific extensions and applications will be covered. - Diameter QoS application. This document will develop a new Diameter application for supporting QoS in AAA deployments. The NSIS WG will be consulted on proper design of QoS attributes. - Diameter URI. RFC 3588 defines an AAA URI which has some known problems. A document revising the AAA URI as a specific Diameter URI will be developed. - Diameter extensions for MIPv6. This may include support for Mobile IP extensions, like FMIP; as well as support for MIP bootstrapping. Additionally, AAA systems require interoperability in order to work. Uncontrolled extensibility is not a mechanism for interoperability. Therefore, the working group, along with the AD, will need to evaluate any potential extensions and require verification that the proposed extension is needed. Coordination with other IETF working groups and other SDOs will used to ensure this. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Mar 2006 Apr 2009 The Diameter API Jun 2006 Apr 2009 Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction Dec 2006 May 2009 Diameter Base Protocol Feb 2007 May 2009 Diameter Quality of Service Application Jun 2007 May 2009 Quality of Service Parameters for Usage with Diameter Jul 2007 Jun 2009 Quality of Service Attributes for Diameter Jan 2009 May 2009 Diameter User-Name and Realm Based Request Routing Clarifications Jan 2009 Apr 2009 Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server Jan 2009 Jan 2009 Diameter Support for EAP Re-authentication Protocol May 2009 Jul 2009 Diameter Credit Control Application MIB May 2009 Jul 2009 Diameter Base Protocol MIB Jun 2009 Jun 2009 Updated IANA Considerations for Diameter Command Code Allocations Domain Name System Operations (dnsop) ------------------------------------- Charter Last Modified: 2008-12-16 Current Status: Active Working Group Chair(s): Peter Koch Rob Austein Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Ronald Bonica Mailing Lists: General Discussion:dnsop@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/dnsop Archive: http://www.ietf.org/mail-archive/web/dnsop Description of Working Group: The DNS Operations Working Group will develop guidelines for the operation of DNS software servers and the administration of DNS zone files. These guidelines will provide technical information relating to the implementation of the DNS protocol by the operators and administrators of DNS zones. The group will perform the following activities: 1. Define the processes by which Domain Name System (DNS) software may be efficiently and correctly administered, configured, and operated on Internet networks. This will include root zone name servers, gTLD name servers, name servers for other DNS zones, iterative DNS resolvers, and recursive DNS resolvers. As part of this effort, the group will produce documents explaining to the general Internet community what processes and mechanisms should be employed for the effective management and operation of DNS software. 2. Publish documents concerning DNSSEC operational procedures. 3. Publish documents concerning the IPv6 DNS operational procedures and DNS-related IPv6 transition and coexistence issues. 4. Publish documents concerning the operations of the root and TLD services, and DNS resolvers. 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. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jun 2006 Feb 2009 Locally-served DNS Zones Feb 2007 Mar 2009 I'm Being Attacked by PRISONER.IANA.ORG! Feb 2007 Mar 2009 AS112 Nameserver Operations Feb 2008 Mar 2009 DNSSEC Trust Anchor Configuration and Maintenance Aug 2008 May 2009 Requirements for Management of Name Servers for the DNS Mar 2009 Mar 2009 DNSSEC Operational Practices, Version 2 Global Routing Operations (grow) -------------------------------- Charter Last Modified: 2008-12-16 Current Status: Active Working Group Chair(s): Peter Schoenmaker Christopher Morrow Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Ronald Bonica Technical Advisor(s): Bill Fenner Vijay Gill Mailing Lists: General Discussion:grow@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/grow Archive: http://www.ietf.org/mail-archive/web/grow Description of Working Group: The Border Gateway Protocol (BGP) is fundamental to the operation of the Internet. In recent years, occurrences of BGP related operational issues have increased, and while overall understanding of the default-free routing system has improved, there is still a long and growing list of concerns. Among these are routing table growth rates, interaction of interior and exterior routing protocols, dynamic properties of the routing system, and the effects of routing policy on both the size and dynamic nature of the routing table. In addition, new and innovative uses of BGP, such as the use of BGP as a signaling protocol for some types of Virtual Private Networks, have created new and unexpected operational issues. The purpose of the GROW is to consider the operational problems associated with the IPv4 and IPv6 global routing systems, including but not limited to routing table growth, the effects of the interactions between interior and exterior routing protocols, and the effect of address allocation policies and practices on the global routing system. Finally, where appropriate, the GROW documents the operational aspects of measurement, policy, security, and VPN infrastructures. GROW will also advise various working groups, including the IDR and RPSEC working groups, with respect to whether it is addressing the relevant operational needs, and where appropriate, suggest course corrections. Finally, operational requirements developed in GROW can also be used by any new working group charged with standardizing a next generation inter-domain routing protocol. GOALS: ----- (i). Evaluate and develop various methodologies of controlling policy information in order to reduce the effect of prefix sub-aggregates beyond the necessary diameter, so as to reduce the Network Layer Reachability Information (or NLRI; see e.g.,draft-ietf-idr-bgp4-23.txt) load on network infrastructure. (ii). Document and suggest operational solutions to problematic aspects of the currently deployed routing system. Examples include instability caused by oscillation of MULTI_EXIT_DISC (or MED; see RFC 3345) values. (iii). Analyze aspects of supporting new applications, including extending existing routing protocols and creating new ones. This includes risk, interference and application fit. (iv). Determine the effect of IGP extensions on the stability of the Internet routing system. (v). Document the operational aspects of securing the Internet routing system, and provide recommendations to other WGs. Some Relevant References: ------------------------- http://www.routeviews.org http://bgp.potaroo.net http://www.cidr-report.org http://www.pch.net/routing/BGP_table_size.ital http://moat.nlanr.net/AS http://www.apnic.net/stats/bgp http://www.merit.edu/ipma http://www.caida.org/projects/routing/atoms 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 Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jul 2005 Feb 2009 MRT routing information export format Nov 2008 Apr 2009 BGP Monitoring Protocol Mar 2009 Mar 2009 Routing System Stability May 2009 May 2009 MPLS Tunnels for Virtual Aggregation May 2009 May 2009 FIB Suppression with Virtual Aggregation Jun 2009 Jun 2009 Requirements for the graceful shutdown of BGP sessions Jun 2009 Jun 2009 Graceful BGP session shutdown IP Flow Information Export (ipfix) ---------------------------------- Charter Last Modified: 2009-03-10 Current Status: Active Working Group Chair(s): Nevil Brownlee Juergen Quittek Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion:ipfix@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/ipfix Archive: http://www.ietf.org/mail-archive/web/ipfix Description of Working Group: The IPFIX working group has specified the Information Model (to describe IP flows) and the IPFIX protocol (to transfer IP flow data from IPFIX exporters to collectors). Several implementers have already built applications using the IPFIX protocol. As a result of a series of IPFIX interoperability testing events the WG has produced guidelines for IPFIX implementation and testing as well as recommendations for handling special cases such as bidirectional flow reporting and reducing redundancy in flow records. Practical experiences with IPFIX implementations exposed new requirements for the IPFIX protocol that so far have not been addressed by the WG. The major current goal of the WG is developing solutions that meet the new requirements without modifying the core IPFIX protocol specifications. 1. The IPFIX WG has developed a MIB module for monitoring IPFIX implementations. Means for configuring these devices have not been standardized yet. The WG will develop an XML-based configuration data model that can be used for configuring IPFIX devices and for storing, modifying and managing IPFIX configurations parameter sets. This work will be performed in close collaboration with the NETCONF WG. 2. There is a need for storing measured flow information and for exchanging this information between different systems and organizations. The WG will develop a common IPFIX file format for storing flow data in order to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools. It will be a flat-file format using binary encodings that are based on the IPFIX message format. 3. When dealing with enterprise-specific information elements in IPFIX flow records, it often occurs that the receiver of the record does not know the definition of the information element. For processing such information elements it would be desirable for the receiver to know at least the data types of the enterprise-specific information elements. The WG will develop an extension to IPFIX that provides means for the encoding of IPFIX data type information within an IPFIX Message stream. 4. Another requirement resulting from practical use of IPFIX is reporting IPFIX template records and corresponding data records within the same SCTP stream. The IPFIX WG will develop guidelines for this use case. 5. First applications of IPFIX at large operator networks showed the need for mediation of flow information, for example, for aggregating huge amounts of flow data and for anomymization of flow information. The IPFIX WG will investigate this issue and produce a problem statement and a framework for IPFIX flow mediation. Description of Working Group: The IPFIX working group has specified the Information Model (to describe IP flows) and the IPFIX protocol (to transfer IP flow data from IPFIX exporters to collectors). Several implementers have already built applications using the IPFIX protocol. As a result of a series of IPFIX interoperability testing events the WG has produced guidelines for IPFIX implementation and testing as well as recommendations for handling special cases such as bidirectional flow reporting and reducing redundancy in flow records. Practical experiences with IPFIX implementations exposed new requirements for the IPFIX protocol that so far have not been addressed by the WG. The major current goal of the WG is developing solutions that meet the new requirements without modifying the core IPFIX protocol specifications. 1. The IPFIX WG has developed a MIB module for monitoring IPFIX implementations. Means for configuring these devices have not been standardized yet. The WG will develop an XML-based configuration data model that can be used for configuring IPFIX devices and for storing, modifying and managing IPFIX configurations parameter sets. This work will be performed in close collaboration with the NETCONF WG. 2. There is a need for storing measured flow information and for exchanging this information between different systems and organizations. The WG will develop a common IPFIX file format for storing flow data in order to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools. It will be a flat-file format using binary encodings that are based on the IPFIX message format. 3. When dealing with enterprise-specific information elements in IPFIX flow records, it often occurs that the receiver of the record does not know the definition of the information element. For processing such information elements it would be desirable for the receiver to know at least the data types of the enterprise-specific information elements. The WG will develop an extension to IPFIX that provides means for the encoding of IPFIX data type information within an IPFIX Message stream. 4. Another requirement resulting from practical use of IPFIX is reporting IPFIX template records and corresponding data records within the same SCTP stream. The IPFIX WG will develop guidelines for this use case. 5. First applications of IPFIX at large operator networks showed the need for mediation of flow information, for example, for aggregating huge amounts of flow data and for anomymization of flow information. The IPFIX WG will investigate this issue and produce a problem statement and a framework for IPFIX flow mediation. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2007 Mar 2009 Definitions of Managed Objects for IP Flow Information Export Jan 2008 Oct 2008 Specification of the IPFIX File Format Jan 2008 Jun 2009 Exporting Type Information for IPFIX Information Elements May 2008 Apr 2009 IPFIX Mediation: Problem Statement Jun 2008 Feb 2009 IPFIX Mediation: Framework Jul 2008 Jan 2009 IPFIX Export per SCTP Stream Jul 2008 Mar 2009 Configuration Data Model for IPFIX and PSAMP IPv6 Operations (v6ops) ----------------------- Charter Last Modified: 2008-08-21 Current Status: Active Working Group Chair(s): Fred Baker Kurt Lindqvist Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Ronald Bonica Mailing Lists: General Discussion:v6ops@ops.ietf.org To Subscribe: majordomo@ops.ietf.org In Body: subscribe v6ops Archive: http://ops.ietf.org/lists/v6ops/ Description of Working Group: The global deployment of IPv6 is underway, creating an IPv4/IPv6 Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and nodes. This deployment must be properly handled to avoid the division of the Internet into separate IPv4 and IPv6 networks while ensuring addressing and connectivity for all IPv4 and IPv6 nodes. The IPv6 Operations Working Group (v6ops) develops guidelines for the operation of a shared IPv4/IPv6 Internet and provides operational guidance on how to deploy IPv6 into existing IPv4-only networks, as well as into new network installations. The main focus of the v6ops WG is to look at the immediate deployment issues; more advanced stages of deployment and transition are a lower priority. The goals of the v6ops working group are: 1. Solicit input from network operators and users to identify operational issues with the IPv4/IPv6 Internet, and determine solutions or workarounds to those issues. These issues will be documented in Informational or BCP RFCs, or in Internet-Drafts. This work should primarily be conducted by those areas and WGs which are responsible and best fit to analyze these problems, but v6ops may also cooperate in focusing such work. 2. Publish Informational or BCP RFCs that identify potential security risks in the operation of shared IPv4/IPv6 networks, and document operational practices to eliminate or mitigate those risks. This work will be done in cooperation with the Security area and other relevant areas or working groups. 3. As a particular instance of (1) and (2), provide feedback to the IPv6 WG regarding portions of the IPv6 specifications that cause, or are likely to cause, operational or security concerns, and work with the IPv6 WG to resolve those concerns. This feedback will be published in Internet-Drafts or RFCs. 4. Publish Informational or BCP RFCs that identify and analyze solutions for deploying IPv6 within common network environments, such as ISP Networks, Enterprise Networks, Unmanaged Networks (Home/Small Office), and Cellular Networks. These documents should serve as useful guides to network operators and users on possible ways how to deploy IPv6 within their existing IPv4 networks, as well as in new network installations. These documents should not be normative guides for IPv6 deployment, and the primary intent is not capture the needs for new solutions, but rather describe which approaches work and which do not. IPv6 operational and deployment issues with specific protocols or technologies (such as Applications, Transport Protocols, Routing Protocols, DNS or Sub-IP Protocols) are the primary responsibility of the groups or areas responsible for those protocols or technologies. However, the v6ops WG may provide input to those areas/groups, as needed, and cooperate with those areas/groups in reviewing solutions to IPv6 operational and deployment problems. Future work items within this scope will be adopted by the WG only if there is a substantial expression of interest from the community and if the work clearly does not fit elsewhere in the IETF. There must be a continuous expression of interest for the WG to work on a particular work item. If there is no longer sufficient interest in the WG in a work item, the item may be removed from the list of WG items. Specifying any protocols or transition mechanisms is out of scope of the WG. 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. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jun 2007 Jun 2009 Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service Jun 2008 May 2009 IPv6 RA-Guard Mar 2009 Mar 2009 IPv6 CPE Router Recommendations May 2009 May 2009 Rogue IPv6 Router Advertisement Problem Statement Jun 2009 Jul 2009 IPv6 Deployment in Internet Exchange Points (IXPs) MBONE Deployment (mboned) ------------------------- Charter Last Modified: 2009-01-28 Current Status: Active Working Group Chair(s): Marshall Eubanks Greg Shepherd Leonard Giuliano Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Ronald Bonica Technical Advisor(s): 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. 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. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jul 2002 Mar 2009 Unicast-Prefix-based IPv4 Multicast Addresses Nov 2003 Apr 2009 IANA Guidelines for IPv4 Multicast Address Assignments Apr 2005 Jan 2009 Requirements for Multicast AAA coordinated between Content Provider(s) and Network Service Provider(s) Apr 2006 Jan 2009 AAA and Admission Control Framework for Multicasting Dec 2006 May 2009 Lightweight IGMPv3 and MLDv2 Protocols Nov 2007 Mar 2009 Mtrace Version 2: Traceroute Facility for IP Multicast Oct 2008 Mar 2009 Requirements for IP Multicast Session Announcement in the Internet NETCONF Data Modeling Language (netmod) --------------------------------------- Charter Last Modified: 2009-05-06 Current Status: Active Working Group Chair(s): David Partain David Kessens Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion:netmod@ietf.org To Subscribe: netmod-request@ietf.org In Body: In msg body: subscribe Archive: http://www.ietf.org/mail-archive/web/netmod/ Description of Working Group: The NETCONF Working Group has completed a base protocol to be used for configuration management. However, the NETCONF protocol does not include a standard content layer. The specifications do not include a modeling language or accompanying rules that can be used to model the management information that is to be configured using NETCONF. This has resulted in inconsistent syntax and interoperability problems. The purpose of NETMOD is to support the ongoing development of IETF and vendor-defined data models for NETCONF. NETMOD's requirements are drawn from the RCDML requirements draft (draft-presuhn-rcdml) and documents referenced therein. The WG will define a "human-friendly" modeling language defining the semantics of operational data, configuration data, notifications, and operations. This language will focus on readability and ease of use. This language must be able to serve as the normative description of NETCONF data models. The WG will use YANG (draft-bjorklund-yang) as its starting point for this language. Language abstractions that facilitate model extensibility and reuse have been identified as a work area and will be considered as a work item or may be integrated into the YANG document based on WG consensus. The WG will define a canonical mapping of this language to NETCONF XML instance documents, the on-the-wire format of YANG-defined XML content. Only data models defined in YANG will have to adhere to this on-the-wire format. In order to leverage existing XML tools for validating NETCONF data in various contexts and also facilitate exchange of data models and schemas with other IETF working groups, the WG will define standard mapping rules from YANG to the DSDL data modeling framework (ISO/IEC 19757) with additional annotations to preserve semantics. The initial YANG mapping rules specifications are expressly defined for NETCONF modeling. However, there may be future areas of applicability beyond NETCONF, and the WG must provide suitable language extensibility mechanisms to allow for such future work. The NETMOD WG will only address modeling NETCONF devices and the language extensibility mechanisms. Any application of YANG to other protocols is future work. The WG will consult with the NETCONF WG to ensure that NETMOD's decision do not conflict with planned work in NETCONF (e.g., locking, notifications). While it is desirable to provide a migration path from existing MIB modules to YANG data models (modules), it is not a requirement to provide full compatibility between SMIv2 and YANG. The Working Group will determine which constructs (e.g., conformance statements) are not relevant for translation from SMIv2 to YANG. YANG is also permitted to introduce constructs that cannot be expressed in SMIv2. However, all basic types that can be represented in SMIv2 must be expressible in YANG. Initial deliverables are below. The working group may choose to combine multiple deliverables into a single document where deemed appropriate. 1. An architecture document explaining the relationship between YANG and its inputs and outputs. (informational) 2. The YANG data modeling language and semantics (proposed standard) 3. Mapping rules of YANG to XML instance data in NETCONF (proposed standard) 4. YIN, a semantically equivalent fully reversible mapping to an XML-based syntax for YANG. YIN is simply the data model in an XML syntax that can be manipulated using existing XML tools (e.g., XSLT) (proposed standard) 5. Mapping rules of YANG to DSDL data modeling framework (ISO/IEC 19757), including annotations for DSDL to preserve top-level semantics during translation (proposed standard). 6. A standard type library for use by YANG (proposed standard) Description of Working Group: The NETCONF Working Group has completed a base protocol to be used for configuration management. However, the NETCONF protocol does not include a standard content layer. The specifications do not include a modeling language or accompanying rules that can be used to model the management information that is to be configured using NETCONF. This has resulted in inconsistent syntax and interoperability problems. The purpose of NETMOD is to support the ongoing development of IETF and vendor-defined data models for NETCONF. NETMOD's requirements are drawn from the RCDML requirements draft (draft-presuhn-rcdml) and documents referenced therein. The WG will define a "human-friendly" modeling language defining the semantics of operational data, configuration data, notifications, and operations. This language will focus on readability and ease of use. This language must be able to serve as the normative description of NETCONF data models. The WG will use YANG (draft-bjorklund-yang) as its starting point for this language. Language abstractions that facilitate model extensibility and reuse have been identified as a work area and will be considered as a work item or may be integrated into the YANG document based on WG consensus. The WG will define a canonical mapping of this language to NETCONF XML instance documents, the on-the-wire format of YANG-defined XML content. Only data models defined in YANG will have to adhere to this on-the-wire format. In order to leverage existing XML tools for validating NETCONF data in various contexts and also facilitate exchange of data models and schemas with other IETF working groups, the WG will define standard mapping rules from YANG to the DSDL data modeling framework (ISO/IEC 19757) with additional annotations to preserve semantics. The initial YANG mapping rules specifications are expressly defined for NETCONF modeling. However, there may be future areas of applicability beyond NETCONF, and the WG must provide suitable language extensibility mechanisms to allow for such future work. The NETMOD WG will only address modeling NETCONF devices and the language extensibility mechanisms. Any application of YANG to other protocols is future work. The WG will consult with the NETCONF WG to ensure that NETMOD's decision do not conflict with planned work in NETCONF (e.g., locking, notifications). While it is desirable to provide a migration path from existing MIB modules to YANG data models (modules), it is not a requirement to provide full compatibility between SMIv2 and YANG. The Working Group will determine which constructs (e.g., conformance statements) are not relevant for translation from SMIv2 to YANG. YANG is also permitted to introduce constructs that cannot be expressed in SMIv2. However, all basic types that can be represented in SMIv2 must be expressible in YANG. Initial deliverables are below. The working group may choose to combine multiple deliverables into a single document where deemed appropriate. 1. An architecture document explaining the relationship between YANG and its inputs and outputs. (informational) 2. The YANG data modeling language and semantics (proposed standard) 3. Mapping rules of YANG to XML instance data in NETCONF (proposed standard) 4. YIN, a semantically equivalent fully reversible mapping to an XML-based syntax for YANG. YIN is simply the data model in an XML syntax that can be manipulated using existing XML tools (e.g., XSLT) (proposed standard) 5. Mapping rules of YANG to DSDL data modeling framework (ISO/IEC 19757), including annotations for DSDL to preserve top-level semantics during translation (proposed standard). 6. A standard type library for use by YANG (proposed standard) Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- May 2008 Jun 2009 YANG - A data modeling language for NETCONF Sep 2008 May 2009 Common YANG Data Types Feb 2009 Apr 2009 Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content Mar 2009 May 2009 An NETCONF- and NETMOD-based Architecture for Network Management May 2009 May 2009 Guidelines for Authors and Reviewers of YANG Data Model Documents Network Configuration (netconf) ------------------------------- Charter Last Modified: 2009-02-03 Current Status: Active Working Group Chair(s): Bert Wijnen Mehmet Ersue Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Technical Advisor(s): Charlie Kaufman Mailing Lists: General Discussion:netconf@ietf.org To Subscribe: netconf-request@ietf.org In Body: in msg body: subscribe Archive: http://www.ietf.org/mail-archive/web/netconf/ Description of Working Group: Charlie Kaufman is Technical Advisor for Security Matters Configuration of networks of devices has become a critical requirement for operators in today's highly interoperable networks. Operators from large to small have developed their own mechanisms or used vendor specific mechanisms to transfer configuration data to and from a device, and for examining device state information which may impact the configuration. Each of these mechanisms may be different in various aspects, such as session establishment, user authentication, configuration data exchange, and error responses. The NETCONF Working Group is chartered to produce a protocol suitable for network configuration, with the following characteristics: - Provides retrieval mechanisms which can differentiate between configuration data and non-configuration data - Is extensible enough so that vendors will provide access to all configuration data on the device using a single protocol - Has a programmatic interface (avoids screen scraping and formatting-related changes between releases) - Uses a textual data representation, that can be easily manipulated using non-specialized text manipulation tools. - Supports integration with existing user authentication methods - Supports integration with existing configuration database systems - Supports network wide configuration transactions (with features such as locking and rollback capability) - Is as transport-independent as possible - Provides support for asynchronous notifications. The NETCONF protocol is using XML for data encoding purposes, because XML is a widely deployed standard which is supported by a large number of applications. The NETCONF protocol should be independent of the data definition language and data models used to describe configuration and state data. However, the authorization model used in the protocol is dependent on the data model. Although these issues must be fully addressed to develop standard data models, only a small part of this work will be initially addressed. This group will specify requirements for standard data models in order to fully support the NETCONF protocol, such as: - identification of principals, such as user names or distinguished names - mechanism to distinguish configuration from non-configuration data - XML namespace conventions - XML usage guidelines The initial work started in 2003 and has already been completed and was restricted to following items: a) NETCONF Protocol Specification, which defines the operational model, protocol operations, transaction model, data model requirements, security requirements, and transport layer requirements. b) NETCONF over SSH Specification: Implementation Mandatory, c) NETCONF over BEEP Specification: Implementation Optional, d) NETCONF over SOAP Specification: Implementation Optional. These documents define how the NETCONF protocol is used with each transport protocol selected by the working group, and how it meets the security and transport layer requirements of the NETCONF Protocol Specification. e) NETCONF Notification Specification, which defines mechanisms that provide an asynchronous message notification delivery service for the NETCONF protocol. NETCONF Notification is an optional capability built on top of the base NETCONF definition and provides the capabilities and operations necessary to support this service. The NETCONF notification specification has been finished now as well. In the current phase of the incremental development of NETCONF the workgroup will focus on following items: 1. Fine-grain locking: The base NETCONF protocol only provides a lock for the entire configuration datastore, which is not deemed to meet important operational and security requirements. The NETCONF working group will produce a standards-track RFC specifying a mechanism for fine-grain locking of the NETCONF configuration datastore. 2. NETCONF monitoring: It is considered best practice for IETF working groups to include management of their protocols within the scope of the solution they are providing. The NETCONF working group will produce a standards-track RFC with mechanisms allowing NETCONF itself to be used to monitor some aspects of NETCONF operation. 3. Schema advertisement: Currently the NETCONF protocol is able to advertise which protocol features are supported on a particular netconf-capable device. However, there is currently no way to discover which XML Schema are supported on the device. The NETCONF working group will produce a standards-track RFC with mechanisms making this discovery possible (this item may be merged with "NETCONF monitoring" into a single document). Note: The schema-advertisement material has been merged into the NETCONF monitoring document based on WG consensus. 4. NETCONF over TLS: Based on implementation experience there is a need for a standards track document to define NETCONF over TLS as an optional transport for the NETCONF protocol. 5. NETCONF default handling: NETCONF today does not define whether default values should be returned by the server in replies to requests for reading configuration and state data. Different clients have different needs to receive or not to receive default data. The NETCONF working group will produce a standards-track RFC defining a mechanism that allows NETCONF clients to control whether default data is returned by the netconf server. 6. NETCONF implementations have shown that the specification in RFC4741 is not 100% clear and has lead to different interpretations and implementations. Also some errors have been uncovered. So the WG will do an rfc4741bis with following constraints: - bug fixes are to be done - clarifications can be done - extensions can be done only when needed to fix bugs or inconsistencies (i.e. we are not doing a NETCONF V2) - The work can be started based on the discussion in IETF #73 (see http://www.ietf.org/proceedings/08nov/slides/netconf-3.pdf). Note: A technical errata has been posted on rfc4742. If the work on rfc4741bis uncovers any additional fixes/clarifications that need to be made to rfc4742, the WG may consider to also do a rfc4742bis as part of this work-item. The following items have been identified as important but are currently not considered in scope for re-chartering and may be candidates for work when there is community consensus to take them on: - NETCONF Notification content - Access Control requirements - NETCONF access to SMI-based MIB data Description of Working Group: Charlie Kaufman is Technical Advisor for Security Matters Configuration of networks of devices has become a critical requirement for operators in today's highly interoperable networks. Operators from large to small have developed their own mechanisms or used vendor specific mechanisms to transfer configuration data to and from a device, and for examining device state information which may impact the configuration. Each of these mechanisms may be different in various aspects, such as session establishment, user authentication, configuration data exchange, and error responses. The NETCONF Working Group is chartered to produce a protocol suitable for network configuration, with the following characteristics: - Provides retrieval mechanisms which can differentiate between configuration data and non-configuration data - Is extensible enough so that vendors will provide access to all configuration data on the device using a single protocol - Has a programmatic interface (avoids screen scraping and formatting-related changes between releases) - Uses a textual data representation, that can be easily manipulated using non-specialized text manipulation tools. - Supports integration with existing user authentication methods - Supports integration with existing configuration database systems - Supports network wide configuration transactions (with features such as locking and rollback capability) - Is as transport-independent as possible - Provides support for asynchronous notifications. The NETCONF protocol is using XML for data encoding purposes, because XML is a widely deployed standard which is supported by a large number of applications. The NETCONF protocol should be independent of the data definition language and data models used to describe configuration and state data. However, the authorization model used in the protocol is dependent on the data model. Although these issues must be fully addressed to develop standard data models, only a small part of this work will be initially addressed. This group will specify requirements for standard data models in order to fully support the NETCONF protocol, such as: - identification of principals, such as user names or distinguished names - mechanism to distinguish configuration from non-configuration data - XML namespace conventions - XML usage guidelines The initial work started in 2003 and has already been completed and was restricted to following items: a) NETCONF Protocol Specification, which defines the operational model, protocol operations, transaction model, data model requirements, security requirements, and transport layer requirements. b) NETCONF over SSH Specification: Implementation Mandatory, c) NETCONF over BEEP Specification: Implementation Optional, d) NETCONF over SOAP Specification: Implementation Optional. These documents define how the NETCONF protocol is used with each transport protocol selected by the working group, and how it meets the security and transport layer requirements of the NETCONF Protocol Specification. e) NETCONF Notification Specification, which defines mechanisms that provide an asynchronous message notification delivery service for the NETCONF protocol. NETCONF Notification is an optional capability built on top of the base NETCONF definition and provides the capabilities and operations necessary to support this service. The NETCONF notification specification has been finished now as well. In the current phase of the incremental development of NETCONF the workgroup will focus on following items: 1. Fine-grain locking: The base NETCONF protocol only provides a lock for the entire configuration datastore, which is not deemed to meet important operational and security requirements. The NETCONF working group will produce a standards-track RFC specifying a mechanism for fine-grain locking of the NETCONF configuration datastore. 2. NETCONF monitoring: It is considered best practice for IETF working groups to include management of their protocols within the scope of the solution they are providing. The NETCONF working group will produce a standards-track RFC with mechanisms allowing NETCONF itself to be used to monitor some aspects of NETCONF operation. 3. Schema advertisement: Currently the NETCONF protocol is able to advertise which protocol features are supported on a particular netconf-capable device. However, there is currently no way to discover which XML Schema are supported on the device. The NETCONF working group will produce a standards-track RFC with mechanisms making this discovery possible (this item may be merged with "NETCONF monitoring" into a single document). Note: The schema-advertisement material has been merged into the NETCONF monitoring document based on WG consensus. 4. NETCONF over TLS: Based on implementation experience there is a need for a standards track document to define NETCONF over TLS as an optional transport for the NETCONF protocol. 5. NETCONF default handling: NETCONF today does not define whether default values should be returned by the server in replies to requests for reading configuration and state data. Different clients have different needs to receive or not to receive default data. The NETCONF working group will produce a standards-track RFC defining a mechanism that allows NETCONF clients to control whether default data is returned by the netconf server. 6. NETCONF implementations have shown that the specification in RFC4741 is not 100% clear and has lead to different interpretations and implementations. Also some errors have been uncovered. So the WG will do an rfc4741bis with following constraints: - bug fixes are to be done - clarifications can be done - extensions can be done only when needed to fix bugs or inconsistencies (i.e. we are not doing a NETCONF V2) - The work can be started based on the discussion in IETF #73 (see http://www.ietf.org/proceedings/08nov/slides/netconf-3.pdf). Note: A technical errata has been posted on rfc4742. If the work on rfc4741bis uncovers any additional fixes/clarifications that need to be made to rfc4742, the WG may consider to also do a rfc4742bis as part of this work-item. The following items have been identified as important but are currently not considered in scope for re-chartering and may be candidates for work when there is community consensus to take them on: - NETCONF Notification content - Access Control requirements - NETCONF access to SMI-based MIB data Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jan 2008 Jul 2009 Partial Lock RPC for NETCONF Jan 2008 Jun 2009 NETCONF Monitoring Schema Feb 2009 Jul 2009 With-defaults capability for NETCONF Mar 2009 Mar 2009 NETCONF Configuration Protocol Operational Security Capabilities for IP Network Infrastructure (opsec) ----------------------------------------------------------------------- Charter Last Modified: 2009-04-20 Current Status: Active Working Group Chair(s): Joe Abley Joel Jaeggli Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Ronald Bonica Mailing Lists: General Discussion:opsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/opsec In Body: In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/opsec/current/maillist.html Description of Working Group: Goals: The OPSEC WG will document best current practices with regard to network security. In particular an effort will be made to clarify the rationale supporting current operational practice, address gaps in currently understood best practices for forwarding, control plane, and management plane security and make clear the liabilities inherent in security practices where they exist. Scope: The scope of the OPSEC WG is intended to include the protection and secure operation of the forwarding, control and management planes. Documentation of best common practices, revision of existing operational security practices documents and proposals for new approaches to operational challenges are in scope. Method: It is expected that the work product of the working group will fall into the category of best current practices documents. Taxonomy or problem statement documents may provide a basis for best current practices documents. Best Current Practices Document For each topic addressed, a document will be produced that attempts to capture current practices related to secure operation. This will be primarily based on operational experience. Each entry will list: * threats addressed, * current practices for addressing the threat, * protocols, tools and technologies extant at the time of writing that are used to address the threat, * the possibility that a solution does not exist within existing tools or technologies. Taxonomy and Problem Statement Documents A document which attempts to describe the scope of particular operational security challenge or problem space without necessarily coming to a conclusion or proposing a solution. Such a document might be a precursor to a best common practices document. While the principal input of the Working Group are operational experience and needs, the output should be directed both to provide guidance to the operators community as well as to Working Groups that develop protocols or the community of protocol developers at large, as well as to the implementers of these protocols. Non-Goals: The Operations security working group is not the place to do new protocols. New protocol work should be addressed in a working group chartered in the appropriate area or as individual submissions. The OPSEC WG may take on documents related to the practices of using such work. 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. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jan 2005 Apr 2009 Security Best Practices Efforts and Documents Jan 2009 Jun 2009 Remote Triggered Black Hole filtering with uRPF Jan 2009 Jan 2009 Security Assessment of the Internet Protocol version 4 Operations and Management Area Working Group (opsawg) ----------------------------------------------------- Charter Last Modified: 2009-05-26 Current Status: Active Working Group Chair(s): Scott Bradner Ted Seely Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion:opsawg@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/opsawg Archive: http://www.ietf.org/mail-archive/web/opsawg Description of Working Group: The Operations and Management Area receives occasional proposals for the development and publication of RFCs dealing with operational and management topics that are not in scope of an existing working group and do not justify the formation of a new working group. The OPSAWG will serve as the forum for developing such work items in the IETF. The OPSAWG mailing list is an open discussion forum for such work items, when they arise. The working group meets if there are active proposals that require discussion. The working group milestones are updated as needed to reflect the current work items and their associated milestones. All new work items and rechartering proposals will be brought for approval with the IESG. The focus of the work will be on topics that govern the behavior or WGs in the O&M area (e.g., manageability requirements) and on small, highly focused projects that don't merit a WG of their own or belong to WGs that have already concluded (e.g. advancement of documents on the standards track, application statements, extensions of MIB modules). The OPSAWG will undertake only work items that are proved to have at least a reasonable level of interest from the operators and users community and have a committed number of editors and reviewers. It is not within the scope of the OPSAWG to pick up failed WG work or parts of a WG charter items that could not come to convergence on what they were chartered to do. The currently active OPSAWG work items mostly fall under the following topics: (A) Development of a BCP document that will provide guidelines for authors and a reference for reviewers of IETF documents that specify new protocols or protocol extensions about the information about operational and manageability requirements that needs to be covered in these documents (B) Templates and tools for Operations and Management Area Documents (C) Maintenance and small scale extensions of documents that were developed in working groups that have concluded (e.g. MIB modules). 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). Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Sep 2007 Jun 2009 Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions Feb 2008 Mar 2009 Expressing SNMP SMI Datatypes in XML Schema Definition Language Jun 2008 May 2009 Alarms in SYSLOG Feb 2009 May 2009 Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications Feb 2009 May 2009 Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages Mar 2009 Mar 2009 Survey of IETF Network Management Standards Packet Sampling (psamp) ----------------------- Charter Last Modified: 2008-11-21 Current Status: Active Working Group Chair(s): Juergen Quittek Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion:psamp@ietf.org To Subscribe: psamp-request@ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/psamp/index.html Description of Working Group: The Packet Sampling working group is chartered to define a standard set of capabilities for network elements to sample subsets of packets by statistical and other methods. The capabilities should be simple enough that they can be implemented ubiquitously at maximal line rate. They should be rich enough to support a range of existing and emerging measurement-based applications, and other IETF working groups where appropriate. The focus of the WG will be to (i) specify a set of selection operations by which packets are sampled (ii) specify the information that is to be made available for reporting on sampled packets; (iii) describe protocols by which information on sampled packets is reported to applications; (iv) describe protocols by which packet selection and reporting configured. Packet reports must be communicable in a timely manner, to applications either on-board of off-board the sampling network element. The streams of packet reports produced by a packet sampling must (i) allow consistent interpretation, independent of the particular network element that produced them; (ii) be self-defining, in that their interpretation does not require additional information to be supplied by the network element; (iii) allow robustness of interpretation with respect to missing reports or part of reports; Network elements shall support multiple parallel packet samplers, each with independently configurable packet selectors, reports, report streams, and export. Network elements must allow easy and secure reconfiguration of these packet samplers by on-board or external applications. Export of a report stream across a network must be congestion avoiding in compliance with RFC 2914. Unreliable transport is permitted because the requirements at the exporter for reliable transport (state maintenance, addressibilty, acknowledgment processing, buffering unacknowledged data) would prevent ubiquitous deployment. Congestion avoidance with unreliable export is to be accomplished by the following measures, which shall be mandatory to implement and use. The maximum export rate of a report stream must be configurable at the exporter. A report stream must contain sufficient information for transmission loss to be detected a collector. Then the collector must run a congestion control algorithm to compute a new sending rate, and reconfigure the exporter with this rate. In order to maintain report collection during periods of congestion, PSAMP report streams may claim more than a fair share of link bandwidth, provided the number of report streams in competition with fair sharing traffic is limited. Selection of the content of packet reports will be cognizant of privacy and anonymity issues while being responsive to the needs of measurement applications, and in accordance with RFC 2804. Re-use of existing protocols will be encouraged provided the protocol capabilities are compatible with PSAMP requirements. Specifically, the PSAMP WG will perform the following tasks, in accordance with the principles stated above: 1. Selectors for packet sampling. Define the set of primitive packet selection operations for network elements, the parameters by which they may be configured, and the ways in which they can be combined. 2. Packet Information. Specify extent of packet that is to be made available for reporting. Target for inclusion the packet's IP header, some subsequent bytes of the packet, and encapsulating headers if present. Full packet capture of arbitrary packet streams is explicitly out of scope. Specify variants for IPv4 and IPv6, extent of IP packet available under encapsulation methods, and under packet encryption. 3. Sampled packet reports. Define the format of the report that is constructed by the network element for each sampled packet for communication to applications. The format shall be sufficiently rich as to allow inclusion in the packet report of (i) IP packet information as specified in paragraph 2 above; (ii) encapsulating packet headers as specified in paragraph 2 above; (iii) interface or channel identifiers associated with transit of the packet across the network element; (iv) quantities computable from packet content and router state, (v) quantities computed during the selection operation. All reported quantities must reflect the router state and configuration encountered by the packet in the network element. 4. Report Streams. Define a format for a stream of packet reports, to include: (i) the format of packet reports in the stream; (ii) the packet reports themselves; (iii) configuration parameters of the selectors of the packets reported on; (iv) configuration parameters and state information of the network element; (v) quantities that enable collectors and applications to infer of attained packet sampling rates, detect loss during samping, report loss in transmission, and correct for information missing from the packet report stream; (vi) indication of the inherent accuracy of the reported quantities, e.g., of timestamps. 5. Multiple Report Streams. Define requirements for multiple parallel packet samplers in one network element, including the allowed degradation of packet reporting when packets are selected by multiple packet samplers. 6. Configuration and Management. Define a packet sampler MIB to reside at the network element, including parameters for packet selection, packet report and stream format, and export. Select or define a communication protocol to configure/read this MIB. 7. Presentation, Export, and Transport of Packet Reports. Define interface for presentation of reports to on-board applications. Select unreliable transport protocol for remote export. Determine rate control algorithms for export. Initial Internet-Draft: A Framework for Passive Packet Measurement [draft-duffield-framework-papame] Description of Working Group: The Packet Sampling working group is chartered to define a standard set of capabilities for network elements to sample subsets of packets by statistical and other methods. The capabilities should be simple enough that they can be implemented ubiquitously at maximal line rate. They should be rich enough to support a range of existing and emerging measurement-based applications, and other IETF working groups where appropriate. The focus of the WG will be to (i) specify a set of selection operations by which packets are sampled (ii) specify the information that is to be made available for reporting on sampled packets; (iii) describe protocols by which information on sampled packets is reported to applications; (iv) describe protocols by which packet selection and reporting configured. Packet reports must be communicable in a timely manner, to applications either on-board of off-board the sampling network element. The streams of packet reports produced by a packet sampling must (i) allow consistent interpretation, independent of the particular network element that produced them; (ii) be self-defining, in that their interpretation does not require additional information to be supplied by the network element; (iii) allow robustness of interpretation with respect to missing reports or part of reports; Network elements shall support multiple parallel packet samplers, each with independently configurable packet selectors, reports, report streams, and export. Network elements must allow easy and secure reconfiguration of these packet samplers by on-board or external applications. Export of a report stream across a network must be congestion avoiding in compliance with RFC 2914. Unreliable transport is permitted because the requirements at the exporter for reliable transport (state maintenance, addressibilty, acknowledgment processing, buffering unacknowledged data) would prevent ubiquitous deployment. Congestion avoidance with unreliable export is to be accomplished by the following measures, which shall be mandatory to implement and use. The maximum export rate of a report stream must be configurable at the exporter. A report stream must contain sufficient information for transmission loss to be detected a collector. Then the collector must run a congestion control algorithm to compute a new sending rate, and reconfigure the exporter with this rate. In order to maintain report collection during periods of congestion, PSAMP report streams may claim more than a fair share of link bandwidth, provided the number of report streams in competition with fair sharing traffic is limited. Selection of the content of packet reports will be cognizant of privacy and anonymity issues while being responsive to the needs of measurement applications, and in accordance with RFC 2804. Re-use of existing protocols will be encouraged provided the protocol capabilities are compatible with PSAMP requirements. Specifically, the PSAMP WG will perform the following tasks, in accordance with the principles stated above: 1. Selectors for packet sampling. Define the set of primitive packet selection operations for network elements, the parameters by which they may be configured, and the ways in which they can be combined. 2. Packet Information. Specify extent of packet that is to be made available for reporting. Target for inclusion the packet's IP header, some subsequent bytes of the packet, and encapsulating headers if present. Full packet capture of arbitrary packet streams is explicitly out of scope. Specify variants for IPv4 and IPv6, extent of IP packet available under encapsulation methods, and under packet encryption. 3. Sampled packet reports. Define the format of the report that is constructed by the network element for each sampled packet for communication to applications. The format shall be sufficiently rich as to allow inclusion in the packet report of (i) IP packet information as specified in paragraph 2 above; (ii) encapsulating packet headers as specified in paragraph 2 above; (iii) interface or channel identifiers associated with transit of the packet across the network element; (iv) quantities computable from packet content and router state, (v) quantities computed during the selection operation. All reported quantities must reflect the router state and configuration encountered by the packet in the network element. 4. Report Streams. Define a format for a stream of packet reports, to include: (i) the format of packet reports in the stream; (ii) the packet reports themselves; (iii) configuration parameters of the selectors of the packets reported on; (iv) configuration parameters and state information of the network element; (v) quantities that enable collectors and applications to infer of attained packet sampling rates, detect loss during samping, report loss in transmission, and correct for information missing from the packet report stream; (vi) indication of the inherent accuracy of the reported quantities, e.g., of timestamps. 5. Multiple Report Streams. Define requirements for multiple parallel packet samplers in one network element, including the allowed degradation of packet reporting when packets are selected by multiple packet samplers. 6. Configuration and Management. Define a packet sampler MIB to reside at the network element, including parameters for packet selection, packet report and stream format, and export. Select or define a communication protocol to configure/read this MIB. 7. Presentation, Export, and Transport of Packet Reports. Define interface for presentation of reports to on-board applications. Select unreliable transport protocol for remote export. Determine rate control algorithms for export. Initial Internet-Draft: A Framework for Passive Packet Measurement [draft-duffield-framework-papame] Internet-Drafts: No Current Internet-Drafts. Performance Metrics for Other Layers (pmol) ------------------------------------------- Charter Last Modified: 2008-08-21 Current Status: Active Working Group Chair(s): Al Morton Alan Clark Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion:pmol@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/pmol Archive: http://www.ietf.org/mail-archive/web/pmol/index.html Description of Working Group: The successful implementation and operation of IP based applications often depends on some underlying performance measurement infrastructure that helps service operators or network managers to recognize when performance is unsatisfactory and identify problems affecting service quality. Standardized performance metrics add the desirable features of consistent implementation, interpretation, no comparison. The IETF has two Working Groups dedicated to the development of performance metrics however each has strict limitations in their charters: - The Benchmarking Methodology WG has addressed a range of networking technologies and protocols in their long history (such as IEEE 802.3, ATM, Frame Relay, and Routing Protocols), but the charter strictly limits their Performance characterizations to the laboratory environment. - The IP Performance Metrics WG has the mandate to develop metrics applicable to the performance of Internet data delivery, but it is specifically prohibited from developing metrics that characterize traffic (such as a VoIP stream). The IETF also has current and completed activities related to the reporting of application performance metrics (e.g. RAQMON and RTCP XR) and is also actively involved in the development of reliable transport protocols which would affect the relationship between IP performance and application performance. Thus there is a gap in the currently chartered coverage of IETF WGs: development of performance metrics for IP-based protocols and applications that operate over UDP, TCP, SCTP, DCCP, Forward Error Correction (FEC) and other robust transport protocols, and that can be used to characterize traffic on live networks. The working group will focus on the completion of two RFCs: 1. A PMOL framework and guidelines memo that will describe the necessary elements of performance metrics of protocols and applications transported over IETF-specified protocols (such as the formal definition, purpose, and units of measure) and the various types of metrics that characterize traffic on live networks (such as metrics derived from other metrics, possibly on lower layers). The framework will also address the need to specify the intended audience and the motivation for the performance metrics. There will also be guidelines for a performance metric development process that includes entry criteria for new proposals (how a proposal might be evaluated for possible endorsement by a protocol development working group), and how an successful proposal will be developed. Also, it is recognized that there are applications and protocols that do not need to use this framework and can make use of simpler specific methods for determining performance. 2. A proof-of-concept RFC defining performance metrics for SIP, based on draft-malas-performance-metrics. This memo would serve as an example of the framework and the PMOL development process in the IETF. Discussion of new work proposals is strongly discouraged under the initial charter of the PMOL WG, except to advise a protocol development WG when they are evaluating a new work proposal for related performance metrics. The Working Group will work closely with the RAI and APPS areas, performing early review of the documents with the two areas and inviting their particpation in the WGLC. The PMOL WG will also be guided by a document describing how memos defining performance metrics are intended to advance along the IETF Standards track (draft-bradner-metricstest). PMOL WG will take advantage of expertise and seek to avoid overlap with other standards development organizations, such as ETSI STQ, ITU- T SG 12, ATIS IIF, ATIS PRQC, and others. Description of Working Group: The successful implementation and operation of IP based applications often depends on some underlying performance measurement infrastructure that helps service operators or network managers to recognize when performance is unsatisfactory and identify problems affecting service quality. Standardized performance metrics add the desirable features of consistent implementation, interpretation, no comparison. The IETF has two Working Groups dedicated to the development of performance metrics however each has strict limitations in their charters: - The Benchmarking Methodology WG has addressed a range of networking technologies and protocols in their long history (such as IEEE 802.3, ATM, Frame Relay, and Routing Protocols), but the charter strictly limits their Performance characterizations to the laboratory environment. - The IP Performance Metrics WG has the mandate to develop metrics applicable to the performance of Internet data delivery, but it is specifically prohibited from developing metrics that characterize traffic (such as a VoIP stream). The IETF also has current and completed activities related to the reporting of application performance metrics (e.g. RAQMON and RTCP XR) and is also actively involved in the development of reliable transport protocols which would affect the relationship between IP performance and application performance. Thus there is a gap in the currently chartered coverage of IETF WGs: development of performance metrics for IP-based protocols and applications that operate over UDP, TCP, SCTP, DCCP, Forward Error Correction (FEC) and other robust transport protocols, and that can be used to characterize traffic on live networks. The working group will focus on the completion of two RFCs: 1. A PMOL framework and guidelines memo that will describe the necessary elements of performance metrics of protocols and applications transported over IETF-specified protocols (such as the formal definition, purpose, and units of measure) and the various types of metrics that characterize traffic on live networks (such as metrics derived from other metrics, possibly on lower layers). The framework will also address the need to specify the intended audience and the motivation for the performance metrics. There will also be guidelines for a performance metric development process that includes entry criteria for new proposals (how a proposal might be evaluated for possible endorsement by a protocol development working group), and how an successful proposal will be developed. Also, it is recognized that there are applications and protocols that do not need to use this framework and can make use of simpler specific methods for determining performance. 2. A proof-of-concept RFC defining performance metrics for SIP, based on draft-malas-performance-metrics. This memo would serve as an example of the framework and the PMOL development process in the IETF. Discussion of new work proposals is strongly discouraged under the initial charter of the PMOL WG, except to advise a protocol development WG when they are evaluating a new work proposal for related performance metrics. The Working Group will work closely with the RAI and APPS areas, performing early review of the documents with the two areas and inviting their particpation in the WGLC. The PMOL WG will also be guided by a document describing how memos defining performance metrics are intended to advance along the IETF Standards track (draft-bradner-metricstest). PMOL WG will take advantage of expertise and seek to avoid overlap with other standards development organizations, such as ETSI STQ, ITU- T SG 12, ATIS IIF, ATIS PRQC, and others. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2008 Mar 2009 SIP End-to-End Performance Metrics Jul 2008 Mar 2009 Framework for Performance Metric Development RADIUS EXTensions (radext) -------------------------- Charter Last Modified: 2009-06-03 Current Status: Active Working Group Chair(s): Bernard Aboba David Nelson Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Technical Advisor(s): Paul Congdon Mailing Lists: General Discussion:radiusext@ops.ietf.org To Subscribe: radiusext-request@ops.ietf.org In Body: In Body: subscribe Archive: https://ops.ietf.org/lists/radiusext Description of Working Group: The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to define extensions to the standard attribute space as well as to address cryptographic algorithm agility and use over new transports. In addition, RADEXT will work on RADIUS Design Guidelines and define new attributes for particular applications of authentication, authorization and accounting such as NAS management and local area network (LAN) usage. In order to enable interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained. Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: - All documents produced MUST specify means of interoperation with legacy RADIUS and, if possible, be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090 and 5176. Transport profiles should, if possible, be compatible with RFC 3539. - All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible, new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. Work Items The immediate goals of the RADEXT working group are to address the following issues: - RADIUS design guidelines. This document will provide guidelines for design of RADIUS attributes. It will specifically consider how complex data types may be introduced in a robust manner, maintaining backwards compatibility with existing RADIUS RFCs, across all the classes of attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it will review RADIUS data types and associated backwards compatibility issues. - RADIUS Management authorization. This document will define the use of RADIUS for NAS management over IP. -RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes. -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally relied on MD5 for both per-packet integrity and authentication as well as attribute confidentiality. Given the increasingly successful attacks being mounted against MD5, the ability to support alternative algorithms is required. This work item will include documentation of RADIUS crypto-agility requirements, as well as development of one or more Experimental RFCs providing support for negotiation of alternative cryptographic algorithms to protect RADIUS. - IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. - New RADIUS transports. A reliable transport profile for RADIUS will be developed, as well as specifications for Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS. - Documentation of Status-Server usage. A document describing usage of the Status-Server facility will be developed. 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. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Aug 2007 May 2009 Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management Sep 2007 Mar 2009 RADIUS Design Guidelines Nov 2007 Mar 2009 Extended Remote Authentication Dial In User Service (RADIUS) Attributes Jun 2008 Mar 2009 TLS encryption for RADIUS over TCP (RadSec) Jun 2008 Mar 2009 Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol Dec 2008 Mar 2009 RADIUS Over TCP Jul 2009 Jul 2009 NAI-based Dynamic Peer Discovery for RADIUS over TLS and DTLS Audio/Video Transport (avt) --------------------------- Charter Last Modified: 2009-05-01 Current Status: Active Working Group Chair(s): Roni Even Tom Taylor Real-time Applications and Infrastructure Area Director(s): Robert Sparks Cullen Jennings Real-time Applications and Infrastructure Area Advisor: Cullen Jennings Mailing Lists: General Discussion:avt@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/avt Archive: http://www.ietf.org/mail-archive/web/avt/index.html Description of Working Group: The Audio/Video Transport Working Group was formed to specify a protocol for real-time transmission of audio and video over unicast and multicast UDP/IP. This is the Real-time Transport Protocol, RTP, together with its associated profiles and payload formats. The current aims of the working group are: - to review and revise existing payload formats to advance those which are useful to Draft Standard, and to declare others as Historic. Milestones will be established as a champion for each payload format is identified. - to develop payload formats for new media codecs, and to document best-current practices in payload format design. The group continues to be precluded from work on codecs themselves because of overlap with the other standards bodies, and because the IETF does not have the ability to effectively review new codecs. An exception was made for the freeware iLBC codec on a highly experimental basis, but acceptance of new codec work is unexpected and subject to rechartering. - to complete the forward error correction work to update RFC 2733 in the form of the ULP payload format - to extend RTP to work with Source-Specific Multicast sessions with unicast feedback - to provide a framing mechanism for RTP over TCP and TLS - in collaboration with the MPLS and ROHC WGs, to develop a solution for header compression of RTP across MPLS networks that avoid decompression and compression at each MPLS node. - to develop a new RTP profile for the combination of the SRTP profile and the Extended RTP Profile for RTCP-based Feedback (RTP/SAVPF) - to maintain and enhance the SRTP Profile, with review and input from the Security Area - to develop a new RTP profile for usage of TFRC (RFC 3448) with RTP over UDP to allow application developers to gain experience with TCP friendly congestion control. - to develop a MIB for RTCP XR (RFC 3611). - to update the RTP MIB, including aligning it with RFC 3550. - to clarify how RTP is used for media in conferencing with centralised nodes performing relay, translation or mixing of media. - to develop the mechanisms needed for efficient control of media and its encoding process in RTP based conferencing, both over multicast and transport containing relays, translators and mixers. An example of such a mechanism is a method to request a full intra coded frame of video. This would be used to allow joining participants to receive video immediately after joining instead of waiting for the next intra coded frame. It also allows mixers to perform switching between media sources without the need to re-encode the media. - to develop a solution for carrying media meta data, specifically SMPTE timestamps, to enhance the media stream. Such transport may be done in either RTP or RTCP depending on which is most suitable. The WG may consider if a generalized mechanism should be developed to enable future types of meta data to be easier to include. - to develop two new metric blocks for the RTCP XR (RFC 3611) framework to provide information on the media quality experienced by the receiver of RTP flows. One metrics block is for high resolution measurements of audio and speech quality. A second one for providing information on the quality of video. The timescale to complete this second block and the included metrics are highly dependable on the development of standardized subjective metrics for video quality. The WG will consider what metrics that are available and if they should be included or not. The metrics blocks shall not duplicate signalling information anyway necessary for the establishment of the session. - to specify how the RFC 3550 requirement on RTCP senders to always send compound packets can be relaxed to allow for non-compound packets. The specification need to define under which criteria non-compound RTCP packets may be sent while maintaining the functionality that motivated the usage of compound RTCP packets and keep the bandwidth within specified limits. The longer term goals of the working group are to advance the SRTP Profile, the Extended RTP Profile for RTCP-based Feedback, the Compressed RTP framework, and the RTP MIB to Draft Standard. The group has no plans to develop new RTP profiles beyond those listed above, but will consider rechartering to produce profile level extensions if appropriate. Description of Working Group: The Audio/Video Transport Working Group was formed to specify a protocol for real-time transmission of audio and video over unicast and multicast UDP/IP. This is the Real-time Transport Protocol, RTP, together with its associated profiles and payload formats. The current aims of the working group are: - to review and revise existing payload formats to advance those which are useful to Draft Standard, and to declare others as Historic. Milestones will be established as a champion for each payload format is identified. - to develop payload formats for new media codecs, and to document best-current practices in payload format design. The group continues to be precluded from work on codecs themselves because of overlap with the other standards bodies, and because the IETF does not have the ability to effectively review new codecs. An exception was made for the freeware iLBC codec on a highly experimental basis, but acceptance of new codec work is unexpected and subject to rechartering. - to complete the forward error correction work to update RFC 2733 in the form of the ULP payload format - to extend RTP to work with Source-Specific Multicast sessions with unicast feedback - to provide a framing mechanism for RTP over TCP and TLS - in collaboration with the MPLS and ROHC WGs, to develop a solution for header compression of RTP across MPLS networks that avoid decompression and compression at each MPLS node. - to develop a new RTP profile for the combination of the SRTP profile and the Extended RTP Profile for RTCP-based Feedback (RTP/SAVPF) - to maintain and enhance the SRTP Profile, with review and input from the Security Area - to develop a new RTP profile for usage of TFRC (RFC 3448) with RTP over UDP to allow application developers to gain experience with TCP friendly congestion control. - to develop a MIB for RTCP XR (RFC 3611). - to update the RTP MIB, including aligning it with RFC 3550. - to clarify how RTP is used for media in conferencing with centralised nodes performing relay, translation or mixing of media. - to develop the mechanisms needed for efficient control of media and its encoding process in RTP based conferencing, both over multicast and transport containing relays, translators and mixers. An example of such a mechanism is a method to request a full intra coded frame of video. This would be used to allow joining participants to receive video immediately after joining instead of waiting for the next intra coded frame. It also allows mixers to perform switching between media sources without the need to re-encode the media. - to develop a solution for carrying media meta data, specifically SMPTE timestamps, to enhance the media stream. Such transport may be done in either RTP or RTCP depending on which is most suitable. The WG may consider if a generalized mechanism should be developed to enable future types of meta data to be easier to include. - to develop two new metric blocks for the RTCP XR (RFC 3611) framework to provide information on the media quality experienced by the receiver of RTP flows. One metrics block is for high resolution measurements of audio and speech quality. A second one for providing information on the quality of video. The timescale to complete this second block and the included metrics are highly dependable on the development of standardized subjective metrics for video quality. The WG will consider what metrics that are available and if they should be included or not. The metrics blocks shall not duplicate signalling information anyway necessary for the establishment of the session. - to specify how the RFC 3550 requirement on RTCP senders to always send compound packets can be relaxed to allow for non-compound packets. The specification need to define under which criteria non-compound RTCP packets may be sent while maintaining the functionality that motivated the usage of compound RTCP packets and keep the bandwidth within specified limits. The longer term goals of the working group are to advance the SRTP Profile, the Extended RTP Profile for RTCP-based Feedback, the Compressed RTP framework, and the RTP MIB to Draft Standard. The group has no plans to develop new RTP profiles beyond those listed above, but will consider rechartering to produce profile level extensions if appropriate. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2002 Mar 2009 RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback Aug 2004 May 2009 RTP Payload Format for Adaptive TRansform Acoustic Coding (ATRAC) Family Aug 2005 Apr 2009 RTP Payload Format for ITU-T Recommendation G.722.1 May 2006 Mar 2009 How to Write an RTP Payload Format Oct 2006 Aug 2007 Multiplexing RTP Data and Control Packets on a Single Port Dec 2006 Mar 2009 RTP Payload Format for SVC Video Jan 2007 Feb 2009 RTP Payload Format for MIDI May 2007 Mar 2009 RTP Payload Format for DV (IEC 61834) Video May 2007 May 2009 RTP payload format for mU-law EMbedded Codec for Low-delay IP communication (UEMCLIP) speech codec Jun 2007 Jun 2009 Application Mechanism for maintaining alive the Network Address Translator (NAT) mappings associated to RTP flows. Jul 2007 Feb 2009 Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP) Oct 2007 Jun 2009 The SEED Cipher Algorithm and Its Use with the Secure Real-time Transport Protocol (SRTP) Dec 2007 Mar 2009 RTP Payload Format for H.264 RCDO Video Apr 2008 May 2009 RTP Payload Format for SPIRIT IP-MR Speech Codec Jul 2008 Jun 2009 Post-Repair Loss RLE Report Block Type for RTCP XR Jul 2008 Jan 2009 RTP Payload Format for Elementary Streams with MPEG Surround multi- channel audio Jul 2008 Mar 2009 Guidelines for Extending the RTP Control Protocol (RTCP) Jul 2008 Mar 2009 Why RTP Does Not Mandate a Single Security Mechanism Oct 2008 May 2009 RTP Payload Format for H.264 Video Oct 2008 Apr 2009 RTP payload format for G.718 speech/audio Oct 2008 May 2009 RTCP XR Report Block for Concealed Seconds metric Reporting Oct 2008 May 2009 RTCP XR Report Block for Delay metric Reporting Oct 2008 May 2009 RTCP XR Report Block for Discard metric Reporting Oct 2008 May 2009 RTCP XR Report Block for Jitter Buffer Metric Reporting Oct 2008 May 2009